Automated legal triage is the set of rules, data fields, lookup values, and workflow actions that classify each incoming legal request and send it to the right team, owner, workflow, or self-service path without someone sorting an inbox by hand. It starts with structured intake, checks that the required information is present, evaluates criteria such as request type, region, risk, and urgency, and then assigns or escalates the request. Every decision is recorded with the request, so legal operations can see why work went where it did.
What is automated legal triage?
Automated legal triage is the rules engine behind a legal front door that turns intake data into a routing decision and an owner, using explicit criteria set by legal operations. It handles the predictable decisions automatically and sends the unpredictable ones to a person.
The difference from manual triage is consistency. A shared mailbox sorted by whoever is on duty produces different outcomes on different days. A rules engine applies the same logic to every request and records it. Many teams still sort by hand: a 2025 survey of in-house legal teams found 44 percent are still manually creating, assigning, and updating legal work. It sits upstream of the legal request triage process in which lawyers prioritize the work, and it only works as well as the data the form collects.
What data does an automated triage engine need?
An automated triage engine needs a small set of structured fields that together identify the right destination, usually eight to fifteen values captured at intake or pulled from the employee directory. Free-text descriptions help the lawyer but cannot drive routing reliably.
- Routing inputs. Request type, sub-type or help code, region or country, legal entity, business unit, value, and business deadline. These decide which team and workflow receive the request.
- Risk and complexity signals. Simple flags such as regulatory involvement, litigation, personal data, or nonstandard terms, plus a complexity indicator that separates self-service candidates from specialist work.
- Validation. Check every routing field before submission. A request with no region or request type has no route, so the engine should block submission or send it to a named fallback queue.
Where free text has to be read before routing, AI legal intake can recommend a classification for a person to confirm.
How does a legal routing table work?
A legal routing table works by combining several intake values into a single key and looking that key up against a maintained list of destinations. Each row says, in effect, “when these values appear together, send the request here.”
A typical key joins the legal team or region, the request type, and a sub-type. The table then returns the queue, the default owner, the workflow to start, and the service level. Examples of how rows behave:
- Region and type. A UK contract review request opens the commercial contract workflow in the UK legal queue.
- Sub-type. A statement of work routes to the SOW specialist or to an approved template path.
- Business unit. A request from procurement goes to the procurement legal team, whatever its region.
Most departments end up with 50 to 200 rows. Keep the table in configuration that legal operations can edit and version, and treat every change as a release. Release management on configured legal platforms applies to routing tables as much as to forms.
How are legal requests assigned to an owner automatically?
Legal requests are assigned automatically by the routing table naming either a queue, a specific owner, or a rule for choosing one, such as rotation or current workload. Every request should end triage with a named person or queue responsible for it.
- Queue assignment. The request lands in a team queue, and a team lead or triage lawyer picks it up. This suits teams where judgment decides who takes what.
- Named owner. High-volume, well-defined work such as NDAs goes straight to a specialist or contract manager.
- Workload balance. Where several people cover the same work, assign by rotation or send the request to the qualified owner with the fewest open items. A threshold of 15 to 20 open requests per person is a common trigger to spill over to another owner.
Aim for time to assignment under four business hours for standard requests.
When should automated triage escalate a legal request?
Automated triage should escalate a legal request whenever its data meets a predefined risk, urgency, or value threshold, moving it to a senior reviewer or an accelerated service level. Escalation rules protect the requests that cannot wait for the normal queue.
- Risk triggers. A high risk rating, a regulatory notice, or litigation routes the request to senior review the same day.
- Value triggers. Values above a set threshold for the request type route to senior review as well, with the threshold kept in the routing table.
- Deadline triggers. A business deadline within three days raises priority and applies an accelerated service level, with the reason for urgency captured so it can be checked.
Keep escalation rules few and specific. If everything escalates, the escalation queue becomes one more backlog. A risk matrix for legal request prioritization gives these thresholds a consistent basis.
What happens in the human triage queue?
The human triage queue holds every request the rules place in a team queue or cannot route with confidence, and a triage lawyer resolves each one with a small, fixed set of actions. The queue should be sorted by age and priority so nothing sits unseen.
- Assign. Allocate the request to a lawyer or matter manager, which can convert it into a tracked matter.
- Request information. Send the request back to the requester with a specific question, pausing the service-level clock.
- Close or void. Answer and close a simple request, or void a duplicate or misdirected one with a reason.
Keep the list of actions short, typically three to five, and record the reason for each. Review the queue daily, with a target of every new request actioned within one business day.
How should rerouting and reassignment work in automated triage?
Rerouting in automated triage should let a triage lawyer change the request type, team, or region with a reason code, after which the rules re-run and pick the new destination. Reassignment should update ownership everywhere the request is linked.
Changing the request type from contracts to privacy, for example, should re-evaluate the routing table and start the correct workflow. The same applies when a request that fits more than one category is reclassified at triage. Manual workarounds that bypass the rules break reporting. When a lawyer leaves or changes role, legal operations should be able to move their open requests and linked matters to a new owner in one controlled action.
Track the reassignment rate by team and request type. A rate above 10 percent points to a routing row, category label, or form question that needs fixing.
How do you keep automated routing decisions auditable?
Automated routing decisions stay auditable when the request stores the inputs used, the rule or table row that matched, the destination chosen, and every later change with its time, user, and reason. Anyone reviewing a request should be able to reconstruct why it went where it did.
The decision record stores the routing key, the matched row, the assigned owner, and the timestamps for submission, assignment, escalation, and closure. The change history logs reroutes, reassignments, and service-level pauses with the person responsible and the reason code.
Plain inbox rules cannot produce this record, which is one reason basic automation fails without advanced conditional logic behind it.
How do you test and measure automated legal triage?
Automated legal triage is tested by running a request through every routing row and escalation rule, then measured by how often requests reach the right owner on the first attempt. Both depend on the routing table being complete.
- Row coverage. Write at least one test case per routing row, plus 20 to 30 edge cases for missing data, unmatched keys, deadline triggers, and workload spillover.
- Unmatched routes. Confirm every unmatched combination lands in a named fallback queue, and keep unmatched requests below 2 percent in production.
- Ongoing metrics. Track first-routing accuracy (target 90 to 95 percent), reassignment rate, time to assignment, escalation volume, and service-level compliance by team.
Review the metrics monthly with team leads, and fix routing rows before adding new ones. Faster, accurate routing is one of the quickest ways to reduce legal turnaround time, and the pressure is rising: in a 2025 survey of 188 companies, 83 percent of legal operations teams expected demand for legal services to increase.
Conclusion
Automated legal triage works when intake captures the right fields, a governed routing table turns them into a destination, and clear rules handle assignment, escalation, and rerouting. The human triage queue catches what the rules cannot place, and a complete decision record shows why every request went where it did. Build the table carefully, test every row, and let the reassignment data tell you where it needs work.
How Basla can help
Basla provides delivery teams for legal intake and request management software implementation, covering automated legal triage design, routing tables and lookup configuration, assignment and escalation rules, triage queue setup, testing, documentation, and hypercare. Across its legal technology services, Basla teams have built a legal service request implementation with eight front doors for language and country variations, each routing through a shared triage model.
Frequently asked questions
What is automated legal triage?
Automated legal triage is the rules engine that classifies incoming legal requests and routes them to the right team, owner, workflow, or self-service path using structured intake data. Requests the rules cannot place go to a human triage queue.
What is a legal routing table?
A legal routing table is a maintained list that maps combinations of intake values, such as region, request type, and sub-type, to a destination queue, default owner, workflow, and service level.
What data does automated legal request routing use?
Automated legal request routing typically uses request type, sub-type, region or country, legal entity, business unit, value, deadline, and risk flags captured at intake or pulled from the employee directory.
When should a legal request be escalated automatically?
A legal request should be escalated automatically when it meets a predefined threshold for risk, value, or urgency, such as a regulatory notice, litigation, or a business deadline within a few days.
What happens when a request does not match any routing rule?
When a request does not match any routing rule, it should land in a named fallback queue for manual triage. Unmatched requests should stay below about 2 percent of volume.
How do you measure whether legal triage automation is working?
Legal triage automation is working when first-routing accuracy stays at 90 to 95 percent, reassignment stays below about 10 percent, and requests are assigned within the target time.
*This article is provided for general information only and does not constitute legal advice. Basla Solutions provides legal technology implementation and support services and does not practice law.*