ooligo
ENTRY TYPE · definition

Legal Intake

Last updated 2026-05-03 Legal Ops

Legal intake is the process by which a request for legal work enters the legal team’s queue — the form, the routing logic, the triage decision, and the assignment to a reviewer. For an in-house team, intake is the front door to the legal department; for a firm, it’s the front door to the matter. Bad intake produces noisy queues, missed SLAs, and the perception that legal is a bottleneck. Good intake makes legal feel like a service that’s available, predictable, and easy to engage.

What a good intake captures

Three things, every time:

  1. Identification. Who’s asking, what business unit, what’s the contact for follow-up.
  2. Categorization. What type of request — contract review, advice question, employment matter, regulatory question, IP filing. Drives routing.
  3. Context. What’s the deal, what’s the urgency, what’s the risk, what dollar amount is involved. Drives prioritization and triage tier.

For contract review intake specifically, also: the counterparty, the contract type, and any applicable templates or NDAs already in place.

The intake form

The form is the single most important Legal Ops artifact. It encodes the contract review SOP, the triage logic, and the SLA expectations into the moment of request. A working in-house intake form has 8-15 fields, takes the requester under 90 seconds to fill out, and routes to the right reviewer automatically.

Common form sections:

  • About the request. Type, urgency, business unit, owner.
  • About the deal. Counterparty, dollar value, term, related agreements.
  • About the documents. Attached files, link to deal room, prior versions.
  • Approval needed by. Specific date or business event.

Intake routing logic

The routing decision tree maps form responses to reviewer assignments. A working routing rule set covers:

  • Contract type → reviewer tier. NDA/standard MSA → auto-approve or paralegal; vendor MSA → in-house attorney; partnership/strategic → senior in-house + GC review.
  • Dollar threshold → approval matrix. Above $X requires VP approval; above $Y requires GC approval.
  • Urgency → SLA. Standard requests get 2 business days; urgent flagged requests get same-day; “emergency” requests trigger immediate paging.
  • Counterparty risk tier → diligence. Known low-risk counterparties bypass vendor due diligence; unknown or high-risk trigger full diligence.

How to operationalize

  1. One intake portal, one form. Channel discipline matters. If requests come via email, Slack, Teams, hallway conversations, and the portal in parallel, the queue is unmanageable. Drive everything to one portal.
  2. Form lives in the CLM. Ironclad and Agiloft both ship intake form builders that integrate with downstream contract workflows. Building the form in a separate tool creates handoff loss.
  3. Auto-classify with AI. When the form requester picks the wrong contract type or vendor risk tier, Claude re-classifies on submission and corrects the routing. Reduces misroutes by 40-60%.
  4. Self-serve where possible. A surprising fraction of “legal questions” are answered by linking the requester to an existing template, a knowledge base article, or a previously-decided position. Build the intake to surface those answers before queueing legal time.
  5. Publish the SLA. When the intake confirms “your standard NDA review will be done in 24 hours,” the requester relaxes and the GC’s email volume drops.

Common pitfalls

  • Form too long. Every additional field reduces submission rate. 15 fields is the practical max; 8 is better.
  • No SLA shown. Requesters chase status when they don’t know when to expect a response.
  • No status visibility. Once submitted, the requester can’t see where the request is. Build status into the portal.
  • Multiple intake forms for similar requests. “Contract review” and “vendor agreement review” should be one form with conditional logic, not two separate paths.
  • Intake form treated as static. The form encodes the SOP; both should evolve together. Audit the form quarterly against actual request patterns.