Skip to main content

​
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 whose verb contract is published and validated in your account, and a 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, 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. 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 and the provisioning and test-mode guide let you walk an end-to-end verb list — say, gather, dial, hangup — before provisioning anything. Start from the quickstart.
  • Feature docs as capability probes — the prompt catalogue row maps to the programmable-voice DSL page; the channel-selection row maps to the 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 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. This page is one entry of the evaluating alternatives catalog — return there for the other capability-class checklists scored on the same template.