Article

What Publishers Should Prepare Before Sending Calls to a New Buyer

A publisher-focused pre-launch guide to source approval, tracking, RTB, routing, qualification, testing, reporting, disputes, and payout preparation before calls go live with a new buyer.

Jul 20, 2026 David Leathers

A buyer has shown interest in your calls. The traffic has been discussed, the opportunity appears real, and both sides want to move.

That is not the moment to open the floodgates.

A new buyer relationship should begin with a controlled, documented launch. The publisher should know exactly which traffic is approved, how calls will reach the buyer, what makes a call payable, which identifiers must survive the handoff, how failures will be handled, and when both sides will compare reports.

This is different from building a traffic package for buyer review.

A traffic package explains what the traffic is: acquisition channel, consumer journey, call type, source structure, creatives, landing pages, disclosures, geography, expected volume, and operating controls. That information helps a buyer decide whether the source deserves consideration. Our guide to preparing traffic for buyer review covers that earlier stage.

Launch preparation begins after interest exists. It turns an approved opportunity into an executable campaign.

The central question is no longer, “Can we describe this traffic credibly?”

It is, “Can we send the first calls without losing source identity, routing control, qualification clarity, reporting continuity, or financial accountability?”

Build one launch record

Every new buyer launch should have one written record that the publisher, buyer, exchange, account managers, technical teams, QA, and finance can reference.

It does not need to be a long contract or complicated project-management system. It does need to be the operational source of truth.

The record should identify:

Campaign, buyer, target, publisher, and approved sources.
Call type and approved consumer journey.
Creative, landing-page, disclosure, and script versions.
Geography, schedule, time zone, caps, and concurrency.
Tracking or routing method.
Caller-ID and reservation requirements.
Qualification, duplicate, existing-customer, and conversion rules.
Recording, reporting, rejection, and dispute expectations.
Buyer invoice and publisher payout terms.
Owners, test plan, initial volume, stop conditions, and review dates.

The record should show who approved a material change and when. A screenshot in a private chat is not a durable campaign specification. Neither is an account manager’s memory.

The purpose is not bureaucracy. It is preventing five teams from launching five slightly different versions of the same campaign.

Freeze the approved traffic scope

A buyer’s interest in one source is not blanket approval for everything a publisher can generate.

Before launch, list every source and sub-source allowed to send calls. The label used in the commercial conversation should match the label in the tracking platform, RTB request, reporting export, dispute record, and payout report.

Depending on the operation, that may include a publisher account, source ID, sub-source ID, campaign ID, ad account, domain, creative group, landing-page version, transfer team, or upstream partner.

Do not use one generic label for unrelated websites, ad accounts, call centers, or partner traffic merely because they share a publisher agreement.

Keep unapproved traffic out

One common failure is launching with a reviewed source and then adding different traffic under the same identifier.

A new path may change consumer expectation, advertising claims, disclosures, call type, geography, duplicate behavior, caller-ID behavior, conversion patterns, or compliance risk.

If traffic changes materially, pause and obtain review before blending it into the approved source. Controlled source enablement works only when the source being routed is the source that was reviewed.

Lock the consumer-journey version

The buyer should know which version of the consumer journey is live on launch day.

Record the exact creative, copy, landing page, number presentation, form flow, disclosure, transfer script, and call to action. Save an approval date and a copy or screenshot that can be tied to the launch cohort.

Advertising claims should be truthful, supportable, and consistent with the consumer’s experience. The Federal Trade Commission’s advertising guidance explains that advertising must be truthful, non-deceptive, and evidence-based, with additional rules applying in some industries.

Define change control before media starts. Edits affecting claims, eligibility, pricing language, urgency, brand identity, disclosures, or the call to action should not go live without review.

This article is educational, not legal advice. Recording, advertising, consent, privacy, licensing, and vertical-specific obligations can vary by jurisdiction and call path. Publishers should have qualified counsel review the rules that apply to their operation.

