Business process automation when the process crosses teams.

Ask where a process is slow and people will describe their own step, because that is the part they can see. Measure it and the answer is usually different: the individual steps are quick, and the time disappears in the spaces between them — waiting for information, waiting for approval, waiting for somebody to notice that it is now their turn.

That gap is not laziness or bad staffing. It is a structural property of a process that crosses a boundary. The person finishing step three has no reliable way to tell the person who owns step four, other than sending a message and hoping. The work is complete but not transferred, and nothing in the system distinguishes those two states.

This is the specific problem business process automation exists to solve, and it is a different problem from making any individual step faster.

A useful diagnostic: for each stage, ask how the next person finds out it is their turn. If the answer is "they check", the process has a queue nobody is watching.

The two terms get used interchangeably and the distinction is worth keeping, because it changes what the work involves. A workflow is a sequence within one team, usually inside one system, where the same group owns the whole thing. Automating it is largely a configuration problem.

A business process spans teams, roles and often systems that were never designed to talk to each other. Automating it is mostly a definition and ownership problem, and only secondarily a technical one. The tooling is rarely the hard part.

If the steps already work, automating them individually produces faster steps separated by the same gaps. The unit worth designing is the transfer: what moves, who receives it, what makes it valid, and what happens when it is not.

A handoff is specified when all five are answered:

• WHAT TRANSFERS

  The record or artefact that moves, named specifically. Not "the job" but the record in the system that represents it, with an identifier the receiving team can also see.

• WHO RECEIVES IT

  A role, not a team. Work handed to a team is work handed to nobody until somebody claims it, and the interval before that happens is invisible.

• WHAT MAKES IT ACCEPTABLE

  The condition the receiving side needs met before they can start. If this is unstated, the receiving team invents it, and the two sides will disagree at the worst moment.

• HOW REJECTION WORKS

  What the receiver does when the condition is not met, and where the work goes. A handoff with no rejection path gets accepted reluctantly and fixed quietly, which hides the real defect rate.

• WHAT MAKES IT VISIBLE

  How either side can see the item is waiting, without asking. This is the part that removes the chase, and it is usually the whole benefit.

Automation makes the loud failure rarer and the quiet ones more consequential, because the quiet ones now happen at machine speed and nobody is watching the step where a person used to look.

1. 01

   Transferred and claimed

   Owner

   The receiving role

   Advances when

   Work proceeds normally

2. 02

   Transferred, unclaimed

   Owner

   Nobody

   Advances when

   Someone happens to look at the queue

   Ends when

   Ages until a customer or a deadline forces attention

3. 03

   Rejected without a path

   Owner

   Disputed between both sides

   Advances when

   An informal conversation resolves it

   Ends when

   Quietly absorbed by whoever has least capacity to argue

4. 04

   Accepted but incomplete

   Owner

   The receiving role, unknowingly

   Advances when

   Discovered mid-work and repaired

   Ends when

   Reaches the customer with the gap still in it

The order is deliberately the reverse of how these projects usually start. Most begin with the step that annoys people most, which is rarely the step that holds the process up.

1. 01

   Map the boundaries, not the tasks

   Decides

   Where does responsibility change hands?

   Output

   A list of transfers, each with a sending and receiving role.

2. 02

   Measure the waiting, not the working

   Decides

   How long does an item sit between stages?

   Output

   Evidence about which boundary actually costs the most time.

3. 03

   Specify the worst boundary

   Decides

   What transfers, to whom, on what condition, with what rejection path?

   Output

   One handoff fully defined, including its failure route.

4. 04

   Give the queue a surface

   Decides

   How does either side see what is waiting without asking?

   Output

   A visible queue with an owner and an age on each item.

5. 05

   Automate the transfer itself

   Decides

   What can move automatically once the condition is met?

   Output

   The handoff happens without a person remembering to make it.

