A pay-per-call dashboard can display accurate numbers and still lead an operator to the wrong conclusion.

The problem is usually not arithmetic. It is definition.

A report may show a 48% connection rate, a 30% qualification rate, a $42 earnings-per-call figure, or a 12% conversion rate. None of those numbers can be interpreted responsibly until the reader knows:

What is in the numerator.
What is in the denominator.
Which call status qualifies a record for either side of the formula.
Which event timestamp determines the reporting period.
Which sources, targets, geographies, schedules, and call types are included.
Whether downstream feedback is complete.
Whether disputes and adjustments are still open.
Whether the value is live, provisional, or finalized.

That is the central rule of this guide:

A metric is not just a number. It is a calculation contract.

The contract should identify the numerator, denominator, time window, status definition, segmentation, data owner, and finalization state. Without those details, two people can use the same metric name and calculate different results.

This article provides an operating framework for buyers, publishers, finance teams, and internal staff. It is not a list of universal benchmarks. A good result depends on the vertical, call type, commercial model, source, target, schedule, buyer capacity, qualification rule, feedback process, and sample size.

Start with the call-status chain

Pay-per-call metrics are easier to read when each call is treated as a sequence of events rather than one row with one final label.

A simplified chain may look like this:

A call is generated or initiated.
A ping or offer is created.
The offer passes or fails eligibility rules.
One or more buyers return a bid, acceptance, rejection, timeout, or error.
A route is selected and reserved.
A destination is attempted.
The call connects, fails, goes unanswered, or is abandoned.
The call meets or misses a qualification rule.
The buyer reports a disposition or conversion outcome.
The call becomes billable, payable, disputed, adjusted, or held.
The record is included in a finalized invoice or payout period.
The financial obligation is settled.

Those stages are related, but they are not interchangeable. The foundational distinction between a routed, qualified, and billable call is explained in The Difference Between a Routed Call, a Qualified Call, and a Billable Call.

A serious metrics model should preserve the transitions. If a dashboard replaces the chain with a single “successful” status, operators lose the ability to diagnose where performance changed.

For example, a decline in billable calls could come from:

Fewer offers.
More eligibility rejections.
Lower buyer acceptance.
More route failures.
Lower connection performance.
A change in duration distribution.
More duplicates.
Slower or missing buyer feedback.
More valid disputes.
A reporting-period or time-zone mismatch.

The billable count alone cannot tell you which explanation is correct.

Use a metric definition card

Before relying on a metric, write its definition in a standard format.

A practical metric definition card includes:

Metric name: The label shown in the report.
Business question: What decision is this intended to support?
Numerator: The exact events counted on top.
Denominator: The exact eligible population counted below.
Event time: The timestamp used to assign a record to a period.
Status rule: The status and version of the rule used for inclusion.
Dimensions: Source, sub-source, buyer, target, campaign, geography, call type, and other permitted segments.
Data availability: Real-time, delayed, incomplete, provisional, or finalized.
Owner: The system or team responsible for the field.
Exclusions: Tests, internal calls, blocked traffic, duplicates, canceled reservations, missing feedback, or other defined exclusions.

This may feel formal for a simple ratio. It prevents expensive disagreements later.

Contact-center systems illustrate why the denominator matters. Amazon Connect defines agent answer rate as accepted contacts divided by routing attempts, while its abandonment rate uses abandoned contacts divided by queued contacts. The labels sound intuitive, but the populations are different. Operators should apply the same discipline to pay-per-call reporting rather than assuming that “answer rate” or “abandonment” has one universal denominator. See the official Amazon Connect metric definitions.

Supply and offer metrics

Supply and offer metrics describe what entered the system and what buying opportunities were created. They should be read before downstream call and financial metrics because they establish the top of the measurement funnel.

Calls generated or initiated

This is the count of consumer call attempts or publisher-side call initiations that meet the reporting definition.

The count can vary depending on where measurement begins:

A consumer taps a call button.
A tracking number receives an inbound attempt.
A publisher platform creates a call record.
An exchange receives a live call.
A transfer operation starts an outbound leg.

Those events are not necessarily one-to-one. A consumer may retry. A publisher may create multiple technical legs. A platform may suppress a test or blocked caller before an offer is created.

A useful definition is:

Calls initiated = distinct qualifying call-initiation records during the period

