The Onboarding Workflow: Where It Stalls and Who Unblocks It

TL;DR

• An onboarding workflow is a state machine with people in it. It stalls at handoffs, not at tasks.
• Map the waiting states rather than the actions. Most of your elapsed time is spent waiting, and none of it is on anybody's list.
• Every step needs an owner, a deputy and a trigger. Steps with two of the three fail intermittently, which is harder to diagnose than failing always.
• The most common silent failure is a task whose predecessor completed in a different system and never signalled.
• A start date that moves must propagate down every path the original signal took, or scheduled work carries on against the old date.
• Measure elapsed days per stage, not task completion. Completion tells you the work happened, never when.

A new starter is due on the fifth. The equipment request goes in on the first. The laptop ships on the fourth, arrives on the seventh, and the person spends two days doing induction reading on their own phone.

Nothing in that sequence failed. Every task was completed by the person responsible, correctly, in order. The workflow produced a bad outcome while every step reported success, which is the characteristic failure of onboarding processes and the reason task checklists keep disappointing the people who build them.

The real issue is not that steps get missed. It is that a workflow made of tasks records what happened and never records when it needed to have happened by.

Recommended Tools

Best tools for HR Operations

B BambooHR HR management system R Rippling HR & IT automation W Workday Enterprise HRIS

View all recommended tools

When you do not need a formal workflow

Below about fifteen starters a year, a named owner and a checklist beat a modelled process. The overhead of maintaining a workflow exceeds the cost of one person remembering, and the person remembering adapts to unusual cases better than any model will.

If every starter is the same, sequence is all you need. Formal workflows earn their keep when paths diverge: by location, by contract type, by whether hardware is involved. A single path for everybody is a list, and calling it a workflow adds machinery without adding capability.

If the real problem is that nobody owns onboarding, modelling it will not fix that. A workflow allocates work to owners. If the owners do not exist, you will build something that looks complete and stalls at the first unassigned step. Ownership first, always.

And the case that argues the other way. If you hire in cohorts, a formal workflow stops being optional much earlier than headcount suggests. Four starters on one Monday generate correlated dependencies, and a single absent approver blocks all four. Burst hiring is the clearest argument for modelling at any size.

There is also a quieter trigger that has nothing to do with volume, which is the departure of whoever has been holding the process in their head. Plenty of companies run onboarding perfectly well on one person's memory for years, and the quality is genuinely high because that person adapts to each case. The risk is concentrated rather than ongoing, and it arrives all at once when they move on, take extended leave or are simply busy during a week when two people start. If your process currently works because of a specific individual rather than because of anything written down, the time to document it is while they are still there to be asked, not afterwards when the knowledge has to be reconstructed from what went wrong.

Map the waiting, not the doing

The standard way to document an onboarding process is to list the tasks. This is the wrong artefact, because tasks are the fast part.

Take any onboarding that went badly and reconstruct it with timestamps. The actions take minutes: creating an account, adding somebody to a group, approving a request, placing an order. The elapsed time is almost entirely spent in the gaps, waiting for somebody to notice there is something to do.

So the useful map is the waiting states. For each one, you want three things: what it is waiting on, who can end the wait, and how they find out it exists. That third question is where most processes have no answer at all, and a step nobody is told about is a step that completes when somebody happens to check.

Do this once and the result is usually uncomfortable in a specific way. The longest waits are rarely the steps anybody would have named as a problem. They are the small approvals that sit with a busy person who has no reason to look.

It is worth distinguishing two kinds of waiting, because they need different fixes. A dependency wait is time spent waiting for something real to happen, such as a machine being built or a carrier moving a box, and the only levers are starting earlier or holding stock. A notification wait is time spent waiting for somebody to find out it is their turn, and it is pure waste, removable with a trigger and nothing else. Teams conflate these constantly and apply the wrong remedy, usually by chasing people over dependency waits and tolerating notification waits because they are invisible. When you map your own process, label each wait as one or the other before deciding anything, because the proportions will tell you whether your problem is design or physics.

The three properties every step needs

An owner, by name. Not a team and not a shared inbox. Teams do not notice things; people do. A step owned by a team is a step owned by whoever feels most guilty, which varies by week.

A deputy, published in advance. The single most common cause of a stalled onboarding is one person being on leave. A deputy named at the point of escalation is a deputy found too late. Name them when you design the step and write them down next to the owner.

