Contract Intake: How to Route Requests to Legal Without the Chaos

Contract intake is the single door through which every request to draft, review, or sign a contract enters a legal or contract-ops team. Most teams do not have one. Instead they have five doors: an email to the general counsel, a Slack DM, a hallway ask, a ticket nobody else uses, and a forwarded chain marked "by EOD". The one thing almost everyone gets wrong is treating intake as a formality, the box you tick before the "real" work starts. It is not. It is the point where risk enters the process, and a bad intake system does not just cause delay, it lets unreviewed terms and unauthorised promises slip past legal entirely.

Adira, which publishes this guide, sells contract lifecycle management software, including intake routing. This page works whether or not you ever buy anything from us, and it says so plainly here: process fixes most of an intake problem, and a form plus a set of rules gets you most of the way there before any software is involved.

Why intake is where contract chaos actually starts

A request with no structure forces the reviewer to do detective work before they can do legal work. "Can legal look at this by Friday" tells a reviewer nothing about the counterparty, value, contract type, or what has already been informally agreed. The reviewer chases the requester for basics, the requester tries to remember a conversation from three weeks ago, and the clock the requester actually cares about has already started ticking before legal has the document in hand.

This compounds at scale. A team fielding forty requests a month across five channels cannot see the queue, and cannot answer "how many came in this month" without manually checking five inboxes. Prioritisation becomes whoever asked most recently or loudest, not whoever's deal is actually time-sensitive. A seven-figure supply agreement and a routine NDA arrive looking identical, a forwarded email, and get worked in whatever order they landed.

Build one intake form or channel, not five

The fix does not require software. It requires one door: a single form (a shared document, a web form, a ticketing system you already own) or one channel (one inbox, one Slack channel, a required template) that every request goes through, no side channel for "quick" requests, because "quick" is exactly the category that turns into an unreviewed commitment.

The form needs to capture, at minimum:

• Counterparty: who the other side is, and whether you have contracted with them before.
• Contract type: NDA, MSA, order form, vendor agreement, and so on, since type drives which template and playbook apply.
• Value: the deal's financial size, even a rough band, because value is the single biggest driver of how much scrutiny is needed.
• Deadline: the actual date something needs to happen by, and whether that date is real or aspirational. Most "urgent" requests are not.
• Key terms already discussed: anything the requester has already told the counterparty, verbally or in writing, about price, scope, or terms. This field alone prevents the most common intake failure, a requester who has already promised something before legal ever saw the deal.
• Requester and business owner: who is asking, and who owns the relationship if questions come up later.

That is six fields. Teams that add twenty usually end up with a form nobody fills in properly, because the effort exceeds the requester's patience. Six fields, filled in consistently, beats twenty filled in badly.

Triage: not every request deserves the same attention

Once requests arrive in one place, sort them. Triage is a small set of fixed rules applied the moment a request lands, not a fresh judgement call:

1. Value bands set a floor for review depth. Below a threshold your team picks, based on typical deal size, a request is low-risk by default; above it, a human reviewer is required regardless of anything else.
2. Contract type overrides value in specific cases. An NDA on your own template is low-risk almost regardless of value; a data processing agreement or anything with indemnity exposure is not, even at low value.
3. Counterparty history matters. A repeat counterparty on paper you have already negotiated needs less scrutiny than a first-timer on their own paper.
4. Deviation from standard paper is the clearest single signal. Your unmodified template is a different animal from the counterparty's own document, or your template with sections struck out.

These four rules, applied consistently, sort most requests into "fast lane" or "needs a reviewer" without anyone judging case by case. That consistency, not the sophistication of the rules, is what triage is actually for.

Self-serve for low-risk, standard paper

Requests that triage as low-risk should not wait for a human at all. A pre-approved NDA on your own template, unchanged, does not need a lawyer's eyes; it needs a checklist confirming it really is unmodified, and a way for the requester to send it themselves. This is what a negotiation playbook enables: pre-agreed fallback positions a non-lawyer can apply without escalating. See how to build a contract negotiation playbook for the mechanics.

