Email and WhatsApp are communication tools, not a verification workflow

Email and WhatsApp are excellent at what they are for. They are fast, everyone already has them, and a client who will ignore a portal invitation for a week will answer a message in four minutes. None of that is the problem, and an article telling you to stop using them would be ignored for good reason.

The problem is narrower and more awkward. A conversation is a very good way to ask for something and a very poor way to hold the answer, and verification work produces answers that have to be held.

See how UMNIII Verify keeps a request and its evidence in one record

---

What a thread is good at, and what it is not

The distinction is between a channel and a record. A channel moves a message from one person to another and then its job is finished. A record has to still be true, findable and complete months later, when the person who created it has moved on and somebody else is being asked a question about it.

Verification work generates the second kind of thing while being conducted almost entirely through the first:

• A document arrives as an attachment and can remain in a mailbox rather than in the business's case record.
• The question that document answers was asked three messages earlier, and the two are never joined except in the head of whoever read both.
• Someone saves the useful attachments to a shared folder, named by whatever made sense that afternoon, and the folder slowly becomes a second system nobody maintains.
• A judgement gets made in a reply, in a sentence, and is never recorded as a decision anywhere.
• A spreadsheet appears to track who has sent what, and is accurate until the first week somebody is busy.
• The same request is made twice by two colleagues, because the only way to know it was already made is to have read the thread.

None of this is a failure of the tools. It is a mismatch. The work needs a record and the channel produces a conversation, so somebody has to convert one into the other by hand, and that conversion is where everything is lost.

---

What it actually costs

These are operational costs rather than regulatory ones, and they are easy to underrate because none of them produces an incident. Nothing goes wrong in a way anybody reports. The cost is spread thinly across every file and every colleague, which is precisely why it survives: there is no moment at which somebody decides to pay it.

• Context goes missing. The document survives and the reason it was requested does not, so a reviewer a month later can see what arrived but not what question it was meant to answer.
• Requests are duplicated. Not through carelessness, but because checking whether something was already asked costs more than asking again.
• Onboarding varies by whoever ran it. Two clients of the same type get different lists in different orders, and nobody notices until the two files are compared.
• Evidence is incomplete in ways that are invisible. A file missing one item looks exactly like a file missing nothing until somebody goes through it.
• Handovers lose the half that was never written down. What a colleague concluded, and why, usually travels with the colleague.
• Nobody can say what is outstanding. Not across the desk, and often not for a single case, without reading back through a conversation.
• Showing the work becomes a project. When a client, an auditor or a regulator asks what was checked and when, the answer is assembled rather than produced.
• The administration is quietly enormous. Chasing, re-reading, re-filing and reconstructing are not billable and do not appear on any report, which is exactly why they persist.

---

Why another spreadsheet does not fix it

The usual first response is a tracker. A sheet with a row per client and a column per item, ticked as things arrive. It helps, briefly, and then it does not, and the reason is worth understanding because it explains why the third tracker fails as well as the first.

A spreadsheet used only as a tracker records a status. By itself, it does not run the surrounding process. Those sound similar and behave nothing alike.

• A status has to be entered by somebody. The tick is a second, manual act after the real one, so the sheet is only ever as current as the last person who remembered. The work and the record of the work are two jobs, and the second gets dropped first.
• A tick is not evidence. "Passport received" in a cell is a claim about a file somewhere else. It proves nothing on its own, and when somebody asks to see the passport the search starts again.
• A standalone tracker does not ask anybody for anything. The sheet knows an item is missing and cannot do anything about it, so the chasing is still manual, still dependent on memory, and still inconsistent between colleagues.
• A manual tracker cannot enforce the list without workflow or automation around it. Nothing stops a consultant asking for five of the seven things, and the sheet will show five green cells and two blanks that nobody reads as a problem.
• It drifts. Columns are added for one awkward case and never removed, two versions appear, and within a quarter the authoritative copy is whichever one the person speaking last had open.

A tracker is a report about a process. If the process underneath is a set of messages, the tracker is a report about a set of messages, and it inherits every weakness it was bought to fix.

This is not an argument against spreadsheets, which are good at what they are for in the same way messaging apps are. It is an argument against expecting one to carry a process it has no way to run.

---

What the alternative looks like

The shape that works is not more discipline applied to the same tools. It is making the asking and the recording the same action:

• One request per party, carrying everything. The questions, the document requests and whichever checks you selected go out together, so the person receiving it does it once.
• The answer lands against the question. Not in an inbox, not in a folder named by date, but attached to the thing that asked for it, so context cannot be separated from evidence later.
• Status is a by-product, not a chore. If completing the work updates the record, nobody has to maintain a second tracker, and the status comes from the request itself rather than a separate manual tick.
• The list is settled once per type of party. So two clients of the same kind get the same request, and a variation is a decision rather than an accident.
• One organised record at the end. Available to an authorised colleague, including someone who was not involved in the original exchange.

Messages still have a place in this. A client who has not responded will still be nudged on WhatsApp, and that is fine. The difference is that the message points at the request rather than carrying the work.

---

How UMNIII Verify helps

UMNIII Verify is built around that single request: you choose the documents, questions and checks a party needs, send one branded link, and the person completes it on their phone. Everything comes back to one record your team can search, reopen and download from.

• The list is composed once. Ready-made question sets, your own custom forms, and forms published by the Verify community, plus document requests, all saved as reusable templates.
• The checks you select, per request. Identity verification, AML screening, business verification and UK residential records, chosen for the party in front of you rather than applied to everyone.
• Status without a tracker. Progress on every request, so one that has stalled is visible rather than forgotten, with optional reminders that follow up automatically while a request is still outstanding, and the ability to nudge a particular person or resend a request that never arrived.
• The record belongs to the business. Work lives in a shared Workspace with members, roles and shared credits rather than in an individual's mailbox, so colleagues you invite see the same requests and the same history.
• One file at the end. One branded evidence pack per request, carrying its history, the available supporting evidence, the results and the submitted forms, with individual documents, form-response PDFs and AML reports available separately.

What it does not do is decide anything. Verify supports your firm's process and evidences it: it does not tell you whether to accept a client, a tenant, a supplier or a candidate, it does not make your compliance decisions, and a possible screening match is a record that resembles someone rather than a finding about them. It also does not make a firm compliant. It makes the work visible, which is a different and more modest claim.

It is worth being equally plain about what remains manual. Anything requiring a third party, an awarding body, a referee, a statutory process or an authorised provider is still your firm's work to complete through those channels.

---

Where to start

Pick the party type you onboard most often and open the last three files for it. Write down what was asked in each. If the three lists differ, and they usually do, the gap between them is the thing to fix first, and the combined list is your template.

See how UMNIII Verify handles structured requests

For how this looks in a particular sector, we have written about it for UAE company-formation and corporate-service providers onboarding clients, for finance and compliance teams verifying suppliers, for real-estate businesses verifying buyers and tenants, and for recruitment agencies onboarding candidates.

---

This article is general information about operational process. Nothing here is legal, tax or compliance advice, and nothing in it says that email or messaging apps are unsafe, prohibited or non-compliant: which channels and controls are appropriate for your firm depends on your obligations, your data-protection position and your sector, and those should be confirmed with a qualified adviser.