“The call did not route” sounds like one problem.

It is not.

A call can fail before buyer evaluation, during buyer eligibility, inside an RTB request, while a route is being reserved, when the live call arrives, during the buyer bridge, after the buyer leg rings, or later when qualification and financial rules are applied.

Those failures can look similar from the outside.

A publisher may see no bid. A buyer may say no call arrived. An agent may report a dropped call. Finance may see a non-billable record. Operations may see only a generic rejection unless the call path was designed to preserve stage-specific evidence.

The first rule of routing diagnosis is therefore:

Do not start with who is being blamed. Start with the last stage that definitely succeeded.

If a bid was never returned, investigate the decision path.

If a bid was returned but no live call arrived, investigate publisher delivery and reservation timing.

If the reservation matched but the buyer never answered, investigate the telephony and buyer-leg path.

If the call connected but did not qualify, stop calling it a routing failure and investigate qualification or settlement.

This guide provides a practical framework for separating those stages, identifying common failure modes, and building a call timeline that buyers, publishers, and operators can use without exposing protected partner information.

For the underlying decision model, read What Is a Call Routing Decision?. For the pre-call and live-call distinction, see Live Call Routing vs Pre-Call Ping.

The short answer

A useful diagnosis answers five questions in order:

Did the request or live call enter the expected campaign path?
Were any buyer targets eligible?
Did a valid offer or route decision exist within the time budget?
Did the live call arrive and consume the correct route?
Did the buyer leg connect, and what happened after connection?

The symptom alone is not enough.

Visible symptom	Possible stages	What to verify first
No bid	Intake, campaign resolution, eligibility, buyer RTB, rate limiting	Was the request valid, and which targets were eliminated for which reasons?
Accepted bid but no call	Publisher choice, transfer delay, abandoned caller, lost response	Was the route selected by the publisher, and did a live call reach the handle?
Call rejected at returned number	Reservation expiry, caller mismatch, reused route, wrong handle	Reservation status, arrival time, expected caller, and single-use state
Buyer says no call arrived	Bridge never attempted, destination failed, buyer did not answer, wrong reporting scope	Provider call-leg events and selected target
Call rang but did not connect	Busy, no answer, carrier failure, caller abandonment	Buyer-leg status and timing
Call connected but shows $0	Qualification, duplicate, dispute, CPA outcome, financial batching	Duration and settlement rules, not routing
Failures rise only under load	Endpoint latency, fan-out pressure, database or cache contention, capacity races	Latency by stage and dependency health
One source suddenly fails	Publisher field change, caller-ID presentation, route timing, bad tags	Compare integration version and reason distribution by source

A dependable operation should be able to move from the visible symptom to a specific stage and bounded reason.

“Routing failed” is not a root cause.

Build a stage map before troubleshooting

The routing path is easier to diagnose when it is treated as a series of gates.

Stage 1: Request or call intake

The system receives either:

A publisher pre-call ping.
A direct live inbound call.
A live call associated with an earlier reservation.
A fixed internal call path.
Another approved integration event.

The intake layer may validate:

Authentication.
Tracking key or campaign identifier.
Publisher authorization.
Required fields.
Caller and geography formats.
Request size.
Rate limits.
Webhook signature.
Duplicate request identity.

A request that fails here never reached buyer routing.

Calling it “no buyer” hides the actual problem.

Stage 2: Campaign, publisher, and source resolution

The operation determines which campaign and supply context the request belongs to.

Failures can include:

Unknown tracking key.
Publisher not assigned to the campaign.
Source not recognized.
Cross-account or cross-organization mismatch.
Campaign inactive.
Integration using a test key against production or the reverse.
Ambiguous routing number.
Missing source attribution.

This stage establishes who sent the opportunity and which rules apply.

Stage 3: Buyer-target eligibility

The system identifies candidate buyer targets and evaluates the rules that determine whether each may participate.

Eligibility can depend on:

Active status.
Campaign assignment.
Source enablement.
Schedule and timezone.
Geography or ZIP code.
Call type.
Tags.
Caps.
Budget.
Concurrency.
Destination health.
Buyer funding or other operational gates.
Duplicate or suppression policy where applicable.

A target can exist and still be correctly ineligible.

For the control layer, see How Caps, Schedules, and Concurrency Shape Call Flow.

Stage 4: Offer creation and buyer RTB

