Legal Intake and Triage Workflow for In-House Teams

When legal work arrives through email, chat, meetings, and personal relationships, the loudest request often receives attention first. The legal team then spends time reconstructing purpose, parties, documents, authority, and deadlines. Requesters cannot see what happens next, and sensitive information can spread before anyone classifies it.

A legal intake and triage workflow creates one visible path from business question to owned legal work. It should reduce repeated clarification while remaining easy enough that colleagues actually use it. The workflow supports legal judgment; it does not automate the answer.

What should legal intake accomplish?

Intake should capture enough context to recognise the work, protect it, and assign the next step. It should not force the requester to complete a legal analysis. Ask for facts the requester is likely to know and let the legal team add professional classifications.

The intake record becomes the starting point for a matter or service request. It should remain linked after work moves into contract review, litigation, corporate, privacy, employment, compliance, or another specialist workflow.

Which fields belong on the first request form?

Keep the first form purposeful. A strong core asks who is requesting help, what outcome is needed, which business activity is involved, the relevant entities and people, what has happened so far, supporting documents, known external communications, the business event driving timing, and who can confirm facts.

Use conditional questions after the request type becomes clearer. A contract request may need counterparty, commercial purpose, proposed paper, value authority, data flows, and target signature event. A dispute may need forum, case or notice material, parties, receipt evidence, and known events. An investigation needs a restricted route rather than a longer public form.

Do not ask “How risky is this?” without definitions. A requester may minimise a sensitive issue or mark every urgent request “critical.” Ask observable questions: Is an authority involved? Has a document been received? Is an external event scheduled? Is personal data involved? Could records change or disappear? Has anyone already made a commitment?

Gotham's contract request intake workflow provides a deeper example for purpose, documents, approvals, and dependencies in contract work.

How can the form stay simple without losing important context?

Use progressive disclosure. Begin with a short recognition layer, then show questions relevant to the chosen work type. Save drafts and allow the legal team to return a specific clarification request. A colleague should not have to restart the entire form because one attachment is missing.

Accept uncertainty explicitly. “Unknown,” “not yet agreed,” and “document requested” are honest states when paired with an owner. Preventing submission until a colleague invents an answer damages the record.

Design accessibility and language support into the path. Use plain labels, explain why sensitive information is requested, and provide an alternative route for colleagues who cannot use the standard form. Keep emergency and confidential reporting paths visibly separate, with clear boundaries.

The Association of Corporate Counsel and CLOC publish legal operations and in-house resources that may help teams develop their service model. Their materials are reference inputs, not a substitute for an organisation's own policy, professional duties, or workflow design.

How should the legal team triage a new request?

Triage is a professional routing decision supported by structured facts. The triager should confirm the record is genuine, identify duplicate or related work, assess access, check for immediate preservation or deadline questions, classify the service path, assign ownership, and explain the next state.

A practical sequence is:

1. Recognise: confirm the request and preserve original attachments.
2. Protect: apply appropriate confidentiality and access controls.
3. Relate: find existing matters, contracts, entities, or prior decisions.
4. Route: assign the responsible legal area and accountable owner.
5. Clarify: request only the missing facts needed for the next decision.
6. Plan: create tasks, approvals, and specialist handoffs.
7. Acknowledge: tell the requester who owns the work and what happens next.

The table is a routing aid, not a legal risk determination. The triager should be able to override a suggested route and record why.

How should urgency be handled without letting every request jump the queue?

Separate the business target from a legal deadline. Ask what event drives the requested date and what happens if it moves. If counsel identifies a legal or procedural date, create a source-linked deadline record under the approved docketing process.

Urgency can be assessed through observable conditions: an authority or court event, an expiring external process, immediate safety or evidence concerns, a transaction dependency, an existing commitment, or widespread operational impact. The team can then choose a response path based on its capacity and policy without publishing universal response promises.

When the requested date cannot be met, give the requester choices where possible. These might include clarifying the immediate decision, narrowing scope, sequencing issues, using approved standard material, or changing the business event. Record the agreed course and its owner.

Who owns the request after triage?

Assign one accountable legal owner even when several specialists contribute. Also identify the business owner who can confirm facts and make business decisions. Contributors receive scoped tasks, not a copy of the whole request by default.

Use explicit states such as received, triage in progress, clarification requested, accepted, active, awaiting business, awaiting third party, under review, decision issued, follow-up open, and closed. Define entry and exit criteria. “Pending” is rarely enough because it does not identify who must act.

A handoff should include the request, issue statement, known facts, missing facts, source documents, access class, decisions made, deadline record if any, next action, and stakeholders. Gotham's legal case intake workflow describes a related structure for case-oriented work.

How should conflicts, confidentiality, and privilege shape intake?

The workflow should avoid promising that every submission is privileged or confidential merely because it enters a legal form. Provide an accurate notice approved for the organisation's context. Limit collection and access according to the request.

Sensitive categories need dedicated routes. Investigation reports, whistleblowing matters, employee health information, competition concerns, transaction secrets, credentials, and security incidents should not sit in a broadly visible queue. Use restricted groups, neutral list labels, controlled notifications, and an audited access-change process.

Conflict or independence checks may be relevant for internal teams or external counsel. Capture parties and relationships as separate structured records, then route the assessment to qualified professionals. Do not let fuzzy matching silently block work or declare that no conflict exists.

ISO publishes standards across information security, privacy, quality, and service management domains. An organisation may use applicable standards as design references where appropriate. It should verify the exact standard, edition, scope, certification claims, and licensed text rather than relying on a generic badge.

When should a request become self-service?

Self-service works when the organisation has an approved, bounded path for a recurring request and the user can recognise when it does not apply. Examples may include an approved template, guidance note, decision tree, clause position, or document assembly flow.

Every self-service path needs scope, exclusions, owner, approved source, version, review trigger, escalation route, and a record of what the user selected. Avoid presenting generic material as personalised legal advice. If the facts fall outside the path, convert the interaction into a legal request without forcing re-entry.

Knowledge feedback should come from reviewed work. If triage repeatedly asks the same clarification, improve the form or guidance. If a request frequently leaves the standard path, narrow its description rather than hiding exceptions.

How should intake quality be reviewed?

Review whether the workflow supports better decisions, not whether it produces more submissions. Sample records across channels and work types. Check that sources are preserved, related matters are linked, access is appropriate, ownership is visible, state changes have reasons, and closure has evidence.

Do not turn these checks into individual productivity rankings. They are controls for the service system. Review incomplete or off-channel work without blaming requesters. If people bypass intake, investigate whether the path is unclear, inaccessible, slow, or poorly matched to how the business works.

How can an in-house team introduce the workflow?

Map current entry channels and select one representative work type. Define the minimum request, triage role, sensitive route, state model, acknowledgement, and closure evidence. Test with synthetic requests that are incomplete, duplicated, urgent, restricted, multidisciplinary, and outside scope.

Publish a short guide that says what the channel is for, what happens after submission, where urgent or confidential matters go, and how to correct a request. Keep an assisted route during adoption and improve the form from real clarification patterns.

Teams can explore Gotham's legal workflows, practice workspaces, security overview, or contact Gotham about connecting intake with documents, approvals, matters, and follow-up. The best workflow is not the most elaborate. It is the one colleagues trust to route important work without losing context.