Self-serve only works if "standard" has a real definition, checked at intake, not assumed; a requester's word alone is not enough. A quick way to check a document against your own baseline, clause by clause, free and without uploading anything anywhere, is to run it through Weave, Adira's browser-based contract markup tool.

Routing to the right reviewer, and setting an SLA

Once a request needs a human, route it to the right one, not the most available one. A data-heavy vendor contract and a real estate lease need different expertise; sending both to whoever is free first means a slow review or one outside the reviewer's competence. Routing rules should key off contract type and jurisdiction, and name a backup for every reviewer, so one person's leave does not stall the queue, the same principle behind contract approval workflows.

Then publish an SLA: low-risk requests get an initial response within one business day, standard requests within three, complex ones a scoping call within two. Most of the frustration that drives requesters to bypass intake comes from not knowing when they will hear back, not the wait itself. Track whether the SLA is actually met; a consistent miss on low-risk requests means triage is too generous, or the fast lane is understaffed.

The legal risk intake exists to catch: who can actually speak for the company

The reason intake matters is not administrative tidiness. It is that, in India, a person without a title suggesting they can commit the company can sometimes still bind it, if the company's own conduct made that belief reasonable. Section 237 of the Indian Contract Act, 1872 sets out the rule, known as agency by estoppel:

"When an agent has, without authority, done acts or incurred obligations to third persons on behalf of his principal, the principal is bound by such acts or obligations, if he has by his words or conduct induced such third persons to believe that such acts and obligations were within the scope of the agent's authority." Source: Section 237, Indian Contract Act, 1872

In practice, this is exactly the "key terms already discussed" field earning its place. A sales manager who tells a prospective vendor "yes, we'll accept net-60 terms" before the request reaches legal has said something that, depending on the company's conduct around that person's role, may already create an expectation the company later has to honour or dispute, well before anyone drafted or signed anything.

The Supreme Court drew the limits of this doctrine recently, in The New India Assurance Company Limited & Ors v M/s Louis Dreyfus Commodities India Pvt Ltd (2026 INSC 876, decided 18 August 2026). A Divisional Manager had emailed the insured's broker suggesting cover would continue beyond a stated limit once the next premium instalment was paid. The insurer argued the manager had no authority to make that assurance, and a statutory precondition had not been met regardless. The Court held that "an agent cannot, by invoking actual or ostensible authority, confer upon the insurer a capacity which the statute itself withholds," finding "no occasion arose" for the assurance given. Full judgment: Verdictum; coverage: LiveLaw.

Together, these give a useful, honest answer: an employee's email is not automatically binding, and courts look closely at whether that person actually had authority, real or reasonably apparent. That is not a reason to relax at intake, though. It is the reason intake needs a clear rule about who may discuss terms with a counterparty before legal has reviewed the request, so your own conduct never does the inducing that Section 237 describes.

Metrics that tell you whether intake is working

Two numbers matter more than any dashboard: volume and turnaround. Volume, requests by type and by which lane they triaged into, shows where the load sits and whether self-serve is working (a falling share needing a human is a good sign). Turnaround, time from submission to first substantive response and to fully resolved, shows a bottleneck forming before it becomes a crisis. Track both against the published SLA, not a vague sense of "we're usually fast." A team that only measures turnaround once someone complains is measuring too late.

Red flags in an intake process

Normal	Red flag	Why it matters
One intake form or channel for all requests	Requests arrive through five channels, informally	No single queue, no reliable volume count, a request can fall through entirely
Triage rules applied the same way every time	Prioritisation depends on who asked loudest	High-risk deals wait behind low-risk ones with no defensible reason
"Standard paper" is checked against a baseline before self-serve	A requester's word alone is taken at face value	An edited template ships as pre-approved, with nobody having reviewed the edit
The form captures terms already discussed with the counterparty	No field for "what have you already told them"	Legal reviews a deal only after a commitment is effectively already made
A published SLA tells requesters when to expect a response	No stated timeline, so requesters chase or go around the process	Bypassing the form becomes the fastest route to an answer, defeating the system
Routing sends a request to the reviewer with the right expertise	Requests go to whoever answers first	Reviews happen outside the reviewer's competence, or stall finding the right person
Volume and turnaround are tracked weekly	Nobody can say how many requests came in, or how long they took	Bottlenecks surface only once someone complains, after costing real time
Every reviewer has a named backup	One person is the only route for a request type	Leave or a busy week stalls the whole category