Classify the call type correctly

A consumer-initiated inbound call is not the same product as a live transfer.

A scheduled callback is not automatically inbound because a consumer once submitted a form. A warm transfer does not become consumer-initiated inbound traffic merely because the caller reaches the buyer through a phone number.

Before launch, define:

Who initiated the first phone connection.
What the consumer saw or heard before the call.
Whether an agent was already speaking with the consumer.
Whether the buyer was introduced before transfer.
Whether the consumer requested a callback.
What information was passed before the buyer received the call.
Which party controlled the handoff.

Call type affects expectations, scripts, disclosures, routing, duration, QA, rejection reasons, and commercial terms. See consumer-initiated inbound calls versus transfers.

Do not test one call type and scale another. If the buyer approved consumer-initiated inbounds, do not fill unused cap with transfers without a separate approval and route.

Turn buyer requirements into exact routing rules

A buyer may say, “We want Florida calls from 9 to 5.” That is not yet a routing configuration.

Geography

Define the controlling location field: caller area code, reported state, ZIP code, service address, licensing state, IP-derived location, or another verified value.

Those values can disagree. A caller may keep a New York phone number while living in Florida. A home-services caller may be in one county while requesting work at another address.

Document accepted and excluded states, ZIP codes, counties, languages, and service areas. Test an accepted geography, a rejected geography, and a boundary case.

Schedule and time zone

Write the schedule in an explicit time zone. Include days, hours, holidays, temporary closures, after-hours treatment, daylight-saving handling, and who owns emergency changes.

A target marked open while the intended agents are offline can make valid publisher traffic appear unqualified.

Caps and concurrency

Define daily or period caps, budget caps, source caps, interval pacing, and simultaneous-call limits. Also identify what consumes capacity: a ping, reservation, routed call, connected call, payable call, or budget event.

A buyer may have room for 100 calls in a day but only two simultaneous calls. Publishers need to understand both limits before increasing spend.

Destinations, overflow, and failure behavior

Confirm the primary destination, receiving team, overflow order, ring timeout, queue and voicemail behavior, closed-hours treatment, and response for busy, failed, no-answer, or unreachable routes.

The publisher does not need unrestricted access to every confidential buyer endpoint. The routing operator does need to verify that the active destination is current, reachable, and attached to the correct team.

A stale destination number is a preventable launch failure. So is routing a sales campaign to the buyer’s general customer-service queue.

Define qualification before the first call

“Qualified call” is not precise enough for launch.

Write the conditions separating routed, connected, qualified, billable, payable, converted, invoiced, and paid calls. These states can overlap, but they are not interchangeable.

Duration-based campaigns

Define:

Minimum duration.
The event that starts and stops the clock.
Whether IVR, ring, queue, hold, transfer, and voicemail time count.
Whether raw, connected, or billable duration controls.
Dropped-call and reconnect treatment.
Rounding.
Authoritative system.
Buyer and publisher thresholds.

A call can connect and still not be payable. It can cross a publisher payout threshold while failing a different buyer rule. It can also reach a duration threshold because it sat in a queue. The measurement rule must be explicit.

See why call-duration rules matter.

CPA campaigns

Define the exact conversion event, such as a qualified appointment, completed application, retained case, funded transaction, or another agreed outcome.

Document the attribution window, required evidence, reporting method, reporting deadline, pending status, rejection handling, cancellations, reversals, late conversions, and the point at which the conversion is final enough to invoice and pay.

A CPA campaign cannot reconcile if the buyer says “sale” and the publisher says “conversion” while each means a different event.

Set duplicate and existing-customer rules

Duplicate handling should be agreed before traffic starts.

Define:

Matching key.
Lookback period.
Buyer, campaign, target, source, or publisher scope.
Whether a prior ring, connection, qualification, or conversion creates the duplicate.
Anonymous caller treatment.
Dropped-call reconnect treatment.
Existing-customer definition and evidence.
Rejection reason and publisher-visible details.

