How to build an intake system that filters, routes, and prioritises automatically (4 of 8)

Picture the morning of a typical Monday in a legal department without an intake system:

⮾ An employment query arrives by Teams from a business partner in Germany.

⮾ A contract request comes by email from procurement.

⮾ A regulatory question lands in a lawyer’s WhatsApp because that lawyer helped the same team three years ago and the team never found another way in.

⮾ Two requests (both marked ‘urgent’) are waiting in a lawyer’s inbox with no context about what makes them urgent or who needs to respond.

By 9:30am, the team is already reactive. The day has been set for them.

In the previous article, we looked at building self-service infrastructure to keep recurring questions off your lawyers’ desks. That is the first layer of defence.

But self-service only handles the questions that already have answers. What about the new work that comes in every day, without structure, without priority, without context?

That is what this article addresses. And the answer is not a tool. It is an architecture decision.

An intake system is not a form. It is a decision-making infrastructure.

Done well, it ensures that every request reaching your team arrives with the right information, goes to the right person, and is handled in the right order.

What an Intake System Actually Does

A well-designed intake system does four things:

• It captures the information your team needs to handle a request before the first interaction, not during it.
• It filters: separating requests that need a lawyer from requests that can be handled by self-service.
• It triages: assigning a priority based on objective criteria, not on who shouted loudest.
• It routes: sending the request to the right person on the team based on expertise, availability, and matter type.

None of this requires an expensive legal technology platform to start.

It requires clarity about what information you need, and a structured way to collect it.

The Information Gap Problem

The single biggest time drain in legal request handling is the information gap: the lawyer receives a request, reads it, and needs to ask four follow-up questions before they can even begin.

What is the contract value? Is this a new counterparty or an existing one? What is the deadline? Has this been reviewed before? Each of those exchanges adds hours, sometimes days, to the actual handling time.

An intake form eliminates this.

By requiring structured input at the point of request, you ensure every matter arrives with the context needed to act on it immediately.

What to Capture at Intake

The goal is not to build a comprehensive case file at the point of intake. It is to collect the minimum information that allows the right person to start work immediately, without a single follow-up question.

• Matter type from a predefined list of 10–15 options
  The list matters. Too short and it obscures patterns; too long and requesters give up and send an email instead.
  Start with your diagnostic data from Article 2 and build from what actually comes in.
• Business unit, country, and name of the requester.
  Not just for routing. Over time, this data tells you which parts of the business generate the most demand, which teams routinely submit incomplete requests, and where you need to invest in business-side education.
• A plain-language description of what is needed and why.
  Prompt it explicitly: “What decision are you trying to make or action are you trying to take, and what’s the business context?” Left unprompted, requesters describe their situation. Prompted correctly, they describe their need. These are not the same thing, and the difference cuts handling time significantly.
• Relevant deadline and whether it is hard (if so, why?) or soft.
  Ask the requester to explain the consequence if the deadline is missed. This single question filters out a large proportion of false urgency. A deadline driven by a board meeting is different from one driven by a counterparty signature window, which is different again from one that is simply when the requester would prefer to have an answer.
• Relevant documents attached.
  Not promised. Not ‘to follow.’ Attached. A lawyer who opens a contract request and finds no contract attached loses ten minutes to a follow-up exchange that should never have happened. Make attachment mandatory for the matter types where it applies.
• Any prior legal involvement on this topic.
  This field prevents the most irritating category of duplicate work: a lawyer spending an hour on a matter that a colleague handled six months ago, with no awareness that a position was already taken. It also surfaces recurring issues that signal a need for a template, a policy, or a clause in the FAQ.
• Urgency level, with defined criteria for each option.
  That last field requires discipline. Define what urgent means in your organisation, make the definitions public, and hold to them. Resist the temptation to be generous: an intake system where everything is marked urgent is not a triage system, it is a queue with extra steps: when everything is urgent, nothing is.

Seven fields. That is all.

The Technology Question

The tool you use for intake should match your organisation’s existing infrastructure, not create a new platform to manage.

For organisations on Microsoft 365, a SharePoint-based intake form with Power Automate workflows is a practical, low-cost starting point. No new vendor, no new contract, no new login.

The best intake system is the one your business colleagues will actually use. Choose the tool that minimises friction for them, not the one with the most features for you.

The Triage Logic

Once a request is captured, the intake system applies triage logic. There are broadly four categories:

• Self-service: the request can be answered by the FAQ, process library, or template library.
• Paralegal or operations handling: the request requires action but not legal judgment.
• Lawyer handling – standard: legal judgment required, no immediate time pressure.
• Lawyer handling – priority: legal judgment required, hard deadline within 48 to 72 hours.

In most legal departments I work with, 20% to 30% of lawyer-handled requests could have been handled at a lower level. That is not a criticism of the team. It is a design gap.

Managing Expectations: The SLA

Define response times for each priority category and publish them. Example:

• Priority requests: acknowledgement within 4 hours, substantive response within 48 hours.
• Standard requests: acknowledgement within 24 hours, substantive response within 5 business days.

This sets realistic expectations, creates accountability, and makes visible when the team is overloaded. Because when SLAs are routinely missed, that is a capacity signal, not a performance signal.

Adoption: The Hardest Part

The critical factor is consistent behaviour from your legal team: if lawyers continue to accept ad hoc requests (by email, by Teams, by corridor conversation) the intake system will never take hold.

The CLO needs to model the behaviour: “Please submit this through the intake form so we can track it properly.”.
Every time.
Consistently.
Without exception in the early months.

Within six to eight weeks, it becomes the norm.

What This Unlocks

When intake is working well, the character of your team’s workday changes.

Instead of arriving to a chaotic inbox and spending the first hour triaging, the team has a structured queue with clear priorities, assigned ownership, and all the information needed to start.

The invisible overhead – the chasing, the back-and-forth, the requests that land with no context – stops being the default. Your team stops being reactive by design.

***********

But getting the front door right only solves part of the problem.

Once requests are flowing in cleanly, you will find that one category of work still dominates the queue, still generates the most back-and-forth, and still consumes the most lawyer hours: contracts.

Most legal departments respond to contracting pressure by asking lawyers to work faster. That is the wrong intervention.

The problem is not speed. It is the absence of pre-agreed positions, standard templates, and a process that does not restart from zero every time a new contract lands.

Every week without that infrastructure is another week of avoidable delay, avoidable escalation, and avoidable cost. Invisible on the budget line, but very visible in the hours your lawyers cannot get back.