Help people who call a legal help hotline get screened, triaged, and routed to the right help through a voice-based AI assistant that works alongside human staff.
Not everyone interacts with legal help through a screen. Many of the people who most need help are more likely to pick up a phone than visit a website, including older adults, people with limited English proficiency, people in crisis, and people without reliable internet. Legal help hotlines handle millions of calls a year, and most go to voicemail or end in long holds.
Voice AI intake is a system that answers a legal help hotline call, gathers enough information to understand the caller's situation, classifies the legal issue, checks basic eligibility, and routes the caller to the right service. The AI handles the initial screening. Human staff handle the advice, representation, and complex judgment.
This is not a replacement for human intake workers. It extends their reach. A voice AI system can answer every call on the first ring, collect the essential facts while the caller is engaged, and hand off a structured summary to the human team.
Who this serves: Legal help hotline callers, court self-help phone lines, pro bono intake programs, and any organization that receives more calls than its staff can answer.
The stages below are the reading order for a team working this through from the start. If you are further along, go straight to the assets that match your role.
The shared assets are arranged by when a team needs them, from deciding whether to do this at all through running a system in the field. Each stage says what it is for and how much of it exists today.
Stage one
Before a team scopes anything, it needs to know what the workflow is, who it serves, what callers get today without it, and whether these systems help. Reviewers told us they could not judge a conformance number because there was nothing to compare it against.
What a caller gets today without a voice AI system: how many calls are answered, how many reach a person, how long a caller waits, and what happens to the rest. Without this, no conformance number can be read as good or bad.
What the research so far says about whether voice AI intake improves on the status quo, and where it does not. Written so a director can take it to a board.
Stage two
A team has to settle what the service will actually do before it reads a specification or signs anything. These are the decisions that determine which capabilities in stage three apply.
What a voice intake system can be made of, piece by piece, how far each piece goes, what it needs from the organization, and what it does not do. A team uses it to decide which pieces it wants.
The questions a team answers before it writes a specification, drawn from teams who have been through it. The answers decide which capabilities in the functional agenda apply.
Language a team can take into an RFP and a vendor contract, covering what the vendor must demonstrate, who owns the data, and what happens when the system falls short.
Case studies from teams that have built or are building voice AI intake systems. What they chose, why they chose it, what surprised them, and what they would do differently. Designed so the next team building this does not start from scratch.
Join the cohort to contribute →Stage three
Read these once the team knows what service it is running. The functional agenda says what the system must do, and the reference architecture shows one proven way to build it.
A checklist of every capability a voice AI intake system should have, organized by what happens during a call: greeting, consent, information gathering, classification, routing, safety escalation, and handoff. The checklist format is what lets a lawyer and a vendor talk about the same thing. Use it to scope a build, write an RFP, or evaluate a vendor proposal, and set your scope level to see which capabilities apply to you.
Read the agenda →A technical blueprint showing how the pieces of a voice intake system fit together: how a phone call becomes structured data a human can act on. Describes each component (speech-to-text, conversation orchestrator, language model, text-to-speech, case management integration) and the design decisions that matter most.
Join the cohort to contribute →Stage four
How a team checks whether the system it has is good enough to put in front of callers, and how it keeps checking once the system is running.
A bank of realistic caller scenarios that you run through your system to see how it performs. Each scenario includes the caller's situation, the correct classification, what good intake looks like, and what bad intake does wrong. Includes straightforward cases, ambiguous situations, crisis callers, and edge cases. Use it during development or for independent evaluation.
View the test suite (Google Sheet) →Five gates a system has to pass before it should be trusted with real callers: whether it performs accurately, whether callers can actually use it, whether it handles safety situations correctly, whether staff can work alongside it, and whether the organization can maintain it. Each gate has pass and fail criteria, and each one says what a failure means for a caller. Reading a score still needs the status quo baseline in stage one, which does not exist yet.
Read the standards →Who runs the tests, how long a full pass takes, what it costs in staff hours, and how the results get written up so another organization can read them.
A hands-on course that walks a team through the decisions involved in building, deploying, and maintaining a voice AI intake system. Each module is built around a real decision the team has to make, and ends with that decision written down. We are looking for teams willing to go through a draft version and give us feedback.
The Voice AI Intake working group is developing the shared assets on this page. The cohort steers what gets built. Members shape the agenda, review standards, and contribute implementation experience.