The word distinct requires an identifier rule. The reporting team should know whether uniqueness is based on call ID, inbound leg, consumer session, caller identifier plus a lookback window, or another documented key.

Pings or offers

A ping or offer is an opportunity submitted for evaluation. It is not automatically a call, route, or buyer acceptance.

Offers created = count of offer records created during the period

One initiated call may create one offer, multiple buyer endpoint requests, or no offer at all. A platform that fans one opportunity to several eligible buyer endpoints should separate:

The publisher-level offer.
Buyer endpoint requests.
Buyer responses.

Otherwise, one call opportunity can be counted several times in the same “offers” metric.

Eligible offers

An eligible offer is one that passes the applicable pre-routing rules for the measured buyer, target, or path.

Eligibility rate = eligible offers / evaluated offers

State the denominator explicitly. It might be all offers received, all offers evaluated for one buyer, or all buyer-target evaluations. Those produce different rates.

Eligibility can be affected by schedule, geography, source enablement, tags, duplicate policy, cap, budget, concurrency, target status, destination health, and other controls. Rejection reasons should therefore be counted separately rather than collapsed into one “not eligible” total.

Bid responses

A bid-response count should classify the response type:

Accepted bid.
Explicit rejection.
No bid.
Timeout.
Malformed response.
Transport or destination error.
Skipped before request because of capacity or another control.

A response rate might be defined as:

Buyer response rate = buyer endpoint requests with a valid response / buyer endpoint requests sent

That is different from:

Bid acceptance rate = accepted bids / valid buyer responses

It is also different from:

Offer coverage rate = offers receiving at least one accepted bid / eligible offers

All three can be useful. They answer different questions.

Rejections and rejection reasons

A rejection rate without reason codes is weak diagnostic information.

Rejection rate = rejected evaluations / total evaluated opportunities

Then segment rejected evaluations by a bounded reason taxonomy such as:

Source not enabled.
Geography not accepted.
Schedule closed.
Cap reached.
Concurrency unavailable.
Duplicate rule.
Buyer no-bid or capacity rejection.
Invalid or missing field.
Reservation expired.
Destination unhealthy.

Reason definitions should be stable enough to compare over time. Free-form text is useful for investigation but difficult to aggregate reliably.

Routed calls

A routed call is a call for which the system selected and attempted a destination path under the applicable routing rules.

Route rate = routed calls / eligible call opportunities

Some teams use all initiated calls as the denominator. That can also be valid, but it measures a different funnel:

Initiation-to-route rate = routed calls / initiated calls

The report should not label both as “routing rate.”

Telephony and routing metrics

Telephony metrics describe what happened after a route was selected. This is where status precision becomes especially important because a call can move through queued, initiated, ringing, in-progress, completed, busy, failed, no-answer, or canceled states.

Twilio’s official Call resource documentation is a useful example of a technical status model. It also notes that status callback requests can arrive out of order even when the underlying events were fired in order. That is a reminder that event time and ingestion time are not always the same.

Attempted routes

An attempted route counts a destination attempt, not necessarily a unique consumer call.

Attempted routes = count of destination dialing attempts

If failover is allowed, one call may produce multiple attempts. Report both:

Unique calls with at least one route attempt.
Total destination attempts.

The ratio between them helps identify repeated failover:

Attempts per routed call = total destination attempts / unique routed calls

A rising value may indicate destination failures, no-answer behavior, timeout settings, routing retries, or misconfigured failover. It does not automatically indicate poor publisher traffic.

Connected calls

A connected call should be tied to a documented event. Depending on the system, connection may mean:

The destination answered.
An IVR answered.
A buyer agent joined.
Two call legs were bridged.
A minimum connected duration was recorded.

Those are not equivalent. The metric definition should state which event controls.

Connection rate = connected calls / route-attempted calls

An alternative buyer-capacity view may be:

Buyer answer rate = calls accepted by the buyer destination / calls presented to that destination

Keep the denominator at the same entity level as the numerator. Do not divide source-level connected calls by target-level attempts without a documented allocation rule.

Abandonment

Abandonment can happen before or after routing, and the responsible system may differ.

Possible definitions include:

Consumer disconnected while waiting before a route was selected.
Consumer disconnected while the destination was ringing.
Consumer entered a buyer queue but disconnected before an agent answered.
Transfer agent disconnected before the buyer joined.

