Letting the Person Who Knows the Fact Record It

A candidate knows their own legal name, address and banking detail with certainty. In most enterprises they write it on a form, send the form to a shared mailbox, and an administrator types it into the platform. Two hands between a fact and its record, each of which can drop a digit, and a record that then feeds pay, tax, benefits enrolment and every downstream report.

Nobody designed this. It is a survival of the period when the system belonged to HR and nobody outside HR could reach it. That constraint went years ago, and the process shaped around it stayed.

What actually happened

Recruitment, onboarding and performance all ran on one platform in the business where Polymath’s founder held global HR shared services — a consumer packaged goods business that had gone public on the TSX, roughly $2–3 billion in revenue, with payroll to run in approximately 21 countries. A single platform is the condition that makes what follows possible. It is not by itself the change.

Before the redesign, the sequence was ordinary and would be recognized in most companies. A candidate accepted an offer. A pack of forms went out by email. The candidate completed them and sent them back. An administrator opened each one and typed its contents into the platform — name, address, banking, emergency contact, right-to-work evidence, tax details. A recruiter separately entered the job, grade, location and start date from the offer approval. A business partner checked that the resulting record looked right.

Every one of those people was doing their job well. The errors that reached payroll were not carelessness. They were the arithmetic of transcription: the more times a fact is copied by someone who does not own it, the more often one copy differs, and the copy that differs is discovered by the new joiner, on their first pay.

The redesign gave the candidate a log-in. They entered their own details directly into the platform, at the point where they were the only person who could be certain of them. Nothing was emailed. Nothing was keyed by anyone else.

Two things followed that the business case had not been built on. The first was that the business partner’s job changed shape. With no data to enter, what remained was the part that had always mattered and had never had time — reviewing whether the hire was right, whether the grade and cost centre matched the approved position, whether anything in the record contradicted anything else. Approval points went up rather than down. What had been removed was transcription; what was added was judgment, and only one of those had ever been the point. The second was that the manager got something they had never had. Because the candidate’s record existed and was complete before day one, preboarding could be built on top of it: a welcome, an introduction to the team, the first week arranged, all of it before the start date rather than during a first morning spent filling in forms. Capacity released by the redesign went into a step that had not previously existed, which is a more honest description than saying the team was freed for strategic work.

Payroll accuracy improved as a direct consequence, and not because anyone checked harder. There was simply nothing left downstream that had been typed twice.

Why it happens

The mechanism is a rule nobody wrote down: the person who records a fact is chosen by who has access to the system, not by who knows the fact.

That rule made sense once. Enterprise systems were licensed by seat, administered centrally, and unreachable by anyone outside the function that owned them. A candidate could not log in because there was no log-in to give them, so a form was the only available interface and an administrator was the only available typist. Everything about the process — the pack, the mailbox, the queue, the checking — is an adaptation to that single constraint.

The constraint is gone. Modern platforms are built for the workforce to reach, external candidates included. But process design does not automatically follow a licensing change, because nobody is accountable for noticing that a reason has expired. The form stays. The mailbox stays. The administrator role is now defined by the typing, which makes the typing difficult to question from inside.

Two consequences follow, and they compound in opposite directions.

The first is error, and it behaves predictably. Transcription error is roughly proportional to the number of hands a fact passes through, and it concentrates in exactly the fields that are hardest to sight-check: a bank account, a tax identifier, a legal name spelled differently from the one the person uses daily. Those are also the fields that fail loudest, because they fail in pay.

The second is that checking gets confused with doing. When the same person types a record and is also nominally responsible for it being right, the typing absorbs all the available time and the checking becomes a glance. The organization believes it has a control. What it has is a second transcription performed by someone who is now too familiar with the data to see it.

Which is why the familiar fixes disappoint. A better form reduces ambiguity without removing a transcription. A quality check adds a third person to a chain whose length was the problem. Training an administrator to be more careful addresses a failure of design as though it were a failure of attention. Each is reasonable. None of them moves who is holding the pen.

And it explains why this is a change management paper rather than a process one. Removing the transcription removes what several jobs largely consisted of. An administrator whose week was data entry and a business partner whose review was a formality are both being asked to do work they have not been doing, and in the case of the business partner, work that is harder and more exposed than what it replaces. That is the change, and no configuration decision addresses it.

The strongest objection

The strongest case against this: candidates make mistakes too, and a trained administrator entering data carefully is more reliable than an anxious applicant filling in fields on their phone.

That is worth taking seriously, and it is half right. Candidates do make mistakes. But the errors differ in kind, and the difference decides the argument. A candidate who mistypes their own account number can be shown the field and will recognize it immediately, because they know what it should say. An administrator who mistypes it cannot, because they have no independent knowledge of the correct value — their only reference is the form, and re-reading the form is what produced the error. One error is self-correcting on sight. The other can only be found downstream, by its consequence.

The second objection is the more serious one: this shifts work onto the candidate, and a clumsy onboarding experience costs offers in a competitive market. It would, if the work were new. It is not — the candidate was already completing the same fields, on a form, at the same point in the process. What changes is that they complete them once, in the system, instead of once on a document that somebody then copies. Where this genuinely goes wrong is when the platform’s external experience is poor and nobody has looked at it, which is a real risk and an addressable one. It should be tested on actual candidates before it is switched on, which is not an argument against the design.

