Use cases
AI employee for onboarding
Tobiloba Odejinmi · 9 Jul 2026 · 6 min · 1,125 words
Direct answer
An onboarding employee runs the checklist after someone says yes: documents, reminders, and a flag when a step is stuck. Good looks like a person who can start work on day one without a scavenger hunt. Escalate access grants, contracts, and money. Do not automate production access or payroll first. Measure time-to-productive and unfinished checklists, not “welcome emails sent”.
- The job is the checklist after yes, not a welcome novel.
- A person still grants access and signs anything that moves money.
- Do not start with production keys or payroll.
- Measure who actually starts, and which step they stall on.
What is the onboarding job after someone says yes?
Someone said yes. Now there is a list. Forms. Equipment. Accounts. A first meeting. A go-live date if it is a customer. Most of that list is chasing and filing. People drop it because it is boring and because nobody owns the red row. That is the job.
The employee sits in the tracker you already use. It knows the steps, who owes each one, and what “done” means. It nudges. It files the PDF. It flags the step that has not moved. If it lives in a chat and the tracker is still a spreadsheet only one person understands, you added a narrator.
I have onboarded providers and I have onboarded engineers. The shape is the same. A finish line you can see. At 10mg that finish line is a clinic that can start an application. At Zeeh it was a company that could call the API before lunch. A welcome PDF is not a finish line.
What does a good onboarding employee do?
It runs one list. The new person or the new clinic can see where they are. The internal owner can see who is blocked. The documents land in the folder the team already uses. The first week calendar is real times, not “we will find a slot”.
Good also means the pack is short. What to do today. What to do before day seven. Who to ping. I like TypeScript and I like checklists. I do not like a 40-page handbook that nobody reads on Tuesday.
When a step is stuck, the employee writes why. “ID expired.” “Bank account rejected.” “Laptop not shipped.” A red row without a reason is how onboarding becomes folklore.
- One tracker, one finish line
- Nudges go to the person who owes the step
- Docs land where the team already looks
- Stuck steps have a reason, not a colour
What should escalate on day one?
Access to production, payments, or patient data. Contract changes. Anything that moves money. A background check that came back odd. A clinic that cannot log in on the morning they were told they could. The employee can assemble the packet. A person clicks.
Escalation is a state handoff. The approver gets the person, the step, the files, and why it is in their queue. “Onboarding blocked” is not a reason. “Needs production read on payments, ticket 1842” is a reason.
Hard gates stay hard. I will not let a first-week employee mint a live key. I will let it open the request so the right adult is not hunting Slack.
What should you not automate first?
Do not start with payroll. Do not start with production access. Do not start with a bot that emails the whole company “please welcome”. Those mistakes are loud and some of them are expensive.
Do not start by rewriting the culture talk. Start with the list that already exists and already fails: equipment, accounts, the first three documents. If you do not have that list, write it on paper. Then automate the chasing.
Skip a custom portal unless the tools you have cannot show the list. New logins are how onboarding dies. The same rule as Zeeh. If the new person cannot use it before lunch, you still have work to do.
How do you measure onboarding that actually finishes?
Share of people or accounts who hit the finish line by the date you named. Median time on each step. Steps that stay red more than three days. Access granted after the start date. Those numbers tell you where the list is a lie.
Do not measure “onboarding emails sent”. Anyone can send mail. Measure who could do the job on the morning you promised. For a clinic, that is login and a first application. For an engineer, that is a laptop and a repo they can open.
If finish rates do not move, you automated the reminder and left the blocker. Find the blocker. It is usually a person who is not on the list, or a system that still needs a ticket in a tool nobody watches.
How do you keep access from becoming a mess?
Prepare, do not grant. The request should name the system, the role, the expiry if there is one, and who approved it. Log it where security already looks. If the only record is a chat, you will not be able to revoke it later.
Contractors and clinics need the same discipline and a shorter life. A contractor who left still having warehouse admin is an incident. A clinic user who never got in is also an incident. Both are onboarding failures.
When we sold companies, buyers asked who could change production and whether we could explain it. Onboarding is where those accounts are born. If the birth is sloppy, diligence is a hunt. Keep the log from day one.
Questions people ask
What should an onboarding AI employee do?
Track the list you already have: forms, equipment, the first meeting, the docs you already send. Nudge the person who is late. File what comes back. Flag the step that has been red for three days. It should not invent a new programme.
Can it grant system access?
It can prepare the request. A person grants it. Production, payments, and patient or bank data stay behind a named approver. If you skip that, you will spend a Friday revoking keys.
What about customer or clinic onboarding?
Same shape. A checklist, a finish line, a person on the money and the go-live. At 10mg a provider who cannot open the system is not onboarded. A PDF dump is not a finish line.
Should it write the welcome pack?
It can assemble the pack from templates you already approved. It should not invent policy. If a paragraph is not in the source, it does not go in the pack.
How do we measure it?
Share of new people who finished the list by the day you named. Time stuck on each step. Access that was granted late. Day-30 still-here is downstream. Do not credit the model for retention you did not measure at the step.
Written by
Tobiloba Odejinmi
Head of Engineering at 10mg Health. I have run engineering at Zeeh Africa and sold Insurpass and Shopl. I still write the code. If you have one process that still runs on people copying things, we can look at it in thirty minutes.