Fixing an intake policy: a bad line vs a better one

Bad: "Requests for legal review should be sent to the legal team, who will review them as soon as possible."

What is wrong: it names no single channel, so requests still arrive however is convenient, sets no information requirement, and "as soon as possible" is not a timeline anyone can plan around.

Better: "All contract requests must be submitted through the intake form at [link], with counterparty, contract type, value, deadline, and any terms already discussed included. No request will be actioned from email, chat, or verbal ask alone. Requests are triaged within one business day and assigned a response time based on risk tier, published on the form itself. Only the requester's named business owner, not the requester alone, may communicate proposed terms to the counterparty before triage is complete."

What changed and why: it names the one channel, sets the minimum information bar, states a concrete timeline, and, closing the Section 237 gap above, restricts who may say anything to a counterparty before legal has actually looked at the request.

How intake feeds the rest of the process, and why process beats tooling

Intake is not isolated. A clean, structured record makes triage possible, feeds the approval matrix with the data it needs to route correctly (see contract approval workflows), and sets the clock turnaround measurement runs against. Fix approvals while intake stays chaotic and you are optimising the middle of a process whose start is broken. See how to reduce contract turnaround time for where that delay costs the most.

Worth saying plainly, since it cuts against what a software vendor is expected to say: a structured form, four triage rules, named backups, and a published SLA get a small or mid-size team roughly eighty percent of the value of an intake system, with none of it bought. Software earns its cost once volume outgrows a spreadsheet, triage gets complex enough that manual sorting errs, or the audit trail needs to survive a dispute without depending on memory. Build the process first; buy the tool once the process, not the tool, is the bottleneck.

US and global contrast

Intake best practice, one form, risk-based triage, self-serve for low-risk paper, published SLAs, travels well across markets. What most US-focused guides skip is the authority question above: they treat "who can talk to the counterparty before legal reviews it" as a company-policy matter alone. In India, Section 237's doctrine of agency by estoppel means that question can carry real legal consequences too, if the company's own conduct made an unauthorised promise look authorised.

FAQ

What is the minimum viable contract intake process? One form or channel capturing counterparty, contract type, value, deadline, and terms already discussed, plus a simple triage rule based on value and contract type. That alone fixes most of the chaos; everything past that is refinement.

Do we need software to run contract intake properly? Not to start. A shared form and a spreadsheet, checked weekly, cover most teams under a few hundred requests a year. Software earns its place once volume, triage complexity, or audit-trail needs outgrow what a spreadsheet can reliably handle.

Can an employee's email really create a binding commitment before legal has reviewed anything? It can, under Section 237 of the Indian Contract Act, 1872, if the company's own conduct made it reasonable for the other side to believe that person had authority to say what they said. The Supreme Court's 2026 ruling in New India Assurance v Louis Dreyfus Commodities shows this is not automatic, an agent's assurance cannot override a statutory precondition, but the safer position is an intake rule restricting who may discuss terms before triage, rather than relying on the doctrine's limits afterward.

How does intake differ from triage? Intake is capturing the request in a structured way; triage is the rule set that decides how much scrutiny it gets once captured. Intake without triage leaves every request looking equally urgent; triage without clean intake data has nothing reliable to sort.

What is the single biggest sign that intake is broken? Requests arriving through multiple, informal channels, email, chat, hallway asks, with no one place to see the full queue. Every other failure, inconsistent prioritisation, missed deadlines, terms committed before legal review, traces back to that one gap.

What SLA should a team just starting out set? One business day for an initial triage response is a common starting point, with a risk-tier target from there, for example three business days for a standard review. The exact number matters less than publishing it and tracking whether it is actually met.

This guide gets you a working intake process, the fields to capture, a workable triage rule set, and the India-specific authority question most intake guides written for other markets do not raise. It does not tell you what value threshold is right for your business, or how a court would weigh your own conduct under Section 237 in a dispute. Those depend on your facts and are not legal advice. Talk to a lawyer before relying on where that line sits for your own team.