Evaluating carrier models
Carrier-model evaluations come down to one question: who holds the numbers and who controls the routing between them. On a single-tenant or multi-tenant aggregator, the vendor rents you capacity on its inventory; on Devotel Orbit the inventory lives in your account. This page gives you the checklist, a worked scoring table for the three carrier models, the surfaces to run the evaluation on, and an FAQ for deciding when the incumbent should stay.1. Gaps buyers hit first
- Single-carrier dependence. The incumbent terminates everything over one wholesale relationship, so a route problem is your problem and there is no second candidate to grade it against. Score how routing preference is expressed before you sign, not when the route degrades.
- Opaque routing. You cannot see which carrier a send will take or what degraded it, because the vendor treats routing as its own layer rather than a policy you can read. A dry-run quote and live route scoring are the strongest screens on a vendor’s routing surface.
- No port-out guarantee. The inventory lives in the vendor’s account, so leaving means a vendor-mediated ticket rather than a tenant-initiated port. Check the escape hatch on the vendor’s inventory page before you fill it.
2. Tenant-owned checklist rows
Score every candidate on three rows you can verify about any vendor:- Number ownership and ports. Inventory lives in the tenant’s own account, not a vendor-rented pool, and ports out on tenant initiation — the full numbers tree spanning inventory and export, per-country capability checks, lookup, and the lifecycle and status map every number moves through. The porting page covers the flow in and out of the vendor’s inventory.
- BYO carrier and routing ownership. A carrier you operate attaches to your account as a policy preference you control — attach, health, LCR scoring, and detach are the tenant-owned BYO carrier lifecycle, and the message’s resolved sender is a policy object you own per the sender-resolution chain.
- Auditability and consent. Every routing and inventory change that affects a tenant-owned sender resolves to an object in your account, and the per-recipient consent and suppression records bound to your senders live in the consent and suppression model you own.
3. Scored candidates
Score each candidate “yes / partial / no” per row, at the level of the published product surface; a blank cell reads as missing research, so mark “partial” or “no” instead of leaving one.
Read the table as a starting hypothesis: re-score the rows against a live trial of each candidate on the surfaces below, and keep the incumbent honest by running it through the same checklist.
4. Evaluation surfaces
Ground every claim from a vendor on the same surfaces you would run Devotel Orbit against:- Sandbox API key — create a
dv_test_sk_key from the dashboard with no KYC or approval step; simulated sends cost $0. Walk the sandbox overview and the provisioning and test-mode guide before you provision anything, then start from the quickstart. - Numbers tree as capability probes — the inventory row maps to numbers overview, country capabilities, lookup, lifecycle, and porting; the BYO row maps to the BYO carrier lifecycle and sender resolution; the consent row maps to the consent and suppression model. If a capability matters to the decision, read the page a tenant configures it from.
- Pricing page — orbit.devotel.io/pricing is the same surface a signed tenant bills against; model your volume there instead of trusting a comparison grid.