A trigger that reaches the owner. This is the one most often missing. A step exists in the process document and nothing tells the owner it is their turn, so the step completes whenever they next look at the document, which may be never. A trigger means a notification, a calendar entry or a queue item, not an expectation.

A step with all three works. A step with two of three fails intermittently, which is substantially worse than failing reliably, because intermittent failure gets attributed to individuals rather than to the design.

There is a fourth property worth adding for anything on the critical path, which is a visible due time rather than a due date. A step due on the fourth can be completed at five in the afternoon on the fourth, perfectly within target, and still be too late for a starter arriving at nine on the fifth. Dates are the natural unit for planning and the wrong unit for the last few steps before somebody arrives, and this single substitution removes a category of failure where everything was technically on schedule. The practical version is that anything which must be ready for day one carries a deadline of the working day before, not the start date itself, which also buys a few hours to notice and fix whatever did not work.

The handoff that breaks most often

The highest value thing to fix in almost any onboarding workflow is the handoff from recruitment to everybody else.

The pattern is consistent. Recruitment works in its own system and considers the job finished at offer acceptance. Everything downstream needs to know a person is coming, and the signal that carries that information is usually a human remembering to mention it. So the lead time available to IT, facilities, payroll and the manager is set by how quickly one person thinks to pass it on, which is unpredictable by construction.

Measure your own version. Take the last ten hires and record the days between offer acceptance and the first downstream notification. Teams that are struggling usually find a median under three days, with at least one case where the first notification was a calendar invite for the welcome call.

The fix is not a platform. It is a required field and an automatic notification at offer acceptance, carrying only what downstream owners need to begin: name, start date, location and role. That takes an afternoon to build in most systems and it removes the largest single source of variance in the whole process.

And it has to carry changes as well as the original. A start date that moves in the recruitment system and nowhere else leaves every downstream schedule running against the old date, which produces hardware arriving two weeks early and, more seriously, accounts activating on a date nobody is watching.

Where the physical constraint sets the ceiling

One part of the workflow does not respond to process improvement, and recognising it early saves a lot of wasted effort.

Hardware has a lead time that is largely outside your control. A machine has to be available from a supplier, configured, enrolled and physically moved to wherever the person is, and each of those has a floor below which it cannot go regardless of how well the trigger works. For a distributed team this is routinely the longest single stage, and no amount of notification design shortens it.

This matters because process work naturally concentrates on the parts that respond, which are the approvals and the handoffs, and those can be optimised until they are genuinely fast while the overall outcome barely moves. A team that has reduced its internal waiting from six days to one, against a twelve day shipping reality, has done good work and will see very little difference in whether starters are ready.

There are three honest responses. The first is to start earlier, which means the trigger at offer acceptance rather than contract completion, and it is where almost all the available improvement lives. The second is to hold a small buffer of configured machines for common roles, which converts a procurement lead time into a dispatch time and costs capital. The third is to accept the constraint and design around it, with a documented plan for the first days that does not require the person's own device.

Which of those is right depends on how predictable your hiring is. Buffer stock suits steady, predictable hiring and is wasteful for a team that hires in unpredictable bursts. Starting earlier suits everybody and is free.

What does not work is treating a physical constraint as a performance problem and applying pressure to the people managing it. The lead time is a fact about the world, and the only variables you control are when you start and what you do while waiting.

Five questions to diagnose your own

Where does elapsed time actually go? Reconstruct three recent onboardings with timestamps. The answer is almost always concentrated in two or three waits, and they are rarely the ones people complain about.

Which steps have no trigger? Go through the process and ask, for each step, how the owner finds out. Any step whose answer is that they check the document is a step that will fail under load.

What happens when the start date moves? Trace it. If the answer is that somebody tells people, you have a one way integration and a predictable failure.

Who is the deputy for each step? If this takes more than a few seconds per step, it is not written down, which means it does not exist at the moment it is needed.

How does the manager know what they own? The manager is a participant in the workflow and is usually the only participant who is never notified of anything. Their steps exist in somebody else's document.

The manager is in the workflow and nobody tells them

Of all the participants in onboarding, the manager has the most influence on the outcome and receives the least support from the process.

Their steps are real and specific: prepare the first week, arrange introductions, decide what the person works on first, set expectations, be available. These are also the steps most likely to happen on the Sunday evening before, because nothing prompted them earlier and everything else in the manager's week was prompted by something.

