> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Evaluating carrier models

> A tenant-owned scoring rubric for carrier models (single-tenant, multi-tenant, Devotel Orbit): the checklist rows for number and routing ownership, a worked scoring table, evaluation surfaces, and the FAQ on when not to move.

# 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.

Orbit closes these with tenant-owned surfaces: a [numbers tree](/numbers/overview) whose inventory lives in your account, a [BYO carrier lifecycle](/concepts/byo-carrier-lifecycle) whose routing preference is yours, and a self-serve [port-out flow](/numbers/porting) you run from your own dashboard.

## 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](/numbers/overview) spanning [inventory and export](/numbers/inventory-export), [per-country capability checks](/numbers/country-capabilities), [lookup](/numbers/lookup), and the [lifecycle](/numbers/lifecycle) and [status map](/concepts/number-lifecycle) every number moves through. The [porting page](/numbers/porting) 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](/concepts/byo-carrier-lifecycle), and the message's resolved sender is a policy object you own per the [sender-resolution chain](/concepts/sender-resolution).
* **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](/concepts/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.

| Checklist row                     | Multi-tenant aggregator                                        | Single-tenant carrier model                                                | Devotel Orbit                                                |
| --------------------------------- | -------------------------------------------------------------- | -------------------------------------------------------------------------- | ------------------------------------------------------------ |
| Number ownership and ports        | no — inventory lives in the vendor's shared pool               | partial — inventory lives on the carrier account you rent                  | yes — tenant-held inventory you port out self-serve          |
| BYO carrier and routing ownership | no — routing is the vendor's own layer                         | partial — routing lives on your own carrier, but reads as a vendor setting | yes — policy-preference route objects you own and probe      |
| Auditability and consent          | partial — vendor exports CSV and runs suppression at its layer | partial — audit export exists but consent stays at the carrier             | yes — self-serve API export and tenant-owned consent objects |

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](/sandbox/overview) and the [provisioning and test-mode guide](/concepts/provisioning-and-test-mode) before you provision anything, then start from the [quickstart](/quickstart).
* **Numbers tree as capability probes** — the inventory row maps to [numbers overview](/numbers/overview), [country capabilities](/numbers/country-capabilities), [lookup](/numbers/lookup), [lifecycle](/numbers/lifecycle), and [porting](/numbers/porting); the BYO row maps to the [BYO carrier lifecycle](/concepts/byo-carrier-lifecycle) and [sender resolution](/concepts/sender-resolution); the consent row maps to the [consent and suppression model](/concepts/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](https://orbit.devotel.io/pricing) is the same surface a signed tenant bills against; model your volume there instead of trusting a comparison grid.

Use the same surfaces for every candidate on your shortlist — the point of the checklist is that you own the verdict, wherever it lands.

## 5. When not to move — FAQ

**Should we move off the incumbent?**
Not when the incumbent is winning on its own merits: a legacy aggregator contract priced below what a self-owned inventory would cost at your volume, whose integration is deep and whose replacement would burn a quarter of engineering time for no ownership gain, or a program trivial enough that ownership is not on the table. Run the checklist; if the ownership rows score "partial" on both sides, the move argument is weak.

**Do we have to give up the incumbent while we evaluate?**
No. Inventory, routing, and consent export are additive evaluation work: provision a sandbox key, run the checklist surfaces, and port a single number only after the scoring table confirms the ownership rows have moved.

## 6. Hub link back

This page is one entry of the [evaluating alternatives](/alternatives) catalog — return there for the other capability-class checklists scored on the same template.

## Related references

* [Numbers overview](/numbers/overview)
* [Inventory and export](/numbers/inventory-export)
* [Country capabilities](/numbers/country-capabilities)
* [Lookup](/numbers/lookup)
* [Number lifecycle](/numbers/lifecycle)
* [Number status map](/concepts/number-lifecycle)
* [Porting](/numbers/porting)
* [BYO carrier lifecycle](/concepts/byo-carrier-lifecycle)
* [Sender resolution](/concepts/sender-resolution)
* [Consent and suppression](/concepts/consent-and-suppression-model)