Platforms can implement duplicates differently. Ringba documents buyer- and target-level duplicate routing based on prior connected or converted calls and configurable time limits. Retreaver documents routing based on whether a caller previously connected or converted with a buyer. Publishers should test the actual configuration rather than assume “30-day duplicate” means the same thing everywhere.

The rule should also distinguish a duplicate from a reconnect. A caller disconnected during the first ten seconds may be continuing the same attempt, not creating unwanted repeated traffic.

Prepare the technical integration

A launch can fail even when the traffic and buyer are a good fit.

Technical preparation should cover tracking numbers, dynamic number insertion, caller ID, ping contracts, response handling, bid expiration, reservations, live-call routing, event callbacks, identifiers, and failure codes.

Tracking numbers and dynamic number insertion

Confirm which number the consumer sees and how it maps to the source.

For dynamic number insertion, verify that the number pool fits expected simultaneous sessions, replacement works on approved pages and devices, the fallback number is reachable, attribution persists across pages, and number reuse does not corrupt source data.

Retreaver’s DNI documentation describes replacing a landing-page number from a pool and attaching source tags. Ringba’s landing-page tagging documentation explains passing URL, publisher, and sub-ID values into call reporting.

The implementation varies by platform. The operational standard does not: the call must retain the source data required to explain where it came from.

Caller-ID transmission

Test normal, anonymous, transfer-agent, country-code, and SIP caller-ID behavior as applicable.

Twilio’s <Dial> documentation notes that the default outbound caller ID in a typical inbound-to-outbound bridge is the original caller’s number, subject to configuration and permitted values. Other call paths can behave differently.

Caller-ID integrity matters for reservation matching, duplicate checks, buyer screening, and investigations. Never assume the buyer sees the same value the publisher sees without testing it.

Ping fields and response handling

For pre-call RTB, document the request and response contract.

Common request fields include publisher, campaign, source, sub-source, caller number, geography, call type, timestamp, unique ping ID, and eligibility tags.

The response should make clear:

Accepted, rejected, timeout, or no-bid status.
Bid or publisher payout.
Required duration.
Routing number or SIP destination.
Bid or reservation ID.
Expiration.
Error or rejection reason.
Retry or fallback behavior.

Retreaver’s RTB API guide documents required fields, response UUIDs, payout and duration values, expiration, caller-ID matching, caps, concurrency, and rejection reasons. Ringba’s RTB FAQ describes responses with bid amount, expiration, routing number, and duplicate behavior, along with eligibility checks for caps, hours, and filters.

Do not collapse a timeout, no-bid, invalid request, and rejected call into one generic failure. Store and act on each outcome.

Bid expiration and reservations

A bid is not permanent permission to send a call.

Document the validity period, authoritative clock, match identifier, caller-ID requirement, single-use behavior, late-call treatment, retry behavior, and response for expired or mismatched calls.

Measure the time between bid receipt and call arrival. Transfer or media workflows that regularly exceed the reservation window will fail even when the buyer wanted the traffic at ping time.

See why reservation windows matter.

Live-call routing

For live-call RTB, test the caller experience while the route is selected: maximum timeout, dead air, ringback or hold audio, no-buyer fallback, transfer-agent experience, and disconnect behavior.

A technically successful API response is not enough if the caller hears silence and hangs up.

Preserve identifiers through settlement

Every call should have a stable identity across systems.

Preserve the available publisher call ID, platform call ID, ping ID, bid ID, reservation ID, campaign ID, source and sub-source IDs, telephony provider ID, buyer CRM ID, conversion ID, dispute ID, invoice reference, and payout reference.

Not every party needs every internal identifier or buyer destination. Each party does need enough shared keys to reconcile its records.

Twilio’s Call resource uses a unique Call SID and distinguishes statuses such as queued, ringing, in progress, completed, busy, failed, no answer, and canceled. A completed telephony call proves an audio connection occurred; it does not prove qualification, conversion, or payment.