Each definition needs its own denominator. For example:

Pre-route abandonment rate = pre-route consumer abandons / calls entering the pre-route queue

Buyer-queue abandonment rate = consumer abandons in buyer queue / calls entering the buyer queue

Combining them can hide where the failure occurred.

Reservation expiration

A reservation expiration occurs when a buyer acceptance or selected route is not used within the applicable window.

Reservation expiration rate = expired reservations / created reservations

Segment it by buyer endpoint, source, call type, and routing mode. A high expiration rate may indicate timing mismatch, slow call arrival, an overly short reservation window, publisher implementation problems, or delayed route execution.

Routing latency

Routing latency requires two named timestamps.

Routing latency = route-decision timestamp - offer-received timestamp

A different metric might measure:

Time to buyer connection = buyer-connected timestamp - call-received timestamp

Do not call both “latency.”

Report latency as a distribution, not only an average. Useful summaries include median, 90th percentile, 95th percentile, 99th percentile, minimum, maximum, and timeout count.

The OpenTelemetry metrics data model describes histograms as a compressed representation of a population using count, sum, and optional buckets, minimums, and maximums. That structure is well suited to latency and duration because averages can conceal a slow tail.

Destination failures

Destination failures should be classified by the failure point:

DNS or network failure.
Connection timeout.
Busy response.
No answer.
Rejected call.
SIP or carrier error.
Invalid destination.
Buyer-side application error.
Parser or response-format failure.

Destination failure rate = failed destination attempts / total destination attempts

A failure rate should not include explicit commercial no-bids unless the report clearly defines them as failures. A buyer that says “not interested” is different from a destination that could not be reached.

Concurrency and cap utilization

Concurrency and cap metrics are point-in-time or period-utilization measures, not call-quality measures.

Concurrency utilization = active concurrent calls / configured concurrency limit

Daily cap utilization = eligible delivered calls counted toward cap / configured daily cap

A cap utilization of 100% may mean demand is available. It may also mean the cap is too low, the schedule is too short, or calls are concentrated in one daypart. The operational relationship among these controls is covered in How Caps, Schedules, and Concurrency Shape Call Flow.

Quality and qualification metrics

Quality metrics should describe defined outcomes, not vague impressions. “Good call rate” is not useful unless “good” has a documented rule.

Qualified calls and qualification rate

A qualified call meets the campaign’s agreed qualification conditions.

Qualification rate = qualified calls / connected calls eligible for qualification

Some organizations use routed calls or all initiated calls as the denominator. Those can be useful funnel measures, but they should be named accordingly:

Route-to-qualification rate = qualified calls / routed calls

Initiation-to-qualification rate = qualified calls / initiated calls

Qualification must use the rule version in effect for the call. If a duration threshold or eligibility condition changes mid-period, the report should preserve historical terms rather than recalculate old calls under the new rule.

Duration distribution

Average duration is rarely enough.

Two sources can have the same average while one has a tight cluster near the qualification threshold and the other has a mix of very short and very long calls.

Report duration bands such as:

No connection.
Connected below the first operational threshold.
Near the qualification threshold.
Qualified duration band.
Extended-duration band.

The boundaries should reflect the campaign’s real decision points, not arbitrary round numbers. The underlying clock definition also matters. Why Call Duration Rules Matter for Buyers and Publishers explains why dial time, ring time, IVR time, bridge time, agent-connected time, and total call-leg duration can produce different results.

Duplicate rate

A duplicate is only meaningful relative to a duplicate policy.

Duplicate rate = calls classified as duplicates / calls evaluated under the duplicate policy

The report should state:

The identity key used.
The lookback period.
Whether the policy is buyer-specific, campaign-specific, or global.
Whether prior qualified, connected, routed, or merely attempted calls count.
Whether the current call can still route or qualify under an exception.

A change in duplicate rate may reflect traffic behavior, but it may also reflect a policy change or improved identity matching.

Existing-customer and ineligible-caller outcomes

These outcomes are often buyer dispositions rather than platform-observed facts.

Existing-customer rate = calls marked existing customer / calls with a usable existing-customer disposition

Do not use all connected calls as the denominator when many calls have no disposition. Instead, show both the outcome rate and the feedback coverage rate.

The same applies to wrong geography, wrong product, no decision-maker, consumer not interested, and other buyer-supplied outcomes.