What makes this worse is that manager steps have no completion state. Nobody ticks prepared the first week. So in a process where everything else is tracked, the contributions that matter most are invisible, which means they are also the first thing to be squeezed when the manager has a difficult fortnight.

The repair is to treat the manager as a participant rather than as a context. Give them two or three specific, dated items pushed to them rather than published somewhere, phrased as actions rather than as guidance. Two weeks before the start date, confirm the first project. One week before, confirm the introductions. On day one, the conversation about how the team actually works.

The second half of the repair is giving them visibility of everybody else's steps. A manager who cannot see whether access has been granted will do the safe thing and tell the starter directly, in their own words, which is how two versions of the process appear inside a single week. A short scheduled summary of state, pushed rather than visited, prevents most of it.

What should not happen is a manager portal, which is the usual over build. Managers are exactly as unlikely to travel to a destination as their new starters are, and a second place to check becomes a second place nobody checks.

Cohorts change the shape of the problem

Everything above assumes one starter at a time. Hiring in cohorts changes the arithmetic in ways that are not obvious until the first bad week.

The first change is correlation. With one starter, an absent approver delays one person. With four, it delays four, and because they share an approver the delays are not independent. Any workflow designed around average case throughput will fail here, because the burst is the case that matters and the average never occurs.

The second is queueing. Four requests arriving within an hour sit in a queue behind each other, so the fourth person's experience is materially worse than the first's even though nothing went wrong. Teams measuring averages across a cohort report a reasonable number and conceal the person who waited longest, which is the person whose week was actually ruined.

The third is that the requesters are all new simultaneously, so there is no nearby colleague who already knows how things work. A single starter joining an established team absorbs a great deal of informal help. Four starters joining together have each other, which is good for morale and useless for finding out where the expense form is.

The practical responses are modest. Provision from the start date rather than from the request, so cohort volume never becomes a queue. Name a deputy approver specifically for cohort weeks. Report the slowest person in each cohort rather than the average. And accept that a cohort needs more scheduled contact rather than less, which is the opposite of the efficiency instinct that usually accompanies batch hiring.

When the workflow crosses an organisational boundary

Onboarding workflows that stay inside one function are rare. Most cross at least three, and every crossing is a place where the process stops being anybody's.

The characteristic failure is mutual assumption. HR believes IT has been told, because the system shows the record was created. IT believes HR will send a request, because that is how it used to work. Nobody is wrong about their own part and the step between them belongs to neither.

What resolves this is naming the boundary itself rather than the steps on each side. For each crossing, write down what is handed over, in what form, to whom, and what the receiving side does to confirm receipt. That last element is the one usually missing, and it is what converts a silent failure into a visible one. A handoff with no acknowledgement is a handoff that fails quietly whenever anything changes.

Confirmation does not need to be elaborate. A status that moves when the receiving side picks it up is enough, and it gives you a measurable gap between handed over and picked up, which is almost always one of your two longest waits.

There is a harder version where the boundary is to an external party, such as a supplier shipping hardware or a provider handling payroll in another country. The same principle applies and the stakes are higher, because you have no visibility at all into their queue. The thing to insist on there is a committed date rather than an estimate, and a notification when it changes, since an external delay that nobody reports is indistinguishable from a step nobody started.

The tools, and where each one struggles

Matram is our own product, stated here rather than buried, and judged on the same criteria as everything else. It is an answering agent and explicitly not a workflow engine: it reads your documentation and answers questions about process in the channel people already use. That covers a real slice of workflow pain, which is people asking where a step has got to and who owns it, and it covers none of the orchestration. Pricing is flat at $29, $69 and $199 a month with unlimited seats and a 30 day trial that needs no card.

The limits are directly relevant. It has no free tier. It is not an HRIS, so it holds no records and, critically for this article, runs no approval chains and holds no workflow state. Its actions reach HubSpot, Zendesk and webhooks only, so it can open a ticket to start work but cannot advance a step, approve anything or notify an owner that their turn has arrived. WhatsApp is coming soon rather than available. If your problem is stalling, this will not fix it, and a vendor in this category implying otherwise should be treated carefully.

BambooHR publishes Core at $10.25 per employee per month, Pro at $17.50 and Elite at $25 above twenty five employees. It sequences onboarding tasks with owners and due dates, which is genuinely the thing this article is about, and its Pro tier bundles an assistant answering from your own policies. Where it struggles is reach: it orchestrates the HR side well and does not extend into device provisioning or application access.

