[de] Why legal intake fails at the second handoff
Legal intake usually survives the first handoff from the business team, then breaks at the second, when someone inside legal tries to route an incomplete request to the right lawyer or workflow.
Why does legal intake fail at the second handoff?
Legal intake has two handoffs. The first handoff is the moment a business team sends a request to legal: an email, a form submission, or a Slack message. Most organisations manage this step adequately because the requester is motivated to push the work forward.
The second handoff is the moment someone inside legal routes that request to the right lawyer or workflow. This is where intake breaks. The person who triages rarely has enough information to route correctly, because the original request is incomplete. The result is a loop: legal asks for clarification, the requester takes days to reply, and the request loses its place in the queue. By the time it resurfaces, the deadline may have passed or the business team has found a workaround that skips legal entirely.
The root cause is not capacity. It is that no one has defined what a complete request looks like before the second handoff happens, so triage becomes investigation rather than routing.
What changed
The obligation to acknowledge and route every legal request within a fixed window applies from the first review cycle, and the deadline for that first response is typically 48 hours. Teams that batch their intake into weekly reviews will feel this sooner, because requests sit unacknowledged past the window before anyone reads them.
The completeness threshold (four fields: requester identity, request type, deal value, and deadline) is set out in the intake policy guidance. See the relevant intake policy for the detail.
Who does this apply to?
- In-house teams handling supplier paper: requests often arrive with only a contract attached and no context, so the triage person cannot tell whether the ask is a review, a redline, or an approval. The second handoff stalls while they chase the requester for basics.
- Anyone routing intake through a shared inbox: emails pile up without priority signals, and the person triaging has to open every thread to decide who should own it. Routing errors at the second handoff send work to the wrong lawyer, adding days.
- Teams who only triage but do not draft: because their sole job is the second handoff, an incomplete request means their entire output is blocked until clarification arrives.
How should teams sequence the fix?
- Map the current intake path: trace a real request from the moment it leaves the business team to the moment a lawyer begins substantive work. Note every point where information is missing or someone waits for a reply.
- Define what a complete request looks like: agree on the four fields (requester, request type, deal value, deadline) that must be present before a request crosses the second handoff.
- Build a visible queue: give requesters a live view of where their work sits so they stop sending follow-up emails, and give the legal team data on how time splits between triage and review.
- Set default answers for common asks: standard NDAs, data processing addenda, and order forms should be self-serve so they never enter the queue at all.
The bottleneck was never the drafting. It was the queue.
One caveat
An external counsel note covers the edge cases in more detail.
| 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 starts with one door. Every request, whether it arrives from sales, procurement or a founder on a Friday evening, lands in the same place and is read by the same rule. 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.