Dispute rate

Dispute rate has at least three useful versions:

Dispute submission rate = disputed calls / billable calls

Approved dispute rate = approved disputes / reviewed disputes

Net disputed value rate = finalized dispute credits / gross invoiced value before dispute credits

These metrics should not be merged. A buyer may submit many disputes but have few approved. A source may have a low dispute count but high disputed value if the affected calls carry a higher buyer price.

QA findings

QA results should separate review coverage from finding frequency.

QA review coverage = reviewed calls / calls eligible for QA

QA finding rate = reviewed calls with a defined finding / reviewed calls

A rising finding rate can mean quality deteriorated. It can also mean the review team changed sampling, added a new check, focused on a risky segment, or improved detection. Preserve the review reason and sampling method.

Conversion and buyer metrics

Buyer metrics describe what happened after the call reached the buyer’s operation. They are often the most commercially important and the least complete.

Buyer dispositions

A disposition taxonomy should be bounded, documented, and mapped across systems.

Common outcome families may include:

Connected but not worked.
Ineligible.
Existing customer.
Appointment set.
Application started.
Application completed.
Sale or policy issued.
Case accepted.
Follow-up pending.
Unable to determine.

The exact labels depend on the vertical. The important requirement is that the same business outcome is not spread across inconsistent free-text values.

Conversion rate

Conversion rate is one of the easiest metrics to misread.

A buyer may calculate:

Conversion rate = conversions / connected calls

A publisher may see:

Conversion rate = conversions / qualified calls

A finance team may use:

CPA conversion rate = finalized payable conversions / calls eligible for CPA evaluation

All three can be mathematically correct. They answer different questions.

Every conversion rate should state:

What counts as a conversion.
Which calls are eligible to convert.
The attribution window.
The feedback cutoff.
Whether reversals are included.
Whether the result is provisional or finalized.

Conversion-feedback coverage

Coverage tells you how much of the denominator has a usable outcome.

Conversion-feedback coverage = calls with a usable buyer outcome / calls expected to receive buyer feedback

Then calculate observed conversion rate only within the covered population:

Observed conversion rate = conversions / calls with a usable buyer outcome

Do not silently treat missing feedback as a non-conversion. That can understate performance and make a buyer with poor reporting look like a buyer with poor conversion.

Feedback delay

Feedback delay should be measured from the call event to the first usable buyer outcome and, separately, to the finalized outcome.

Initial feedback delay = first usable outcome timestamp - call connected timestamp

Final feedback delay = finalized outcome timestamp - call connected timestamp

Report the distribution and the percentage completed within defined age bands.

Delayed data is not unique to pay-per-call. Google Ads explains in its official data freshness documentation that conversion reporting timing varies and that reports can be updated later because of late conversions, invalid-traffic review, and billing adjustments. The operational lesson is broader: a live metric can change after the underlying event.

Source- and target-level outcomes

Blended conversion metrics can conceal strong and weak combinations.

Segment outcomes by at least the dimensions required for the decision:

Publisher.
Source and sub-source.
Campaign.
Buyer.
Target or destination group.
Call type.
Geography.
Daypart and day of week.
Creative or landing-page version when permitted and relevant.
Qualification-rule version.

Publishers need enough source-level detail to improve traffic without exposing every protected buyer or destination detail. That operating case is covered in Why Source-Level Reporting Matters for Publishers.

Financial metrics

Financial metrics should be derived from call-level financial events, not reconstructed from a blended average when the underlying records are available.

Billable calls and payable calls

A billable call creates or supports a buyer charge under the applicable commercial terms.

A payable call creates or supports a publisher payout obligation under the applicable commercial terms.

Billable rate = billable calls / calls eligible for buyer billing

Payable rate = payable calls / calls eligible for publisher payout

The two rates may differ. Do not assume every billable call is payable or every payable call is billable without verifying the agreement and adjustment logic.

Buyer price and publisher payout

Keep the two values separate on every report.

Buyer price is what Dependable Calls charges the buyer for the applicable billable or converted call.
Publisher payout is what Dependable Calls pays the publisher for the applicable payable call.

If rates vary by source, target, event, or time, use call-level amounts.

Gross buyer revenue = sum of finalized buyer charges before collections status

Publisher payout obligation = sum of finalized publisher payouts before payment status

