Onboarding a new hire with AI

How the bot works

Nine steps. The checklist, the dates, the dependency order and the readiness view are ordinary code and cost almost nothing to run; the model is only used to read what comes back and to write the chase in your voice.

1. It builds the checklist for this hire. Role, location, employment type and start date in; a task list out, where every task has a named owner and a date counted from day one rather than from today. The same list every time, so the tenth hire does not get a worse first week than the first.

2. It puts the tasks in an order that actually works. The account before the tool that needs it, the signed form before the payroll record, the equipment request before the day it has to be on a desk. What makes onboarding feel like firefighting is finding out mid-task that something else had to happen first.

3. It asks the new hire only for what only they can give. The forms your process requires, the details nobody else has, the documents you collect — in one place, in your words, with a single link back. Not six emails from four people asking for overlapping things.

4. It chases what is outstanding, by name. Reminders to the person who actually owes the thing — the hire, the manager, IT, whoever — on your schedule, through your channel, escalating the way your rule says. A blocked task names what is blocking it and who owns that.

5. It checks each form field by field. A form is complete when its fields are complete, not when a file arrives. A blank where your rule needs a value, a name that disagrees between two forms, a missing signature, a date in the wrong century: each one is named on the form it came from.

6. It opens the requests in your systems. The account, the license, the group membership, the laptop, the badge, the training enrollment — raised as requests in the tool your team already works from, with everything the approver needs attached. Requests, not grants.

7. It keeps one picture of day one. What is done, what is outstanding, who owes it, and which of the outstanding items would actually stop the first day. One view, not a thread. Anyone can answer "are we ready for Monday" without asking four people.

8. It hands over everything that is a decision. Whether somebody may be hired, what the terms are, whether a document satisfies a requirement, whether to make an exception to your own process. All of these arrive at a named person with the evidence attached and none of them are answered by the bot.

9. It keeps the record, hire by hire. Every task with its owner and its dates, every reminder sent, every document received and when, every field check and its result, who confirmed what. The thing you wish you had the next time somebody asks when a form was returned.

What you configure

It can be configured to run in any business. This is what that actually means — the list of things that are yours, not ours.

Your checklist, per role and location

The tasks for a warehouse hire and a remote analyst are not the same list. Each variant is yours, written down, with the owner and the day-one-relative date for every task.

Your order of operations

What must happen before what, and which prerequisites are hard. This is the part that turns a checklist into something that can run itself without stalling.

Your forms and their required fields

Which forms, which fields are mandatory, which must agree across two forms, who countersigns, and what an acceptable document looks like for each one.

Your chase rhythm

How often a reminder goes, through which channel, who is copied, when it escalates to a manager — and the words it uses, which are yours.

Your approvals

Who signs what, which tasks cannot proceed without a signature, and who is allowed to approve an exception to your own process.

Your provisioning map

Which tools a role gets, which group and which license tier, where the request goes, and who actually creates the account — because that is a person with rights, not a bot.

Your equipment and access

The standard kit per role, who ships it and to where, what a badge or a key requires, and what happens when something is out of stock.

Your definition of day one

What must be true for a first day to be ready, and which outstanding items are merely untidy. Without this the readiness view is just a list of everything.

Your records, access and retention

Where personnel documents go, who may see which ones, how long each is kept, and what the bot is allowed to read at all.

Transparent, and configurable by you

The dark band below is what the system will not do. This is what you can see and change — and it is how we build everything, not something invented for this page.

You see what it did, and why

Every task shows its owner, its date, what it is waiting on and every reminder that has gone out. Every form check shows which field failed and why, next to the form it came from, so nothing is ever just marked incomplete.

Versioned prompts you can tune yourself

The prompts behind reading a returned form and writing a chase are yours to read and yours to tune. A change is a reviewable diff, replayed against hires you have already onboarded so you can see exactly what it would have sent, and rolled back the same way.

A human in the loop wherever judgment actually matters

Building the list, chasing it and checking fields is automatic. Eligibility, the offer, granting access, accepting a document and every exception are a person's — that boundary is a property of the system, not a promise about how carefully we'll use it.

Every run logged, along with what it cost

One row per task and one per message: who owed it, when it was due, what was sent and to whom, what came back, which field checks ran, who confirmed it, and the model and prompt version where a model was used — plus token usage and cost for that run.

It can be configured to run in any business. The checklist and the rules are yours: your tasks, your owners, your order, your forms, your approvals, your definition of a ready first day. The new-hire wiring on this page is one configuration of it, not the limit of it.

Works with your tools

This runs on top of the HR system, the payroll and the ticketing tool you already use. We're not selling you a new HR platform.

• An HR system
• An applicant tracking system
• ADP, Gusto or Paychex
• DocuSign or a similar tool
• Google Workspace
• Microsoft 365 or Outlook
• A project or task tracker
• A helpdesk or ticketing tool
• A spreadsheet you control
• Email, Slack or Microsoft Teams

Works well for

• Home care agencies — Caregivers start constantly and each one needs the right checks on file before a first visit.
• Clinics and healthcare practices — Clinical hires arrive with licenses, credentials and training that all have to be on file by day one.
• Manufacturers — A shift hire needs safety training, a locker, a badge and a time clock before they can work at all.
• Franchise and multi-location operators — The same onboarding runs at every site, and each site is somebody's second job.
• Staffing and recruiting agencies — Onboarding is the product, and every placement restarts the whole paperwork cycle.

