Rolling out automation without a team revolt

The short answer

This guide covers the part of the project that starts after the system works. The code is done, the evals pass, and twelve people who did not ask for any of this have to change how they work on Monday. That transition has its own failure modes, as specific and as diagnosable as a retry bug.

Why rollouts fail, and it is rarely the software

Rollouts fail for four reasons, and model quality is not one of them. The system replaced a step without replacing the accountability attached to it. The old path was closed before the new one had earned it. Nobody could see what the automation had done, so checking meant redoing the work. Or the queue of things the machine could not handle grew silently until it became somebody's second job.

Each has a signature you can watch for and a fix that is structural rather than persuasive. No amount of internal comms fixes a system whose output cannot be inspected.

The Reversal Ladder

Give the machine autonomy in rungs, and define each rung by two properties only: who commits the action, and how expensive the undo is. The second is the one usually left out, and it is the one that decides how much evidence you need before climbing.

The rungs also answer the question people actually ask, which is not "is it accurate" but "what happens when it is wrong". At rung 2 a human catches it in the normal course of work. At rung 3 anyone can cancel it for half an hour. At rung 4 the answer has to be a documented reversal procedure, and if you cannot write that procedure you are not ready for rung 4.

# rollout.yaml -- one file per automation, read at boot, changeable without a deploy
automation_id: invoice-triage
rung: suggest                 # shadow | compare | suggest | act_with_hold | act
owner: name of the human who is paged
descend_authority: [ops_lead, on_call_engineer]   # who may drop a rung, no approval needed

rungs:
  shadow:
    writes: none
    human_sees_output: false
    exit_when: "runs >= 500 and crash_rate < 0.5%"
  compare:
    writes: log_only
    human_sees_output: after_commit
    exit_when: "agreement_rate >= 0.85 over the last 300 records"
  suggest:
    writes: draft_field_only
    human_sees_output: before_commit
    exit_when: "median_edit_ratio <= 0.05 and p90_edit_ratio <= 0.40 over 300 records"
  act_with_hold:
    writes: real
    hold_minutes: 30          # action is queued, visible, and cancellable for this long
    exit_when: "reversal_rate < 1% over 400 actions and zero severity_1 reversals"
  act:
    writes: real
    sample_review_pct: 5

descend_triggers:             # any one of these drops the rung automatically
  - "reversal_rate > 3% over any rolling 100 actions"
  - "any severity_1 reversal"
  - "exception_queue_age_minutes > 240"
  - "upstream schema hash changed"

manual_path:
  status: live
  restart_minutes: 15         # measured, not estimated, by an actual drill
  drill_cadence: monthly
  sunset_when: "rung == act for 60 days and reversal_rate < 0.5%"

Edit distance is the instrument nobody installs

At rung 2 you get a measurement almost nobody captures: how much the human changed before committing. Store the draft and the committed version for every record, compute a normalised difference, and you have a continuous quality signal generated by work people were doing anyway. No annotation project, no eval budget.

Report the distribution, not the average. A median near zero with a ninetieth percentile near total rewrite does not describe a system that is mostly good. It describes two populations: one class of input the system handles perfectly and another it cannot touch. Find the feature that separates them, route the second class to a human, and perceived accuracy jumps with no change to the model.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "review_event",
  "description": "One row per record a human touched. This is the rollout instrument.",
  "type": "object",
  "required": ["record_id", "automation_id", "rung", "machine_output",
               "committed_output", "reviewer_id", "seen_at", "committed_at"],
  "properties": {
    "record_id":        {"type": "string"},
    "automation_id":    {"type": "string"},
    "rung":             {"enum": ["shadow","compare","suggest","act_with_hold","act"]},
    "input_hash":       {"type": "string", "description": "so you can group by input class later"},
    "machine_output":   {"type": "string"},
    "committed_output": {"type": "string"},
    "edit_ratio":       {"type": "number", "description": "0 = accepted as written, 1 = fully rewritten"},
    "override_reason":  {"enum": ["wrong_fact","wrong_tone","missing_context",
                                  "policy","format","other", null]},
    "reviewer_id":      {"type": "string"},
    "seen_at":          {"type": "string", "format": "date-time"},
    "committed_at":     {"type": "string", "format": "date-time"},
    "reverted":         {"type": "boolean", "default": false},
    "revert_reason":    {"type": ["string", "null"]}
  }
}

• Edit ratio. A character or token level diff normalised to the committed text length. The algorithm matters far less than using the same one every week.
• Override reason. A short closed list, chosen in one click. Free text does not get filled in, and a reason taxonomy is what turns a complaint into a backlog item.
• Time from seen to committed. Rising while edit ratio falls means people stopped reading and started rubber stamping.
• Input hash or class. Without it you cannot segment, and segmentation is where the wins hide.
• Reverted flag, set later. Committed then undone an hour afterwards is a different failure from edited before committing. Count it separately.