Where appropriate and authorized:

Gross spread = gross buyer revenue - publisher payout obligation

Gross spread is not net profit. It does not include telephony, platform, payroll, refunds, bad debt, processing fees, overhead, taxes, or other costs.

Adjustments, credits, disputes, and settlement

A finance report should separate the original event from later changes.

Useful fields include:

Original buyer charge.
Original publisher payout.
Dispute amount.
Approved credit.
Denied dispute.
Publisher adjustment.
Reversal.
Final buyer charge.
Final publisher payout.
Invoice inclusion.
Payout-batch inclusion.
Buyer payment status.
Publisher payment status.

This is the difference between a live operating estimate and a settlement record. Why Pay-Per-Call Needs Better Financial Reconciliation explains how calls, disputes, invoices, payouts, and adjustments should tell the same story.

Earnings per call

“Earnings per call” is ambiguous until the denominator is named.

Publisher views may include:

Earnings per initiated call = finalized publisher payout / initiated calls

Earnings per routed call = finalized publisher payout / routed calls

Earnings per connected call = finalized publisher payout / connected calls

An operator might calculate gross spread per billable call:

Gross spread per billable call = finalized gross spread / billable calls

These numbers should not share the same label. The denominator changes the business interpretation.

Cost per qualified or converted call

A buyer’s acquisition view may include:

Cost per qualified call = finalized buyer charges / qualified calls

Cost per converted call = finalized buyer charges / finalized conversions

The numerator should state whether it includes only call charges or also media, staffing, telephony, platform, and other acquisition costs. “Cost per conversion” based only on buyer call charges is not the same as fully loaded customer-acquisition cost.

Provisional versus finalized values

A dashboard should label the maturity of financial values.

A practical state model is:

Estimated: Calculated from incomplete live events.
Provisional: The call has a preliminary financial classification but may still receive feedback, dispute review, or adjustment.
Finalized: The review window is closed and the value is approved for the settlement period.
Invoiced or batched: Included in a buyer invoice or publisher payout batch.
Paid or collected: Cash movement has been recorded.

Finalized does not necessarily mean paid. Invoiced does not necessarily mean collected. Payable does not necessarily mean paid.

Scoped finance visibility helps both sides understand those distinctions without exposing protected counterparty terms. See Why Finance Visibility Builds Trust Between Buyers and Publishers.

A worked hypothetical metric chain

Consider a clearly hypothetical reporting period with the following counts:

120 distinct calls initiated.
110 offers created.
90 offers evaluated for the measured path.
72 offers eligible.
60 eligible offers received at least one valid buyer response.
48 calls routed.
42 calls connected under the documented connection event.
30 calls met the qualification rule.
27 calls became billable.
25 calls became payable.
24 calls were expected to receive buyer conversion feedback.
18 calls had usable feedback by the reporting cutoff.
5 of those 18 had a qualifying conversion outcome.

The formulas are:

Offer creation rate = 110 / 120 = 91.7%
Eligibility rate = 72 / 90 = 80.0%
Offer coverage rate = 60 / 72 = 83.3%
Initiation-to-route rate = 48 / 120 = 40.0%
Connection rate = 42 / 48 = 87.5%
Qualification rate = 30 / 42 = 71.4%
Billable rate among qualified calls = 27 / 30 = 90.0%
Payable rate among qualified calls = 25 / 30 = 83.3%
Conversion-feedback coverage = 18 / 24 = 75.0%
Observed conversion rate = 5 / 18 = 27.8%

It would be misleading to report a finalized 20.8% conversion rate by dividing 5 conversions by all 24 expected-feedback calls and treating the six missing outcomes as losses. It would also be misleading to call 27.8% the final rate while 25% of expected feedback is missing.

The correct interpretation is:

Five conversions are currently observed.
Feedback coverage is 75%.
The observed conversion rate within covered calls is 27.8%.
The final conversion rate is not yet known.

No benchmark conclusion should be drawn from these hypothetical figures.

How mathematically correct metrics become operationally misleading

The denominator changes

A qualification rate based on connected calls will usually be higher than one based on initiated calls. Neither is automatically wrong. The label must disclose the denominator.

Different statuses are mixed

Combining routed, connected, qualified, billable, and payable calls in one “approved calls” bucket destroys the ability to explain leakage and money flow.

