Voice AI lead qualification works when the agent has a narrow decision to make, evidence to collect, and a reliable path into the CRM. A natural voice cannot rescue vague criteria or a broken handoff. We build Dasha for production voice workflows. The practical task is to turn your qualification policy into a conversation, a deterministic score, and an auditable record your sales team can use.
What voice AI lead qualification should own
A voice AI qualification agent calls or answers a prospective buyer, asks approved questions, captures the answers as structured data, applies qualification rules, and takes one permitted next action. That action may be booking a meeting, routing to a sales representative, scheduling a callback, placing the lead in nurture, or recording an opt-out.
The scope should end there. Contract negotiation, custom pricing, regulated eligibility decisions, unusual policy exceptions, and sensitive disputes belong with a person.
We recommend defining six terminal dispositions before writing any prompt:
| Disposition | Meaning | Required system action |
|---|---|---|
| Sales-ready | Required evidence meets the routing rule | Book or transfer, assign an owner, write the evidence to the CRM |
| Nurture | Fit may exist, but timing or intent is weak | Record the next permitted contact date and follow-up channel |
| Disqualified | A documented exclusion applies | Store the exclusion code and prevent accidental rerouting |
| Human review | Evidence is ambiguous or a policy exception appears | Create a review task with transcript context |
| No contact | The call did not produce a qualification conversation | Store the attempt result and apply the retry policy |
| Do not contact | The person opts out or an eligibility control blocks outreach | Suppress future outreach across connected systems |
This boundary gives the agent a clear job and gives your team a result that can be tested.
The production flow from trigger to CRM
A reliable workflow separates conversation from control. The language model can decide how to phrase a question or repair a misunderstanding. Your application should decide whether a lead is eligible for a call, which evidence is required, how points are assigned, and which actions each score permits.
The end-to-end flow is:
- Accept a trigger. An inbound call, form submission, campaign event, or approved CRM record starts the workflow.
- Run the eligibility gate. Check campaign purpose, consent record, suppression lists, local operating window, lead ownership, and duplicate status before dialing or continuing.
- Load approved context. Give the agent only the fields needed for the call, such as name, product interest, account segment, language, and known answers.
- Conduct the conversation. Ask one question at a time, follow up on unclear answers, and explain the next step accurately.
- Capture evidence. Store normalized answers and the transcript evidence that supports them. Unknown remains a valid value.
- Apply rules. Calculate the score and disposition outside the conversational prompt.
- Take one action. Book, transfer, schedule a callback, nurture, disqualify, or suppress.
- Write back and observe. Update the CRM, emit lifecycle events, and record whether every downstream write succeeded.

With our managed voice AI backend, technical teams can run inbound and outbound calls, pass campaign context into a call, invoke business-system tools during the conversation, receive completion events, inspect calls, and extract structured post-call fields. The managed runtime handles the real-time conversation layer while your application keeps ownership of eligibility, scoring, and CRM policy.
Design qualification criteria as evidence
BANT, which stands for budget, authority, need, and timing, is a useful prompt for discovery. It is too vague to serve as a production specification. Each criterion needs an observable field, allowed values, a source, and a rule for missing data.
Start with the sales decision you want to make. Then work backward to the minimum evidence needed for that decision.
| Decision input | Strong field definition | Weak field definition |
|---|---|---|
| Need | Named problem, affected workflow, and current workaround | Interested |
| Fit | Segment, supported geography, use case, and required capability | Good company |
| Timing | Explicit date range or trigger event | Soon |
| Buying path | Decision role and identified next participant | Has authority |
| Budget | Approved range, funding status, or explicit deferral | Can afford it |
| Permission | Allowed next channel and contact time | Follow up later |
Before the call, classify every field as one of four types:
- Known and trusted: Load it from the system of record and avoid asking again.
- Known but confirmable: Ask for confirmation when the field may be stale.
- Unknown and required: Ask during the conversation.
- Unknown and optional: Capture it if it arises naturally.
This keeps the call short and reduces conflicting CRM data. It also prevents the agent from inventing a complete profile when the prospect never supplied an answer.
For each required field, define a repair path. If a date is vague, ask for a range. If the speaker is not the decision-maker, identify the buying process. If an answer conflicts with CRM context, preserve both values and send the conflict to review.
Use extraction for evidence and rules for scoring
An auditable score has two layers. The extraction layer turns conversation into typed fields. The decision layer maps those fields to points, exclusions, and actions. Keeping them separate lets you change a threshold without rewriting the conversation, and it lets a reviewer see why a lead received a disposition.
A simple model might allocate points across fit, demonstrated need, timing, buying path, and permission to continue. Hard exclusions run before the score. Examples include an unsupported geography, a duplicate active opportunity, a prohibited campaign, or a do-not-contact request.
The score should never hide uncertainty. Every field needs one of these evidence states:
- confirmed: the prospect stated or explicitly confirmed it
- inferred: the system derived it from indirect language
- crm: it came from an approved system of record
- unknown: the call did not establish it
- conflicting: sources disagree
Only confirmed and approved crm values should trigger high-impact actions by default. An inferred value can prompt another question or human review.

