Onboarding automation the same path every time
Employee onboarding and client onboarding are the same machine: a start event, a list of steps with owners and dates, access granted by role, materials, and a moment when somebody takes over. We build one path that handles both cases, and we measure the days it takes to get to full speed. The first path runs in production 14 days after the workshop.
- 14 daysfrom the workshop to the first onboarding path running in production. One role or one service package, not the whole process at once
- 2 kindsemployee onboarding and client onboarding handled by one mechanism: the same step list, the same owners, the same measurement
- 30 and 90 dayswhen we check the time to full speed and the steps that went back to a manual fix
The problem
Why does every onboarding at your company look different?
A new person starts on Monday. IT creates the account, the manager clicks through access to the project system, somebody on the team sends the materials, and the list of steps lives in an email from last year. A new client starts much the same way. One person sets up the folder, a second sends the credentials, a third remembers the kickoff call. Two different situations, one shared fault. The order of the steps depends on who happened to have time.
The path is not written into any system, so nobody watches it. A step missed in the first week surfaces in the fourth, when the new hire has no access to a report they need, or a client asks about something they were supposed to get on day one. Nobody can say when onboarding is finished either, because there is no step that closes it.
The expensive part is the mess in access rights. Under time pressure permissions get handed out broadly so nobody sits idle, and when the engagement ends nobody takes them back, because taking them back is not anybody's step. GDPR 2016/679 is explicit here: Art. 5(1)(f) requires personal data to be processed in a way that ensures its confidentiality and integrity, and Art. 32 requires technical and organisational measures appropriate to the risk, together with regular testing of how well they work. An account with access to everything, created just in case and never revoked, meets neither.
The scale grows with the number of systems. Five tools and three roles make fifteen permission combinations that nobody holds in their head. Every slip costs either the new person's time or the security of your data, and usually both, one after the other.
- A new hire waits on day one because access is granted by somebody who is off
- A client gets a different start than the last one, depending on who handled it
- A step missed at the start surfaces a month later and lands on somebody else
- Broad permissions stay on accounts after the engagement has ended
Why now
What makes one path enough for both employee and client onboarding?
Mechanically it is the same process. There is a start event, a list of steps with owners and dates, a package of access and materials tied to a role, a moment of handover to the team, and a number that says when it finished. What differs is the content of the steps and the system that fires the signal: the HR system or the CRM. The build is one. We wrote both scenarios up separately, employee onboarding with its statutory deadlines and client onboarding from signature to kickoff call. This page is about what they have in common.
The second reason is technical. The systems that carry out these steps can be driven from outside today: Google Workspace and Microsoft 365 create the account and put it in a permission group, Slack, Notion, ClickUp, Jira and Asana create tasks and grant access from a template, a CRM or an HR system fires a signal a second after a status changes. We build the joining layer in n8n, Make or as a direct API integration, and the path lives there rather than in somebody's head.
The third thing is the AI agent. A rule will close a step, but it will not answer who is currently going through onboarding and which step they are stuck on. BOND, our company AI agent, answers that in a plain sentence in 5 to 10 seconds, with nobody opening three systems in a row.
What changes
What does a company with one path actually get?
One step list instead of five versions
The path lives in the task system and in the automation layer, not in an email and not in a spreadsheet copied three times. Every step has an owner, a date counted from the start date and a condition that closes it.
A step with no owner and no date does not enter the path, because there is no way to account for it later
Who gets what and when, settled once
The package of access, materials and tasks is tied to a role or to a service package, not to whoever happens to be running the onboarding. A new sales rep gets what the last one got, a new client gets what last month's client got.
A matrix of roles and systems written down in the workshop, one place instead of several people's memory
Access by role, not just in case
For every role we write down the scope of permissions together with the date they are granted and the date they come back. Granting runs automatically, or lands with IT as a task carrying the full context when the decision has to stay with a person.
Revoking access is a step in the path with a date on it, not a good intention after the fact
Materials and training assigned by themselves
The set of materials follows from the role and arrives together with the access, in an order that makes sense. Confirmation that somebody read them is saved on the step, so you can see what has been covered and what is stuck.
Access to the material and the confirmation in one record, instead of an email with an attachment
Handover has a date and a name on it
Onboarding ends with a specific step: somebody takes over, on an agreed day, with the list closed. Nobody is left unattended and nobody stays the new person for half a year.
The closing date of the path visible in the task system and on the CRM record
Time to full speed becomes a number
We measure the days from start to the path closing, the steps that went back for a manual fix and the ones that stood still longest. After 30 and 90 days you know where the process jams.
Three metrics agreed in the workshop, counted from the path log rather than from a survey
And in your company
What if our onboarding works differently?
Four sentences we hear most often, and what we say back to them.
We bring in two people a quarter, this will never pay off.
At two people a quarter, simply writing the path down gives you more than automating it, and we will tell you so on the consultation. It is worth checking the other side then: companies that hire rarely often sign several clients a month, and that is where the path pays for itself faster.
We already have a checklist in a spreadsheet.
A checklist is a document, not a process. Nobody enforces the order, nobody sees that a step has been stuck for three days, and nobody revokes access when the engagement ends. Automation turns that same list into a path with owners, dates and a closing condition. The spreadsheet is good material for the workshop, because half the work is already done.
IT will never let us create accounts.
And they are often right. In that case the workflow does not create the account itself, it creates a task for IT with the scope already filled in: role, systems, permission groups, start date, revocation date. The decision stays with a person, only the chasing disappears. If a service account is needed at all, we write down its scope in the workshop along with what data it can see.
Employee onboarding and client onboarding are two different worlds.
The content of the steps, yes. The build, no. Both have a start event, a list of steps with owners, access by role, materials, a handover and a measurement. That is why we put them on one layer with one measurement, and keep the differences in the path templates.
- Start event
- HR system, HubSpot, Pipedrive, Salesforce, LiveSpace
- Accounts and permissions
- Google Workspace, Microsoft 365, Slack, Notion, CRM and project system access
- Tasks and the path
- ClickUp, Jira, Asana, Notion, Google Sheets
- Communication and materials
- Slack, Microsoft 365, Google Workspace, e-signature
- Data and measurement
- BigQuery, Google Sheets, SQL databases, GA4
- The automation layer
- n8n, Make, Zapier, custom API integrations
Onboarding path steps, the owner and the closing condition
Six steps that go into the path whether you are onboarding an employee or a client. The right hand column matters most here: a step with no closing condition always looks done.
| Path step | Who closes it | Closing condition |
|---|---|---|
| Start event | HR system or CRM | start date and role or service package recorded in one place |
| Step list with owners | the person running the onboarding | every step carries a name and a date counted from the start date |
| Access and permissions | IT or a service account | scope written down for the role, with a grant date and a revocation date |
| Materials and training | the manager or the account owner | the assigned set plus confirmation of reading it, saved on the step |
| First task on real data | the manager or the account owner | a task with a real result, due within the first week |
| Handover to the team | the manager or the account owner | the name of the person taking over and the date the path closes |
| Measuring time to full speed | the person who owns the process | days from start to close and the list of steps sent back for a fix |
The rows are a starting point. In the workshop you cross out what you do not have and add what is missing here. Statutory hiring deadlines and the client start sequence are written up on separate pages, because that is where the differences are large.
How we work
Five steps from a list in an email to a path in production
Process first, tools second. Every step ends with something you can judge before you decide on the next one.
Workshop
We sit down with the people who onboard staff and clients today and take both paths apart, step by step. The material is real recent cases, usually two or three hires and the same number of new clients. The output is a matrix of roles and service packages: who gets what, when and from whom.
Designing the path
We settle the start event, the order of steps, the owner of each one and the condition that closes it. Separately we write down the permission scope for every role along with the revocation date. We pick the tool: n8n, Make, Zapier or a direct API integration with what you already run.
Build and a test on real data
The path runs first on a test case, then on one real role and one real client, alongside the current list. We test the scenarios that break automations in practice: incomplete data in the source system, a start date that moves, a role that is not in the matrix.
Running in parallel
The path goes to production next to the current way of working, so nothing disappears if something fails. We set up error monitoring and an alert when a step stands still longer than the agreed threshold. The old way is switched off only once the new one has been through a few real starts.
Training and measurement at 30 and 90 days
The person running onboarding learns to change the path without us: a new role, a new system, a different service package, an exception for one person. Then we measure the days to full speed, the number of steps sent back for a manual fix and the steps that stood still longest. We tune the path to what actually comes through it.
Before and after
How the week changes for the person doing the onboarding
Before
- The step list is reconstructed from an email and from memory by whoever is onboarding
- The new hire writes on chat that they have no access to the system they are meant to work in
- Nobody knows whether last month's onboarding is closed
- Permissions stay live after the engagement ends, because revoking them is nobody's task
After
- The path starts itself from an event in the HR system or in the CRM
- Access by role is ready before day one, in the scope written down for that role
- The handover step has a name and a date, so you can see when onboarding ended
- Revoking access is a step in the same path, with a date of its own
The first path runs in production 14 days after the workshop. Time to full speed only means something after 30 and 90 days, because before that there is nothing to compare it with.
For the person signing this off
What a COO gets out of it
Questions like does the new starter have access yet and who is actually running this client stop landing on your desk, because the answer sits in a path you approved yourself. Onboarding stops depending on who is in the office that week.
The second thing matters more in a board meeting and in an audit. You know how many days pass from start to full speed, which steps stood still longest, and who had access to what and until when. That is an argument you do not have today, because nobody counts it.
- The path written down and versioned, independent of any one person
- Permission scope per role, with a grant date and a revocation date
- A parallel run, so the current way of working holds until testing ends
- Changes to roles and systems made by your team, without raising a ticket with us
What it costs
The workshop has a published price, the rollout is quoted after it
The process workshop costs EUR 3,500 net per week and runs from 1 to 7 weeks. Onboarding usually comes to one or two, because two paths have to be taken apart and the permission matrix has to be closed. We quote the rollout after the workshop, once it is clear how many roles there are, how many systems are involved and what state the data in the source system is in.
You pay the cost of running the path directly to the tool provider, n8n or Make for instance, or you pay nothing at all when it runs on your own infrastructure. Same with the language model once an AI agent goes in, where a single query costs the provider roughly EUR 0.005 to 0.07. There is no margin from us on any of it.
Process workshop
EUR 3,500 net
per week, and onboarding usually takes one or two
A self-contained piece of work. It ends with the onboarding path written down, a matrix of roles and permissions, and a plan you could execute without us.
- A map of employee and client onboarding as they run today, with the places they stall
- A matrix of roles and service packages: who gets what, when and from whom
- Permission scope per role together with the access revocation date
- A tool recommendation and three metrics to measure at 30 and 90 days
- Most popular
Workshop and path rollout
Quoted after the workshop
scope follows from the number of roles and the number of systems
The option most companies choose. The first path runs in production 14 days after the workshop, the whole thing usually takes 2 to 4 weeks.
- Everything in the workshop
- A path in n8n, Make or over the API, wired into the HR system or the CRM
- Access granted by role and revoked as a step in the path
- A parallel run, error monitoring and alerts on steps that stand still
- Training so the person running onboarding can change the path alone
Onboarding and an AI agent
Quoted after the workshop
for companies onboarding several people or several clients a month
Everything in the rollout plus BOND, which answers questions about the state of onboarding in a plain sentence, in 5 to 10 seconds.
- Everything in the path rollout
- An AI agent wired into the path: who is in progress, which step they are stuck on, what is overdue
- Alerts on steps standing longer than the threshold and on access due for revocation
- Access for HR, IT and managers, with no login to three systems
The workshop ends with a document that stands up without us: the path, the matrix of roles and permissions, and a rollout plan. If it turns out that at your scale a written path and a task template in the system you already run are enough, we say so plainly and the engagement ends at the workshop.
Frequently asked questions
What is onboarding automation?
It is turning a step list kept in an email or a spreadsheet into a path that a system runs. An event in the HR system or the CRM triggers the steps, each with an owner, a date and a closing condition. Access and materials follow from the role rather than from the memory of whoever is onboarding. People decide where a decision is actually needed.
Will one path handle both employee and client onboarding?
Yes, because the build is the same: a start event, steps with owners, access by role, materials, handover and measurement. The differences live in the path templates, so an employee and a client follow separate steps on one automation layer. One rollout, two templates, one set of metrics.
How long does an onboarding automation rollout take?
The first path for one role or one service package runs in production 14 days after the workshop. The whole thing, meaning several roles and several systems, usually takes 2 to 4 weeks. The workshop itself is one or two weeks, depending on how many separate paths have to be taken apart.
How is this different from a checklist in a spreadsheet?
A checklist says what to do but does not make sure anybody does it. A path has an owner on every step, a date counted from the start date and a closing condition, so you can see that something has been stuck for three days. The spreadsheet is good material for the workshop, because half the work is already in it.
Who grants access once the path is automated?
That is your call, and we fit around your IT rules. The workflow can grant access itself through a service account with a written scope, or it can only create a task for IT with the full context: role, systems, permission groups, start date and revocation date. In the second option the decision stays with a person and only the chasing disappears.
What happens to access when an engagement ends?
Revoking access goes in as a step in the same path, with a date and an owner. We hold a permission scope for every role, so it is clear exactly what to take away and from which systems. It is the same mechanism run in the other direction, and the part of onboarding most often skipped.
How do you measure time to full speed?
With three numbers agreed in the workshop: days from start to the path closing, the number of steps sent back for a manual fix, and the step that stood still longest. We count them from the path log rather than from a survey. The first reading at 30 days shows whether the path works, the second at 90 days whether it holds.
Do we need a new system for this?
Usually not. The path uses what you already run: the HR system or the CRM as the source of the event, the task system as the place where steps live, and the account directory as the place where permissions live. On top of that sits a joining layer in n8n, Make or Zapier. We only propose a new tool when something is genuinely missing, and we say plainly why.
Let us take your onboarding apart, step by step
The free consultation takes 30 minutes. You tell us what the start of a new person and a new client looks like today, even if the step list only exists in an email. We tell you which steps can move into a path straight away and which need a decision about permissions first. You do not have to share any systems at this stage.
We run at most two rollouts at a time, so that someone is genuinely sitting on each of them.
Book a free consultationPS. If somebody at your company spent day one waiting for access this month, or a new client asked who their contact was, that is exactly this problem. A path written into a system does the same thing every time, and after 30 days it tells you in numbers where it jams. That is where the workshop starts.