> ## 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 voice-routing DSL ownership

> A tenant-owned scoring rubric for voice-routing DSL ownership (vendor-owned DSL, vendor-free DSL, Devotel Orbit's programmable voice DSL): the checklist rows, a worked scoring table, evaluation surfaces, and the FAQ on when not to move.

# Evaluating voice-routing DSL ownership

Voice-routing evaluations come down to one question: who owns the dial plan — you, or the vendor's support queue. A programmable voice DSL is the JSON verb list that decides what happens to a call the moment it lands, and the score that matters is whether the prompt catalogue, the digit-collection discipline, and the routing policy are objects you read and edit, or a file maintained behind a ticket. This page gives you the checklist, a worked scoring table across the three ownership models, the surfaces to run the evaluation on, and an FAQ for deciding when the incumbent should stay.

## 1. Route-numbering decision opener

The first routing decision a voice platform makes is which number routes to which flow. Buyers hit this opening gap the same way on every vendor: the dial plan exists, but nobody in the account can read it, so a numbering change means a vendor change order instead of a tenant edit. Score that decision layer first — every checklist row below hangs off it.

* **Unreadable dial plan.** The routing from number to flow lives in the vendor's scaffolding, so a prompt change, a menu re-map, or a fallback rewrite goes through a support ticket. Score whether the full route-from-DID-to-verb-list is exportable through the vendor's own API.
* **Non-standard prompts.** Digit prompts, menu maps, and collected-input handling differ per vendor because each encodes its own voice primitives. Score whether DTMF prompt standardization — a `gather` collecting digits with a defined `numDigits` count and a defined `finishOnKey` behaviour — is a published primitive you can verify, not a vendor-internal convention.
* **Opaque channel and route selection.** The vendor treats routing as its own layer, so a dry-run of which channel or route a send takes is unavailable. Score whether the vendor publishes a route-preview surface that pre-flights the path before the call goes out.

Devotel Orbit closes these with tenant-owned surfaces: a [programmable-voice DSL](/reference/programmable-voice-dsl) whose verb contract is published and validated in your account, and a [route-preview](/outbound/route-preview) tab that shows the channel, reason, fallback chain, and cost estimate a send will follow before it goes out.

## 2. Tenant-owned checklist rows

Score every candidate on four rows you can verify about any vendor:

* **Standardised prompt and digit catalogue.** Prompt playback, digit collection, and menu branching are published DSL verbs with a defined contract — in Orbit's [programmable-voice DSL](/reference/programmable-voice-dsl), the `say` verb speaks the prompt, the `gather` verb collects DTMF with explicit `input`, `numDigits`, `timeout`, and an `actionHook` for the next step, and `play` streams a recorded file from a `https://` URL. A vendor whose prompt handling is console-internal scores partial; a vendor with no published verb contract scores no.
* **Channel selection.** The outbound termination choice is explicit, documented, and not a field you return hoping it sticks. In Orbit's DSL every `dial` and `transfer` terminates on Devotel's wholesale softswitch — carrier-selection fields are ignored by design, so the channel you get is the channel the docs name. A vendor whose channel selection is ambiguous between tenant and vendor scores partial.
* **Rate-limiting discipline.** The inbound webhook and the per-day verification probes the DSL fires stay inside the vendor's published limits, and the limits are the tenant's own quotas, not an account-wide vendor knob. A vendor whose rate limits are negotiated by contract scores partial.
* **Per-day gotchas vs ownership trade.** Every-checklist ownership only matters if the per-day edge cases — fallback on a malformed verb list, reserved verbs the vendor manages, recording-consent gates — are published with the contract. Orbit publishes its fallback ladder (safe-default, voicemail, decline), its two reserved verbs (`conference`, `config`), and where the recording-consent obligation sits (on your `record` verb). A vendor whose edge cases are tribal knowledge scores no.

## 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 | Vendor-owned DSL (incumbent) | Vendor-free DSL (generic open standard) | Devotel Orbit programmable-voice DSL |
| - | - | - | - |
| Standardised prompt and digit catalogue | partial — prompt handling exists but the contract is console-internal | partial — the standard exists, but per-day validation is yours | yes — `say`/`gather`/`play` verbs published with `numDigits` and `finishOnKey` semantics |
| Channel selection | no — routing is the vendor's own layer | partial — routing works, but termination choice drifts across providers | yes — `dial` and `transfer` terminate on the Devotel softswitch; carrier fields are ignored by design |
| Rate-limiting discipline | partial — limits are a contract line | partial — limits are whatever you negotiate per provider | yes — tenant-owned quotas on your own account |
| Per-day gotchas vs ownership trade | no — edge cases are tribal knowledge | partial — the standard is silent on fallback and reserved verbs | yes — fallback ladder, reserved verbs, and consent gates published |

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. The [sandbox overview](/sandbox/overview) and the [provisioning and test-mode guide](/concepts/provisioning-and-test-mode) let you walk an end-to-end verb list — say, gather, dial, hangup — before provisioning anything. Start from the [quickstart](/quickstart).
* **Feature docs as capability probes** — the prompt catalogue row maps to the [programmable-voice DSL](/reference/programmable-voice-dsl) page; the channel-selection row maps to the [route-preview](/outbound/route-preview) tab in the dashboard; the consent row maps to the DSL's own recording-consent note. 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 call-minute 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 call flow whose prompt and menu map are one-deep and never re-touched, a legacy contract priced below what re-owning the dial plan would cost at your volume, or a program trivial enough that reading the routing policy never crosses a compliance desk. Run the checklist; if the ownership rows score "partial" on both sides, the move argument is weak.

**Do we have to abandon the incumbent while we evaluate?**
No. The DSL surface is additive evaluation work: provision a sandbox key, return a verb list from your own answer URL, run the fallback ladder once, and only then decide whether the incumbent's tribal edge cases are worth keeping.

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

* [Programmable Voice DSL](/reference/programmable-voice-dsl)
* [Voice channel](/channels/voice)
* [Quickstart](/quickstart)
* [Sandbox overview](/sandbox/overview)
* [Provisioning and test mode](/concepts/provisioning-and-test-mode)
* [Pricing](https://orbit.devotel.io/pricing)