An eligible target may produce an offer in two basic ways:

A fixed offer is synthesized from configured terms.
An RTB buyer endpoint is contacted for a live decision.

The buyer endpoint can:

Accept.
Decline.
Time out.
Return an HTTP error.
Return malformed data.
Return an unusable buyer price or duration.
Return a destination that fails validation.
Be skipped because the remaining decision budget is too small.

A buyer decline is a normal business outcome.

A timeout or malformed response is an integration failure.

Those should not share one undifferentiated no_bid reason.

See How Fixed-Bid Targets Differ from RTB Buyer Endpoints for the operating tradeoffs.

Stage 5: Ranking, transformation, and route reservation

Valid offers are compared under the approved routing policy.

The winning route may then require:

Commercial transformation.
A financial snapshot.
A controlled DID or SIP handle.
A capacity claim.
A short-lived reservation.
A frozen target and destination.
A publisher-safe response.

Failures can include:

No offer survives ranking or margin rules.
Invalid transformed terms.
No controlled handle is available.
A capacity claim loses a race.
Reservation persistence fails.
The route cannot be represented safely.
A buyer destination would leak into publisher-facing output.

A destination leak is not a minor routing error. It is a security incident.

Stage 6: Publisher delivery and reservation matching

In a pre-call flow, the publisher must send the live call to the returned route.

The operation checks whether:

The call arrived before expiry.
The route exists.
The route is still pending.
The handle belongs to the intended reservation.
The caller ID or metadata token matches.
The reservation has not already been consumed.
Any required confirmation succeeded.

A successful ping is not proof that this stage occurred.

Read Why Reservation Windows Matter in Pay-Per-Call and Why Caller-ID Matching Matters in Call Routing for the two most common reservation controls.

Stage 7: Telephony bridge

Once the route is valid, the telephony provider is instructed to dial the protected buyer destination.

Failures can include:

Invalid or unreachable phone number.
SIP address or credential failure.
Provider API or webhook error.
Invalid call-control response.
Buyer destination rejected by the carrier.
Bridge timeout.
Caller hangs up before the buyer leg connects.
Callback delivery is delayed or repeated.

Twilio documents that its <Dial> result can distinguish completed, busy, no-answer, failed, and canceled, and can include a child call ID, duration, and whether the call was bridged. See Twilio’s <Dial> documentation.

Those provider outcomes are evidence. They still need to be connected to the correct internal call, target, and route.

Stage 8: Connection and call handling

The buyer leg may ring, answer, or fail.

A call that reached the buyer destination can still produce:

Busy.
No answer.
Agent rejection.
IVR failure.
Immediate hangup.
Caller abandonment.
Early disconnect.
Transfer failure inside the buyer’s own system.
Poor handling after connection.

The route may have worked exactly as configured while the call still produced no useful conversation.

That distinction matters when deciding whether to change routing, staffing, buyer capacity, or call-center handling.

Stage 9: Qualification and settlement

After the call ends, the operation evaluates the applicable commercial rules.

The call may be:

Connected but too short.
Qualified for the buyer but not payable to the publisher.
A duplicate under the campaign rule.
Pending a CPA outcome.
Disputed.
Reversed.
Valid but not yet invoiced or included in a payout batch.

These are financial or policy outcomes, not proof that routing failed.

See The Difference Between a Routed Call, a Qualified Call, and a Billable Call.

”No buyer” is a result, not a diagnosis

One of the most common routing mistakes is collapsing every unsuccessful auction into no buyer.

That phrase can mean:

No buyer was assigned to the campaign.
Every target was paused.
Every target was closed by schedule.
Every target was capped.
The call was outside accepted geography.
The source was not enabled.
Required tags were missing.
Every buyer declined.
Every buyer timed out.
Responses could not be parsed.
The request was rate-limited.
The system could not reserve a safe route.
A dependency failed before the auction completed.

Ringba’s published RTB error codes illustrate why reason separation matters. Its documentation distinguishes disabled campaigns or publishers, initial and final tag-filter failures, no capacity, caller-ID checks, closed or capped publisher overrides, rate limiting, caller-ID verification, missing required tags, and third-party enrichment or pass-through failures. See Ringba’s RTB Error Codes.

The exact codes vary by platform.

The lesson is broader:

Preserve the most specific safe reason the system actually knows.

A buyer or publisher may not be allowed to see every internal target or private response. The operation can still provide a useful category such as:

campaign_inactive
source_not_enabled
schedule_closed
capacity_exhausted
geo_not_supported
buyer_declined
buyer_timeout
buyer_response_invalid
rate_limited
reservation_unavailable
internal_error

The reason should describe the stage without exposing another partner’s confidential data.

Separate normal business outcomes from system failures

Not every unsuccessful call is an incident.

Normal outcomes

These can occur while the system works correctly:

No buyer wants the opportunity.
The call is outside every buyer’s geography.
A target is closed.
A cap is reached.
A publisher chooses another accepted bid.
A reservation expires unused.
The buyer does not answer.
The connected call misses the duration threshold.
A duplicate policy blocks payout.

System or integration failures

These indicate something broke or was misconfigured:

Valid buyers were never evaluated.
The wrong schedule timezone was used.
A required field disappeared after a publisher release.
Buyer responses stopped parsing.
A slow endpoint consumed the whole decision budget.
A handle pool could not allocate a route.
Expired reservations were not released.
A live call consumed the wrong reservation.
Webhook signatures failed because URLs or secrets drifted.
Provider callbacks could not be matched to the call.
A buyer destination was malformed.
The same completion event created duplicate settlement.

The response should match the category.

A normal no-bid may need no engineering action.

A parser failure may require an integration fix.

A destination leak requires immediate containment.

Use the last successful state

A practical investigation starts by reconstructing the call timeline.

Ask:

Was the request received?
Was the publisher authenticated?
Was the campaign resolved?
Was the source recognized?
Which targets were considered?
Why was each target eligible or ineligible?
Which buyer endpoints were called?
What did each endpoint return?
Which offer ranked first?
Was a reservation created?
Was a route returned to the publisher?
Did a live call arrive?
Did it match and consume the reservation?
Was the buyer destination dialed?
What provider status did the buyer leg produce?
Did the call connect?
How did the call end?
Which qualification and settlement rules were later applied?

The first missing or contradictory transition usually identifies the investigation area.

Examples:

request_received exists, but no campaign resolution: intake or tracking-key problem.
Target evaluations exist, all with schedule_closed: configuration or timezone problem.
Buyer requests exist, all time out: buyer endpoint or network problem.
Accepted bid exists, no reservation: route-allocation or persistence problem.
Reservation exists, no live arrival: publisher delivery, caller abandonment, or publisher choice.
Live arrival exists, reservation expired: timing or TTL problem.
Reservation consumed, no dial attempt: telephony rendering or provider-webhook problem.
Dial attempt exists, no-answer: buyer availability or staffing problem.
Connected call exists, $0 financial result: qualification or settlement problem.

This method prevents teams from debugging the entire system at once.

Diagnose eligibility before blaming RTB

An RTB endpoint cannot bid on a target the router never allowed to participate.

When a target is missing, inspect eligibility in a consistent order.

Active state and assignment

Confirm that:

The buyer is active.
The target is active.
The target belongs to the campaign.
The campaign relationship is active.
The environment and account are correct.

Schedule and timezone

A schedule that looks correct in local time may be evaluated in another timezone.

Check:

Target timezone.
Day of week.
Open and close boundaries.
Daylight-saving transitions.
Overnight windows.
Holiday or emergency overrides.
Whether the timestamp was stored in UTC and interpreted correctly.

Caps, budget, and concurrency

These are separate limits.

A target may be:

Under its daily call cap but at concurrency.
Under concurrency but out of budget.
Open in the schedule but at a source-specific cap.
Available during ping but full when the live call arrives.

Record which limit eliminated the target.

Geography and tags

Check the actual normalized values used by the decision.

Common problems include:

ZIP was never passed.
State was derived incorrectly.
A tag key changed capitalization.
An empty tag was treated as present.
The source sent a value outside the agreed vocabulary.
An allowlist and denylist conflicted.
A required field was available in the form but missing from the API request.

Do not debug the buyer bidder until the target is proven eligible.

Diagnose buyer RTB with outcome and latency together

A buyer endpoint can respond quickly and decline.

It can respond slowly and accept after the decision window has already closed.

It can return HTTP 200 with unusable content.

A useful buyer-attempt record includes:

Buyer and endpoint ID.
Request ID.
Start and end time.
Configured timeout.
Remaining auction budget.
HTTP status.
Parsed outcome.
Decline reason when available.
Validation or parser error.
Circuit-breaker state.
Whether the endpoint was skipped or shed.
Whether the response arrived too late to participate.

