Observable condition
A supplier invoice is approved on a Tuesday. By the following Wednesday it has not been paid, and the supplier is phoning. The accounts clerk says she was waiting for the purchasing manager to confirm the goods had arrived. The purchasing manager says the storeman signs for deliveries and he assumed the storeman had told her. The storeman says he put the delivery note in the tray. Nobody has done anything wrong, and the invoice has been sitting for eight days.
The same silence shows up everywhere. A customer's signed quote is in the sales inbox, and nobody is sure whether sales, the project office or finance should open the job. A staff member resigns and the equipment, access and final pay each wait for a different person to realise it is their turn. A complaint is acknowledged, then goes quiet, because the person who acknowledged it assumed another team would investigate.
An illustrative example: a Durban distribution business with sixty staff discovers that new trade accounts take an average of nine working days to become active. When it traces three of them step by step, the actual work adds up to about ninety minutes. The rest is waiting for somebody to notice that the file has landed on their side of the line.
Realisation
The delay is not caused by slow people. Everyone involved is busy and willing, and each can name what they did. The problem is that the work finished one task and had no named destination. A step was completed, but the question "and now it is whose?" was never answered by anyone, at any point, in writing or in the system.
That is why the usual reminder emails feel pointless. They chase an individual, when the real gap is that the process does not say which individual. Asana's guide to RACI charts, a common tool for assigning roles, begins from exactly this observation: when it is unclear who is responsible, accountable, consulted or informed, tasks stall or are done twice.
Realisation prompt: pick the last job that took far longer than its actual work. At the moment it stopped moving, can you name the one person who was supposed to pick it up next?
Identification
This is a pattern of unowned transitions. The visible symptom is work that waits in an inbox, a tray or a status field with no one chasing it. The common assumption is that staff need to be more proactive. The structural cause is that responsibility is attached to tasks and departments, but not to the moment between them, so the gap belongs to nobody.
The published Pattern the cost of delayed handoffs after a deal is won examines one well-known instance of this. The Pattern when the next step waits for someone to check another system covers the case where the trigger exists but is invisible. This Pattern is wider: it is about any process where the next owner is unclear at the moment of transfer.
Diagnosis
- Roles are described by title, not by trigger. A job description says what a purchasing manager is responsible for, but not what event obliges her to act. Without a trigger, action depends on noticing.
- Departments own steps, not outcomes. Each team is measured on its own stage, so the time between stages appears on nobody's report.
- Handoffs rely on goodwill. A verbal "I will send it over" or a note left in a tray works until somebody is on leave, in a meeting, or simply busy.
- Exceptions have no home. The standard path may be clear, but the dispute, the missing document or the unusual customer has no assigned owner, so it drifts.
- Shared responsibility becomes no responsibility. When a task is given to "the team" or to a shared mailbox, each member reasonably assumes a colleague has it.
- The system cannot show the waiting. Status fields such as "in progress" or "pending" hide whether anyone is actually holding the work. IBM's explanation of process mining describes how event logs can reveal where cases wait between activities, which is usually where unowned transitions sit.
Commercial impact
The commercial value at stake is cash flow, customer retention, throughput and management time.
Cash is the clearest measure. If invoicing waits for a completion sign-off nobody knows to give, revenue is recognised later and collected later. For a business working on thirty-day terms, a week of idle waiting at each of three stages can add most of a month to the cycle from work done to money received.
Customers feel the delay as unreliability. They do not see which internal step stalled; they see a promise broken. In a competitive market a late onboarding, a slow refund or an unanswered query tells them what future service will be like. Supplier relationships suffer the same way, and a supplier who is paid late may tighten terms.
The hidden cost is managerial. Someone senior ends up as the human router, answering "whose is this?" several times a day. That attention is expensive, and the arrangement stops working as soon as the business grows past what one person can keep in their head. The Insight broken handoffs are systems problems makes the same point from the design side.
Common misidentification
The first instinct is to blame attitude, and to run a session on accountability or ownership mindset. It sounds reasonable, but it asks people to compensate for a design gap through effort, which lasts a few weeks. The second instinct is another weekly status meeting. Meetings find the stuck jobs after the delay has happened, and they add a standing cost to catch a problem that a clear rule would prevent.
A third response is to buy workflow software. A tool can assign tasks and send reminders, but only if someone has decided who the assignee is. Installed on top of an unclear process, it records the confusion more neatly.
Possibility
In a better state, every stage of an important process ends with a defined handover: a named role receives the work, knows it has arrived, and knows what "done" means for their part. If the role is unfilled that day, a stated deputy takes it. Nobody has to remember to tell anyone.
Staff can see where a job is and who holds it, and a job that has waited longer than an agreed time raises itself to the manager. Exceptions go to a named person rather than a general pool. The route is dull and predictable, which is the point.
Intervention
- Trace three real jobs. Pick recent ones that dragged. Mark every point at which the work waited and ask what the person on each side believed.
- Name the owner of each transition. For every handover, write one line: when X is complete, role Y receives it, and Z covers when Y is away. Use roles, not individuals, so the rule survives leave and resignations.
- Make the handover visible. Whether in a system, a shared board or a simple tracked list, the receiving owner should see the work arrive without having to go and look. The Insight how to make ownership clear at every stage sets out a practical way to do this.
- Set a waiting limit. Decide how long work may sit before it is escalated, and who is told. Even a simple rule such as one working day is better than none.
- Give exceptions an owner. Nominate one person per process for disputes, missing information and unusual cases.
- Remove dependence on memory. The Insight how to design a handoff that cannot depend on memory explains how to do this without heavy tooling.
Diagnostic questions
- For your three most important processes, who receives the work at each handover, by role?
- How long can a job sit untouched before anyone is told?
- Who covers when the usual owner is on leave?
- When something unusual happens, is there a named person or a shrug?
- How often does a manager answer the question "whose is this?"
Bottom line
When nobody knows who owns the next step, effort is not the shortage. The shortage is a clear destination for work at the moment one task ends. Naming the receiver of each transition, making arrival visible and setting a waiting limit takes little money, and it returns days to the cycle from order to cash.
Sources and further reading
- RACI Charts: The Ultimate Guide, with Examples [2025] • Asana (last verified 10 October 2026)
- RACI Chart: What is it & How to Use - The Workstream (last verified 10 October 2026)
- What is Process Mining? - IBM (last verified 10 October 2026)
Related Mellorca reading
- The Business Process That Only Works Because Someone Remembers
- When Nobody Knows Which Spreadsheet Is the Latest
- When One Employee Becomes the Company’s Search Engine