6. 06

   Instrument the exception route

   Decides

   What happens to rejected and stalled items, and who sees them?

   Output

   An exception queue that is owned rather than merely existing.

Not every transfer should become automatic, and the useful distinction is not technical difficulty but consequence. A boundary where the receiving side needs context that does not fit in a record is a boundary where automation removes the one thing that made it work.

The common example is an escalation. A case moves from a routine queue to a senior person precisely because something about it is unusual. Automating that transfer while discarding the explanation produces a faster arrival of a case nobody understands.

The workable pattern is to automate the movement and preserve the judgement: the system routes the item, records who decided, and carries the reason with it. The transfer becomes reliable without becoming anonymous.

• CROSS IT AUTOMATICALLY

  Transfers with an objective condition, a defined receiver and a rejection path. Status changes, record creation, notification, queue assignment.

• CROSS IT WITH CONTEXT

  Escalations and exceptions, where the movement can be automatic but the reason must travel with the item and be readable by the receiver.

• KEEP A PERSON IN IT

  Transfers that commit the business — pricing, promises, approvals — or that depend on a relationship rather than a record.

Most cross-team delay that looks like a communication problem is a records problem. Sales holds the opportunity, delivery holds the job, finance holds the invoice, and each of those systems is a reasonable choice for the team that chose it. The difficulty appears only at the boundary, where the same real-world thing exists in two places under two names with two owners.

The instinct is to consolidate — one system, one truth, no reconciliation. Sometimes that is right. Often it is not, because the specialist capability each team depends on is the reason they are on separate systems in the first place, and a consolidated tool that does every job adequately can be worse than two that each do one well.

The question that actually has to be settled is narrower and more useful: for each fact that crosses the boundary, which system is authoritative? Not which tool is better, and not which team is more important — simply where the correct value lives when the two disagree. A boundary with an answer to that question can be automated. A boundary without one is renegotiated by two people every time an item crosses, and that negotiation is the delay.

The failure to watch for is the silent copy: both systems hold a value, neither is defined as authoritative, and both are updated independently. Nothing reports an error, because from inside either system nothing is wrong. It surfaces weeks later as a customer being told two different things, and by then the version that was correct is a matter of argument rather than record.

A practical way to settle it: for each field that crosses, write down the system that owns it and the direction it flows. Fields nobody will commit to are the ones that will cause the next dispute.

The instinct after an automation project is to measure the time the automated step used to take. That number improves almost by definition and tells you very little, because the step was not the constraint.

The measures that reflect what was actually built are about the boundary: how long items wait unclaimed, how many are rejected and why, how many reach the end without passing through the defined route, and how many exceptions are still open. If those have not moved, the process is faster in a place that was never slow.

Worth watching after a cross-team automation:

• TIME UNCLAIMED

  How long an item sits after transfer before somebody owns it. The single most honest measure of whether the handoff works.

• REJECTION RATE AND REASON

  How often the receiving side sends work back, and for what. A rate of zero usually means the rejection path is unused rather than unnecessary.

• BYPASS RATE

  How often work reaches the end without going through the defined route. Persistent bypassing is feedback about the design, not misbehaviour.

• OPEN EXCEPTIONS AND THEIR AGE

  The queue that determines whether the new process is trustworthy. An exception queue with no owner recreates the original problem in a new place.

1. In a process that crosses teams, most of the elapsed time is spent between steps rather than inside them, so automating individual steps leaves the constraint in place.
2. A workflow inside one team is mainly a configuration problem; a process across teams is mainly a definition and ownership problem.
3. The unit worth designing is the handoff: what transfers, who receives it, what makes it acceptable, how rejection works, and how the queue is visible.
4. Work handed to a team rather than a role is unowned until somebody claims it, and that interval is invisible unless the queue has a surface.
5. Automate the movement but carry the reason with it; escalations lose their value when the context is discarded in transit.
6. Measure waiting time, rejection rate, bypass rate and open exceptions — not the duration of the step that was automated.