Why legal intake fails at the second handoff
A short standfirst for "Why legal intake fails at the second handoff", written to sit under the headline on the index page.
What are the first and second handoffs in legal intake?
In most legal intake flows, the first handoff is the moment a business requester submits a request to the legal team. That step is usually straightforward: someone fills out a form, sends an email, or drops a message in a shared channel. The second handoff is where the legal team passes the triaged request to the lawyer who will actually do the work. This is where intake breaks down.
At the second handoff, context disappears. The person who triaged the request rarely records why it was prioritised, what is missing, or what the requester already tried. The lawyer picking it up reopens the same questions the requester already answered, and the requester loses confidence that anyone read their original submission. Deadlines slip, reminder emails multiply, and the legal team looks slow even when the bottleneck is information loss, not capacity.
The rest of this page covers what a reliable intake path looks like and how teams can close the gap at that second handoff.
What changed in how legal teams handle intake handoffs?
Teams that rely on a shared inbox for intake now face a measurable problem: requests that pass through triage without structured context lose that context at the second handoff. The result is duplicated effort, because the assigned lawyer restarts discovery from scratch. Teams that batch their intake rather than processing requests continuously feel this sooner, because batched queues widen the gap between triage and assignment.
The practical threshold is simple: if more than a quarter of requests require a follow-up question after assignment, the second handoff is leaking information. Tracking that ratio week over week shows whether a new intake process is working.
Who does this apply to?
- In-house teams handling supplier paper
- Anyone routing intake through a shared inbox
- Including the teams who only triage
Sequencing
- Map the current intake path from first request to lawyer assignment.
- Decide what a complete request looks like: who is asking, what they need, what it is worth, and when they need it.
- Build a single entry point so every request lands in the same place.
- Add a visible queue so requesters and lawyers can see status without asking.
- Create default responses for the most common request types.
The bottleneck was never the drafting. It was the queue.
One caveat to keep in mind
The caveat is that self-service defaults only work when the template has already been approved for the jurisdiction and deal size in question. For anything outside that approved range, the request should still route to a lawyer for review. Skipping that check trades speed for risk.
| Stage | Owner | Typical duration |
|---|---|---|
| Intake | Requester | 1 day |
| Review | Legal | 3 days |
| Signature | Requester | 1 day |
What does a working intake path look like?
A working intake path has three elements: one door, a visible queue, and a default answer for common requests. The first element, one door, means every request lands in the same place and is read by the same rule, whether it arrives from sales, procurement, or a founder on a Friday evening. That rule is not a person. It is a short list of questions: who is asking, what they are asking for, what it is worth, and when they need it. A request that answers all four is complete and moves on. A request that answers fewer than four goes back to the requester with the missing questions, and nobody in legal has spent a minute on it yet.
The second element is a visible queue. When requesters can see where their work sits and what is ahead of it, the reminder emails stop, because the answer to "any update" is already on the screen. The queue also tells the legal team something the inbox never could: how much of the week is triage and how much is review.
The third element is a default answer for the most common asks. A standard NDA, a standard data processing addendum and a standard order form cover most of what a growing company signs. When the default is the answer, the requester should be able to send it without waiting for a lawyer to say so.
None of this requires new software. It requires agreeing on what a complete request is, writing that agreement down, and holding the door.