Candidate verification without the email chase: a better workflow for recruitment agencies

A consultant places a candidate on Thursday. The identity document came in on Monday, photographed at an angle. The right-to-work evidence was handled in a separate process and only summarised in the CRM afterwards. Two references were promised and one arrived. The qualification certificate is somewhere in a thread with the salary negotiation in it.

Nothing there is negligent. It is what happens when onboarding a candidate is twelve small asks spread across a fortnight, each made by whoever happened to be speaking to them at the time.

See how UMNIII Verify keeps candidate requests and their documents in one record

---

Why the chase happens

Recruitment collects more about a person than most onboarding processes, and it collects it from someone who is simultaneously being sold to. That tension shapes the whole thing:

• Identity documents arrive on whatever the candidate has to hand, usually a phone, often as a photograph of a screen rather than a scan.
• The CV arrives first and sets expectations, but it is a claim rather than evidence, and the evidence comes later or not at all.
• Declarations about notice periods, restrictive covenants, visa status or other role-specific matters are asked verbally during a call, because that is when the conversation naturally reaches them, and recorded afterwards from memory.
• Referee details are given by the candidate, and the agency then chases a third party who has no reason to hurry and no relationship with it.
• Qualification certificates are promised, forgotten, and asked for again a week later by a different consultant.
• Contractors bring a limited company, which means a second set of documents entirely.
• The candidate is asked for the same thing twice by two people, and concludes the agency is disorganised.

By the time a client asks what you hold on a shortlisted candidate, the answer exists in six places and nobody is quite sure it is complete.

---

What it costs

These are commercial and operational consequences rather than regulatory ones. Where a specific obligation applies to your agency, your sector or the roles you place, that is a matter for your own adviser, and this article does not attempt to settle it.

• Inconsistencies surface late. A name that does not quite match between a passport and a payroll record is usually a middle name or a marriage, and it is a five-minute conversation in week one and an awkward one the day before a start date.
• Claims need checking that nobody scheduled. A qualification or an employment date that needs following up is work, and discovering it at offer stage means doing that work against a deadline.
• A candidate progresses further than they should have. Not through anyone's fault, but because the question that would have surfaced it was asked late, asked informally, or asked and not written down.
• Placements slip. A start date that moves because a document is missing costs the margin on the delay and some of the client's patience.
• Client confidence erodes quietly. An employer who has to ask twice what checks you ran forms a view, and they rarely say so.
• The same administration is repeated. Chasing, re-reading threads, rebuilding a picture that should have assembled itself.
• Handovers lose context. When a consultant leaves or goes on holiday, what they concluded about a candidate rarely travels with the file.
• Candidates get different experiences. Two people applying for similar roles are asked for different things in a different order, which is a fairness problem as much as an efficiency one.

Individually these are small. What makes them expensive is that they compound across a desk: every consultant absorbs a little of the same overhead on every candidate, and none of it appears on a report anywhere. The agencies that notice usually notice through the client, when an employer asks a question the file cannot answer quickly.

---

One request, decided once per role type

The fix is not to ask for more. It is to decide what a given type of engagement needs, once, and then send that rather than improvising:

• Settle the list per role type, not per candidate. A permanent placement, a contractor working through their own company and an executive search need different things. Three lists, agreed once, covers most agencies.
• Combine the checks, the questions and the documents in one ask. The identity check, the structured declarations and the uploads belong together, because they are evidence of the same decision and they are easier for the candidate to complete in one sitting.
• Make the questions structured. A notice period captured in a field is searchable and comparable. The same answer in an email is neither.
• Let the candidate complete it on their phone. That is where the documents already are, and it is the difference between a request done that evening and one done next week.
• Watch what is outstanding rather than remembering it. A candidate who has done four of six items is a different situation from one who has not started.
• Keep the result with the request. So the file can be produced when a client asks, by whoever is available.

Role-appropriate is doing some work in that first point, and it is worth being explicit about what it means. It does not mean asking everyone for everything. A warehouse temp and a finance director in a regulated firm are not the same onboarding problem, and treating them as one produces either a request that is intrusive for the first or thin for the second. Deciding the list per role type is what lets you be proportionate without improvising, because the thinking happens once, in advance, rather than per candidate under time pressure.

It also makes the request explainable. When a candidate asks why you need something, a list that was reasoned through has an answer, and a list assembled ad hoc usually does not.

---

How UMNIII Verify helps

UMNIII Verify is built around that single request: you choose the documents, questions and checks a candidate 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.

• One reusable request per role type. Ready-made question sets, your own custom forms, and forms published by the Verify community, plus document requests, all saved as reusable templates. The permanent, contractor and executive intakes are each composed once rather than rebuilt per candidate.
• The checks you select, where the role warrants them. Identity verification, with a government-issued document checked for authenticity and matched against a live selfie, and liveness confirming a real person is present. UK residential records, confirming a UK residential address against a records source. AML screening against sanctions, watchlist and politically exposed person data where a role or sector makes it appropriate. Business verification for a contractor's limited company or for an employer you are onboarding as a client.
• Structured answers, not prose. Your own questions, asked the same way every time, so a notice period or a visa status comes back as an answer in a field rather than a sentence in a reply.
• Nothing chased from memory. 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.
• A handover is a change of who is looking. Work belongs to a shared Workspace with members, roles and shared credits rather than to an individual, so colleagues you invite see the same requests and the same history.
• One file per candidate. 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.

Your logo, name and colours carry across the request the candidate receives, the emails Verify sends and the documents it generates, which matters when you are asking someone for a passport before they have signed anything.

One boundary matters more than any feature here, and it is worth stating in full rather than by implication. UMNIII Verify does not perform right-to-work checks, DBS or criminal-record checks, credit checks, employment-history verification, or qualification or reference verification. Identity verification confirms identity through the supported identity process; it is not, by itself, a right-to-work determination, and it should not be read as one.

Verify's role is narrower: it can collect the documents, declarations, structured answers and candidate-supplied referee details your agency lawfully chooses to request. Those materials are submitted against the candidate's request alongside any supported Verify checks selected for that request. Verify does not contact a referee and does not validate what a referee says. A reference arrives as information the candidate supplied or a document they uploaded, not as a reference independently obtained by the product.

So the separate work remains separate. Confirming that a degree was awarded, that a previous employer agrees with the dates, that a person has the right to work, or anything else requiring a statutory process, a referee, an awarding body or an authorised provider, is completed by your agency or the employer through those channels. Nothing in Verify replaces them, and a candidate's own declaration is not a substitute for a check somebody else is authorised to carry out.

The same applies to the decision. Your agency chooses which checks are appropriate for a role, and reviews what comes back. Verify supports that process and evidences it. It does not decide whether a candidate is suitable, honest or placeable, and a possible screening match is a record that resembles someone rather than a finding about them.

---

Where to start

Take the role type you fill most often and write down everything you ask a candidate for, in the order you would want it. That list, written once, is the template. The next candidate gets one request instead of nine messages, and the one after that gets the same request rather than a slightly different one.

See how UMNIII Verify handles candidate onboarding

For contractors operating through a limited company, or for onboarding an employer as a client, the KYB and company verification page covers what a registry lookup returns and where supporting documents fill the gaps. Where a role or sector makes screening appropriate, the AML and adverse-media page sets out what it does and does not establish.

---

This article is general information for recruitment businesses and the teams that support them. Nothing here is legal, employment or compliance advice. Which checks are appropriate, and which are required, depends on the role, the sector, the jurisdiction and your own obligations as an employer or agency, and those should be confirmed with a qualified adviser rather than inferred from an article.