The method

Six steps. One and two find the transcriptions, three and four remove them, and five and six deal with what that does to people’s jobs. We do not reorder them, and the last two are the ones programmes skip.

1. We map the process by field rather than by step. For every field that ends up in the employee record, we write down who knows it first, who currently types it, and how many hands we count between the two. The trade-off we accept: this is slower than a swim-lane and it produces an unglamorous spreadsheet rather than a diagram. Skip it and you will automate the steps you can see instead of the copies you cannot.
2. We follow the errors backwards from payroll. We take a recent run of new-joiner exceptions and trace each one back to the field and the hand that produced it. The trade-off we accept: this names individuals, so we do it on the understanding that the finding is about the design and we say so out loud before we start. Skip it and the case for change rests on principle, which loses to a functioning status quo.
3. We give each fact back to its source. We have the candidate enter their own details, the manager enter what only the manager knows, and the business partner enter nothing at all. Where we find a fact that genuinely cannot come from its source, we record why and we treat it as a known exception rather than as the default. The trade-off we accept: it requires the platform’s external experience to be good enough to put in front of someone deciding whether to join you. Skip it and every later step is decoration on an unchanged chain.
4. We convert the removed keying into named approvals. This is the step that is nearly always missed. When we take data entry out of a role we leave a gap, and we fill it with the judgment the entry was crowding out — does this record match the approved position, does the grade match the offer, does anything here contradict anything else. We write each approval down with a name against it. The trade-off we accept: the process gains steps, which reads badly in a business case promising simplification. We argue it on accuracy instead, because that is where we can show it paying. Skip it and the chain is shorter and nobody is looking at it, which is a weaker control environment than the one you started with.
5. We rewrite the affected job descriptions in the same release as the configuration. We treat an administrator who no longer keys and a business partner who now reviews as doing different jobs, because they are, and if we leave the descriptions and objectives describing the old ones, people will do the old ones. The trade-off we accept: HR is now changing its own roles in public, which is uncomfortable and also establishes the credibility to do it anywhere else. Skip it and the roles drift back toward what their descriptions still say they are.
6. We spend the released capacity on a step that did not exist before. Preboarding is the obvious one and it is where we usually point it: because we have the record complete before day one, a manager can build a welcome, an introduction and a first week on top of it. The trade-off we accept: this looks like scope beyond the automation, and it is the part that persuades everybody involved that the change was worth having. Skip it and the freed hours quietly refill with the work they replaced.

The order matters because step four carries the outcome. The accuracy gain comes from removing transcription; the durability comes from replacing it with judgment that has a name on it. A programme that does three and stops has a faster process with nobody reviewing anything, which is a worse control environment than the one it replaced.

Evidence and measures

The employee record, by who actually knows each fact:

Five measures worth tracking over ninety days. None of them requires a new system:

— Number of hands a single fact passes through between its source and the employee record. Track the worst field, not the average.

— Proportion of new-joiner payroll exceptions traceable to a field recorded by somebody other than its source. — Elapsed time from offer acceptance to a complete, approved employee record.

— Share of an HR administrator’s week spent entering information that arrived in writing from someone else.

— Ratio of approval steps to transcription steps in the process. This one should invert, and the date it inverts is the date the change actually happened.

Watch the last two together. Capacity released and never reassigned is a saving that reverses.

How Polymath solves this

We begin with the field map, not the platform. One Hire to Retire process, every field in it, and a written answer to who knows this first and how many hands touch it — which takes days and is normally enough on its own to settle whether there is a case. From there we redesign the flow so each fact is entered once by its source, and we specify the approvals that replace the keying. The discipline is Change Management, because the configuration is the part of this that was never difficult.

We do the work against the platform and the processes you already run, with the administrators and business partners whose jobs are the ones changing. They are in the room for the redesign rather than briefed on it afterwards, and they write the approval definitions themselves, since it is their own judgment being put on paper. We rewrite the job descriptions and objectives in the same release as the configuration, run one full hiring cycle alongside the team, and hand the next one over.

What accumulates is the principle rather than the process. Once an organization has established that a fact is recorded once, by whoever holds it, with an approval rather than a re-key downstream, the same test applies to every other process in the estate — expenses, time, vendor onboarding, master data. By the time it is applied somewhere else, the argument has already been had and the job-design work that makes it stick has already been done once in public, which is most of what usually makes it slow.

What it costs to do nothing

The visible cost is the error rate, and in money it is usually modest. Corrected payments are not what moves a P&L.

The second cost is where it lands. A payroll error at the start of someone’s employment is the first operational promise your company makes to a person who has just left another job to join you, and it is a promise about competence. The population it hits hardest is new joiners, which is the population with the least accumulated goodwill and the shortest route back to the market. That cost never appears as a payroll line. It appears in early attrition and in what people say about you to the next candidate.

The third is capability, and it accrues quietly. Every quarter that keeps transcription in the process keeps a group of capable people doing work that a log-in makes unnecessary, and keeps a business partner’s review at the level of a glance. Those are the same people you will need when something genuinely requires judgment — a restructure, an acquisition, a country going live — and they will be practised at typing rather than at deciding.

None of this requires a platform decision. It requires one question asked of one process — who knows this fact — and then the work arranged so that person is the one who records it. The question is available to you now, and putting it to a process is what we are for.