Skip to content
allanninal.dev/build
Collaborate

Part 2 of 7 · Background check chaser series ~5 min read

How a starter’s checks get created

Almost all of the value in this system comes from a decision made in the first second of a starter’s existence: how many things to track, and who owns each. Get that wrong and everything downstream is chasing the wrong person about the wrong item.

Key takeaways

  • The checks come from the role, not from the company. A driver needs things an office hire does not.
  • Each item gets exactly one owner, and the owner is whoever can make it move.
  • Some checks must not be created on day one; they depend on an earlier one completing.
  • The expected duration is a property of the check type, revised from your own history.
  • A starter with no start date yet is tracked, but nothing is predicted or chased.

The check list, per role

CheckOwnerUsual durationApplies to
Reference 1The referee5 daysEveryone
Reference 2The referee5 daysEveryone
Right to workThe candidate2 daysEveryone
Standard disclosureThe screening agency18 daysRoles with a requirement
Licence checkThe candidate3 daysDrivers
MedicalThe clinic21 daysDrivers, some site roles
Professional registrationThe candidate4 daysRegulated roles

The owner column is the one that matters and the one most systems get wrong by defaulting everything to the candidate. A reference is owned by the referee: they are the only party who can produce it. Recording that means chasing lands where it can do something, which is covered in Part 5.

Creating the items

How a new starter's checks are created as separate tracked itemsA vertical chain of five steps entered by a box labelled Offer accepted, carrying a role and a start date. Step one asks which checks apply, taken from the check list per role and per type. Step two asks who owns each, being the referee, the candidate or the agency; an unknown owner exits to Ask for a referee, which the candidate supplies. Step three asks whether each check can start now, since some depend on others; a blocked check exits to Hold it, created but not started. Step four requests and records each check with its requested and expected dates in a DynamoDB checks table, one item each. Step five is Clocks running, independently. A note says held items exist from day one so that the plan is honest about what has not started.AWS ACCOUNTOffer acceptedrole and start dateWhich checks apply?from the roleCheck listper role, per typeWho owns each?referee, candidate, agencyAsk for a refereecandidate suppliesunknownCan it start now?some depend on othersHold itcreated, not startedblockedRequest and recorddate requested, expectedDynamoDB checksone item eachClocks runningindependentlyHeld items exist from day one, so the plan is honest about what has not started.
Fig 1. How an accepted offer becomes a set of independent items. Items that cannot start yet are created and held rather than being invisible, so the plan reflects the whole sequence.
  • Database
  • App integration
  • Machine learning
  • Management
  • Analytics
  • People

Checks that must wait

Some checks cannot be requested until another has completed, and creating them as running clocks on day one produces a plan that is quietly wrong. A disclosure usually cannot be submitted until identity has been verified. A medical is often only booked once an offer is unconditional.

So those items are created immediately and held. They appear in the plan with a dependency — “disclosure: waiting on identity verification” — and their clock starts when the blocker clears. The predictor accounts for both durations, which is what makes it possible to say on day one that a twenty-eight-day start date is already unrealistic.

Where a referee comes from

Almost the only thing the candidate is asked for directly, and it is worth asking for it well: a name, a relationship and an email address, twice. The most common cause of a late reference is not a slow referee; it is a reference request sent to a shared recruitment address at a company where nobody owns it. A named individual with a direct address halves the typical turnaround.

Expected durations

The duration on each check type starts as a guess and should be replaced by your own history within a few months. The system records how long each completed check actually took, and the median for a type is a far better expectation than anything an agency’s brochure claims.

Median durations for four check types, and what they implyA horizontal row of five boxes. Reference: median six days. Right to work: median one day. Disclosure: median twenty-two days. Medical: median twenty-six days. Slowest wins: the start date follows the slowest check. A note says the last box is the whole planning insight, because the slowest check sets the earliest realistic start.YOUR OWN DURATIONS, NOT THE BROCHURE'SReferencemedian 6 daysRight to workmedian 1 dayDisclosuremedian 22 daysMedicalmedian 26 daysSlowest winsthe start date follows itThe last box is the whole planning insight: the slowest check sets the earliest start.
Fig 2. Real durations from your own completed checks. The last box is the fact that makes offer conversations honest: the earliest realistic start is set by the slowest item.
  • App integration
  • Security & identity
  • Management
  • Analytics

That last observation is worth acting on before any chasing happens. If your medical median is twenty-six days and somebody agrees a three-week start date for a driver, no amount of chasing will fix it, and the honest thing is to say so on the day the offer is accepted rather than on the Friday before.

Next: how a status update arrives without dragging a result along with it.

All posts