One slow endpoint should not control every call

Live-call routing has a tighter latency budget than a pre-call ping because the caller is already waiting.

The system should:

Fan out only to eligible targets.
Use bounded parallelism.
Apply per-endpoint deadlines.
Enforce an overall decision deadline.
Skip work that cannot finish within the remaining budget.
Isolate unhealthy buyers with circuit breakers or equivalent controls.
Preserve timeout reasons.

Do not increase the global timeout merely to accommodate one unstable endpoint.

That can turn one partner problem into a caller-experience problem across the whole campaign.

A decline is not an error

Track at least:

Accepted.
Declined.
Timeout.
Transport error.
HTTP error.
Parse error.
Validation error.
Circuit open.
Skipped for insufficient budget.
Load-shed.

This distinction supports better partner conversations.

“You declined 62% of the eligible opportunities” is different from “your endpoint failed on 62% of requests.”

Reservation failures need their own timeline

A pre-call bid and the later live call are different events.

Retreaver’s RTB troubleshooting guidance tells operators to use the reservation UUID and call flow to see which buyers were closed, filtered out, or unavailable. It also distinguishes no-target, expired reservations, and successful bids that never become calls because the publisher chose another demand path. See Retreaver’s RTB troubleshooting documentation.

For a reservation failure, verify:

Reservation ID.
Bid or request ID.
Controlled handle.
Expected caller or metadata token.
Creation time.
Expiration time.
Arrival time.
Status: pending, used, expired, rejected, or canceled.
Whether the handle was reused.
Whether the publisher attempted more than one delivery.
Whether capacity was claimed and released.
Whether a confirmation step was required.

Expired

The call arrived after the valid window.

Possible causes:

Publisher processing delay.
Too many downstream auctions.
Carrier delay.
Caller hold or transfer delay.
Clock disagreement.
TTL too short for the real path.
Call sent to an old route.

Caller or token mismatch

The live call did not match the identity bound to the route.

Possible causes:

Wrong caller sent.
Caller-ID formatting or regional normalization.
Transfer platform rewrote caller ID.
Wrong SIP URI or token.
Leaked or shared route.
Replay or probing.

Already used

A second attempt tried to consume a single-use route.

Possible causes:

Publisher retry after success.
Duplicate provider webhook.
Two workers handling the same arrival.
Route reuse.
Caller redial under an old decision.

Do not “fix” these by making reservations reusable. Diagnose why the second attempt exists.

Telephony status is not one boolean

Once the buyer destination is dialed, preserve the buyer-leg outcome.

Twilio’s official documentation distinguishes:

completed: the called party answered and connected.
busy: a busy signal was received.
no-answer: the destination did not answer before timeout.
failed: the provider could not route to the destination.
canceled: the attempt was canceled before answer.

It can also report whether the call was bridged, the child call ID, and the dialed-leg duration.

These outcomes lead to different actions.

Busy

Check whether the destination supports the expected concurrency and whether the buyer’s internal line hunt is configured correctly.

No answer

Check staffing, ring timeout, business hours, destination health, and whether the buyer is accepting more calls than agents can handle.

Failed

Check number validity, carrier routing, SIP response, destination configuration, credentials, and provider error details.

Canceled or caller abandoned

Check whether the caller hung up while the auction or buyer leg was still in progress. Long decision and ring times can make a technically valid route commercially useless.

Connected then dropped

Inspect which party ended the call, bridge duration, carrier events, and the buyer’s internal transfer path. Do not automatically attribute every early disconnect to the publisher.

Twilio also recommends securing incoming webhooks with HTTPS and verifying that the request came from Twilio. A rejected or unverified webhook can look like a missing call event even when telephony occurred. See Twilio’s Voice Webhooks documentation.

Common failure patterns

Everything fails after a configuration change

Look for:

Target pause.
Schedule change.
Parser update.
Formula update.
Required tag change.
Destination edit.
Credential rotation.
Source enablement change.
New country or phone format.
Deployment affecting routing composition.

Compare the change timestamp with the first failure.

Only one publisher fails

Look for:

Tracking key.
Required fields.
Caller-ID presentation.
Transfer delay.
Source or subsource value.
API version.
Authentication.
Rate limit.
Test versus production endpoint.

