Collect vehicle, damage, location, insurance, and calibration context so staff can confirm service eligibility without the agent promising an unsafe repair method or final price.
Last updated: June 21, 2026
Clear operating rules
These pages explain how the service is intended to be used and how customer data is handled inside VoxsAgents.
Illustrative product workflow—not a verified customer result. It does not claim a conversion, revenue, cost-saving, or performance outcome.
Auto-glass calls combine vehicle identification, damage descriptions, mobile-service boundaries, weather, parts availability, insurance questions, and possible driver-assistance calibration. A caller usually wants an immediate quote and appointment, while the business may need staff or supplier review before either can be confirmed.
Original VoxsAgents research
Which facts can a voice agent reliably collect and act on during an auto-glass call, and which conclusions must remain pending until the business verifies vehicle configuration, parts, calibration, and service conditions?
We modelled the call as a sequence of evidence gates rather than a single qualification script. Each proposed claim—serviceable location, correct glass, available part, eligible mobile visit, appointment, insurance treatment, and final price—was mapped to the business record or external tool that could support it. We then designed separate outcomes for direct booking, estimate review, parts review, safety escalation, and unsupported requests, including provider failures and caller corrections.
Vehicle details are not ordinary free text because small differences can change the part or required work. The agent should collect year, make, model, body style, glass position, and approved indicators for cameras or sensors, then read back critical fields. It should not infer a precise part from a caller's casual description when the business requires a VIN, photograph, supplier lookup, or technician inspection.
A useful intake can reduce the next staff call without pretending to finish the estimate. The record should preserve caller-stated facts separately from verified catalog or account facts. Staff need to see which fields were read back, which remain unknown, and why the workflow selected booking or review. This is more actionable than a polished paragraph that combines assumptions and confirmed data.
Calendar eligibility depends on more than an open time. Mobile zones, job duration, technician capability, parts readiness, weather policy, and calibration workflow may affect the slot. VoxsAgents should pass a structured service classification into availability rather than querying a generic calendar. If eligibility is not established, the system creates a preferred-time request and clearly labels it as pending.
Insurance questions need a narrow administrative boundary. The agent may collect the insurer and approved claim details or explain the business's standard process, but it should not state that a policy will pay, that a deductible has been verified, or that a caller has no cost unless an authoritative integration returns that exact result and the business approves the wording.
Identify the glass location, vehicle year, make, model, body style, service address, and whether the vehicle appears to have cameras or sensors near the affected glass.
Separate a request that is eligible for direct scheduling from one requiring parts, safety, insurance, or calibration review under the business's rules.
Offer only slots and service zones returned by the configured system, then create either a confirmed appointment or a staff-owned estimate task.
Read back what is confirmed, what remains subject to inspection or parts verification, and how the customer will receive the next update.
Do not determine whether the vehicle is safe to drive or whether repair is preferable to replacement.
Do not guarantee insurance coverage, deductible, parts availability, calibration requirements, or final price.
Keep a quote request distinct from a confirmed work order and a preferred time distinct from a provider-confirmed appointment.
Escalate configured safety concerns and unsupported vehicle or service-area combinations to staff.
Create organization-owned lookup values for service zones, supported job types, direct-booking criteria, review reasons, durations, buffers, and escalation destinations. Tool inputs should reference these values by identifier. This prevents a language model from inventing a service type or squeezing an uncertain job into a short generic appointment simply because the caller requests the earliest time.
Store intake status independently from appointment status. Suggested states include collecting, ready-for-review, review-blocked, appointment-pending, provider-confirmed, and cancelled. A quote status can separately be not-requested, pending, provisional, or staff-confirmed. The call summary should render these states rather than generating a confident conclusion from the transcript.
Test similar vehicle names, corrected model years, an unreadable VIN, locations at a service-zone boundary, a requested slot lost before creation, unavailable parts, calibration uncertainty, a direct safety question, and calendar timeouts. The expected outcome is accurate routing and honest uncertainty, not maximum automated booking.
A caller's requested price must not be stored or spoken as an approved quote.
A preferred mobile location outside the verified zone must not receive a confirmed mobile appointment.
A calendar timeout must enter reconciliation rather than automatically retrying an unsafe create operation.
Vehicle and appointment corrections must propagate to staff tasks and customer-facing confirmation text.
Intakes complete enough for staff or supplier review
Appointments created from verified availability
Vehicle, service-zone, parts, and calibration corrections
Quote requests mistakenly communicated as confirmed prices
This is a workflow design, not automotive, insurance, or safety advice. Vehicle configuration and calibration requirements vary, provider data can be incomplete, and local operating conditions change. The business must define the authoritative catalog, qualified reviewers, direct-booking rules, safety language, and evidence required for any price or coverage statement.
This page is original VoxsAgents workflow analysis based on product behavior, failure-path review, and the official references below. It is not an empirical customer outcome study.
Treat these steps as a test plan. Adapt the fields, routing, permissions, and failure handling to the business before launch, then review real calls for errors and unintended behavior.
Read the evidence and methodology policy for the standard required before publishing customer outcome claims.
