JAWC
  1. Home
  2. Notes
  3. The handoff tax

The handoff tax

5 min readworkflowhandoffsautomationprocesscutover

Manual handoffs between systems cost delay, errors, and lost context. How to find each one, score it, remove the best ratio first, and cut over safely.

Every time a person moves data or a decision from one system to another by hand, the organization pays a tax. It is small per transaction and it never stops. Most organizations have never added it up, so they pay it in overtime, in rework, and in the week it takes to close a request that should take an hour. This note is how we find the tax, score it, and remove it in the right order.

What a handoff is

A handoff is a person carrying something from one system to the next because the systems do not talk. The thing carried is data (an order, an address, a signed form) or a decision (approved, rejected, assigned to you). The carrying is re-keying, copy and paste, an export and an import, a forwarded email, a message that says “can you put this in the system”.

The person who does it rarely calls it a handoff. They call it their job. That is why it hides.

The three costs

Each handoff charges three times.

Delay. The record waits in an inbox until the person gets to it. The wait is hours in a good week and days when they are out. Every handoff in a chain adds its own wait, and the chain is what the customer feels.

Error. Re-keyed data is wrong at a steady rate. A digit in a phone number, a wrong status, a form attached to the wrong record. The error is not found at the handoff. It is found two systems later by someone who does not know where it came from.

Lost context. The decision was made in an email thread. The system got the outcome and none of the reasons. Six months later, nobody knows why the account was flagged, and the thread is in a mailbox that belongs to someone who left.

How to find them

Sit with the person who does the work and walk one record through the whole process. Ask one question at every step: where does this go next, and how does it get there. Write the answer down in their words. Do not ask for a process map. Ask to watch the process.

Five things give handoffs away.

  • An inbox that is a queue. If “check the shared mailbox” is a step, that is a handoff.
  • A spreadsheet that is a system. If a sheet holds state that no other system holds, every row in it was keyed by hand.
  • An export. If a report is downloaded to be uploaded somewhere else, that is a handoff with a weekly or monthly delay built in.
  • A reply-all approval. If a decision is made by someone writing “approved” in an email, the decision lives in the email and the system gets it later, by hand, if at all.
  • A portal with no integration. If someone logs in to a vendor or agency portal to type in what the CRM already knows, that is a handoff at both ends.

Count them. One process has more than you expect. You will not remove all of them. You will remove the right ones.

How to score them

Score each handoff with three numbers: how often it happens, what an error costs, and how much delay it adds.

Frequency is per month. Error cost is the hours lost when one goes wrong, scaled by how often one goes wrong. If one in ten is wrong and a wrong one costs ten hours to find and fix, the error cost is one hour. Delay is the hours a record sits waiting, on an ordinary day.

Multiply the three. The units mean nothing. The ranking is what matters. Then estimate the effort to automate, in days, and divide. The ratio is the score per day of work.

The table is an example. The four handoffs are invented, and so are the figures.

Handoff (example) Per month Error cost (h) Delay (h) Score Effort (days) Ratio
Invoice approved by reply-all, then keyed into finance 300 1 36 10,800 20 540
Signed quote re-keyed into the CRM as a closed deal 120 2 24 5,760 5 1,152
New hire request emailed to IT, created in three systems 25 4 48 4,800 8 600
Monthly case export pasted into a board report 1 8 72 576 3 192

Remove the best ratio first, not the biggest

In the example, the invoice handoff has the biggest score and the third-best ratio. The finance system has no API, so the work is twenty days before anyone sees a result. The quote handoff is half the score and a quarter of the effort. Do it first.

The reason is not only arithmetic. The first automated handoff teaches the organization what automation looks like: who gets the failure message, how the cutover runs, what it feels like to stop doing a step. A quick first win buys patience for the twenty-day one. A twenty-day first project that slips to thirty buys nothing.

Run both

Do not switch a handoff off the day the automation ships. Run both. The automation does the handoff, the person keeps doing it the old way, and every day someone compares the two. Any difference is a bug, in the automation or in the old process. Fix it and keep comparing.

Agree the exit before you start: two weeks with no differences, or fifty records, or one full billing cycle, whatever fits the rhythm of the work. When the exit is met, the person stops. They do not go away. They become the owner of the failure path.

The failure path rule

Every automated handoff must report its failures to a named person, with the record attached. Not a log line. Not a dashboard someone might check. A message to a person, with the record ID, the payload that failed, the error, and what to do about it.

This is the rule most automation breaks. A manual handoff fails loudly, because a person notices the inbox is full. An automated handoff with no failure path fails silently, and the tax comes back as a pile of records that nobody has seen for a month. Automation without a failure path moves the handoff from visible to invisible. That is worse than the tax.

Ten questions to ask about any handoff

  1. Who does it, and what happens when they are out?
  2. How many times a month does it happen?
  3. How long does a record wait before it is picked up?
  4. How often is it done wrong, and where is the error found?
  5. Where does the decision get recorded, and where do the reasons go?
  6. What does the receiving system need that the sending system does not have?
  7. Does either system have an API, a webhook, or a scheduled export that already runs?
  8. Who is told when it fails, and how?
  9. What is the smallest version of this handoff we could automate this month?
  10. If it ran itself for a year, what would the person do with the time?

The last question is the one to ask out loud. The answer is the business case. See Workflow automation for how we take it from there.

Related service: Workflow automation. All notes.

Sound familiar?

Have a system like this?

Tell us what fails, and how often. We answer in one business day with a first read and a clear next step.