Ask a wholesale voice buyer what they optimise for and you will usually get one of two answers. Either they buy on price and manage the consequences, or they buy on quality and absorb the margin hit.
Both answers are wrong, because they treat routing as a single decision. It is not. It is a decision made per destination, per traffic type, and often per hour of the day.
Key takeaways
- Least-cost routing optimises the rate per minute. Quality routing optimises the chance the call works.
- The cheapest route is only cheapest if you ignore the cost of calls that fail.
- Most mature setups blend the two, with the split driven by what the traffic is for.
- Automatic failover matters more than the initial route choice: routes degrade without warning.
- You cannot manage any of this without per-destination reporting you can see in real time.
What each approach actually does
Least-cost routing (LCR) sorts the available routes for a destination prefix by rate and sends the call down the cheapest one that is currently up. When it fails, the engine tries the next cheapest.
Quality-based routing sorts the same routes by measured performance (answer rate, average duration, post-dial delay, caller ID integrity) and sends the call down the best performer, accepting a higher rate to get it.
The difference is which column the sort runs on. Everything else about the mechanism is identical, which is why blending them is straightforward once you decide what each type of traffic is worth.
The cost that LCR hides
The argument for pure least-cost routing is simple arithmetic: a route at 0.8p per minute beats one at 1.4p per minute, so use the cheaper one.
That arithmetic is only complete if a connected minute on both routes is worth the same. Often it is not.
Consider outbound calls confirming appointments. If the cheap route connects 72% of the time and the premium route connects 88%, the cheap route is not saving 0.6p per minute, it is failing to reach 16 in every 100 of the people you were trying to reach. Whether that matters depends entirely on what a reached person is worth, which is a business question, not a telecoms one.
The same logic runs in reverse. For traffic where a failed call genuinely costs nothing (a retryable notification, an internal test, a low-value automated dial), paying premium rates buys nothing at all.
Where each one fits
| Traffic type | Lean toward | Why |
|---|---|---|
| Customer support, inbound | Quality | A failed call is a customer who could not reach you |
| Appointment and delivery notifications | Quality | Reach rate maps directly to revenue and cost avoided |
| High-volume outbound campaigns | Blended | Volume makes rate matter, but reach rate still drives return |
| Automated retryable alerts | Least cost | A failure costs one retry and nothing else |
| Anything carrying your brand's caller ID | Quality | Stripped or rewritten CLI damages answer rates over time |
The part that matters more than the sort order
Whichever way the routing engine sorts, the thing that determines real-world quality is what happens when a route degrades.
Routes do not fail cleanly. They drift. A supplier's own upstream changes, a destination network congests during local business hours, an interconnect starts stripping caller ID after a config change. In none of those cases does the route go down. It just quietly gets worse.
Three things make that survivable:
- More than one route per destination. Without an alternative, failover has nowhere to go and comparison has no baseline.
- Automatic failover on measured degradation, not just on hard failure. A route that has dropped 15 points of ASR should stop receiving traffic before a human notices.
- Per-destination visibility in real time. A weekly report tells you what went wrong last week.
A workable default
For most buyers, a sensible starting position looks like this: quality-routed by default for anything customer-facing, least-cost for anything automated and retryable, at least two routes on every destination that matters, and automatic failover triggered by measured performance rather than by outage alone.
Then review it per destination rather than in aggregate. Blended averages are where routing problems go to hide.