Automate the right things: human-in-the-loop for service desks

Every service desk has an automation story that ends badly. The auto-responder that told a furious customer "we're happy to help!" The ticket-closing rule that closed a director's open issue. The chatbot that confidently walked a user through resetting the wrong system's password.

What these have in common isn't bad technology. It's that something was fully automated that should have been assisted, and the desk found out in production, in front of a user. One incident like that and the team's appetite for automation drops to zero for a year. The engineers aren't wrong to be wary; they're the ones who clean up.

The way out isn't less automation. It's a different default: human-in-the-loop first, full automation only after the numbers earn it.

Draft, review, send

The pattern is almost boring, which is its strength. The machine does the work; a human approves the work; only then does anything leave the building.

AI drafts the first response, the engineer reads it for five seconds and hits send, or fixes the one wrong sentence first. AI proposes the ticket category and priority, the dispatcher confirms with a keystroke. AI writes the KB article from the resolved ticket, the resolver skims and publishes.

Notice what this does to the failure mode. Fully automated, an error reaches the customer at machine speed. Human-in-the-loop, an error costs one person five seconds of correction. Better still, it gets noticed, which means it can be fixed at the source. You keep perhaps 80 percent of the time saving and roughly zero percent of the reputational risk. For a service desk, that trade is nearly always right on day one.

What to automate first

Rank candidate tasks on two axes: how often it happens, and how bad a mistake would be. High frequency, low blast radius wins. That points away from the flashy candidates and toward the unglamorous ones, which is correct.

First responses on the five most common ticket types. Categorisation and routing. Escalation summaries. Closure notes. Chasing users for information on stale tickets. None of these will make a conference talk, and together they're often a quarter of a desk's keyboard time.

Be equally clear about what waits: anything irreversible (deletions, access revocation), anything with compliance weight, anything customer-visible where tone matters more than speed, and anything you couldn't cleanly undo. Not never. Just not first, and not without the pattern above.

Before anything goes live

Automation earns production the same way a change does: with a pre-launch check. Has it run in shadow mode alongside a human for a couple of weeks? Do you know its error rate on your real tickets, not the vendor's demo set? Is there a visible way for any engineer to flag a bad output, and does someone own reading those flags? Is there an off switch that doesn't require a developer?

That last one sounds paranoid until the Friday afternoon you need it. Every automated flow should have a kill switch a shift lead can flip, because the alternative is engineers manually racing a machine that's sending wrong answers faster than they can apologise.

We keep both of these as one-page checklists in the Opstimio library, a human-in-the-loop design check and an automation pre-launch check, because this is exactly the kind of discipline that evaporates in the excitement of shipping. The desks that use them tend to be the ones whose engineers still trust the tooling a year later, which is the entire game.

Graduating to full automation

Some flows do earn autonomy. The bar should be numeric, not vibes: after a defined shadow period, if the human reviewers changed the machine's output in fewer than some agreed percentage of cases (teams commonly land between 2 and 5 percent), the flow can run unattended, with sampling instead of universal review.

Keep the sampling forever. Ten percent of outputs, reviewed weekly, on a rota. Models drift, ticket mixes shift, and vendors push silent updates; sampled review is how you notice before your customers do. And publish a monthly health number for each automated flow, even if it's just in the team channel. Automation that nobody watches degrades in the dark, and dark degradation is how the next bad story starts.

Do it in this order (assist first, measure, graduate the winners, keep watching) and automation stops being the thing that burned the team once. It becomes what it should have been from the start: the desk's quietest, most reliable colleague.