A rented number that is paid for but unused is a cost you do not see in the moment: the charge happens once, at renewal, and nobody checks between renewals whether the number is getting any real activity at all. Here is how to calculate each number's actual utilization, what criteria decide its fate, and what to log before releasing it.
Idle time is the most invisible cost item
An idle number does not throw an error or trigger an alert — it just keeps getting charged at every renewal, indistinguishable in billing from one that is actively used. The gap only shows up when you compare the date of its last real activity against the date of its last payment, and almost nobody does that comparison by hand for months on end.
The danger is that idle time builds up quietly: one forgotten number is a small amount, but a dozen forgotten numbers in a fleet of fifty is already a noticeable share of the monthly bill that is not going toward any current task.
How to calculate each number's utilization
The math is simple: the number of days or tasks with real activity on the number — an inbound code, a call, a binding to a new registration — divided by the number of paid rental days. A number that received three codes over thirty days runs at roughly 10% utilization, and the actual cost per code received on it is several times higher than a one-off activation's listed price.
The source data for this calculation is transaction history: it shows, per number, the rental date, every renewal, and every inbound event as its own line, with no manual spreadsheet matching needed.
Criteria: keep, release, or replace with one-off activations
Keeping a number makes sense if it reliably gets tasks at least once every week or two, or if it holds a critical binding — more on that below. Releasing it makes sense if two or three renewal cycles in a row have shown zero activity with none planned. The in-between case is irregular but non-zero load, once a month or two: here a long-term rental usually loses to one-off activations on cost per outcome, since paying for thirty days for one event a month costs more than paying for a single activation exactly when it is needed.
Why some numbers need to stay even at zero load
A formal zero on tasks does not always mean a number is spare. A number bound as a second factor to an account holding valuable data or payment rights can go months without receiving a single code and still be critical: releasing it means losing the way to confirm sign-in the next time it is requested. Such numbers need to be flagged separately from ordinary idle ones, so an audit does not release them automatically under a "zero tasks — release" rule.
The working practice is to keep a separate list of numbers tagged "second-factor binding", excluded from the general utilization rule, and to review that list on a longer cycle than the main fleet — but never skip it entirely.
How often to audit, and what to log before releasing a number
A full fleet audit once a month is the minimum, synced to the rental renewal cycle: that way the keep-or-drop decision runs on fresh data, not inertia. With a fast-growing fleet — dozens of new numbers a month — checking every two weeks keeps decisions from lagging behind reality.
Before releasing a number, log three things: the date of its last real activity, the list of services it was bound to, so access is not lost unnoticed, and the reason for release — idle time, replacement with one-off activations, or a project wrapping up. Without that record, the same number sometimes gets rented again in a spot where it was already flagged as spare a month earlier.
Frequently Asked Questions
What counts as low utilization for a number?
The rule of thumb is below 20–30% of paid rental days, meaning less than one task every week or ten days. At that level, one-off activations are almost always cheaper than a long-term rental on cost per outcome.
Can auditing the number fleet be automated?
Partially: matching the renewal date against the last-activity date for each number can run off transaction history without manually reviewing every card. The keep-or-release call on borderline cases still needs a manual check of bindings.
What if a released number is needed again later?
A released number is not reserved for its previous owner and goes back into the shared pool — there is no guarantee of renting the same one again. That is why it is worth confirming no critical bindings remain before releasing it.
Check your fleet's real utilization right in your account: the number rental section shows the term and status of every number, and transaction history supplies the source data for the calculation. The same spend-control principle applies at the team level too — covered in team spending limits.