Callbacks can arrive late or out of order. Store events idempotently, retain timestamps and sequence fields when available, and avoid letting an older event overwrite a final state.

Agree on recording and QA

Before launch, clarify whether calls are recorded, which leg and channels are captured, who controls recording, what consent process applies, who may access recordings, retention, redaction, QA sampling, and how missing recordings affect disputes.

Federal law contains a party-consent exception for certain interceptions, but state laws and call facts can impose different requirements. Do not treat a general federal rule as a complete multistate recording policy. Obtain legal guidance for the jurisdictions, call types, and uses involved.

Test that recording starts when expected, contains both sides, finishes processing, and links to the correct call.

Recordings are useful evidence, but not the only evidence. Route logs, timestamps, caller-ID records, source IDs, ping payloads, buyer dispositions, and conversion records can be equally important.

Define reporting and rejection handling

The first reporting conversation should happen before the first call.

Agree on call-level fields for IDs, timestamps, source, call type, geography, ping and routing outcome, target label, answer and connection events, duration, qualification, conversion, duplicate status, rejection reason, dispute, buyer price where appropriate, publisher payout, and settlement period.

Rejection reasons should be specific enough to act on. Useful categories include:

No buyer available.
Outside schedule.
Cap or concurrency reached.
Unsupported geography.
Invalid or missing field.
Expired reservation.
Caller-ID mismatch.
Duplicate or existing customer.
Wrong product, intent, or call type.
Duration not reached.
CPA result missing or rejected.
Buyer no answer.
Technical failure.
Manual dispute pending.

“Bad call” is not operational feedback.

The publisher’s integration should store rejection responses. Ignoring a no-bid, expiration, or caller-ID mismatch and sending the call anyway turns a clear technical rejection into a predictable dispute.

Prepare dispute evidence

Know what evidence will exist before a dispute occurs.

A useful evidence bundle can include the original ping, bid response, routing record, caller-ID values, source IDs, creative version, timestamps, status events, recording where lawful, QA notes, buyer disposition, duplicate-match detail, conversion record, and campaign-rule version.

Set the dispute window, acceptable reasons, evidence requirements, response deadline, financial treatment while pending, and escalation owner.

Dispute reduction does not mean eliminating legitimate disputes. It means reducing disputes caused by vague rules, missing records, inconsistent handling, and delayed feedback.

Align invoicing and publisher payout terms

Publishers should understand how buyer billing relates to publisher settlement without assuming the cycles or amounts are the same.

Document:

Buyer billing and publisher payout cadence.
Currency.
Buyer price basis.
Publisher payout basis.
Duration or CPA rule.
Cutoff time and time zone.
Reporting and conversion lag.
Dispute window and adjustments.
Payment terms and method.
Authoritative report.
Financial contacts.

Buyer price is what the buyer is charged. Publisher payout is what the publisher earns. The amounts and thresholds may differ.

Do not scale until the publisher can reproduce the first payout calculation from call-level records. A launch is not complete when calls connect. It is complete when the first settlement period can be explained.

Run test calls before live media

A test call should prove a rule, not merely make a phone ring.

Use identified test traffic and keep it out of production settlement. When possible, use a sandbox, test endpoint, paused target, or controlled destination. Retreaver’s campaign-testing guidance recommends testing routing and source tracking while preventing test calls from reaching unintended live endpoints.

Test at least:

Route and caller experience

Intended buyer team and destination.
Busy, no-answer, unreachable, overflow, and closed-hours behavior.
Two-way audio, DTMF, ring time, dead air, hold, and disconnect.
No protected buyer destination exposed to the publisher.

Twilio’s Voice Insights documentation describes call metadata and quality indicators that can support audio and connectivity diagnosis.

Caller ID and controls