Only one buyer fails

Look for:

Buyer endpoint latency.
HTTP status.
Response schema.
Destination validity.
Schedule and caps.
Circuit-breaker state.
Buyer-side deployment.
Network allowlisting.

Failures increase gradually

Look for:

Caps or budget approaching exhaustion.
Handle pool depletion.
Reservation expiry jobs falling behind.
Database connection pressure.
Cache memory pressure.
Accumulating stale state.
Slow buyer endpoint tail latency.
Growing call volume beyond staffed capacity.

Failures happen only at peak volume

Look for:

Concurrency races.
Admission-control shedding.
Fan-out socket pressure.
Database pool saturation.
Cache contention.
Provider rate limits.
Buyer call-center capacity.
Insufficient handle inventory.

Reporting says no route, but the buyer has call records

Look for:

Duplicate or delayed provider callbacks.
Different call-leg IDs.
Route fallback not reflected in the primary record.
External transfer outside the controlled path.
Timezone or reporting-window mismatch.
Call associated with another campaign or target.
Historical platform versus internal platform data.

The solution is correlation, not choosing whichever dashboard looks more convincing.

Metrics that make diagnosis possible

A routing dashboard should show a funnel rather than one success rate.

Intake

Requests and live calls received.
Authentication failures.
Validation failures.
Rate-limited or load-shed requests.
Unknown campaign or tracking key.

Eligibility

Candidate targets considered.
Eligible targets.
Eliminations by schedule, cap, budget, concurrency, geography, source, tag, and status.
Calls with zero eligible candidates.

Buyer RTB

Requests by endpoint.
Acceptance and decline rate.
Timeout and error rate.
Parse failures.
Latency median, p95, and tail.
Circuit-open and skipped counts.

Reservation

Reservations created.
Reservations consumed.
Expired unused.
Caller or token mismatches.
Reuse conflicts.
Handle-allocation failures.
Time from response to live arrival.

Telephony

Dial attempts.
Busy.
No answer.
Failed.
Canceled.
Connected.
Time to buyer-leg ringing.
Time to answer.
Caller abandonment.

Downstream

Connected-to-qualified rate.
Buyer-billable rate.
Publisher-payable rate.
Duplicate and dispute rate.
Reconciliation exceptions.

Break the metrics down by publisher, source, campaign, buyer target, route type, integration version, and time window.

An aggregate routing-success rate can hide one bad buyer endpoint or one publisher integration sending malformed tags.

A practical incident workflow

When routing performance drops:

1. Bound the incident

Determine:

Start time.
Affected campaigns.
Affected publishers and sources.
Affected buyers and targets.
Ping, live, DID, or SIP path.
Whether failures are total or partial.
Whether the problem follows volume.

2. Select representative calls

Use:

One successful call before the incident.
One failed call early in the incident.
One recent failed call.
One call from each affected integration path.

Avoid drawing conclusions from one call.

3. Reconstruct each timeline

Use a stable request, call, bid, reservation, and provider identifier.

Find the last successful transition and the first missing or failed transition.

4. Compare reason distributions

Ask whether the mix changed:

Schedule closed.
Cap reached.
Buyer decline.
Buyer timeout.
Reservation expiry.
No answer.
Provider failure.
Non-qualified.

A volume spike in one reason is more useful than a generic failure-rate spike.

5. Check recent changes and dependencies

Review configuration and deployment history.

Check database, cache, host, network, and telephony-provider health before assuming the business rules are wrong.

6. Protect invariants while mitigating

Do not:

Expose buyer destinations.
Disable authentication.
Make single-use routes reusable.
Ignore caller mismatch.
Bypass financial snapshots.
Collapse all traffic into an unrestricted overflow buyer.
Lengthen every timeout without measuring caller impact.

A temporary mitigation should remain controlled and auditable.

7. Verify the fix end to end

A green API request is not enough.

Confirm:

Valid request accepted.
Expected buyer considered.
Route returned.
Live call arrives.
Reservation matches.
Buyer leg rings.
Buyer answers.
Completion callback records.
Qualification and finance records remain consistent.

A hypothetical diagnosis

Consider a hypothetical plumbing campaign.

Publishers report that accepted bids have dropped sharply since 2:00 p.m.

Weak diagnosis

“The buyer is down.”

That conclusion is based only on the publisher seeing fewer accepted responses.

