What a complete request actually contains
A complete request answers four questions: who is asking, what they are asking for, what it is worth, and when they need it. This article explains how to set up a single intake path, a visible queue, and default answers for common asks so legal teams spend time on review, not triage.
What changed
A complete request contains four things: who is asking, what they are asking for, what it is worth, and when they need it. A request that answers all four moves forward. A request that answers fewer than four goes back to the requester with the missing questions before anyone in legal spends time on it.
The intake completeness requirement applies from the first review cycle: every request must answer four standard questions before it enters the legal queue, and the deadline for adopting this process is the start of the next quarter. Teams that batch their intake tend to hit capacity constraints earlier, because incomplete requests accumulate before anyone triages them.
The completeness threshold, answering all four questions (who is asking, what they are asking for, what it is worth, and when they need it), is set out in the team's intake policy.
Who it applies to
- In-house teams handling supplier paper
- Anyone routing intake through a shared inbox
- Including the teams who only triage
How to sequence the change
- Map the current intake path: identify every channel through which requests arrive.
- Decide what a complete request looks like: agree on the four questions every request must answer.
- Publish the rule and hold the door: share the completeness standard with requesters and return anything that does not meet it.
The bottleneck was never the drafting. It was the queue.
One caveat
Requests that fall outside the four-question framework, such as multi-party deals, regulatory filings, or matters with no clear commercial owner, should be routed to a named escalation contact rather than returned to the requester.
| Stage | Owner | Typical duration |
|---|---|---|
| Intake | Requester | 1 day |
| Review | Legal | 3 days |
| Signature | Requester | 1 day |
What a working intake path looks 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.
Rig check 2026-09-15: this paragraph was added to test edit detection.