Voice AI Intake: Functional Agenda

A person calls a published phone number. The system answers, tells the caller what it is, takes consent, collects who they are and what happened, classifies the legal issue, screens eligibility, checks for a conflict, and produces an intake record that staff can act on without calling the person back for the basics. At the widest scope the record flows into a document.

Three neighbouring workflows have their own agendas. Brief help question answering starts from a question rather than a caller. Referral routing scores and ranks services against capacity. Document assembly fills a form out. A single deployed product often crosses those lines, and the agendas stay separate so that conformance can be tested one workflow at a time.

Level	Keyword	What it requires
Required	MUST	The system does this before it serves the public. A deployment that misses a required capability has a failure mode the field has already documented.
Critical	MUST	A required capability where failure harms a person directly. These are the items to test hardest and to review by hand.
Extended	SHOULD	There may be good reasons to skip one of these, and the reasons should be written down. Most are what a mature deployment adds after its first year.
Aspirational	MAY	Few systems do these yet. They mark the direction of travel, and they are the capabilities most likely to change in the next version.

The keyword column follows BCP 14, the convention used in internet specifications, where the capitalized words carry the requirement level and ordinary prose does not. The keywords appear in the CSV and JSON downloads so that they can be pasted into a solicitation or a grant condition.

Identifiers

Each capability carries an identifier in the form VOI-<task area>.<capability>, for example VOI-4.2. Identifiers do not move or get reused inside a version. A retired capability keeps its number and is marked retired rather than deleted. Because numbers can change between versions, cite an item with the version attached: VOI-4.2 (voice-intake v1.0). This follows the identifier rule used by the OWASP Application Security Verification Standard.

Scopes

This agenda holds one catalog of 71 capabilities. Each of the five scopes is a selection over that catalog, stating which capabilities apply to a deployment of that shape and at what level. A capability marked not applicable is out of scope for that shape of deployment rather than unimportant. An organization can publish its own scope, saying what it requires locally, without forking the capability list.

Formats

This page is the reference view. The CSV and JSON downloads carry whatever the filters are currently showing, so a scope and level selection becomes a working checklist. The print view produces a PDF of the same selection. Every download records the version, the status, and the scope it came from.

Jump to a task area