The demo goes well. A summariser reads the shared inbox, drafts a reply, and posts it into a channel. Everyone agrees it is impressive. Six weeks later the department runs the way it ran before, the channel has become another place to check, and somebody quietly stopped reading it.
Nothing was broken. The automation does what it was built to do. It handled one step of a workflow that has four, and the three it left alone are the ones that hold the elapsed time.
A workflow is intake, decision, handoff, and reporting. Automating the decision is the fun part and the smallest part. Here is what the other three are, and why skipping any one of them returns minutes instead of hours.
Intake
Work does not arrive in one shape. It arrives as email, as a form, as a Slack message to someone's direct messages, as a voicemail, and as a colleague leaning over a desk. Automating the channel that already arrives as structured data is the easiest thing to build and the least useful, because the structured channel was never the problem.
The real work in intake is normalisation. Deciding that two submissions four minutes apart are the same request. Recognising the request that arrived without an account number and going to get one. Classifying well enough to route. Reading an attachment that is a photo of a printed form. If an agent only handles the clean channel, a person still has to read everything else to route it, and that reading is where the hours are. You have removed typing, not deciding.
So intake gets designed as one funnel with several mouths. Every channel lands in the same queue, in the same shape, with a source recorded. Then the agent behind it is working on one problem rather than five. This is unglamorous integration work and it is usually a third of the build.
Decision
This is the part everyone demos, and it is the part where a model earns its place. Apply the rule, match the record, classify the request, draft the reply, pick the approver.
Two things determine whether it holds up. The decision needs a written definition of done that a person can argue with, because "handle the request appropriately" is not testable and cannot be tuned. And it needs a way to decline, an explicit outcome where the agent says it cannot place this one and states why. An agent with no way to decline resolves every ambiguity by guessing, and you will not find out which ones until later.
Beyond that, keep one agent per workflow rather than one agent for the department. A single agent told to handle everything cannot be tested, because the input space has no edges. Separate agents share connections to your systems and one place where the rules live, so the fourth one costs far less than the first.
Handoff
This is where most agent projects quietly die.
The output has to arrive where the next person already looks, in the state they expect, with a clock on it. A summary posted to a channel is not a handoff, it is a new inbox. Somebody has to notice it, decide it is theirs, and act, and none of those steps have an owner. The item that nobody claims does not fail loudly. It just sits there, and three weeks later the team's confidence in the system is gone for reasons nobody can point to.
A handoff needs a named owner, a place in the system of record rather than in chat, a due time, and a behaviour when the due time passes. A task in the ticketing system with an assignee and a deadline beats a beautifully written notification every time. If the next step is a human decision, hand over the work rather than the leftovers: what the agent tried, what it considered, and what it would do if the human confirms. That turns an investigation into a click.
And when the human decides, the item has to re-enter the flow automatically. If a person resolves an exception and then has to manually push it onward, you have built a system with a hole in it that fills with people.
Reporting
If you cannot count what the agent did, you cannot tune it and you cannot defend it.
The first time the agent gets something wrong, and it will, there is a meeting. Without numbers, that meeting is one anecdote against a general feeling, and the anecdote wins, because the person holding it is annoyed. With numbers, it is a conversation about a rate and a threshold.
The minimum is a weekly count of items handled, the exception rate, the time from arrival to closed, and a list of every item the agent touched with what it decided. The list matters as much as the rates. Someone should be able to sample twenty items and check them by hand without asking for a database query.
Watch the shape of the exception rate rather than its level. A rate that drifts upward means something changed upstream: a new intake channel, a new entity, a customer who started submitting in batches. That drift is the most useful signal the system produces, and it only exists if you built the counting in from the first run.
Follow one item
Here is the test I would apply before scoping anything. Take a single real item. Follow it from the moment it arrives to the moment it is closed and counted, and write down every point where a person touches it.
Most workflows have four or five such points. Automating one of them returns a quarter of the touch time and none of the elapsed time. That distinction is the whole argument. A request that takes eleven minutes of human attention and three days to complete is not slow because of the eleven minutes. It is slow because it waits in four queues. Take out the decision in the middle and the customer notices nothing, because the waiting is untouched.
The same test tells you when to stop. If a workflow has a step that genuinely needs judgement, information the agent cannot reach, or a conversation, then that step stays with a person and the honest scope is everything around it. Agents that do intake, routing, preparation, handoff, and reporting around a human decision remove more time than agents that try to make the decision and fail at it.
Why saved minutes do not add up
Twenty minutes a day, recovered in fragments, does not turn into capacity. It turns into slightly less pressure and no change to headcount, hiring plans, or how long anything takes. The team feels marginally better and the numbers move nowhere.
Removing a whole workflow is different. The person who used to reconcile two ledgers every month-end now does something else that week. The close does not slip when they take holiday. That is a change you can see in a plan rather than in a sentiment survey.
Which is the case for going wider before going deeper. One workflow owned end to end, with intake normalised, the decision tested, the handoff landing in the system of record, and a weekly number on the wall, beats six clever automations bolted to the middle of six processes. The second version is more impressive in a demo. The first one is still running next year.