How do you automate onboarding? start with the list of steps, not with the tool
Employee onboarding and client onboarding are the same mechanism with different content in the steps. Below is the path you write yourself: seven steps, deadlines in days from the start date, one role per step, an access matrix and the three numbers that tell you whether it works.
- 7 stepsthe size of a minimum onboarding path, the one you write on a single sheet before you switch on any automation
- 7 dayshow far ahead of the start date the access request reaches IT, so nobody spends day one waiting for a login
- 15 combinationswhat 5 tools across 3 roles produce; that many permissions live in somebody's head until the matrix is written down
- 30 and 90 dayswhen you read time to independence: the first reading says whether the path works, the second whether it holds
Short answer
How do you automate employee and client onboarding?
Write the path down before you open any tool. Take the last two real cases, one new hire and one new client, and reconstruct from email and calendar everything up to the first normal working day. Every step gets one sentence of description, one role, a deadline in days from the start date and a condition that closes it.
Then turn the list into a template in the task system you already have: ClickUp, Jira, Asana, Notion or Google Sheets. Copy it by hand for every new case. The automation layer in n8n, Make or Zapier comes in once that copying starts getting in the way.
Finally switch on an alert for any step past its deadline, addressed to the person who owns it, and measure the time from the start date to the moment the path closes. Without a closing step there is nothing to measure, so write that step first.
Why does the list of steps have to exist before the automation?
An automation does not tidy a process up. It repeats whatever you show it. If every start looks different today, after go-live it will look different faster. The first version of the path belongs in a document, not in a tool.
The raw material is not your idea of the process. It is the last two real cases. Reconstructing them takes one afternoon. The same work, run by us, is described on the onboarding automation page.
- Every step gets one sentence in the imperative: „create the directory account”, „send the materials pack”
- Next to each step write the system it happens in and the data it needs as input
- Mark the steps that carry a human decision: those stay with a human after automation too
- Cross out the steps nobody can justify; an automation is the most expensive way to make them permanent
How do you count deadlines from the start date instead of the calendar?
A fixed date in a checklist goes stale the day somebody moves the start by a week. Write deadlines as an offset from one date: the first day of work, or the day the contract is signed. Then moving the start moves the whole path.
The same rule saves the deadlines you are not allowed to miss. When you hire, some of them are set by the employment law of the country you hire in, and the path has to hold them for you. We laid the sequence out on the automatic employee onboarding page.
| Step in the path | Deadline from the start date | What you record on the step |
|---|---|---|
| Start event in a system | day minus 10 | start date plus the role or the service package |
| Access request to IT | day minus 7 | systems and permission level for that role |
| Accounts and permissions ready | day minus 1 | who granted them, when and for how long |
| Materials and the intro meeting | day 1 | confirmation they were read, recorded on the step |
| First task on real data | day 3 | the result of the task, not the fact it was assigned |
| Handover to the team and close | day 30 | name of the person taking over and the closing date |
| Access revoked after the engagement | last day plus 1 | which accounts were switched off and by whom |
The numbers in the middle column are a starting point, not a standard. Set them once against your own process, so that a new start means swapping one date and nothing else.
Who owns a step: a role or a name?
A name in a checklist works until the first holiday. A role keeps working, because you change who fills it in one place instead of twenty rows. So the owner of a step is „HR”, „IT”, „the manager” or „the account manager”.
The owner is the person who closes the step, not the person who reminds others about it. If two roles stand next to a step, one of them is the recipient of a notification. Split them, because a step with two owners stalls the longest.
- One role per step, always; a second role gets a notification at most
- Who fills each role lives in one table you update when the team changes
- Every role needs a stand-in, otherwise one holiday stops the path
- A role you do not have cannot own a step: give it to somebody real or cross it out
Why do access rights eat the new person's first day?
This is the most common bottleneck and the easiest one to see coming. IT creates the account, the manager clicks through access to the project system, administration buys the licence. Three queues, one deadline, no shared view.
The fix is not faster clicking. It is an earlier request with the scope already decided. Write the matrix: a row is a role, a column is a system, the cell holds the permission level. Five tools across three roles give 15 combinations, and nobody keeps that in their head. Then the request reaches IT 7 days before the start and closes without anyone chasing it.
- The access request comes off the same start date as the rest of the path, not off an email sent the day before
- The role describes the scope, so IT does not guess and does not grant wide just in case
- When you grant access you record the revocation date, even if that is the end of a fixed-term contract
- Revoking access is a separate step in the path, with its own owner and its own deadline
What can be automated for an employee, and what for a client?
The build of the path is the same, the content of the steps differs. For an employee a fair number of steps carry a deadline set by law and need a document, so the automation prepares and chases. For a client the automation runs more of the steps end to end.
The second source of difference is the system that fires the start signal: HR and the first day of work, or the CRM and a signed contract. We wrote the client side out on the automatic client onboarding page.
| Element of the path | Employee onboarding | Client onboarding |
|---|---|---|
| Start signal | status in the HR system, first day of work | status change in the CRM, or a signed contract |
| Accounts and access | account directory, email, chat, work systems | client panel, drive folder, contact channel |
| Documents | some carry a statutory deadline, the automation reminds | starter materials, sending is automated end to end |
| Kickoff meeting | intro to the team from the manager's calendar | opening call from the account manager's calendar |
| Closing the path | handover to the manager's ongoing care | handover from implementation to day-to-day service |
The columns differ in content, not in mechanics. That is why one layer with two path templates pays off better than two separate automations.
How do you launch the first path without ordering an implementation?
You can stand the first version up in tools you probably already own: a task system with list templates, a calendar and an account directory. The automation layer comes later, and only where the manual work starts getting in the way.
Pick one role or one service package
Not the whole of onboarding, just the case that repeats most often. One path taken all the way to the end teaches more than five mapped halfway.
Write down the steps, the owners and the deadlines from the start date
One table: step, role, offset in days, closing condition. The last column matters most, because a step without one always looks done.
Turn the table into a template in your task system
A list template in ClickUp, Jira, Asana, Notion or Google Sheets, with deadlines counted from the start date. You copy it by hand, and that is enough for the first few starts.
Add the trigger and the access request
Now n8n, Make or Zapier come in: an event in HR or in the CRM creates the path from the template, and the access request reaches IT with the scope already filled in. Run it alongside the current way of working, so a mistake by the automation loses nothing.
Switch on the measurement and the overdue-step alert
Record the start date and the closing date of every path, and when a step goes past its deadline notify the owner and the person running the process. First reading at 30 days, second at 90.
How do you measure time to independence and catch the steps that stall?
Time to independence is the number of days from the start date to the day the owner of the last step closed the path. It is a number rather than a feeling, so you can compare it across cases.
The signal that something has stalled is simple: a step past its deadline with nothing changed on it for 24 hours. One notification a day listing those steps, sent to somebody allowed to push them, is enough.
If you want to ask about the state of onboarding in a plain sentence, an AI agent comes in. BOND, our company AI agent, answers from company data in 5 to 10 seconds and says which step is stuck. That is an addition to the measurement, not a replacement for it.
- Days from start to close, counted separately for employees and for clients
- Number of steps sent back for a manual fix in the first 30 days
- The step that stalled the longest, together with the role that closes it
- Share of paths where access was ready before day one
Common mistakes
Five mistakes that stop an onboarding path from working
Automating before the path is written down
The tool makes the mess it found permanent. A month later you have the same exceptions, only harder to change, because they now sit in a configuration.
Fixed dates instead of days counted from the start
One change of start date invalidates the whole list and somebody retypes the deadlines by hand. The second time it happens, they stop retyping them.
A name instead of a role on the step
The first holiday stops the path, because nobody knows who takes over. Every change in the team means editing every row of the list.
The access request sent the day before the start
IT cannot make it, and the new person spends day one waiting. Under pressure somebody grants permissions wide, and that is how they stay.
No step that closes onboarding
Nobody knows when the process ended, so there is no way to count time to independence and no moment at which care gets handed over.
Checklist
Checklist before you automate onboarding
If any line is a no, the path is not ready for an automation yet.
- The path written on one sheet, based on the last two real cases
- Every step has one role as its owner, and a named stand-in
- Deadlines written as a number of days from the start date, not as calendar dates
- A role and system matrix with permission level, grant date and revocation date
- A step that closes the path, with the name of the person taking over and a date
- The overdue-step alert addressed to the owner, not to everyone
- Three metrics to read at 30 and 90 days, counted from the path log
Sources
Sources
- GDPR, Regulation 2016/679, Art. 32: measures appropriate to the risk and regular testing of their effectiveness
- n8n documentation: triggers, schedules and error handling in workflows
- Make help centre: scenarios, triggers and modules
- Zapier help centre: triggers, actions and multi-step Zaps
- JustAutomate, onboarding automation: steps, owners and closing conditions
Let us break your onboarding into steps
You can write the path yourself, a workshop only makes it shorter
The free consultation takes 30 minutes. You describe how a new hire and a new client start today, and we say which steps can move into the path straight away. The process workshop costs EUR 3,500 net per week and ends with a written path, a permissions matrix and a plan you can execute without us.
Book a free consultationFrequently asked questions
Where do you start when automating onboarding?
By writing the path down from the last two real cases: one new hire and one new client. You pick the tool after that, because the first version lives perfectly well in a task list template that somebody copies by hand.
How many steps should an onboarding path have?
The minimum version has 7 steps: the start event, the list of steps with owners, access, materials, the first task on real data, handover to the team and measurement. A step you cannot describe in one sentence is in fact two steps.
Should onboarding deadlines be written as fixed dates?
No, as an offset in days from the start date, meaning the first day of work or the day the contract is signed. Then a change of start moves the whole path with no retyping. A fixed date goes stale the first time a plan changes.
Who should own a step in onboarding?
A role, not a person: HR, IT, the manager or the account manager. You then change who fills the role in one table instead of twenty rows of a list. Give every role a stand-in, because otherwise one holiday stops the path.
Why is access the most common problem on day one?
Because several people grant it in several queues, and the request usually goes out the day before the start. The fix is a role and system matrix with permission levels, plus a request sent 7 days ahead with the revocation date recorded straight away.
How does employee onboarding differ from client onboarding?
The mechanics are the same, the content of the steps and the start signal differ. For an employee the signal is a status in the HR system, and some deadlines are set by the employment law of the country you hire in. For a client the signal is a status change in the CRM.
How do you measure whether onboarding automation achieved anything?
With three numbers from the path log: days from start to close, the number of steps sent back for a manual fix, and the step that stalled the longest. Read them at 30 and at 90 days. Write the metrics down before you start, or there will be nothing to compare against.