Somebody in a 60-person company owns a spreadsheet called Onboarding. It has a row per new hire and a column per thing that has to happen: offer signed, HR forms, laptop, email account, CRM login, manager briefed, payroll set up. It is maintained with real care, and it fails on day one with real regularity, and the failure is never written down anywhere because the spreadsheet is the record and the spreadsheet says every box was ticked.
The failures are specific, they repeat, and they are not an HR problem. They are five handoffs between five systems that the spreadsheet cannot see.
A hire moves through five systems before they can do a day's work. The offer lives in the recruiting tool or an email thread. The person's record lives in HR, which at this size is often the spreadsheet itself. Their accounts live in IT: the identity provider, the laptop, the email, the CRM seat. Their start date, team and manager live with the manager, who has a calendar and a plan. Their pay lives in payroll, and the cost lives in the books.
Each boundary between those is a handoff: a fact that one system holds and the next one needs. The spreadsheet records that the handoff was meant to happen. It cannot record that it did, because it is not connected to any of the systems that would know.
The offer goes out from the hiring manager's email and comes back signed. The spreadsheet gets a row when someone remembers to add one, which is usually the following Monday. Everything downstream starts late by that gap, and the gap is invisible, because the row's date is the date the row was created.
The fix is not a reminder. It is the signed offer creating the record, so that the start of onboarding is an event in a system rather than a memory in a person.
The row says laptop and email: pending. IT reads the spreadsheet when IT remembers to, or when the manager asks on the Friday before. The laptop is ordered with two working days to spare and arrives on Wednesday. The email account is created on the morning, which means the calendar invitations sent the week before went nowhere.
This is the handoff that most often lands on the new hire's first morning, and it is the one a spreadsheet is worst at, because the request to IT is not a state the spreadsheet holds. It is a message somebody sends. The fix is the hire record raising the IT tasks, with their due dates counted back from the start date, into the tool IT actually works from.
The email account works. The CRM seat was never assigned, or was assigned with the default role, which can see everything and edit nothing, or can edit everything. The shared drives are a request to someone who is on holiday. The new rep spends the first week asking for access and the second week discovering they had too much.
We wrote the CRM half of this up as a checklist in the Zoho CRM user onboarding checklist, and it is the right checklist. The failure here is upstream of it: nothing told the CRM administrator that a person with this role was starting on this date, so the checklist was never opened. Role-based access is a fact about the hire that the hire record should carry, and the systems should read.
The manager wrote a first-week plan: who to meet, what to read, which customers to shadow. None of it is in a system. The plan is in a document, the meetings are in the manager's head, and when the manager is pulled into a customer problem on Tuesday the plan stops. The hire has a laptop, a login and nothing to do, and reads that as a verdict on the company.
The fix is small and almost never done: the plan as tasks against the hire record, owned by the people in it, visible to the manager as a state rather than a document.
The cut-off for the month's payroll was the 20th. The hire started on the 22nd. Nobody added them to the payroll system, because the spreadsheet's payroll column was ticked when HR sent the forms, not when payroll confirmed the record. The first pay is late by a month, with an apology and a manual payment that the books then record twice.
This is the failure that gets escalated, because it is the one with money in it. It is also the clearest example of the pattern: the spreadsheet recorded an intention as a completion. The fix is payroll's confirmation being the state, written back to the hire record, not HR's request.
Every one of the five is a handoff where one system held a fact and the next one needed it, and a person was the only wire between them. The spreadsheet did not cause the failures. It just made them invisible, because it recorded what was supposed to happen and had no way to know what did.
That is why the employee onboarding process is an integration problem before it is an HR software problem. Buying an HR system helps, and we have written about when Zoho People is worth adopting, but an HR system with the same five handoffs done by email reproduces the same five failures with a nicer interface. The thing to build is the chain: the hire as one record, each handoff as a state that the receiving system sets, and the exceptions, the hire who starts mid-cycle, the contractor converting, the rehire, written down rather than remembered. We made the general case for that last point in write down the exceptions.
Count last quarter's hires and, for each, write down which of the five failures happened. Most companies find three of the five in every hire and had never counted them, because nothing was logging them. Then take the most expensive one, usually payroll or IT, and make it a state the receiving system sets.
This is integration work done by engineers, not a template, and it is the kind of work we do under a guaranteed estimate. Discovery is no-risk: we map your five handoffs, show you which ones have no wire, and you pay only if you go ahead.
In a no-risk discovery we look at your CRM, finance and operations systems and who owns each part, and show what a connected system would do differently. You pay only if you proceed. Or see how we approach it.
More on the same problem:
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
