Active cohort

Voice AI Intake & Triage

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.

← All Workflows

What This Workflow Is

Someone holding a phone, telling a long story about what happened and asking for help.
The call a hotline takes: a person telling what happened, in the order it happened to them.

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.

What callers get today

If you already know what you need

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.

Program manager evaluating a vendorFunctional agenda and conformance standards
Developer building a systemReference architecture and test suite
Funder writing grant requirementsConformance standards and test suite
Team deciding whether to buildMasterclass and case studies

The Package

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

Decide whether to do this

Planned

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 team settles here
Planned

Status quo baseline

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.

Planned

Evidence summary

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

Decide what you are building and what you are buying

Working draft

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 team settles here
Planned

Module catalogue

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.

Planned

Scoping questions

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.

Planned

Procurement and contract terms

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.

Working draft

Implementations

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

Specify and build

Open for review

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.

Open for review

Functional Agenda

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 →
Working draft

Reference Architecture

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

Test and run

Open for review

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.

What a team settles here
Open for review

Test Suite

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) →
Open for review

Conformance Standards

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 →
Planned

Evaluation protocol

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.

Working draft

Masterclass

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.

Join This Cohort

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.

Join this Working Group See All Working Groups