Pay per call connects marketing spend to inbound conversations, but the voice workflow still has to qualify, route, and document each call. An AI voice agent can handle that narrow operating layer when business rules, disclosures, handoffs, and payout decisions stay under the operator's control. Here is how to design the flow, choose where AI belongs, and measure accepted calls without mistaking automation signals for payable outcomes.
What pay per call AI does
Pay per call AI uses a voice agent to answer a tracked inbound call, collect a limited set of qualification facts, consult operator-owned rules or systems, and transfer the caller to an appropriate buyer or team. It can also return a structured call result for review and reconciliation.
In performance marketing, a buyer or advertiser pays a publisher, affiliate, or network for an inbound call that satisfies their contract. The contract defines an accepted call. That definition might include the traffic source, service area, operating hours, caller eligibility, duplicate policy, required disclosures, connection state, and buyer acceptance.
A conversation length threshold may help flag short or disconnected calls. It cannot establish that a call was qualified, accepted, or payable on its own.
This use of “pay per call” is different from a premium-number service where the caller pays an added per-call or per-time charge. The federal definition of that separate category appears in 16 CFR § 308.2. It is also different from a marketplace that recruits publishers, supplies buyers, or settles payouts. A voice agent can operate inside a pay-per-call program without providing those commercial functions.
The end-to-end call flow
The reliable design keeps conversational work, business decisions, and financial adjudication separate.
- Receive a tracked inbound call. A tracking number or carrier passes the call into the voice workflow. The operator binds source, campaign, creative, consent, and buyer-program identifiers to the session when those fields are available.
- Give the required opening. The agent identifies the business or program and delivers the disclosure approved for that call type and jurisdiction.
- Qualify only what routing needs. The agent asks a short set of questions with defined answer formats and an escape path to a person. A useful inbound qualification flow avoids collecting fields that will not change eligibility or routing.
- Check eligibility and capacity. The agent calls the operator's service for territory, schedule, duplicate status, buyer availability, or another deterministic rule. The system of record makes the decision.
- Select a destination. An operator-owned router chooses a buyer or internal queue under the current agreements and capacity rules.
- Transfer the call. A warm transfer can brief the recipient before connecting the caller. A cold transfer sends the caller directly to the destination. The flow needs a defined result for rejection, no answer, and technical failure.
- Return outcome evidence. The runtime sends call status, timestamps, transcript, configured recording, tool events, transfer result, and post-call fields to the operator's data pipeline.
- Adjudicate the call separately. Contract logic and authorized reviewers determine acceptance, payout, reversal, and dispute status. An AI label can prioritize review. It cannot make a call payable by itself.
This separation makes failures easier to diagnose. It also prevents a routing model from quietly becoming the source of truth for money.
AI voice agent vs. IVR vs. human screening
Interactive voice response (IVR), voice AI, and human screeners solve different parts of the intake problem. Choose the least complex option that can apply the required policy reliably.
| Screening method | Strong fit | Main tradeoff |
|---|---|---|
| IVR | A stable menu with a few deterministic choices | Callers must fit their need into the menu, and each branch has to be maintained explicitly |
| AI voice agent | Short spoken qualification with bounded tools, rules, and transfer paths | Speech, model, tool, and routing errors require review, fallbacks, and regression tests |
| Human screener | Ambiguous, sensitive, high-stakes, or exception-heavy conversations | Staffing, consistency, coverage, training, and quality review remain operational concerns |
A hybrid is often the right design. An IVR can handle language or department selection. A voice agent can collect a narrow set of routing facts. A person can take over when the caller disputes a decision, gives conflicting information, requests a human, or reaches a regulated or sensitive topic.
Where the voice agent fits for each operator
Publishers and networks
A publisher or network can use the agent as the intake layer between a tracked number and its routing service. The useful work is consistent data capture, real-time eligibility checks, transfer execution, and a call record that can be reconciled with buyer feedback.
The agent should receive campaign context from the tracking system instead of asking the caller to repeat facts the operator already knows. Buyer selection and payout rules stay in the network's system.
Advertisers and buyers
A buyer can use a voice agent on its own inbound traffic or require selected qualification facts before accepting a transfer. The buyer still defines availability, serviceable territory, duplicate handling, acceptance criteria, and downstream conversion reporting.
Closed-loop feedback matters. If the buyer later rejects a call, the rejection reason should map to a contract rule and a call record. That gives the operator a reviewable error category rather than an unexplained “bad lead” label.
Call centers and vertical software companies
A call center can place an AI intake layer ahead of a specialist queue or use it for bounded overflow. A vertical software company can embed the same pattern for customers while keeping tenant-specific numbers, qualification rules, and destinations isolated.
Consider a hypothetical travel workflow. A caller has opted in to speak with an automated agent, provides itinerary preferences, and asks to continue. The operator-owned system checks whether an identified travel business accepts the call, then the agent transfers it. Inventory, rates, payment, booking policy, and final confirmation remain with the travel system and its staff. The agent does not invent an itinerary or represent that a booking is complete.
Implementation blueprint
1. Write the accepted-call contract first
Turn every acceptance rule into an explicit field, state, or reviewer decision. Define what happens when a value is missing, ambiguous, disputed, or unavailable. Keep publisher payout, buyer price, and network margin as separate ledger fields.
2. Review consent, disclosure, and data handling
Map traffic source, call direction, purpose, jurisdiction, number type, recording, transfer recipient, and any later callback. Approve the opening disclosure, opt-out handling, consent evidence, retention, access, and deletion policy before traffic enters the system.
3. Configure numbers and carrier ownership
Decide whether a number routes directly to the agent or an existing telephony platform holds the call and bridges it after registration. Keep ownership of numbers, carrier credentials, caller ID policy, and routing configuration clear. A bring-your-own-carrier design can preserve that operating boundary.
4. Pass session context
Attach stable identifiers such as call ID, source, campaign, consent record, program, tenant, and proposed buyer pool. Use opaque internal IDs rather than exposing unnecessary personal data to prompts or logs.
5. Keep policy in deterministic tools
The agent can ask questions and call tools. Eligibility, capacity, duplicate detection, routing priority, and buyer availability belong in operator-owned services with authentication, input validation, timeouts, and audit logs. Define a safe response for every tool failure.
6. Design transfer and fallback states
Specify warm or cold transfer behavior, maximum wait, rejection, no answer, destination error, caller hang-up, and operator-tool timeout. A fallback may continue the conversation, send the caller to a general queue, offer an approved callback path, or end the call with an accurate explanation.
7. Deliver and reconcile records
Send lifecycle and result webhooks to a durable store. Join the runtime record to the tracking platform, buyer response, conversion event, publisher invoice, and reversal record by stable IDs. Keep raw evidence and derived labels distinguishable.
8. Test production acceptance
Use consented test calls and controlled traffic to cover accents, silence, interruptions, corrections, noisy audio, tool latency, unavailable buyers, transfer failure, and contradictory answers. Review false accepts and false rejects before expanding traffic. Re-run the suite after changes to prompts, models, tools, buyer rules, or telephony.
Metrics that make results comparable
Name the denominator for every metric. A percentage without its eligible population cannot explain where the funnel changed.
| Metric | Definition |
|---|---|
| Answer rate | Answered sessions ÷ valid inbound attempts |
| Qualification completion rate | Calls with all required routing fields ÷ answered sessions that entered qualification |
| Qualified-call rate | Calls meeting the operator's rules ÷ calls that completed qualification |
| Transfer initiation rate | Transfer attempts ÷ qualified calls |
| Transfer connection rate | Connected transfers ÷ transfer attempts |
| Buyer acceptance rate | Buyer-accepted calls ÷ connected calls presented for acceptance |
| Appointment or sale rate | Confirmed downstream outcomes ÷ buyer-accepted calls |
| Quality-review agreement | AI-derived labels matching the reviewer decision ÷ manually reviewed calls |
| False-accept rate | Calls the system accepted but review rejected ÷ manually reviewed calls |
| False-reject rate | Calls the system rejected but review accepted ÷ manually reviewed calls |
| Operational error rate | Sessions with a defined technical error ÷ started AI sessions |
| Duplicate, reversal, or dispute rate | Calls in that state ÷ calls submitted for payment |
Calculate unit economics from reader-owned inputs:
- Cost per accepted call = media, publisher payout, carrier, voice runtime, human review, and transfer costs ÷ buyer-accepted calls.
- Customer acquisition cost = the agreed acquisition-cost pool ÷ new customers attributed under the operator's policy.
- Contribution margin = buyer revenue minus publisher payouts, call costs, review costs, and reversals. State whether the report expresses it as currency or as a percentage of buyer revenue.
Segment the same measures by source, campaign, buyer, qualification version, transfer path, and time period. That isolates whether a change came from traffic quality, conversation behavior, buyer capacity, telephony, or adjudication.
Compliance and operating boundaries
Inbound traffic is not automatically compliant. Requirements depend on the call's direction, purpose, content, jurisdiction, number type, consent history, recording, and transfer or callback behavior.
For US operations, the restrictions in 47 CFR § 64.1200 are a starting point for calls using an artificial or prerecorded voice and for telemarketing consent and opt-out rules. The Telemarketing Sales Rule's recordkeeping requirements require covered sellers and telemarketers to retain specified call, transfer, script, consent, and other records for five years. State laws, sector rules, carrier policies, contracts, and recording-consent laws can add obligations.
A practical control set includes:
- preserve the exact source and scope of consent;
- identify the seller or business the caller will reach;
- use counsel-approved AI and recording disclosures where applicable;
- honor opt-outs and suppression rules across connected systems;
- minimize collection of sensitive data and restrict who can access recordings and transcripts;
- keep the prompt, qualification policy, tool version, transfer result, and buyer response traceable;
- review AI labels against recorded evidence before using them for payment or adverse decisions; and
- assign a person to handle exceptions, complaints, disputes, and deletion requests.
Legal review has to cover the actual program. A platform feature, an inbound number, or a disclosure sentence cannot supply compliance by itself.
When pay per call AI is a good fit
The pattern fits when qualification is short and bounded, acceptance rules can be represented in systems, routing destinations expose current capacity, and the operator can review calls and resolve exceptions. It also requires enough technical ownership to maintain telephony, integrations, data controls, and regression tests.
Keep humans in front when the conversation relies on professional judgment, negotiation, empathy, or an open-ended exception policy. AI is also a poor fit when consent provenance is unclear, buyer rules change without version control, downstream outcomes are unavailable, or no reliable fallback exists.
How Dasha supports the voice layer
We provide a managed real-time voice runtime and operational surface for technical teams. Dasha can receive inbound calls through customer-owned Twilio or Session Initiation Protocol (SIP) credentials. A number can link directly to an agent, or your telephony can register a held call and bridge it to the returned SIP destination. Session data can carry your source, campaign, consent, tenant, or buyer-program context.
During the call, webhook tools can consult your eligibility, capacity, customer relationship management (CRM), or routing services. Transfers can be warm, cold, or selected through a routing webhook with a configured fallback. Result webhooks and call history provide status, transcripts, recordings when configured, tool logs, timing evidence, and configurable post-call labels.
The boundary is just as important. We do not supply a lead marketplace, buyer network, payout system, settlement service, attribution ledger, or compliance-management service. You own traffic sources, tracking numbers, carrier relationships, buyer agreements, qualification policy, consent and compliance, buyer availability, payment and reversal logic, record retention, and downstream conversion data.
If that responsibility split matches your program, evaluate the Dasha voice AI backend with one accepted-call contract, one routing service, and a controlled set of test calls before expanding traffic.
Frequently asked questions
Can an AI label decide whether a call is payable?
No. A label can flag likely qualification, transfer outcome, or review priority. Payability depends on the buyer agreement, deterministic records, buyer response, and any authorized review process.
Should call duration be part of an accepted-call definition?
It can be one contract field. Pair it with source, eligibility, duplicate status, connection state, required disclosure, and buyer acceptance. A long call can still be ineligible, misrouted, or disputed.
Can the agent transfer a caller to different buyers?
Yes, when the operator's routing service returns an approved destination and the runtime has a defined transfer and fallback path. The operator remains responsible for buyer priority, capacity, authorization, and contract rules.
Does an inbound call allow an automatic AI callback?
Do not infer callback permission from the inbound event alone. Treat any later outbound call as a separate workflow with its own purpose, consent evidence, disclosure, suppression, and jurisdictional review.
