Zero Touch Onboarding

1. The moment before the first payslip

We have been building a category under the “Zero” prefix, and each piece takes an artefact of an older operating model and treats it as optional. Zero UI removed the interface as the bottleneck. Zero Touch Payroll removed the calendar. This piece is about the moment before payroll ever runs: onboarding — the letters, the documents, and the chase that stands between an agreed hire and their first payslip.

The worked example is a real build for a global energy & engineering workforce firm that operates in 45+ countries and onboards contractors continuously — the same organisation behind the seven-agent timesheet pipeline. At their scale, onboarding is not a form a new hire fills in once. It is a steady stream of offer and assignment letters, each assembled from an assignment record, each needing the right terms, the right region-specific clauses, an internal approval, and a countersignature — before anyone can be paid.

Done by hand, that stream is a document factory: someone reads an assignment, picks a template, fills it in, sends it for approval, chases the approver, issues it to the contractor, chases the contractor, files the signed copy, and updates the source system. Multiply by a country's worth of hires a week, across dozens of countries, and the cost is not any single letter. It is the rework.

Onboarding has its own cut-off date: the moment the wrong letter is already in the contractor's inbox.

2. The re-issue chase

The single most expensive event in onboarding automation is a letter that goes out wrong. A missing notice period, a rate in the wrong currency, an end date before the start date, a region-specific clause that should have been there and wasn't — any of these, caught after the document is already with the contractor, triggers the same costly sequence: withdraw the letter, regenerate it, route it for approval again, re-issue it, and chase a second signature from a person who now trusts the process a little less.

The same error, caught one stage earlier — before a template was ever opened — costs a single prompt back to the person who initiated the assignment. The entire architecture follows from taking that asymmetry seriously. The cheapest place to catch a problem is the earliest place, and in onboarding the earliest place is the assignment data itself.

An error caught at the gate costs a prompt. The same error caught at the signature costs a re-issue, a re-sign, and a chase.

3. Validate before you generate — the three-tier gate

The first real stage after intake is a validation gate that runs before any letter is generated. It has three tiers, in ascending order of cost to check and value to catch:

• Presence — every merge-critical field is present and non-empty: name, job title, pay and charge rate, currency, start and end dates, contracting entity, reporting manager, work location, notice period.
• Format & sanity — dates parse and are correctly ordered; the rate is numeric and inside a plausible band; the currency matches the country; the email is well-formed.
• Consistency & rules — the right letter type for the situation; region-specific fields present where the jurisdiction demands them (a Gulf assignment needs its sponsorship entity and wage-protection details; a fixed-term contract needs an end date); the rate currency matches the contracting entity's country.

A pass moves silently to generation — the initiator and the support team see nothing, which is exactly the point. A soft fail (a missing or malformed field) holds the case and returns an itemised prompt to the initiator naming which fields are wrong and why; it never lands on the support team. A hard fail (something structurally impossible, like an end date before a start date, or an unsupported country) is blocking and cannot be force-pushed to generation.

The value of the gate is not that it refuses bad input. Anything can refuse bad input. The value is in the specificity of the reason it hands back — a named field and a named problem the initiator can fix in one edit, rather than a generic rejection that starts a support ticket.

The gate's value is not that it says no. It is that it says exactly why.

4. The pipeline

Here is the whole flow on one page. If it looks familiar, that is the point: it is the same seven-stage agentic shape we keep arriving at — intake, classify, validate, generate, route, human gate, write back with an audit trail. This is the third independent domain to land on it, after timesheets and payslip explanations, which is the argument of One pipeline, three domains.

5. Generation as configuration

Once a case passes the gate, the letter is not written — it is assembled. A rules engine selects the template variant from three axes: the region, the contracting entity, and the employment type. Then the assignment fields are merged into the chosen template, and any placeholder that has no value is reported rather than quietly left blank or, worse, guessed.

This is the same discipline that runs through everything we build, and the same one that lets one payroll engine run across ninety countries: the variation lives in configuration, not in code or in a human's memory. Adding a country's letter, or a new entity's clause set, is authoring a template variant and its selection rule — not writing a new document-generation path.

The letter is assembled from rules, not written from memory.

6. Where the human signs

Onboarding is a legal act, so a human gates it — twice. The draft is routed to the correct approver by a most-specific-first matrix (client, then region, then entity, then a tenant default), with delegation and escalation handled when an approver is away. The approver reviews the letter with full context and signs. Only then is it issued to the contractor for their signature.

The two signatures are always in series — approver first, then contractor — and the order is stamped on each letter as explicit signing steps that advance as each party signs. The signing itself is native to the portal: the approver and the contractor draw or type their signature on the review screen, it is captured, stamped onto the stored document, and audited. No external signing provider is required for the flow to work end-to-end, though an Adobe Sign or DocuSign adapter drops in behind the same interface when a client prefers one.

The human effect is the one worth naming. The support team that used to assemble every letter by hand does not disappear; it moves up the stack. Its job shifts from building documents to overseeing the exceptions the system holds — the same pattern we saw when payroll teams stopped reconciling spreadsheets and started clearing a readiness dashboard.

The people who used to build every letter now only see the ones the system couldn't.

7. The exceptions are the product

A demo handles the happy path. A product handles what happens when the happy path breaks, and onboarding breaks in specific, enumerable ways. Each one has a designed destination, and the destinations matter as much as the automation:

• Incomplete or invalid intake data returns to the initiator who raised the assignment — never to the support team. Fixing source data is the initiator's job; routing it to anyone else just adds a hop.
• Non-standard terms that need a manual template edit before generation go to the support team — this is exactly the work they move up into.
• Approver-requested changes send the case back to be regenerated with a version bump, so the document history is honest about what changed.
• A contractor who declines or asks for an amendment re-issues cleanly, rather than leaving a half-signed document in an ambiguous state.

Deciding where each exception goes — and being strict that source-data problems never land on the team that handles template exceptions — is most of what separates this from a script. It is the same lesson as the guard rails on the HR assistant: the interesting design work is in the refusals and the routing, not the happy path.

Real onboarding is the exceptions. Naming them is the product.

8. What is real, and what is honest about it

It would be easy to describe this as finished. It is not, and the distinction is worth stating plainly. The parts that are real and run end-to-end today are the ones that carry the intellectual weight: the three-tier validation gate, the rules-driven letter generation and field merge, the approver routing, the in-portal signing, and the per-stage audit trail with a confidence score on every step. Those work against a bundled template engine so the whole flow is exercisable without waiting on anything.

The parts that are still pluggable stubs are the integrations to the systems around it — the staffing platform the assignment comes from, the external e-signature providers, the finance system the executed document writes back to. They are stubbed behind clean interfaces, pending credentials, precisely so the reasoning engine could be built and proven without them. That is the honest state of a working proof of concept: the thinking is done and demonstrable; the plumbing to the enterprise's other systems is the next tranche of work.

What makes even the proof cheap to stand up is that it is not a new architecture. It reuses the timesheet and payslip pipeline wholesale — the confidence routing, the queue-based orchestration, the audit shape, the prompt-injection and token-budget guardrails. A Python service on FastAPI and LangGraph runs the reasoning; a Node tier on Fastify, Prisma, and a job queue runs the orchestration. The third domain was the fastest to build because the first two had already paid for the framework.

The gate, the letter, and the signing are real. The plumbing to the systems around them is the honest work that remains.