A Legal Intake Process That Does Not Become a Bottleneck (2026)

What legal intake is and why it matters Legal intake is the front door to a legal team. It is how the rest of the company asks legal for help: a new contract, a question about a clause, a review of a marketing claim, a dispute, a policy sign-off. Everything the team does starts as a request, and the quality of that request decides almost everything that follows. A clear request with the right facts gets a fast answer. A vague request, "can you look at this," starts a slow back-and-forth before any real work begins. When intake is unmanaged, legal becomes a bottleneck even when the team is not actually overloaded. Requests arrive by email, chat, hallway and meeting, with no priority and no complete picture. The team spends its first hour on each matter just working out what is being asked and how urgent it is. This guide is about designing intake so that stops happening. It is operational guidance, not legal advice. ## The three jobs of a good intake process A legal intake process has to do three things well. Get these right and most of the pain disappears. 1. Capture complete information once. The request should gather enough that work can start without a follow-up. What is this, who is it with, what is the deadline, what is the business context, and what is attached.

2. Route to the right place automatically. A simple contract from an approved template is not the same as a litigation hold. Intake should sort requests by type and urgency and send each to the right person or queue.
3. Make status visible. The requester should be able to see that their request was received, where it is, and roughly when to expect a response, without sending a chasing message. A process that does only the first job, a form, still helps. A process that does all three stops legal being perceived as a black hole. ## A legal intake form you can use The form is the heart of intake. Keep it short enough that people fill it in, long enough that work can start. These fields cover most legal teams: ``` LEGAL REQUEST Requester: [name, team] Date needed by: [date] Why this date: [real reason, not "ASAP"] Type of request: [ ] New contract [ ] Review their contract [ ] Contract question [ ] Dispute / claim [ ] Policy / compliance [ ] Marketing / claims review [ ] Other: __________ Counterparty / other side: [name] Value or budget: [amount, or "none"] Business context: [1-3 sentences: what is the deal or problem, what outcome you want] Does this involve any of the following? [ ] Personal data [ ] Our IP [ ] A regulated activity [ ] A foreign jurisdiction [ ] A public commitment / announcement Attachments: [draft, their paper, prior contract, email thread]

- **Rework rate.** How often a request has to go back for missing information. High rework means the form is wrong or not enforced.
- **Cycle time by type.** How long each category takes end to end, so you can see where work piles up.
- **Deflection rate.** How many requests were met by a template or self-service instead of lawyer time. Rising deflection is a sign the routine is being handled efficiently. Track these monthly and the process improves itself, because you can see which stage is slow and fix that one thing rather than guessing. ## Keeping the request and the work it creates together The quiet failure of legal intake is that the request and the work drift apart. The intake form lands in one system, the contract gets drafted in another, the negotiation happens over email, and the obligations the signed contract creates end up in nobody's calendar. The clean record of "what was asked and what happened" that you built at intake is lost by the time anyone needs it again. That is the single-workspace idea: the request, the draft it becomes, the edits, the version history and the dates and obligations that follow can live together rather than scattered across tools. [Adira](https://adiralaw.com) is built around keeping a contract's drafting, review, versioning and obligations in one workspace tuned to how your company works, with a broader intake and command view on its roadmap rather than presented as finished today. You do not need a platform to run the intake process in this guide; the point worth keeping is that intake is only valuable if the context it captures survives all the way to the work it starts.