Handoffs between teams: where the request gets lost
A request gets lost at the moment one team hands it to another, because the context stays with the person who handed it over and the receiver only has the message. This is an architecture problem, not an attention problem. The fix is a single record that travels with the request, required fields, and an explicit acceptance from whoever receives it.
Where does a request get lost between two teams?
At the handoff, and almost never in either team's own work. The person handing over knows the context: what the customer asked for outside the form, what was already agreed, what is still pending. The person receiving sees what arrived. That gap is the handoff, and it is where information disappears without anyone having made a mistake.
Medicine studied this closely, because errors are costly and records are good. The "Empty Handoff" case, published in 2012 by the US Agency for Healthcare Research and Quality, describes a patient who reached surgery without the team knowing about his sensitivity to insulin. The nurse asked an assistant to pass on the warning, the warning was not passed on, and the glucose monitor had not been docked, so the low reading never reached the chart. The commentary cites a review of 60 surgical malpractice claims tied to poor communication: 43% involved a poor handoff.
A hospital is not your company. The mechanism looks alike: the information depends on someone remembering to relay it, through a channel that does not oblige anyone to confirm. The case authors conclude that relying on individuals to bridge the gap is unreliable, even with careful staff.
What changes when the handoff has structure?
Errors fall in a measurable way. Starmer and colleagues tested the I-PASS program in nine pediatric hospitals, covering 10,740 admissions, in three six-month phases: baseline observation, training with required use, and follow-up. Medical errors went from 24.5 to 18.8 per 100 admissions, a 23% drop. Preventable adverse events fell from 4.7 to 3.3 per 100, a 30% drop. The result appeared in the New England Journal of Medicine in 2014.
I-PASS is not only a script. It combines training, a five-part verbal handover (illness severity, patient summary, action list, situation awareness with contingency planning, and synthesis by the receiver), digital tools that follow the same structure, supervision, and an institutional campaign. The design compares before and after, with no simultaneous control group, so the number shows an association, not isolated proof of cause.
The part that matters for your operation is the last letter: the receiver summarizes back what they understood. The handoff is only finished when the receiver confirms.
Is a written message enough as a handoff?
Not when it is the only channel. Parke, Hobbs and Kanki, at NASA, ran an experiment with 50 participants on a task that mimicked shift handovers in industrial settings. Supporting the written record with face-to-face conversation, video or audio significantly reduced task errors, and written text alone was the least preferred option. The study summary does not give the error rates.
Our reading for a company is this: what reduces errors is the chance for the receiver to ask and for the sender to correct. In a system, the equivalent is an acceptance step with a reply, not a notification the receiver simply marks as read. That reading is ours, not the study's.
A practical example: the approved quote that becomes the wrong policy
The scenario below is hypothetical, with no measured numbers. A commercial insurance broker has sales on one side and policy issuance on the other. The broker closes a business quote and, over the phone, the customer asks for an extra coverage for a warehouse. The broker writes in the team chat: "approved, go ahead and issue." Issuance reads the message, opens the standard form, and issues the policy without the extra coverage.
Nobody worked badly, and that says where the problem is: it is not attention, it is architecture. The broker passed on what seemed central, and issuance did exactly what the message asked. The error shows up months later, in a claim, or at renewal when the customer questions the price. The information existed. It just did not travel.
A structured handoff would change three things. The approved quote would move as one record, with the history of what was agreed, not as a loose message. A required "non-standard conditions" field would stop the request from leaving empty. And issuance would only accept the request after sending back a summary of what it is about to issue, for the broker to check.
How do you design the handoff into the system?
With four elements, which are our translation of I-PASS to a company operation, not a recipe from its authors.
The first is the single record: the request moves as the same object from one team to the next, history attached. When each step opens a new record and copies data by hand, the handoff becomes retyping and the context stays behind. The second is required fields, chosen by asking "what does the receiver need to know and cannot deduce": deadline and priority, what was agreed outside the form, what is still missing, and what could go wrong.
The third is acceptance by the receiver. Whoever receives confirms what they understood, and the system only moves the request to the next stage after that. The fourth is a check afterwards. The commentary published by AHRQ recommends verifying, after the handoff, that expectations, situation and documentation match, since most handoff errors cause no immediate harm and can stay hidden for a long time. In a system this becomes a simple check: does what was issued match what was approved?
Two articles on this blog deal with neighbors of this problem. Process exceptions: the path nobody logs covers what the team does when the system does not cover a case, and an informal handoff by message is one such path. Approval bottlenecks: where the process really stops covers the other half: the wait between one team and the next.
The SuperVida case shows the single record applied to a whole operation: contracts, beneficiaries, sellers and partners came to be managed in one place when the benefits-card network moved from Airtable to a custom ERP, delivered in 2023.
Frequently asked questions
My team is used to passing requests along by message. Will they accept a form?
It depends on what it costs the person handing over. If a required field takes seconds to fill and saves the question coming back, teams tend to adopt it. Start with one type of request, the one that causes the most rework, and keep messages as a complement, not as the channel.
Will integrating with what I already use be complicated?
It does not always take integrating everything. The critical point is one handoff, between two teams, and the record can live in the system you already have or in a new module, as long as the data from the previous step arrives with it. Mapping which data crosses the boundary is the first step, before choosing any tool.
I am not sure this pays off. How do I measure it?
Measure before changing anything: how many requests go back to the previous team, how long they sit waiting for clarification, and how many errors reach the customer. The studies cited come from healthcare and NASA, so they are not a target for your operation. Your own baseline is what counts.
The next step
If requests in your company move between teams by message today and nobody confirms what they understood, the Operational Architecture Diagnostic, a 30-minute conversation, is an invitation to map where those handoffs happen and what each one needs to carry: talk to Yowpi.
Related case studies
Did you recognize your operation in this article?
Book the Operational Architecture Diagnostic: 30 minutes to map where your operation's bottleneck is. No proposal in the first conversation.
Book a diagnostic