Skip to main content

​
Evaluating alternatives

Readers choosing a vendor land on evaluation content before integration content. This hub is the organized entry point for every alternatives page in docs: each one scores the candidates on the same tenant-owned checklist, so you can compare pages to each other, not just vendors to vendors.

​
Why this hub exists

A decision-stage reader does not start with a quickstart; they start with “is this vendor ours?” Scattering that material across unrelated guides strands the reader. The hub exists so every alternatives page is one link away from every other, and the scoring format stays uniform as the catalog grows.

​
Evaluate in orbit yourself

A checklist narrows shortlists; the evaluation stage closes on surfaces you can touch. Run Devotel Orbit against the same axes you will score vendors on:
  • Sandbox API key — create a dv_test_sk_ key in the dashboard with no KYC or approval step. Sandbox sends are simulated and cost $0, so you can walk an end-to-end message or call flow before provisioning anything. Start from the quickstart.
  • Feature docs as capability probes — every checklist axis below maps to a section of these docs (numbers, compliance, channels, voice). If a capability matters to your decision, read the exact 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.
  • Support path — score response time and answers against the questions your shortlist raises. Vendor support during evaluation is the best sample of support after contract.
Use the same four surfaces for every candidate on your shortlist, not just this one — the point of the checklist is that you own the verdict, wherever it lands.

​
The tenant-owned checklist format

Every alternatives page scores the candidates on the same axes, so the field stays comparable across pages:
  • Number ownership — tenant-held inventory you can port, not a vendor-rented pool.
  • Attribution ownership — mapping and rollups resolved from objects in your own account. For the ad-attribution side specifically, the ads hub overview maps how Meta click-to-chat entry ads, lead-form ingestion, and per-ad ROAS roll up from objects in your account.
  • Consent posture — per-workspace consent controls you own, not a vendor policy.
  • Auditability — API export of configuration and assignments, not support tickets.
Keep the shape consistent across new pages; a reader who has done one checklist should be able to run the next without re-reading the format.

​
Page template — every alternatives page carries these sections

An alternatives page is a checklist, not a position paper. Every new page in this catalog carries the same six sections, in this order, so pages stay cross-comparable:
  1. Gaps buyers hit first — the failure modes that actually trigger the evaluation (porting a number pool out, an audit request the incumbent cannot answer), not a generic market intro.
  2. Tenant-owned checklist rows — the scoring rows for this capability class, phrased as facts a buyer can verify about any vendor. Example ownership row: “Number inventory lives in the tenant’s account and ports out with no vendor mediation.” Example auditability row: “Every configuration change that affects routing is retrievable through the API, without opening a support ticket.”
  3. Scored candidates table — the shortlist scored row-by-row against the checklist. Mark a cell “partial” or “no” rather than leaving it blank; empty cells read as missing research.
  4. Evaluation surfaces — the sandbox, docs, and pricing pointers above, re-anchored to this capability class.
  5. When not to move — FAQ — the incumbent-wins cases, in the same honest tone as the rest of the page.
  6. Hub link back — one line returning the reader here, so the catalog stays one hop away.
Two pages with the same structure are worth more than four with different ones: a buyer comparing two capability classes can overlay the checklists row-for-row.

​
The catalog

“Pending” rows are the catalog’s honesty about its own coverage — the marketing corpus already carries deep narrative for those classes, and the docs checklist lands there next.

​
Comparison pages on the marketing site

Narrative comparisons — pricing anecdotes, per-vendor position papers, per-archetype round-ups, and published vendor scoring — live in the marketing compare corpus, not in docs: The split is deliberate: docs checklists keep claims tenant-owned and verifiable by the buyer, while the marketing corpus is where compiled vendor rankings and the persuasive narrative live. The call-tracking evaluation parity table is the same checklist applied to its own shortlist — the two surfaces reinforce each other, one hop apart.

​
When not to migrate — the FAQ convention

Every alternatives page ends with a “when NOT to move” FAQ, not a CTA. The checklist exists so a vague “we should own this” feeling does not turn into a migration; keep the FAQ in the same tone — it tells the reader when the incumbent is right, which is what makes the rest of the page credible.