Voice AI for Lost Property, Complaints, and Non‑Emergency Service Requests
Practical, operational guidance for transit leaders to measure, optimize and scale Voice AI for lost property intake, complaints and non‑emergency service requests — with QA, containment, escalation, multilingual scale and procurement controls.
1. Scope, outcomes, and where this fits in your program
Define what success looks like and what this article covers. This section clarifies scope (lost property, complaints, non‑emergency requests), outcome metrics, and how Voice AI fits into a Measurement → Optimization → Scale program.
Scope and exclusions
Voice AI in this article covers inbound voice intake for lost property reports, customer complaints, and routine service requests that do not require immediate field response or emergency intervention. Do not use Voice AI here for safety‑critical incident triage, medical emergencies, or any call that requires a trained dispatcher or first responder. Emergency escalation must route to trained staff by clear prompts and priority routing.
- Included: intake, validation, duplicate detection, case submission, confirmation delivery, and human handoff.
- Excluded: emergency response, real‑time vehicle control, and unsanctioned next‑bus predictions without a verified, low‑latency data source.
Primary operational outcomes
Target measurable outcomes early: containment rate (percentage of contacts closed by automated flow), escalation quality (percentage of escalations correctly routed without re‑triage), and cost‑to‑serve (total operating cost per completed case). Set baseline KPIs during a pilot and iterate to improve these metrics. Use both qualitative QA reviews and quantitative telemetry.
- Containment quality — aim for predictable incremental improvements (e.g., pilot → baseline → optimized), not instant parity with humans.
- Escalation quality — measure accuracy of routing and the proportion of escalations that require rework.
- Cost‑to‑serve — include platform, telephony, ASR/NLU credits, agent time, and exception handling costs.
2. Architecture and operating model (decision map)
A clear, minimal architecture reduces operational risk. The Rider → Voice AI → Controlled knowledge / Service‑alert APIs → Validation → Response/Case/Handoff flow should be implemented with explicit boundaries and observability.
Canonical architecture and data flow
Implement a deterministic flow: 1) Rider calls; 2) Voice AI ASR/NLU routes to intent and slots; 3) system checks controlled knowledge for scheduled/static info or authorized service‑alert APIs for detours/delays; 4) validation and interactive form completion; 5) automated resolution, case creation in backend systems, or human handoff. Keep the controlled knowledge store for schedule and station metadata and call service‑alert APIs for live alerts. Use orchestration adapters to decouple vendor voice stacks from case management and service‑alert integrations.
- Controlled knowledge: static timetables, station names, lost‑property policies, and FAQ text under strict update processes.
- Service‑alert APIs: live detours, delays, or incident status pulled at runtime; treat as authoritative for any time‑sensitive guidance.
- Adapters: thin, observable connectors between Voice AI and CRM/case systems to enforce validation and mapping.
Separation of scheduled knowledge from service‑alert APIs
Operationally separate the data sources: scheduled knowledge is managed on a cadence with versioning and rollouts; service‑alert APIs deliver ephemeral state (detours/delays). Voice flows must query the appropriate source depending on intent. For example, when a caller asks about a timetable, use the controlled knowledge. When they ask if a route is delayed or subject to a detour, fetch live service‑alert API data to avoid delivering stale or misleading guidance.
- Maintain a registry that marks each question type with the permitted data source and TTL (time‑to‑live) for cached entries.
- Design prompts that clearly indicate live data is being used (e.g., “I’m checking current alerts for Route 15”).
- Log the data source and timestamp for all responses for post‑call QA and audit.
3. Measurement: QA, analytics and core KPIs
Measurement must be both precise and actionable. This section defines how to measure containment, escalation quality, and cost‑to‑serve, and the instrumentation required.
Core KPIs and how to measure them
Define a short list of metrics that inform product and ops decisions: containment rate, escalation quality, first‑pass accuracy (correct intent + full slot set), average handle time for escalations, and cost‑to‑serve per case. Use evented telemetry at each touchpoint: ASR confidence, NLU intent confidence, slot completion flags, validation failures, handoff triggers, and case outcome (closed/assigned/reopened).
- Containment rate = automated resolutions / total contacts for covered intents.
- Escalation quality = successful escalations (no rework) / total escalations.
- First‑pass accuracy = intents with correct classification and complete validated slots on first interaction.
Quality assurance program
QA mixes automated and human audit: sample transcripts for annotation, targeted review of low‑confidence intents, and case audits comparing Voice AI capture to the human final record. Set clear acceptance thresholds and cadence for retraining. Keep a feedback loop where human edits to case data feed model improvements and phrase‑list updates.
- Automated alerts for low‑confidence transcripts and repeated failures per intent.
- Regular audits of escalations to identify routing errors and training data gaps.
- Use controlled A/B experiments to validate changes before full rollout.
4. Multilingual and multi‑site scale
Scale introduces complexity: multiple languages, local place names, regional policies, and site‑specific routing. Treat scale as operational configuration, not model magic.
Multilingual strategy and quality gates
Design language support incrementally: start with top languages by call volume and pilot localized ASR models or custom lexicons for place names. Implement language detection early in the call and route to language‑specific flows and agents as necessary. Put language‑specific QA in place — measure containment and first‑pass accuracy per language and track phrase list coverage for local station names and landmarks.
- Use language detection followed by explicit language confirmation for low‑confidence cases.
- Maintain language‑specific phrase lists for place names and abbreviations; update them from real call data.
- Measure containment, escalation quality and cost‑to‑serve by language to prioritize investments.
Multi‑site configuration and routing
Keep regional rules and site configurations in a central configuration service that Voice AI queries at runtime. Key items include service hours, local lost‑property policies, regional contact centers, and escalation paths. Ensure the orchestration layer maps the caller’s site (by phone number, input, or ANI) to the correct configuration and routing pool.
- Centralize configuration but allow per‑site overrides with strict change control.
- Use phone number geography plus caller prompts to confirm site when ambiguous.
- Track per‑site KPIs to detect localized failures or phrase‑list gaps.
5. Continuous optimization, procurement and governance
Operational resilience requires governance and procurement choices that preserve observability, failure safety, and continuous improvement.
Human‑in‑the‑loop and continuous improvement
Design a lightweight HIL program where high‑value failures are reviewed daily and model or flow updates are released on a short cadence. Use experts to approve phrase‑list changes and to validate slot‑mapping rules. Maintain an experiment framework for controlled rollouts and rollback paths.
- Triage queue for human review of low‑confidence and repeated failures.
- Daily extracts of recent escalations for fast fixes to routing or validation logic.
- Controlled rollout with automated rollback if containment or escalation quality degrades.
Procurement checklist for vendors
Procure vendors based on functional fit and operational controls. Require clear statements on integration ownership, observability endpoints, failure boundaries, subprocessors, data residency options, retention policies, and liability for data breaches. Ask for documented runbooks for outages and a commitment to provide event logs for audits.
- Contractual requirements: interface SLAs, change management, and audit access to telemetry.
- Operational requirements: error codes, retry behaviors, and deterministic fallback plans.
- Subprocessor and residency disclosure with options for regional hosting where required.
6. Implementation patterns, failure modes and runbooks
Concrete workflows and explicit runbooks reduce ambiguity when things go wrong. This section provides implementation patterns for the three use cases and recommended failure responses.
Lost property workflow (typical automated flow)
Guided intake should capture minimal structured fields: last seen date/time, route/vehicle/stop, item category, contact info, and any identifying details. Use validation (confirmations, spelling backfill) and a deduplication check before creating a case in the case management system. If confidence is high and policy permits, return immediate claims guidance and a reference number. Otherwise, escalate to a human with the collected summary.
- Required fields: location (normalized), date/time, item category, caller contact.
- Validation: repeat back captured details; confirm ambiguous place names using phrase lists.
- Fallback: if ASR confidence < threshold or dedupe uncertain, queue for human review.
Complaint intake workflow
For complaints, capture complaint type, location/time window, impacted service (route/stop), and desired outcome. Use branching to identify policy‑bound complaints (e.g., accessibility issues) that require higher‑priority human review. Ensure the flow records the data sources used to answer any factual questions (controlled knowledge vs live alert).
- Classify complaint severity to determine priority and SLA for human follow‑up.
- For protected‑class or accessibility complaints, escalate to trained staff for sensitivity handling.
- Log the data source used for each response to maintain transparency in reviews.
Non‑emergency service requests and form validation
Non‑emergency requests (e.g., lost property collection, late refunds, minor maintenance requests) should be handled by a dynamic form in Voice AI. Validate critical fields inline to reduce rework: address normalization, service point selection, and date/time windows. Where required, ask permission to record and retain the call, and store minimal PI necessary for the task.
- Inline validation reduces follow‑up contact and improves containment.
- Ask for explicit consent to record where legally required and capture consent event in logs.
- If a request requires field‑dispatch, confirm it is non‑urgent before creating a work order; otherwise route to after‑hours protocols or human triage.
Related Peak Demand resources
Industry and AI sources reviewed
- Artificial Intelligence Risk Management Framework (AI RMF 1.0)National Institute of Standards and Technology (NIST)
- OECD AI PrinciplesOrganisation for Economic Co-operation and Development
- Transportation Systems SectorCybersecurity and Infrastructure Security Agency (CISA)
Transit safety, accessibility, privacy, cybersecurity, records, and service-information obligations vary by jurisdiction and operating authority. This article is operational guidance, not legal advice; organizations should confirm applicable requirements with qualified professionals.
Frequently asked questions
Good starting points include lost property, complaints and feedback, stop or shelter issues, fare-machine faults, non-emergency accessibility service requests, schedule information from approved sources, and structured routing to customer service or field teams.
Official reference: Artificial Intelligence Risk Management Framework (AI RMF 1.0)
Use GTFS Realtime only when the agency exposes suitable feeds and the workflow genuinely needs service alerts, trip updates, or vehicle positions. The integration should validate freshness and availability, and the agent should avoid presenting stale feed data as a guaranteed arrival prediction.
Emergency, security, injury, crime, and safety-critical reports should follow approved transfer or emergency-routing procedures. Voice AI may detect and route the call, but it should not make operational safety decisions or replace trained personnel.
Official reference: Transportation Systems Sector
Request realistic call testing, feed and system failure handling, service-request integration, transfer context, audit logs, accessibility channels, monitoring, change control, and evidence that the agent distinguishes scheduled information from dynamic service alerts.
Official reference: Artificial Intelligence Risk Management Framework (AI RMF 1.0)
Design the transit service workflow before automating it
Peak Demand helps transit teams connect Voice AI to rider information, service requests, approved live-data sources, escalation, confirmation, and analytics.
Schedule a discovery call