How a rollout works

Nobody is onboarded by a bot on day one. The first milestone is the checklist and the messages it would have sent for hires you have already brought in.

1. 01Discovery

   The quote call, then a working session. We go through every task you can remember, who owns each one, when it has to happen relative to day one, which forms are required and which fields on them matter, who approves what, and what a ready first day means here. You get the checklist design, the dependency map, the exception classes and a written scope.

2. 02Dry run

   The bot builds the checklist and drafts every chase for hires you have already onboarded. Nothing is sent to anybody and no request is raised. We compare its list against what actually happened, and every difference is either a task nobody wrote down or a step that only lives in somebody's head. This is where your own numbers come from.

3. 03Assisted mode

   Live on one role or one location. The bot runs the list, chases by name and checks the forms; a person approves every request, accepts every document and owns every decision. Onboarding stops being remembered and starts being read. The control doesn't change.

4. 04Optional wider rollout

   Optional. Once a role has run clean for a while, more roles and locations come on, with every hard stop in force, no access rights ever, and the kill switch. Plenty of teams stop at step 03, and that's a good place to stop.

What we don't claim

• No numbers we haven't earned. No time-to-productivity figure, no retention claim, no admin-reduction percentage. We haven't onboarded anybody for you. Every number on pages like this one belongs to somebody else's survey; yours come out of the dry run and the first role you run live.
• No customer claims on this page. No names, no case studies, no logos.
• It does not make your compliance somebody else's problem. Which forms you must collect, in which state, by when, and what counts as acceptable are yours to decide and yours to answer for. We turn them into checks the bot cannot skip — we will not tell you that your obligations are handled.
• It will not judge a person. No scoring of candidates or new hires, no model opinion about whether somebody is a good fit, no inference from a document beyond the fields on it. Hiring decisions and eligibility decisions are human work, and this bot is deliberately built not to touch them.
• Fully autonomous onboarding isn't on offer. A person approves every access request, accepts every document and owns every exception. That's deliberate, and it's why the boundary is written down.

Questions people ask

Can AI run our new-hire onboarding?

Yes, for the coordination - which is where the week actually goes. An agent can build one checklist per hire from the role, location, employment type and start date, give every task an owner and a date counted from day one, sequence them so prerequisites come first, ask the new hire for the things only they can give, chase whatever is outstanding by name, check each returned form field by field, and open the account and equipment requests in your own systems. What it does not do is decide anything: eligibility, the offer and every access grant stay with a person.

Does it decide whether somebody is eligible to work?

No, and it never will. Work authorization, identity documents, background and license checks are collected, recorded and routed to the person who owns that decision, with the evidence attached. Whether a document satisfies a requirement is not a judgment we will let a model make, in any configuration. That is a hard stop in the design, not a setting.

Will it create accounts and order the laptop?

It raises the requests, with everything the approver needs attached, in the tool your team already works from - and a person with the rights to create an account is the one who creates it. The bot holds no administrative credential for your systems. What it is good at is the ordering: knowing that the mailbox has to exist before the tool that logs in with it, and that the kit request has to go out before the day it is needed.

How does it chase paperwork without becoming annoying?

The rhythm is yours: how often a reminder goes, on which channel, who is copied, and when it escalates to a manager. Each reminder goes to the person who actually owes the thing rather than to everybody, names exactly what is outstanding, and stops the moment it arrives. A task that is blocked by somebody else says so, and names them, instead of chasing the new hire for something they cannot do.

What about I-9s, W-4s and state forms?

It collects them, checks them field by field and records what arrived and when - and it treats the form as complete only when the fields are complete, which matters more than it sounds. Blank mandatory fields, a name that disagrees between two forms and missing signatures are the common silent failures, and each one is named on the form it came from. The determination on any form that carries one is a person's, and which forms you owe is your decision to make and ours to turn into checks.

Does it know the employment rules where we operate?

No, and any tool that tells you it does is selling you something. It knows the forms, the required fields, the deadlines and the acceptable documents you give it. Those become checks the bot cannot skip, and the person who signs off on the hire remains the accountable one. That is a deliberate boundary, not a gap we plan to close.

Does it work with our HR system and payroll?

Yes, for most of them. A hire is picked up wherever a hire becomes real - an HR system, an applicant tracking tool, a payroll record or a manager's email - and the requests go into the ticketing or task tool your team already uses, with signatures happening where they happen today. If onboarding currently lives in a spreadsheet and a folder, that works the same way. Naming a system means we can read or write it, not that we are partnered with it.

What happens when something is still missing on the first day?

You know before the first day. The readiness view separates what is outstanding from what would actually stop day one, so the conversation on Friday is about a short list rather than a thread. Nothing is reported as ready on an assumption, and if a system cannot be reached or a form cannot be parsed, the task stays open with the gap named rather than quietly closing.

Who can see the documents, and how long are they kept?

You decide both, and this is the part worth being strict about. Access is scoped to the fields each step actually needs, identity documents can be excluded from everything the bot reads, documents land in the system you name and nowhere else, retention per document type is your rule, and nothing is used to train anything. One flag puts the whole thing back to checklist-only, instantly.