Legal front door and triage
One way in, questions answered at the door, the rest routed with context attached.
The problem
Work arrives by email, chat, hallway and ticket. Nobody can see the queue, the same questions are answered repeatedly, and the team absorbs demand that was never sized.
How we would run it
STAGE 1
Evidence
A written picture of the current state, with its gaps named.
Sample a period of real requests across every channel and classify them. Most departments find a third of the volume is the same handful of questions.
STAGE 2
Baseline
A baseline measurement both sides agree on.
Cost the current model: volume by type, time to first response, and how much of it never needed a lawyer at all.
STAGE 3
Design
A design your architecture and risk leads have approved.
Design the door: what self-serves, what routes, what always reaches a named person. Agree the service levels with the business before anything is built.
STAGE 4
Ship
Working software or a live process, in production.
Launch with one business unit and the two highest-volume request types. Answers cite the policy they came from, so a requester can check them.
STAGE 5
Prove
A result measured against the baseline, and an instrument you keep.
Report deflection, response time and satisfaction against the baseline, then add request types in order of volume.
What you get
- Request taxonomy built from real intake
- Triage and routing rules, with service levels the business agreed
- Self-service answers that cite their source policy
- Queue reporting the team can read without us
What it needs from you
- A sample of real requests across channels
- Current policies and standard answers
- Access to the channel the business will actually use
Where the human stays
Self-service answers are limited to questions with an approved written answer. Anything outside that set routes to a person, and every answer shows the policy behind it.
How we would know it worked
- Share of requests resolved at the door
- Time to first meaningful response
- Volume reaching lawyers that did not need to
Where it starts
Starts as a sprint
AI Tooling Reality Check
What you own, what you use, and what the demo did not show.
Sprint details →Grows into
Operating Model & Transformation
Fix how the work is staffed, routed and measured — not just the tools.
Program details →Grows into
AI Build — pilot to production
One use case, built and put into production, with evidence it works.
Program details →Start with one sprint
Two to three weeks, one approver, a deliverable you keep. Tell us the problem and we'll come back within one business day with a scope, a date and a fee.
Scope a sprint →