AI for operations teams: the work nobody has time to write down

Ask an operations lead what would break if a particular colleague left, and the answer arrives in about four seconds. Ask where that process is written down, and it takes rather longer. AI for operations teams belongs exactly there, in the space between what an organisation knows and what it has ever recorded.

The evidence is better than the usual hand-waving. Of the work people give Claude Cowork, Anthropic's agent for general knowledge work, 33.4% is business process work: compiling reports, reconciling spreadsheets, the administrative middle of a company. Software development is 8.7%. Whatever the coverage suggests, the centre of gravity for this technology is your function, not engineering.

Documentation, built from the mess you already have

Nobody writes a procedure from a blank page, which is why the procedure never gets written. Start instead from what exists: the message thread where an exception was agreed, the email chain, a transcript, or five minutes of you talking through the steps into your phone while walking to the station.

Ask for a numbered procedure with the decision points marked, and add the one instruction most people miss. Tell it to flag anything ambiguous in your notes as an open question rather than resolving it. Left alone, the model smooths the gap over, and a tidy document containing an invented step will cost you more than no document at all.

The best version of this I have watched was not a session at all. An operations manager recorded herself talking through a returns process from a stockroom, because every meeting room was booked, and a colleague interrupted twice to correct her. Both interruptions ended up in the transcript, and both were steps that had never appeared in any written version. The mechanics of writing a usable prompt are most of what separates a procedure you can hand to a new starter from a page of confident guesswork.

Turning an hour of discussion into a decision

A long meeting usually contains four decisions, three of which were implied rather than stated. Give it the transcript and ask for what was decided, what was explicitly deferred, who owns each item, and a separate list of matters discussed at length that reached no conclusion. That last list is frequently the valuable one, because it tends to contain the same two items month after month.

Operational writing rewards a back-and-forth here. What comes back is a position to argue with, not a paper to circulate, and the first version is almost never the one you keep.

Pre-mortems and the assumptions underneath

The pre-mortem is the oldest trick in operational planning and it works better with a machine than with a room full of colleagues, because the machine has no career at stake. Set the scene: the programme failed, it is twelve months from now, write the review explaining why. You get the concerns people were being polite about. The same move at a different altitude is what founders get out of a machine with no stake in the answer.

The sharper version is to ask what would have to be true for the plan to succeed. Have it list every assumption the plan rests on, then rank each by how much collapses if the assumption is wrong, and separately by how confident you genuinely are in it. The uncomfortable pairing is high impact and low confidence. Most plans have two or three sitting there, unexamined, and they are rarely the risks on the risk register.

A well-documented broken process is still broken

Writing a process down does not improve it. If your approval route passes through four people because of an argument in 2019 that nobody wants to reopen, documenting it faster produces a well-documented broken process, delivered sooner and now harder to change because it is written down and looks official.

Every technique above comes second to that. Fix the route, then record it.