Rippling starts from $8 per employee per month plus a monthly base fee. Its distinctive property here is that it spans HR, devices and application access, so a workflow step can actually grant something rather than instruct a human to grant it. That removes whole categories of waiting state. Where it struggles is scope, since it is a broad platform decision rather than a workflow fix.

Workday publishes no public rate, its pricing URL returning a 404, so any per employee figure attributed to it is an estimate. Appropriate at enterprise scale, implemented over quarters.

Enboarder is built specifically around onboarding sequencing, nudges and manager prompts, which makes it the most directly relevant specialist here, particularly for the manager participation problem. It publishes no price. Where it struggles is that it assumes you have already decided the process.

Leena AI and Moveworks are enterprise agents rather than workflow tools, and neither publishes a price. The Moveworks pricing page carries a Forrester study rather than a rate card.

Designing for the paths that are not the normal one

Most onboarding workflows are designed around a full time permanent employee starting in a supported location, and then quietly fail for everybody else. The exceptions are not rare in aggregate, and because each one is individually uncommon nobody owns the problem.

Contractors and temporary staff are the largest group. They frequently never enter the HR system at all, being engaged through procurement by an individual manager, which makes them invisible to every downstream trigger. The consequences are not only at the start. Without a joiner event there is no leaver event, so access granted informally is access nobody revokes, and the discovery usually happens during an audit. The fix is a rule rather than a tool: every worker exists in the HR record before any access is requested, whatever the commercial arrangement.

Internal moves are the most under served path. Somebody changing role already has accounts, a device and a history, so the workflow is not creation but adjustment, and almost no process models that. The result is people accumulating permissions across every role they have held, which is both a security problem and the reason internal movers often take longer to become productive than external hires, despite knowing the company.

Rehires are a small category with a sharp edge. Reactivating a dormant account is faster than creating one and carries whatever the account had when it was deactivated, which may be more than the new role warrants. Treating a rehire as a new starter for access purposes, while keeping the historical record, is the version that does not produce surprises.

People starting in a location you have not hired in before need the workflow to pause rather than proceed. Something about shipping, employment arrangement or local requirement will differ, and the failure mode is a process that runs confidently to completion using assumptions from somewhere else. A simple check for whether this location has been used before, routing to a person if not, prevents more problems than trying to model each jurisdiction in advance.

Write down which paths you actually have and which the workflow covers. The gap between those two lists is where your unpredictable onboardings come from, and it is usually a short list that nobody has ever drawn up.

The decision table

Who owns the workflow itself

Every step has an owner, in a well designed process. The process as a whole frequently does not, and that absence produces a specific pattern of decay.

Each function optimises its own section sensibly. IT improves its provisioning, HR tightens its documentation, the manager gets better at the first week. All of it is genuine improvement and none of it touches the handoffs, because a handoff belongs to the space between two owners and improving it requires somebody with standing in both.

So the gaps persist while the parts get better, and the organisation becomes gradually more confused about why onboarding still feels poor when everyone involved can demonstrate their own section works. That confusion is diagnostic. If every function reports that its part is fine and the outcome is bad, the problem is definitionally in the space nobody owns.

The role needed is small and does not require a new position. Somebody has to be accountable for the end to end elapsed time, with enough standing to ask another function why a handoff takes four days. In most companies this sits naturally with whoever owns people operations, provided it is written down as part of the job rather than assumed.

What that person actually does is modest: look at elapsed time per stage once a quarter, notice which handoff has drifted, and convene the two sides. That is perhaps half a day every three months, and it is the difference between a process that degrades slowly and one that does not.

The alternative, which is what most organisations run, is that the workflow is reviewed when something goes badly enough to be discussed. That produces reactive additions, which is how processes accumulate the steps the previous section recommends removing.

Removing steps is the cheapest improvement available

Almost every attempt to improve an onboarding workflow adds something: a tracker, a notification, a review, a new approval to catch the problem that occurred last time. Removal is rarely considered and is usually the better move.

Workflows accumulate steps by the same asymmetry that makes documentation accumulate pages. Adding a check is always defensible, because it addresses something that went wrong and nobody has to justify the ongoing cost. Removing one requires somebody to argue that a safeguard is unnecessary, which is an uncomfortable position to hold if anything subsequently goes wrong. So steps are added after incidents and never retired, and after three years the process contains several checks whose original purpose nobody remembers.

