Legal intake and triage

Who it is for

An in-house legal team that receives requests from the whole company and has no single front door. The starting profile this design proposes is a team of more than three people in which at least half of the incoming work is of a repeating kind. It is also intended for a one-person legal function, where the purpose is preventing overlooked work, not a claim of faster work. The symptom is familiar. Two lawyers answer the same question in the same week. An urgent request sits in a mailbox nobody owns. At the end of the quarter nobody can say what the team actually spent its time on. This is the workflow I would start with in almost every in-house engagement, because it is the one that produces the baseline the other three are later measured against.

The trigger

A request arrives. An email to a shared mailbox, a chat message to whoever is online, a form submission, a forwarded contract, or a corridor conversation that somebody writes down afterwards.

A system notification can also start the workflow. Whoever captures the request completes the initial fields.

The stages

1. 01

   Capture

   Requests from the agreed channels land in one place, unchanged, with their raw text, attachments, sender and arrival time.

2. 02

   Bind

   Each request becomes a named file with a type, an owner, a clock and a priority. No work starts before the file exists.

3. 03

   Classify

   The agent proposes the type, the urgency and the owner, inside its mandate, and names the rule that produced the proposal.

4. 04

   Confirm

   A lawyer accepts, changes or rejects the proposal. A change stays next to the proposal with a one-sentence reason, so the routing rules can later be corrected from evidence rather than from memory.

5. 05

   Route

   The file goes to the named owner, the routing clock starts and its place in the queue is visible. That clock is an internal service target; a legal deadline runs from its own event, such as the date of service, and is recorded on the file as a separate date. The requester receives an acknowledgement that says what the work is, where it stands in the queue, what happens next and by when.

6. 06

   Close

   The file closes with an outcome, its duration and its final owner, and the closing entry stays in the record.

What the agent may read, keep and do

Where a person signs

Stage 04, and the workflow will not pass it. A named lawyer accepts, changes or rejects the classification before anything is routed. Matter types you mark sensitive, such as investigations, employment matters and anything privileged, skip the proposal entirely and go straight to the lawyer you name. The agent’s mandate does not include reading them.

The lawyer sees the original request, the proposal and the rule that produced it. A rule that needs correction is flagged to its owner; the reason for a changed classification is recorded.

What the record contains

The workflow writes the record, not the user. This is the file that answers, at the end of a quarter, what the team actually spent its time on.

The measure a pilot uses

One measure, chosen by you, with a baseline taken before the pilot starts. The one I would usually propose is the share of requests that reach the right owner without a second hop, measured against the two weeks before the workflow ran. Two secondary figures are recorded for information: the time from arrival to acknowledgement, and reviewer minutes per request. They are not additional acceptance measures. You set the number that counts as a pass, and you set it in advance.

The critical error is a deadline-bound request classified under the wrong type. Tolerance is zero: one such error prevents the workflow from passing the gate.

The systems it usually sits on

A shared mailbox and a chat tool, a form or a service desk, and whatever the team already uses to hold matters. In a corporate stack that may be a matter or intake system the team already has, such as LawVu, Onit, SimpleLegal, Brightflag, Streamline AI, Checkbox, BRYTER or Clio, beside a document system such as iManage, NetDocuments or SharePoint. In Türkiye, depending on the institution’s requirements, UYAP notifications and their deadlines, UETS e-Tebligat arrivals and KEP correspondence can enter the same queue, which is a clock question before it is a software question. LEXSAS resells none of these and claims no certified connector to any of them.

The first week

Day one

The scope call: channels, matter types, the rota, the lawyers who sign, the systems, the measure.

Days two and three

Preparation for the baseline: I read two weeks of your real requests with you, and we count arrivals and acknowledgement times over the last thirty days. The matter types come out of what actually arrived, not out of a template.

Day four

The routing rules and the agent’s mandate are written down, and you correct them. Most of the value of the week is in these corrections.

Day five

The record format and the wording of the acknowledgement are agreed, a gold set is selected from past requests with the lawyers’ recorded correct answers, the baseline count starts, and the pilot dates are fixed.

The engagement brief determines the sequence for each assignment. This is the usual order of work, not a timetable commitment.

Exit terms

Everything below is yours from the first day and leaves with you in an exportable format, whatever happens to the workflow:

• The matter-type list and routing rules
• The mandate and its version history
• The record format
• The gold set and the lawyers’ correct answers
• Every run record
• The workflow definition and the design brief

The exit terms are written into the pilot from the start, not negotiated at the end. If we stop, everything listed above stays, and the queue keeps running without me. If any part of the workflow depended on my continued involvement, I would tell you before the pilot rather than after it.

Three questions