Data is delayed

Buyer dispositions, conversions, recordings, disputes, credits, and invoice approvals may arrive after the call. A live dashboard should show as-of time and coverage.

Sources or targets are blended

A blended average can make one strong source and one weak source appear ordinary. It can also hide a target-specific capacity problem.

Time zones differ

The publisher may report in UTC, the buyer in local time, and finance by an invoice-period time zone. A call near midnight can land in different reporting days. Define the canonical event timestamp and reporting zone.

Small samples are overinterpreted

One conversion out of three calls is 33.3%. That does not make it a stable estimate. Show counts beside percentages and avoid scaling decisions from thin segments.

Buyer feedback is incomplete

Missing outcomes should be reported as missing, not automatically converted into negative outcomes.

Dashboard values are not finalized

Open disputes, reversals, late feedback, and adjustments can change financial totals. Label estimated, provisional, finalized, invoiced, and paid states separately.

Averages hide distributions

Average duration and average latency can remain steady while the tail deteriorates. Use bands, percentiles, and failure counts.

The rule changed during the period

A new duration threshold, duplicate lookback, source permission, cap, or conversion definition can create an apparent trend that is really a policy change. Preserve rule versions and annotate comparisons.

The counting grain changes

A report can count consumer calls, call legs, route attempts, buyer requests, or financial events. Mixing grains creates inflated or contradictory totals.

Buyer and publisher views should reconcile without being identical

A buyer and publisher do not need identical dashboards. They do need compatible operating records.

A buyer usually needs:

Calls presented and answered by target.
Queue and connection performance.
Qualification and disposition outcomes.
Conversion feedback and delay.
Buyer price and invoice status.
Source-level performance within approved visibility boundaries.

A publisher usually needs:

Calls initiated, offered, accepted, routed, and rejected.
Rejection reasons that can be acted on.
Connection and qualification outcomes.
Payable status and publisher payout.
Disputes and adjustments affecting the publisher side.
Source- and sub-source-level performance.

Internal operations and finance need the bridge between them:

Shared call and event identifiers.
Versioned commercial terms.
Status-transition history.
Source and target references.
Buyer and publisher financial legs.
Dispute and adjustment records.
Invoice and payout-batch membership.
As-of and finalization timestamps.

The views can be scoped differently while still reconciling to the same underlying call history.

A practical metrics-review checklist

Before using a metric to scale, pause, invoice, pay, or investigate, confirm the following:

Use metrics to choose the next investigation

A metric should narrow the next question, not pretend to answer every question.

Consider increasing volume only when

The relevant source and target segments have enough mature data.
Connection and handling capacity remain stable.
Qualification definitions have not changed unnoticed.
Conversion feedback coverage is adequate for the decision.
Financial values are mature enough to support the economics.
No concentrated failure mode is hidden by blended averages.

Hold volume when

The top-line rate improved but the denominator or source mix changed.
Buyer feedback is late or incomplete.
A cap or schedule change altered delivery patterns.
A small sample is driving a large percentage movement.
Disputes or credits are still open.
The live dashboard and settlement report do not yet reconcile.

Investigate before blaming traffic when

Connection performance declined at one target but not others.
Route attempts per call increased.
Destination errors or no-answer outcomes rose.
Queue abandonment increased during a specific daypart.
Feedback coverage fell.
A policy or rule version changed.
Time-zone boundaries moved records between reporting periods.

Investigate the source when

A source-specific rejection, duplicate, qualification, QA, or dispute pattern persists after buyer-side and routing causes are separated.
The issue is reproducible across compatible targets.
The source’s consumer journey or traffic package no longer matches the reviewed configuration.
The sample is sufficient and the data is mature.

The Dependable Calls perspective

Dependable Calls is being built around source-level visibility, routing controls, precise call statuses, and explainable financial records.

The current software includes bounded RTB outcome and latency instrumentation for parts of the routing path. That is evidence of implemented measurement capability, not proof that every metric described in this guide is portal-exposed, operationally used, or fully mature. Broader reporting and settlement workflows remain subject to live validation and continued hardening.

The operating goal is straightforward: a buyer, publisher, finance reviewer, or internal operator should be able to understand what a metric counts, why it changed, which records support it, and whether the value is still provisional.

Need cleaner call settlement? Talk with Dependable Calls about buyer or publisher workflows.