Our post-call analysis supports labeled string, number, Boolean, and enum fields. Results can arrive by webhook or API. During a live call, tools and functions can look up records, check availability, or book an appointment through your own authenticated endpoint.
Keep write-capable tools narrow. book_appointment is safer than a generic CRM mutation tool. Constrain fields with JSON Schema, use enums where the value set is known, validate tool arguments server-side, and make writes idempotent so a retry cannot create a second meeting.
Make the conversation collect clean data
Qualification calls fail when they feel like a spoken form. A good flow still has structure, but it adapts the order and wording to what the prospect has already said.
Use these conversation rules:
- State identity and purpose early. The person should understand who is calling, that the interaction uses AI when disclosure is required by your policy, and what the call is intended to accomplish.
- Confirm availability. Give the person a quick way to continue, schedule another time, reach a person, or end the call.
- Ask one question per turn. Compound questions create partial answers that are hard to score.
- Acknowledge before probing. Use the answer to choose the next question instead of reading a fixed sequence.
- Confirm high-impact fields. Repeat dates, contact details, appointment times, and disqualifying facts.
- Use unknown without pressure. A missing budget or timeline should follow the defined rule rather than invite guessing.
- End with a concrete state. Recap the next action, owner, time, and permitted follow-up channel.
Personalization should come from approved context and the live conversation. It should not rely on invented familiarity, unverified personal details, or a claim that the agent is a person.
Escalate with context, not just a phone transfer
Human escalation is part of the qualification design. Define triggers before launch:
- the prospect asks for a person
- repeated speech-recognition or intent-repair failures occur
- a sensitive, regulated, or high-risk topic appears
- the prospect disputes consent, recording, identity, or account ownership
- the request needs pricing, legal, security, or policy authority the agent lacks
- a high-intent lead meets an immediate-transfer rule
- a tool or CRM write fails after the safe retry path
Choose the handoff mode by urgency. A warm transfer fits a complex or high-value conversation because the receiving representative gets a briefing first. A scheduled callback fits closed hours or unavailable teams. A review task fits ambiguity that does not require the prospect to wait.
The handoff packet should contain the call ID, lead and account IDs, disposition, score version, confirmed answers, open questions, reason for escalation, promised next step, consent state, and a short evidence-grounded summary. We support warm call transfers that can brief the operator before connecting the caller.
Treat consent and operating windows as runtime controls
Consent cannot live only in a prompt. It belongs in the eligibility service, the call context, the transcript, the CRM writeback, and suppression systems.
For US campaigns, FCC 24-17 confirms that current AI-generated voices count as artificial or prerecorded voices under the TCPA. Covered calls require the called party's prior express consent, absent an emergency purpose or exemption. When a call introduces an advertisement or constitutes telemarketing, the FCC's rules require prior express written consent. The FTC telemarketing guidance covers calling-time restrictions, Do Not Call rights, caller ID, abandoned calls, opt-out mechanisms, and recordkeeping. The applicable rule depends on the call purpose, destination, recipient, and jurisdiction.
Store consent as structured provenance, not a single Boolean. Useful fields include:
- captured timestamp and source
- campaign or form version
- permitted purpose and channel
- phone number and jurisdiction used for the decision
- disclosure version
- recording and transcription setting
- revocation timestamp and source
- suppression propagation status
An opt-out should stop the conversation cleanly and update every connected outreach system. Monitor the time between the request and completed suppression.
We can execute calls around the clock only when configured workflows and operating constraints allow it. Inbound coverage, outbound local-time windows, carrier policies, transfer-team availability, consent, capacity, and internal schedules all shape actual availability.
Define the CRM handoff as a data contract
The CRM should receive a usable decision record, not only a transcript or summary. A compact payload can look like this:
{ "lead_id": "lead_8421", "call_id": "call_a17f", "qualification_version": "inbound_demo_v3", "disposition": "sales_ready", "score": 78, "evidence": { "need": {"value": "replace manual call intake", "state": "confirmed"}, "timeline": {"value": "this quarter", "state": "confirmed"}, "buying_path": {"value": "technical evaluation first", "state": "confirmed"}, "budget": {"value": null, "state": "unknown"} }, "next_action": { "type": "book_meeting", "owner_queue": "solutions_engineering", "scheduled_at": "2026-08-27T15:00:00Z" }, "consent": { "source": "demo_request_form_v6", "captured_at": "2026-08-24T14:03:11Z", "voice_follow_up_allowed": true }, "open_questions": ["budget"], "write_idempotency_key": "call_a17f:qualification:v3" }
Use the CRM's stable lead or contact ID as the join key. Store the qualification policy version so a future rule change does not rewrite history. Add a unique idempotency key to each mutation. Record failed writes in a retry queue and surface them as operating incidents, since a qualified call that never reaches the CRM is a failed workflow.
Measure the system, not just call volume
Start with a baseline from the same lead source, segment, and operating window. Define each denominator before comparing variants.
| Metric | What it reveals |
|---|---|
| Eligible-to-connected rate | Reachability after policy and suppression checks |
| Connected-to-completed rate | Conversation flow and early abandonment |
| Required-field completion | Whether the agent captures usable evidence |
| Scoring agreement | Agreement between the automated disposition and blinded human review |
| False-positive rate | Routed leads rejected by sales under the same policy |
| Sales-accepted lead rate | Whether qualification produces useful work for sellers |
| Booking and show rates | Whether the next action survives beyond the call |
| Median and tail time to contact | Speed across typical and delayed cases |
| Transfer completion | Whether escalations reach the intended team |
| CRM write success | Reliability of the final handoff |
| Suppression latency | How quickly an opt-out reaches every connected system |
| Cost per sales-accepted lead | Total platform, telephony, model, and review cost per accepted result |
Review a labeled sample of calls by segment and disposition. Include false positives, false negatives, opt-outs, failed tool calls, transfers, accents, background noise, interruptions, and ambiguous answers. Our testing workflow covers happy paths, edge cases, tool failures, schedule behavior, concurrency, and end-to-end voice tests. Call history and inspector data support transcript, recording, tool-execution, and performance review.
The figures and scenarios below are representative examples informed by Dasha’s experience across deployments and common industry workflows. They are not customer testimonials or guaranteed outcomes; actual results vary by implementation, traffic, and baseline.
- Illustrative scenario assumption. Assume lead conversion increases by 30% relative to baseline. Define conversion as the same fixed CRM event in both periods, use the same attribution window and source system, and compare eligible leads from the same lead sources, segments, geographies, and operating windows.
- Illustrative scenario assumption. Assume response time decreases by 50% relative to baseline. Measure the same interval, such as form submission to the first live qualification attempt, from the same event timestamps, and compare like-for-like lead-source cohorts under the same operating-hours and retry policies.
- Illustrative scenario assumption. Assume customer satisfaction scores increase by 45% relative to baseline. Bound the metric to the mean score from the same post-call question, numeric scale, survey channel, and response window among the same connected-call cohort, and report response rate and sample size with the score.
- Illustrative scenario assumption. Assume average deal size increases by 25% relative to baseline. Calculate it as closed-won revenue divided by closed-won deals in the same currency, source it from the same CRM fields, and compare matured cohorts with the same segments, lead sources, offer mix, and close window.
- Illustrative scenario assumption. Assume lead qualification accuracy improves by 40% relative to baseline. Define accuracy as correctly classified qualified and unqualified calls divided by all calls under a fixed, blinded human-adjudication policy, use the same class balance, and compare calls from the same lead sources, segments, languages, and traffic window.
- Illustrative scenario assumption. Assume sales-cycle length decreases by 20% relative to baseline. Measure median elapsed time between the same CRM start and closed-won events, and compare fully matured cohorts with the same lead sources, segments, offer mix, and observation window.
Roll out in controlled stages
- Choose one queue. Start with one lead source, language, offer, and CRM owner.
- Freeze the policy. Version the eligibility rules, evidence schema, scoring weights, thresholds, and terminal dispositions.
- Build the data contract. Implement reads, writebacks, idempotency, suppression, and failure handling before adding conversation polish.
- Test adversarially. Cover interruptions, vague answers, repeated questions, tool timeouts, closed calendars, duplicate records, transfer failure, and opt-outs.
- Shadow the decision. Let the system score calls while people retain final routing control. Measure agreement and investigate every high-impact mismatch.
- Release one action at a time. Enable CRM notes first, then tasks, then booking or transfer once each tool meets its reliability threshold.
- Monitor by version. Compare qualification policy, prompt, model, voice, and integration versions so a regression can be isolated and rolled back.
The best first deployment is deliberately narrow. Once the eligibility gate, evidence model, score, handoff, and measurement loop hold up under real traffic, you can expand to more segments and actions without losing control.
Build the first qualification workflow on Dasha, then test the full path from consent gate to CRM writeback before you increase traffic.