Controlled diagnosis

Operations compares a successful request from 1:55 p.m. with failed requests after 2:00 p.m.

The timeline shows:

Requests are authenticated.
Campaign and source resolve correctly.
Two targets are assigned.
Target A is eliminated because its daily cap is reached.
Target B is eligible.
Target B’s RTB endpoint receives the request.
The endpoint returns HTTP 200.
The response parser marks the bid invalid because a required field changed from a number to a formatted string after the buyer’s deployment.
No valid offers remain.
The publisher receives a no-bid.

The buyer’s call center is not down.

The buyer’s bidder is reachable, but its response contract changed.

The fix is to restore the agreed response or intentionally version the parser—not raise caps, change publisher traffic, or send calls blindly to the buyer destination.

After the fix, operations validates a complete ping-to-call flow and checks that the same issue did not affect other endpoints using the parser.

That is diagnosis by stage and evidence.

What buyers should ask

A buyer should ask:

Which eligibility reasons can prevent my target from participating?
Can I see whether my endpoint declined, timed out, or errored?
What is my endpoint timeout?
How are malformed responses handled?
Are fixed and RTB offers traced through the same downstream route record?
How are caps, schedules, and concurrency explained?
What provider outcomes distinguish busy, no answer, and failed?
How are fallback attempts recorded?
Can an invoice line be traced back to the call and route decision?
How are protected destinations kept out of publisher-facing diagnostics?

What publishers should ask

A publisher should ask:

Which fields are required in the ping?
Which no-bid and rejection reasons are available?
How long is a returned route valid?
How are caller ID and SIP metadata matched?
What happens when a response is lost or retried?
Can I distinguish no buyer from expired reservation?
Can I see whether the live call reached the exchange?
How are buyer no-answer and provider failure reported?
What timestamps are available for latency diagnosis?
How do routing outcomes connect to publisher payout status?

How Dependable Calls is approaching routing diagnosis

Dependable Calls is being built around a stage-specific routing record rather than one generic success flag.

The current implementation supports or includes:

Separate pre-call and live-call decision budgets.
Publisher request validation and authorization.
Source and campaign resolution.
Buyer-target eligibility with bounded reasons.
Fixed offers and buyer RTB endpoints.
Parallel buyer evaluation with timeouts and failure isolation.
Controlled ranking and route reservations.
Short-lived, single-use number and SIP/metadata routes.
Caller-ID and reservation matching.
Protected buyer destinations.
Twilio voice and status callbacks.
Separate routing, connection, completion, qualification, billing, and payout events.
Structured logs, metrics, traces, audit records, and routing runbooks.
Automated tests for acceptance, rejection, expiry, reuse, latency, and finance paths.

The intended diagnostic path is:

alert or partner complaint → call or request identifier → event timeline → eligibility reasons → buyer attempts → reservation lifecycle → provider call-leg outcome → qualification and settlement record.

That is implementation evidence, not a claim that every route has been certified in live production conditions.

Dependable Calls remains beta-stage and launch-in-progress. The application repository identifies live Twilio validation, one live campaign, and RTB capacity certification under real load as remaining production-certification work.

The operations repository also documents a current Ringba-centered call-truth workflow. The internal platform should therefore be understood as the system being built and validated, not proof that every existing campaign has migrated to the same observability and routing path.

The practical operating standard is:

Preserve stage-specific reasons.
Keep business no-bids separate from system errors.
Diagnose from the last successful state.
Use correlation IDs instead of screenshots alone.
Measure latency and outcomes together.
Protect buyer destinations and caller data during troubleshooting.
Do not loosen single-use, matching, or financial controls to make failures disappear.
Verify fixes with a real end-to-end call path.

The bottom line

Pay-per-call routing breaks in many places.

A request can be invalid. A target can be correctly ineligible. A buyer can decline. An endpoint can time out. A reservation can expire. A caller can reach the wrong handle. A destination can fail. A buyer can be busy. A connected call can miss qualification.

Those are not interchangeable outcomes.

The fastest way to diagnose routing is to stop asking only, “Why did the call fail?”

Ask instead:

What is the last stage we can prove succeeded, what should have happened next, and what evidence explains why it did not?

That question turns a vague routing complaint into an operating problem that can be measured, assigned, corrected, and verified.

Need a more controlled call flow? Start a conversation with Dependable Calls.