An employment verification request arrives in one of three unhelpful shapes. A lender faxes a form with twenty boxes, half of which ask for information no policy allows releasing. A former employee emails a manager directly, and the manager writes a warm paragraph from a personal account. A screening company sends an automated request with a reference number and a deadline, addressed to nobody in particular.
The person handling these has two risks pulling in opposite directions. Answer too slowly and somebody loses a flat or a job offer. Answer too freely and salary history, dates that contradict what the candidate told a new employer, or an offhand remark about performance leaves the building in writing. An intake form is the tool that resolves that tension, because it decides in advance what gets confirmed, to whom, and on what authority.
Who is asking, and what each one actually needs
Most verification processes break because they treat one category of request as if it were all of them. The four categories behave differently.
| Who is asking | What they usually want | What makes it legitimate | Typical urgency |
|---|---|---|---|
| The employee or former employee | A letter they can forward themselves | They are asking about their own record | Days |
| A lender, landlord or insurer | Dates, title, sometimes income | An authorisation signed by the individual | Days, with a stated deadline |
| A background screening company | Dates and title, occasionally reason for leaving | A release signed by the applicant, held by the requester | Hours to days |
| A government or court body | Whatever the instrument specifies | The instrument itself | Fixed by the notice |
Two design conclusions follow. The first is that the form should ask who is asking as its first question, then show a different set of fields for each answer. A single flat form that suits all four asks a lender for a case reference and asks a former employee for an authorisation they do not need.
The second is that the fastest possible path is the one where the individual requests their own letter. A letter addressed to the person, sent to the address on record, which they then forward to the lender themselves, removes the authorisation question entirely and takes minutes. Steering as much traffic into that path as possible is the single largest reduction in workload available, and it is a wording change on a public page rather than a project.
What gets confirmed, and what does not
The tight version of a verification policy is short enough to remember. Most organisations settle on confirming that employment existed, the dates it covered, and the job title held. Everything beyond that is a decision, not a default.
Compensation. Released only against a signed authorisation from the individual that names income as something that may be disclosed. Some jurisdictions restrict asking about salary history at all, which is a reason to confirm current pay against an authorisation rather than to supply a history nobody has asked for.
Reason for leaving. Most policies decline this in writing. A single word in the wrong column turns a routine confirmation into something the former employee will dispute.
Eligibility for rehire. Frequently requested and rarely safe to answer, because it is a judgement dressed as a fact.
Performance, attendance, disciplinary history. Outside the scope of verification. A request for these is a reference request, which is a different process with different approvals.
Hours worked or full time status. Often needed for benefits and loan purposes, and usually fine to confirm as a fact from the payroll record rather than as an estimate from a manager.
There is one case the list does not cover: the dates in the payroll record disagree with the dates the individual gave their new employer. The record is what gets confirmed, and the discrepancy is not something to explain, soften or annotate on behalf of the person. The defensible handling is to confirm what is held, note in the internal record that a discrepancy was visible, and, where the request came from the individual, let them see the dates before anything goes to a third party. Adding commentary to reconcile the two is how a routine confirmation turns into a dispute with the employer in the middle of it.
Write that list once, publish it on the page that carries the form, and the volume of out of scope requests drops on its own. Requesters are not trying to extract information; they are filling in whatever their own template asks for.
The authorisation is the gate, so treat it as a field
For every request that does not come from the individual, one artefact decides whether a reply can be sent: written authorisation from the person whose record is being discussed. A verification process that treats it as an attachment somebody remembers to check is the process that eventually replies without one.
Four things make an authorisation usable rather than decorative.
It names the individual and is signed and dated by them. An authorisation with no date has no end.
It states what may be released. A general release is weaker than one that says dates, title and income, because the person reading it later has to guess at intent.
It names the party who may receive it. The request in hand should come from that party, at a domain that matches.
It is recent. A release signed two years ago for a different application is not authority for today's request. Choosing a maximum age and applying it consistently is more defensible than judging case by case.
Practically, this means the file upload for the authorisation should be a required field for the requester types that need one, enforced by the form rather than by a sentence asking politely. Conditional requirements do this work reliably, and they remove the most common reason a verification request sits for three days before anyone notices it is incomplete.
Electronic signatures are normal here. What matters is that the record identifies the person who signed and shows their approval, which is also why a typed name in a text box on a third party's own form is the weakest version in circulation.
The fields on the intake form
A verification intake form that fits on two screens looks roughly like this.
Shown to everybody:
- Who is making this request, as the first choice
- Name of the individual whose employment is being verified, as recorded by the employer rather than as currently used
- Employee identifier or last four digits of a national identifier, where policy permits
- Approximate dates of employment, which is the cheapest check against a request about the wrong person
- What is being asked for, as a checklist limited to what policy allows
- Where the reply should be sent
- Deadline, if the requester has one
Shown to third party requesters only:
- Requesting organisation and the individual handling it
- Case or reference number
- Authorisation document, required
- Purpose of the request, from a short list
Shown to the individual only:
- Confirmation of identity against the record, rather than an authorisation
- Who the letter should be addressed to, if a named addressee is required
One field deserves special attention: where the reply is sent. A reply address typed into a form by an unknown requester is the weak point of the entire process. The safer pattern is to send to a domain that matches the requesting organisation, or to send the letter to the individual and let them pass it on. A request from a free mail account, on behalf of an organisation, is worth a phone call to a number found independently rather than to the number on the request.
Turnaround, and the queue behind it
Verification requests have an external clock. A mortgage application, a tenancy, a start date: somebody downstream is waiting, and the requester will chase by phone if nothing is heard.
Three practices absorb most of that pressure.
A published turnaround. Two working days, three, five: the number matters less than stating it on the form and in the automatic acknowledgement. Most chasing calls come from silence rather than from delay.
An owner on every request. Verification work is bursty and frequently handled by whoever is free, which is exactly the condition under which two people answer the same request differently or nobody answers it at all.
Stages that mirror the real path. Received, waiting on authorisation, waiting on payroll data, ready to send, sent, declined as out of scope. A filter on "waiting on authorisation" is the report that prevents the requests that go quiet.
Requests that arrive outside the form need a route back into it. A manager who receives a call should be able to point at one page rather than answering from memory, and the request that arrived as an email to a shared mailbox should be entered into the same queue rather than answered in the thread. Otherwise the record of what the organisation said about a former employee is scattered across individual mailboxes, which is the situation that becomes expensive when somebody disputes what was confirmed.
The reply, and the record of it
The output of a verification request is a short letter, and it should be assembled from a template rather than written each time. Dates, title and, where authorised, compensation, dropped into fixed wording by variables. Nothing about performance, nothing conversational, and a named contact for follow up questions rather than an individual manager's direct line.
What matters as much as the letter is the record that it was sent. The question asked months later is never "what is the policy". It is "what exactly was confirmed about this person, to whom, and on what date". A reply sent from a personal mail client answers that question badly. A reply sent from the same screen that holds the request, with the send recorded against the record and the authorisation attached to it, answers it in one search.
This is the reason a verification queue tends to outgrow a shared mailbox faster than other intake processes. The volume is manageable; the requirement to reconstruct the history is not. A form tool with response management keeps the request, the authorisation, the stage, the letter and the send in one place, which is also what makes it possible to hand the process to a colleague for a fortnight without a handover document. The same shape of work appears across other kinds of intake a small team runs, which is why these queues usually end up in one tool rather than several.
What to change first
Put one question at the top of the form asking who is making the request, and branch from it, so a former employee is never asked for an authorisation and a lender can never skip one. Then publish what is confirmed and what is not, next to the form, in five lines.
After that, make the authorisation a required upload for third party requests and give every submission an owner and a stage. A queue where the request, the authorisation and the letter that went out all sit together is what turns this from a recurring risk into routine work, and Halict can be tried on a month of requests before any commitment.
Q1. What should an employment verification request form ask for?
Who is making the request, the name of the individual as recorded by the employer, an identifier or partial identifier where policy allows, approximate dates of employment, exactly what is being asked for, and where the reply should go. Third party requesters additionally need to supply their organisation, a reference number and the individual's signed authorisation as an upload.
Q2. Is written authorisation always required?
Not when the individual is asking about their own employment, and not when a legal instrument compels the disclosure. For every other third party request, a dated authorisation signed by the individual, naming what may be released and who may receive it, is what makes a reply defensible. Treating it as a required field rather than a courtesy is what keeps that consistent.
Q3. Should salary be confirmed?
Only against an authorisation that names compensation, and only as the fact held in the payroll record rather than as a history nobody requested. Some jurisdictions restrict what may be asked about pay, so the safe default is to confirm the narrow point the authorisation covers and nothing beyond it.
Q4. How fast do these requests need to be answered?
Faster than the requester's own deadline, which is usually days rather than weeks because a loan or a start date depends on it. Publishing a turnaround time on the form and acknowledging every submission automatically removes most of the chasing, since the calls are generally caused by silence rather than by the wait itself.
Q5. Can a manager answer a verification request directly?
It is the most common way an organisation says something it cannot later defend. A single route, a template letter and a named contact protect both the manager and the former employee. Where a manager is approached directly, the useful response is to point at the form rather than to answer from memory.