Offer Accepted. Five Systems Need to Know.

An offer is accepted. It is the happiest email the company gets all week, and it starts a chain that nobody owns. The recruiter has the candidate in one system. The people team needs an employee in another. Payroll needs a pay record. Finance needs a cost centre. The sales manager needs a user with a territory by Monday. Five systems, the same seven facts, and at most companies of our size a spreadsheet between each pair. Everything on screen is a mock demo with sample data: an invented company, an invented hire, and Zoho applications as the example set, because they are the ones we configure; the shape is the same whichever vendors you run.

Here are the five. Zoho Recruit holds the candidate: the application, the interviews, the offer. Zoho People will hold the employee: the record, the manager, the leave, the start date. Zoho Payroll needs the pay, the bank details and the tax form. Zoho Books needs the cost centre and the budget line the salary comes from. And Zoho CRM needs a user, a role and a territory, because this hire is a sales rep. Now the seven facts every one of them needs: legal name, start date, job title, manager, location, pay, cost centre.

Seven facts, five systems. Written by hand, that is thirty-five fields typed from one offer letter, by four different people, over about two weeks. The sixth system is the one nobody lists: the internal technology team, which needs the same facts to order a laptop and create a mailbox. Six readers, then, and the argument is the same. This is how it actually happens. The recruiter exports the offer to a spreadsheet and emails it to the people team, who type it into the people system. The people team sends a different spreadsheet to payroll, who type it again, and a third to finance for the cost centre.

Nobody sends anything to the sales manager, who creates the user himself on the Friday before the start date and guesses the territory. Each copy drifts a little. The start date moves by a week and reaches payroll but not the people system, so the first pay run is wrong. The title on the offer letter and the title in the sales system differ. These are the two numbers the theme behind this video measures: days from offer to a productive first week, and hours re-keyed per pay run. Both are large, and both are invisible because no system records the chain.

Ask a people team how long an offer takes to become a correct first pay run and a working login, and the honest answer at a company this size is usually two to three weeks, most of it waiting for a spreadsheet to be opened by the next person. The fix is one decision: which system is the employee record, and the answer for a company our size is the people system, Zoho People in this demo. The hiring system hands the candidate over once, on offer accepted, and from that moment the employee exists in exactly one place.

Payroll reads the pay facts from it. The accounting system reads the cost centre from it. The sales system creates its user from it, with the role and territory the manager chose on the people record, not on a Friday afternoon. Ownership also decides who edits. The start date moves? It moves on the people record, and every system that reads it sees the move. The hiring system is closed to edits once the offer is accepted; payroll never types a name. One owner per fact, the same rule we apply to a stock count or an invoice, applied to a person.

This is the same rule the written piece on the resource planning system and the sales system draws: each system is the record for different facts, and trouble starts where two of them compete for the same one. For a person, the people system wins, and the sales system holds only what it needs to log her in. With one record, the onboarding checklist can be a workflow instead of a memory. On offer accepted: create the employee, assign the manager, open the document requests for the tax form and the bank details.

Ten days before the start: create the payroll record from the people record, create the sales user, order the laptop, which is the internal technology team's one task and the only one that needs a person to carry a box. On the start date: the first pay run already has the right amount, the sales user already has the right territory, and the manager's first task is a conversation, not a form. Every item on the checklist reads the seven facts from the one record. Nothing is typed twice. The chain that nobody owned now has an owner, the people record, and a clock, the start date.

When a hire falls through before the start date, the same record carries the cancellation: one change on the people record, and the pay record, the user and the laptop order are withdrawn by the same checklist running backwards, instead of three people being told in three emails. Offer accepted; five systems need to know; seven facts; one record. Decide which system owns the employee, hand the candidate over once, let the other four read, and run day one as a checklist that reads the record. Measure it in the two numbers the spreadsheet hid: days to a productive first week, and hours re-keyed per pay run.

If you want to see where your own chain re-types, that is a no-risk discovery, paid only if you proceed. We are CodeStringers. We design, build and run business systems for companies of fifty to a thousand people. The Zoho People explainer is linked below.