Renting your phone numbers means renting your reputation

A rep dials. The prospect's handset shows "Spam Likely" before it rings. Nothing about that call caused it. Nobody at your company did anything wrong that morning.

The label was attached to eleven digits, and those eleven digits had a life before you.

What the label actually is

"Spam Likely", "Scam Likely" and the various carrier-branded variants are not a verdict on your company, your product or your consent posture. They are an analytics verdict attached to a telephone number, computed from how that number has behaved on the network.

The inputs are behavioural and they are observable from the outside. A number with a very low answer rate. A number whose calls consistently end in a few seconds. A number producing a high volume of dials per day. A number that carries weak or missing call authentication. A number that users have reported.

None of that is about who currently holds the number. It is about the number.

We built a scoring model on exactly those signals, and it is worth saying plainly what it is and is not. It scores each number from connect rate, the share of calls ending in under about 15 seconds, dials per day against a 100-per-day pacing guideline, any provider-reported spam flag, and STIR/SHAKEN attestation-A coverage parsed out of carrier call detail records. Its own header describes the mechanism it is modelling: "Carriers down-rank numbers that show spam-like behavior: low connect rates, very short calls, high daily dial volume, missing attestation."

That is our model of the thing, not the thing. We cannot see the carriers' analytics models and neither can you. What we can do is watch the same observable signals and rotate a number out before it earns a label, which is a different and more modest claim than preventing labels. We do not guarantee you will never be flagged, and any vendor who does is selling you something they do not control.

One check we could not run for this article: fcc.gov returned HTTP 403 to two different fetch methods from this machine, so we are not quoting the FCC's own wording on call authentication. What we can cite is that the FCC's 8 February 2024 Declaratory Ruling makes an AI-generated voice an "artificial or prerecorded voice" under the TCPA, triggering full consent obligations, as summarised by the National Consumer Law Center at https://library.nclc.org/article/top-six-tcparobocall-developments-20242025. That is settled law, not news.

Why this is physics and not policy

A policy constraint is something a vendor chooses and can change. A physical constraint is a property of the system that no contract clause reaches.

Number reputation is the second kind, for one reason: reputation attaches to the identifier, and the identifier is transferable.

If a dialing product hands your reps a caller ID out of a pool shared across its customers, the behaviour of every other tenant on that number is part of what your prospect's handset sees. If a number is recycled, its previous holder's pattern is baked in. If someone else ran an aggressive campaign from it last quarter, you inherit that. Not as a rule, not as a penalty applied by a vendor you can appeal to, but as an accumulated statistical history sitting in analytics systems you have no relationship with.

You also cannot audit it. You cannot ask a shared pool what the number did before you, because the answer belongs to another customer.

This is the question worth asking any vendor, before the demo: is this number mine, or yours? Has anyone else ever dialled from it? What happens to it when I leave? Those are answerable questions with short answers, and the answers are more informative than any connect-rate benchmark.

What we own, and what that buys

We run our own Asterisk PBX with a Telnyx trunk rather than reselling a shared carrier pool, and numbers are held per workspace. The pool loader reads only the numbers the workspace actually owns, from that workspace's own phone-number records, and hands them to a pure selector that picks a caller ID by exact area-code match, then same-region grouping, then health tier, then a stable tie-break.

The reason that module exists is a good illustration of how these systems really go wrong. Its own header records that the selector had been written and was correct, and had no consumer: the live dial path was hardcoded to a single environment-variable number, so a 415 prospect and a 212 prospect in the same wave both saw the same out-of-area caller ID. The capability existed in the codebase and did not exist in behaviour. A feature list would have shown local presence as shipped. Nothing was reaching a phone.

The same shape appears one layer up. Health scoring flagged at-risk numbers, a rotation planner partitioned the pool into rest and keep, and that output was used only to paint advisory pills on a dashboard. The rotation actuator is what closes that gap: it removes at-risk numbers from the pool so the selector cannot pick one.

The budget, and the decision to burn it

The hard constraint on our side is a per-number daily dial cap, defaulting to 50 dials per number per day, tunable through an environment variable and bucketed on the UTC calendar date. How that ceiling is made atomic against two dial paths racing for the last slot is its own subject and has its own article. What belongs here is what happens to a slot once it is claimed.

When a batch claims its slots and the call registration then fails, those slots are burned rather than returned. From the comment sitting on that branch of the dial path: the slots this batch claimed up front are deliberately forfeited, not refunded, because a decrement "could race concurrent claims into allowing more real dials than the cap", and "the cap is a carrier-reputation heuristic whose fail-safe direction is under-dialing."

That is the whole posture in one comment. A dial you did not make costs you one conversation. A number you burned costs you every conversation from that number, for as long as the label sticks, and numbers do not recover on your schedule. So when the safe answer and the productive answer disagree, the budget is spent rather than recovered, and the loss is logged loudly so an operator can see dial budget consumed by a failure instead of by a call.

The same asymmetry is why the cap is a number-level budget rather than a workspace-level one. A team-wide throttle protects nobody: it lets one number absorb the whole day's volume while the others sit idle, and high daily volume on a single number is precisely the pattern our health model treats as a spam signal.

Where it is not clean

Four things, because a piece like this is worthless without them.

The cap is not unconditionally fail-closed. If the claim cannot be evaluated at all, the code logs "daily-dial-cap: could not evaluate cap, dialing without cap enforcement" and proceeds. That is a deliberate availability choice on a rare path, and it is fail-open. We would rather name it than let you discover it.

There are two numbers, not one. The hard cap defaults to 50 per number per day. The health model separately treats 100 per day as a pacing guideline when scoring. Those are different constants doing different jobs, and anyone reading only one of them will describe our system wrongly.

Resting everything is an outage. If every number in a pool scores at-risk, we do not stop the workspace dialing. We keep the single healthiest number, mark the pool degraded and warn the rep, because, in the module's own words, "resting everything is an outage, not a safety control". That is a product decision, not a safety property, and it means a degraded pool can still place calls.

Carrier registration is a human upload. FreeCallerRegistry has no submission API. Our export route produces the file, an operator uploads it, and the submit route records that they did. It never contacts a provider and never invents a registered result. Similarly, provisioning fresh local numbers from a carrier pool is gated on provider credentials a human supplies; only the selection half is automated.

And two scope limits. Parallel-dialer phases beyond the shipped power dialer are not generally available yet. External do-not-call registry scrubbing is not provisioned, so no number has ever been checked against a national registry by us; internal do-not-call, suppression and consent gates are live and are not overridable. This article is about voice, and nothing in it should be read as a claim about text messaging, which runs on a separate carrier registration regime.

Every code reference above was read from committed state at the deploy commit, not from a working tree.

The question to take away

Connect rate is the metric everyone optimises, and it is downstream. It is what happens after the handset has already decided what to display.

The upstream question is ownership. When your rep dials, whose number reputation are they inheriting?