A customer requests a quote on Monday. Sales reviews the request the same day and sends it to operations for pricing. Operations needs clarification from a supplier, then sends the numbers back to sales. Someone notices that the original specifications are incomplete. The customer receives a quote on Friday.
Depending on the complexity of the request, five days might be perfectly reasonable. But suppose the actual work took less than three hours. The rest of the time was spent waiting for someone to pick up the request, answer a question, confirm a detail, or approve the next step.
There is nothing particularly unusual about this sequence. Similar patterns appear in customer onboarding, purchasing, hiring, contract approvals, project delivery, and dozens of other business activities.
What interests me is how easily this time disappears from the way companies describe their operations.
Sales completed its part. Operations completed its part. The supplier responded within its usual timeframe. Each department may have met its internal expectations. Yet the customer experienced a five-day process.
The individual activities were reasonably efficient. The process connecting them was not necessarily efficient at all.
Where the time actually goes
Most business processes consist of relatively short periods of activity separated by intervals of waiting.
A person reviews a document, makes a decision, enters information, or produces something. Then the work moves to another person or system. That next step may begin immediately, but often it enters a queue.
The distinction matters because organizations tend to have much better visibility into activity than into waiting.
They can measure how many requests someone processed, how many hours were spent on a project, or how quickly a support agent handled a ticket. Those measures say something about individual performance and capacity. They do not necessarily explain how long the entire process takes.
Consider a hypothetical company handling 100 customer requests per month. Suppose each request requires an average of two hours of actual processing but takes six business days from initial receipt to completion.
The processing effort matters for labor cost and capacity planning. The six-day turnaround matters for the customer and for the company's ability to respond to demand. Both measurements are legitimate, but they describe different aspects of the operation.
If the company concentrates exclusively on reducing the two hours, it may improve labor efficiency without materially changing the customer's experience.
The more useful question might be what happens during the other five days and six hours.
A handoff is more than a transfer
We often describe a handoff as a simple movement of responsibility from one person or department to another.
In practice, it may involve several separate events. The first person considers the work complete. The next person receives it. That person determines whether the information is sufficient, decides where it belongs among competing priorities, and eventually begins working on it.
Those events rarely happen at exactly the same moment.
A request can be marked complete in one system and remain effectively invisible in another. An email can be delivered without being understood. A task can be assigned without anyone accepting responsibility for the next action.
And when information is incomplete, the handoff reverses direction. The receiving team asks for clarification, the original team reconstructs the context, and the request enters another waiting period.
This is why adding an approval step or another department to a process can have a larger effect than the additional work itself would suggest.
The new step introduces not only processing time, but also a queue, a priority decision, and another opportunity for information to be lost or misunderstood.
There is useful evidence of this mechanism in software engineering, where the flow of work has been studied extensively.
Google Cloud's guidance on cloud-native architecture describes how separating teams strictly by function can create handoffs that increase lead times, batch sizes, and rework. The same material draws on DORA research about the performance of cross-functional teams.
Software delivery is not identical to commercial operations, and I would be cautious about transferring performance claims directly from one industry to another. Still, the underlying mechanism is recognizable: work crosses an organizational boundary, and the receiving team needs time, capacity, and context before it can continue.
The mathematics of waiting
There is also a useful relationship between the amount of unfinished work in a system and the time it takes to complete it.
Little's Law, a well-established principle in queueing theory, connects average work in progress, average throughput, and average time in the system.
In its basic form:
Average work in progress = Throughput × Average time in the system
The relationship applies under appropriate stable-system assumptions. It is not a universal promise that removing half the tasks from a queue will automatically double performance.
But it offers a useful way to think about operational delays.
Imagine a process that completes 20 requests per business day and, on average, has 100 requests somewhere between starting and finishing. Under stable conditions, those numbers imply an average time in the system of five business days.
If the business wants a shorter turnaround, it is worth examining how much unfinished work has accumulated and where that work is waiting.
This is a different perspective from trying to make every employee work faster.
An organization can be busy because it is completing work quickly. It can also be busy because it has started more work than its processes can comfortably finish.
From the outside, these situations may look similar. Internally, they have very different consequences.
Why department-level optimization can make the problem worse
One of the more interesting effects appears when individual departments are managed primarily around their own efficiency.
Suppose the sales team is measured on the speed of transferring qualified opportunities to implementation. Sales has a strong incentive to move requests forward quickly.
Implementation, meanwhile, is measured on utilization and completed projects. It may prefer to receive work in organized batches, prioritize assignments that fit available capacity, and avoid interruptions.
Neither approach is necessarily unreasonable. Both teams may be responding sensibly to their own objectives.
But the combination can create an expanding queue between them.
Sales considers an opportunity successfully handed off. Implementation considers it pending until capacity becomes available. The customer considers the company slow.
The problem is not that either department is poorly managed in isolation. It is that the incentives and definitions of completion are different.
This is one reason I find it useful to examine a process from the customer's initial request to the final outcome rather than beginning with the organization's departmental structure.
A company chart explains who reports to whom. It does not necessarily explain how work travels through the business.
Looking at one completed request
There is a practical way to investigate this without introducing a new management framework or purchasing another software platform.
Take a recently completed request and reconstruct its timeline from beginning to end.
For a commercial process, that might mean finding the original customer inquiry, the first response, the internal assignment, requests for clarification, pricing activity, approval, and final delivery.
The objective is not simply to find who took too long. It is to distinguish the time when something was actually being worked on from the time when it was waiting.
A basic reconstruction might reveal that a request spent 25 minutes in initial review, 18 hours awaiting assignment, 40 minutes in pricing, two days awaiting a technical clarification, and another day waiting for final approval.
That example is illustrative, not an actual company case. But the sequence shows why a timestamped history can be more informative than a departmental productivity report.
It also makes the causes of waiting easier to distinguish.
Some requests wait because the next team has no capacity. Others wait because the necessary information is missing. Some are blocked by an external dependency, while others have simply lost a clear owner.
These situations may appear identical in a turnaround-time report, but they require different responses.
If capacity is the constraint, improving the intake form will not fix it. If incomplete information is causing repeated rework, hiring another employee may only increase the volume of requests moving through the same flawed process.
I would be more interested in reconstructing five or ten representative requests than in immediately building a company-wide process map. A small sample cannot establish a statistically reliable average, but it can expose recurring mechanisms worth investigating across a larger set of cases.
Not every handoff should disappear
There is a temptation to conclude that fewer handoffs are always better.
I don't think that is a particularly useful conclusion.
Some handoffs exist for good reasons. Financial controls, legal reviews, technical validation, quality assurance, and separation of duties can protect a company from errors that are much more expensive than the waiting time they introduce.
Specialization also matters. A complex company cannot necessarily place every capability inside one team.
The more relevant question is whether a handoff produces enough value to justify the coordination it requires.
An approval may catch material errors. Another approval may simply repeat work already performed elsewhere. One specialist review may prevent expensive failures. Another may exist because the organization has never reconsidered a rule established years ago.
The value of a handoff is not determined by how quickly it happens, or even by whether it can be automated. It depends on what risk it manages, what information it adds, and what would happen if it were changed or removed.
For that reason, the solution may involve clearer information requirements, a different division of authority, better coordination between functions, or greater capacity at a particular stage. Sometimes it may involve removing a step. Sometimes the existing process is already reasonable.
It is difficult to know without following the work.
The process belongs somewhere
There is one organizational question that tends to emerge from this analysis.
Who is responsible for the performance of the process as a whole?
Not the performance of sales, finance, operations, or any other department individually, but the complete sequence that produces an outcome for a customer or for the business.
In a small company, that responsibility may sit naturally with the founder or an operations manager. In a larger organization, it may be shared across several functions or assigned to a dedicated process owner.
Shared responsibility can work, but only if someone has the authority and visibility to address problems between departments. Otherwise, the points where work changes hands can remain outside everyone's immediate priorities.
That is where an interesting contradiction appears.
A company can have good people, clearly defined departments, modern software, and detailed performance reports while still struggling to complete ordinary work predictably.
The missing information may not concern what employees are doing. It may concern what happens after one person finishes and before the next person starts.
For many operating problems, that is a useful place to begin looking.
Sources
Google Cloud — Re-architecting to Cloud Native
DORA — Research and Core Model
ASCM — Supply Chain Dictionary, Little's Law
Toyota — Applying the Toyota Production System to Office Work