Normal, anonymous, transferred, and formatted caller ID.
Accepted, rejected, and boundary geography.
Open and closed schedules.
Cap boundary.
Concurrent calls and capacity release.
Correct reservation match and deliberate mismatch.

Tracking and events

Tracking number and DNI attribution.
Source and sub-source in reports.
Ping, call, bid, and reservation IDs joined.
Answer, completion, recording, disposition, and conversion events.
Delayed or out-of-order callbacks.

Qualification and finance

Below-threshold and at-threshold duration calls.
Queue and hold treatment.
Accepted and rejected CPA events.
Duplicate, reconnect, and existing-customer behavior.
Test calls excluded from invoices and payouts.

Failures

Missing or invalid ping field.
Timeout or no bid.
Expired or reused reservation.
Caller-ID mismatch.
Buyer no answer.
Destination or callback failure.
Missing recording.

A failed test is useful when it exposes the problem before paid traffic begins.

Start with controlled volume

The first live calls should be a sample, not a flood.

Set an initial cap that is large enough to expose normal behavior but small enough to investigate every call. Name the launch window, approved sources, maximum concurrency, pause authority, and stop conditions.

Pause when source IDs disappear, calls reach the wrong team, caller ID fails, audio is poor, rejections are ignored, duplicate behavior differs from the rule, events cannot be joined, or reports do not reconcile.

Scaling should require a decision. When practical, increase one dimension at a time: more volume from the same source, one new sub-source, expanded hours, added geography, or higher concurrency. Changing everything at once makes the result hard to diagnose.

Brief every team

A launch is fragile when one account manager is the only person who understands it.

Media buyers need approved sources, versions, caps, prohibited changes, stop signals, and the checkpoint before scaling.

Transfer agents and supervisors need the accepted call type, intent requirements, script, disclosures, buyer hours, qualification boundaries, caller-ID expectations, and escalation path.

Developers need endpoints, authentication, schemas, timeouts, retries, expiration, identifier mapping, callbacks, logs, alerts, rollback, and pause procedures. Credentials and buyer destinations should stay out of broad launch documents.

Account managers need the complete launch record, contacts, stop conditions, reporting schedule, and authority boundaries. They should coordinate the agreed process, not reinterpret qualification during a dispute.

Finance needs buyer price, publisher payout, cycles, cutoffs, source of truth, conversion lag, dispute treatment, required fields, and the first reconciliation date.

The campaign should survive a sick day, vacation, shift change, or personnel change.

Monitor the first calls, first day, and first settlement

First calls

Review every early call when volume allows.

Confirm the correct source, buyer team, caller ID, audio, call type, identifiers, recording, event tracking, and platform outcome. Do not wait until the end of the day to discover that the source field is blank on every record.

First day

Compare calls attempted, pinged, accepted, routed, answered, connected, qualified, payable, and converted. Break down rejections, duration, duplicates, geographies, schedules, source performance, buyer dispositions, and technical problems.

The decision is whether to continue unchanged, narrow the scope, pause for repair, or move to the next controlled level.

First settlement period

Reconcile the publisher log, tracking platform, buyer report, qualification results, disputes, buyer invoice-ready total, and publisher payout-ready total.

Investigate differences at the call level. Common causes include time zones, late CPA conversions, duration definitions, missing source IDs, duplicate rules, excluded tests, delayed callbacks, and inconsistent identifiers.

Do not accept “the totals are close” as the standard for a new integration. A small unexplained variance becomes a large unexplained variance at scale.

See why pay-per-call needs better financial reconciliation.

Common launch failures

Sending unapproved sources

A reviewed source goes live, then different media or partner traffic is added under the same label.

Prevent it: source-level approval, stable IDs, and change control.

Routing before the buyer is open

The schedule uses the wrong time zone or does not match the actual team.

Prevent it: explicit time zone, inside/outside-window tests, and a schedule owner.

Using a stale destination

An old number remains after a buyer changes teams or systems.