Go through the workflow and ask, for each step, what decision it makes and what has ever happened as a result. A step that has never once produced a different outcome is not a safeguard, it is a delay with a job title. The approval that has been granted every time for four years is the clearest example and usually the longest wait.

Two categories are worth looking at specifically. The first is double checking, where one person verifies work another person has already verified, which tends to reduce the care taken by both. The second is approvals of decisions made elsewhere: if the hire was approved at requisition and the budget was approved at offer, approving the equipment separately is confirming something already settled.

Count what you remove in days rather than in steps. A single approval that adds two days of waiting to every onboarding costs more over a year than most of the tooling anybody is considering buying, and removing it is free.

The one caution is that some apparently useless steps are doing invisible work, usually by creating a moment where a human looks at the whole picture. If you remove a step and the error rate changes, put it back. That is a better test than reasoning about it in advance.

The cost of getting this wrong

The obvious cost is the lost days, and it is the smallest one. A starter idle for two days is two days, recoverable and visible.

The expensive cost is that workflow failures are read as people failures. When a process stalls because a step had no trigger, the conversation afterwards is about whoever did not do the thing, not about the fact that nobody told them. That misattribution is corrosive, it is extremely common, and it makes the design problem harder to see each time it happens, because the organisation believes it has already found the cause.

The second cost falls on the starter and is rarely counted. Somebody whose first week is spent waiting forms a view about how the place operates, and that view is largely accurate. They also learn, early, that things here require chasing, which is a behaviour they will adopt. The cost is not the two days; it is the norm that was demonstrated.

The third is that bad workflows are self concealing. Every task reports success. The dashboard is green. The failure exists only in elapsed time, which nothing measures, so the process looks healthy to everybody who is not the person waiting.

So the question worth asking is not whether your steps get completed. It is how many days pass between a step becoming possible and somebody discovering it was their turn.

What to do when a step fails on the day

However well a workflow is designed, something will fail on somebody's first morning. The quality of a process is partly how well it runs and substantially how well it degrades, and almost nobody designs the second part.

The first thing a degraded process needs is a fallback that does not depend on the thing that failed. If the laptop has not arrived, there has to be a way for the person to do something useful that does not require it. If the account is not ready, there has to be a contact route that does not require the account. These sound obvious and are routinely absent, which produces the circular failure where instructions for what to do when you cannot log in are emailed to the address you cannot log in to.

The second is a named person whose job on day one is to notice. Not a queue and not a shared inbox, because the specific failure here is a new starter who does not know whether to report something and a system that is waiting to be told. Somebody checking in at eleven on the first morning catches most of it, and the check has to be a direct question rather than an invitation to get in touch.

The third is a decision, made in advance, about what the person does with a day that cannot be used as planned. Having an answer ready removes the worst outcome, which is a new starter sitting alone deciding whether it would be rude to ask what they should do. Reading, shadowing a call, or simply being told the day is written off and to go for a walk are all better than the silence that otherwise fills it.

And afterwards, record the failure against the step rather than the person. A log of which steps failed on the day, kept over a year, is the single most useful input to improving the workflow, and it is almost never kept because each individual failure is dealt with and forgotten within the hour.

Building the smallest version that works

If this sounds like a modelling exercise, the useful version is much smaller and takes about a day.

Start with three recent onboardings and reconstruct them with timestamps. You are looking for the two longest waits, and you will find them quickly. Almost every team discovers that the top two account for the majority of their elapsed time, which means the rest of the process does not need touching yet.

Then fix those two, and fix them by adding a trigger rather than by reorganising anything. A notification that reaches the owner at the moment the step becomes possible is usually the entire intervention. If the wait is on an approval, ask whether the approval is doing real work or is ceremony, because a meaningful share of onboarding approvals are confirmations of decisions already made.

Then add the recruitment handoff if you have not already, since it is the largest single source of variance and it sits upstream of everything.

Measure the same three stages again after a month. You are looking for elapsed days per stage, not task completion, because completion was never the thing that was broken. If the two waits have shortened and nothing else has got worse, stop. The remaining steps will tell you when they need attention, and modelling them before then produces a document that describes a process nobody follows.

Frequently asked questions