Watch the rubber-stamp signature specifically. Acceptance rising while review time falls towards a couple of seconds means you have all the risk of rung 4 with none of the sampling discipline. When you see it, either climb to rung 3 honestly or make review harder by showing only the parts the model was least confident about. Half-attention review manufactures a paper trail of approval nobody actually gave.

Tell people in the right order

Announcement order is a design decision, not a courtesy. The person whose name is attached to the output hears first, and nobody learns about the change from the tool itself. Discovering that your job changed by noticing a new button turns a rollout adversarial in one afternoon.

1. The people doing the work today, individually, before any group announcement. Ask them what the automation will get wrong. They will be right, and their list becomes your test set.
2. Their manager, with a specific answer on headcount and workload. Refusing that question is itself an answer, and the team hears the loudest version of it.
3. The wider team, demonstrated on real records rather than slides. Show a failure on purpose, because a demo of only successes is believed by nobody who has worked with software.
4. Anyone customer facing, with the escalation path written down. They will be asked "was that a bot" and they need a true sentence to say.
5. Everyone else, including whoever inherits it later. Keep it short and link the runbook rather than restating it.

Keep the manual path alive, and sunset it on evidence

Keep the old path running until the numbers say otherwise, and make the sunset a threshold rather than a date. Dates get set in a plan written before anything was known, then defended out of pride. Thresholds get met or they do not.

Two paths cost real money and you should say so rather than pretending otherwise. It means two sets of permissions, two places a record can be created, and a reconciliation job to catch drift between them. Budget for the drill as well: once a month, push a real piece of work through the manual path and time it. A fallback nobody has exercised in four months is a story people tell each other about a fallback. The drill also tells you when the manual path has genuinely died, which is the honest moment to declare the sunset. See the baseline you take before any automation for what to measure on that run.

What to watch while the rollout is live

Six numbers, on one screen, read daily by a named person. Anything more and nobody reads any of it. Each metric needs a defined response, because a metric with no attached decision is decoration.

Coverage deserves a note. If the machine handles a falling share of total volume while quality metrics look fine, people are diverting work around it for reasons they consider obvious and have not mentioned because nobody asked. That is a workflow design signal, not a model signal, and it appears in no quality metric. The same applies to work arriving through a channel the automation does not watch, which is how a shared inbox becomes the escape hatch. Automating a shared inbox covers that case.

How much review capacity a rollout actually needs

Review capacity is the constraint discovered late and it hurts most. A rollout needing more human attention than the team has will either stall or degrade into rubber stamping, and both look like quality problems when they are staffing problems. Run the arithmetic before picking a sampling rate.

The third output is the one that changes decisions. Reviewing a small share of a small volume for a short window can leave you unable to rule out a fault rate of several percent, and several percent of a customer-facing action is not a rounding error. If it comes back uncomfortable you have three levers: review more, run longer before climbing, or accept the risk in writing with the person whose budget carries it. Quiet hope is not a fourth lever.

The rollout checklist

Work through this before the first real record touches the automation. Most items take under an hour, and every one is cheaper now than in week three. Ownership questions in particular are far easier to settle before launch, which is the argument of who owns the automation after launch.

The vocabulary, used precisely

Rollout terms, defined

Shadow mode

Running an automation against live production input while writing its output only to a log that nobody uses in the workflow. It tests throughput, integration and crash behaviour without exposing anyone to the results.

Edit distance, or edit ratio

The normalised difference between the output a machine drafted and the version a human committed. Zero means accepted as written, one means fully rewritten. Tracked as a distribution, it is the cheapest continuous quality signal in a rollout.

Reversal window

A deliberate delay between an automated action being committed and taking effect, during which any human can cancel it. Its length is set by how long a person realistically takes to notice.

Descend trigger

A pre-agreed condition that automatically reduces an automation's autonomy without a discussion, a deploy or an approval, such as a reversal rate crossing a threshold or an upstream schema changing.

Rubber stamping

A reviewer approving machine output without reading it, visible as acceptance rate rising while time between seeing and committing falls. It carries the risk of full autonomy while producing a false audit trail of approval.

Sunset criterion

The numeric condition under which the manual fallback path is retired, stated before the rollout begins. It replaces a cutover date, which is a commitment made when the least was known.

One closing note. Every rollout produces a version of the sentence "the system is fine, people just need to use it". Treat it as a bug report about the design. People route around automation for reasons that are legible once you ask, and they are specific: an exception type nobody handled, a field that is not shown, a customer who always calls. If the programme is to survive past the third automation, those reasons are the backlog. Business process automation is mostly this work, not the model.