Prevent it: validate destinations immediately before launch and after changes.

Misunderstanding duplicates

The publisher expects a target-level 30-day rule while the buyer applies an organization-wide existing-customer rule.

Prevent it: write the match key, event, scope, lookback, and evidence.

Losing source identifiers

The source appears in the landing-page URL but disappears during DNI, ping, SIP, CRM, or export processing.

Prevent it: end-to-end ID tests and rejection of records missing required source data.

Sending transfers as inbound calls

Agent-assisted traffic enters a route approved for consumer-initiated calls.

Prevent it: separate integrations, labels, scripts, and approvals.

Ignoring rejection responses

The platform returns no bid, expiration, or mismatch, but the publisher sends the call anyway.

Prevent it: explicit response handling, logs, alerts, and a safe fallback.

Scaling before reports reconcile

The first calls look promising, so spend increases before outcomes and payouts can be matched.

Prevent it: first-day review, first-settlement review, and written scale criteria.

Publisher pre-launch checklist

Traffic and buyer rules

Technical

QA, reporting, disputes, and finance

People and launch control

Media, transfer, technical, account, QA, and finance teams are briefed.
Launch owner and pause authority are named.
Initial cap and concurrency are intentionally limited.
Stop conditions are written.
Early calls will be reviewed individually.
First-day and first-settlement reviews are scheduled.
Scaling requires an explicit decision.
No one person is the only holder of campaign knowledge.

Hypothetical example: a clean inbound launch

A publisher operates an owned-and-operated home-services site and has buyer interest for consumer-initiated plumbing calls.

The launch uses one domain, two paid-search campaigns, one landing-page version, and separate source IDs for branded and non-branded search. The buyer accepts three counties from 8:00 a.m. to 6:00 p.m. Eastern, Monday through Saturday, with two concurrent calls and an initial cap of 15.

Testing covers DNI, source tags, county filters, schedules, caller ID, simultaneous calls, no-answer overflow, recording, and status callbacks. One test finds that mobile visitors using the fallback number lose the paid-search sub-source.

The team fixes attribution before launch and starts with five calls.

The first-day review finds one excluded-county call. The record shows that the route used billing ZIP while the buyer required service address. The teams correct the controlling field before raising the cap.

The traffic did not become better because the launch was controlled. The operation became capable of seeing and fixing the problem before it spread.

Hypothetical example: a transfer launch that should pause

A transfer publisher receives buyer approval for a duration-based campaign. Testing uncovers three disagreements:

The transfer platform presents the agent’s number instead of the consumer’s caller ID.
The buyer defines existing customer across its organization, while the publisher expected a campaign-level 30-day rule.
The platform starts duration at bridge answer, while the buyer believes it begins when an agent joins.

Those are not minor settings.

Caller-ID substitution can break matching and duplicate checks. The customer rule can materially change payable volume. The duration disagreement can produce two internally consistent but incompatible settlement reports.

The correct decision is to pause, resolve the definitions, repeat tests, and record the agreement. Sending traffic first would not create clarity. It would create a larger dispute file.

A controlled launch protects good publishers

Good publishers sometimes treat launch controls as buyer protection.

They are publisher protection too.

A controlled launch creates evidence that the approved traffic was sent, the call type was represented accurately, the buyer was open, the route worked, source IDs survived, and the payout followed the agreed rule.

It also exposes buyer-side problems early: poor answer behavior, stale destinations, inconsistent agent dispositions, delayed conversion reporting, and financial records that do not reconcile.

Dependable Calls is being built around reviewed source enablement, controlled routing, call-level records, and finance visibility. The current implementation includes substantial routing, reservation, reporting, dispute, and finance capabilities, but the platform and operating model remain subject to live validation and continued hardening.

That is why a new relationship should begin with a documented test, not an uncontrolled flood of traffic.

Have buyer-ready traffic and want a more controlled path from approval through launch and settlement? Start a publisher conversation with Dependable Calls.