Skip to main content

​
Evaluating call-tracking alternatives

Call-tracking evaluations come down to one question: who owns the attribution pipeline. This page gives you the checklist that separates a rented vendor pool from tenant-held DIDs, a weighted scoring rubric with a worked example for CallRail, Invoca, and Devotel Orbit, the workflow to run the evaluation end to end, and an FAQ for deciding when a move is not worth making.

​
1. The gaps buyers hit first

  • Self-serve numbers. Can you provision inbound DIDs per source and campaign yourself, from your own account, without a vendor ticket?
  • Insights dashboards. Does per-source call attribution live in the same account as your SMS, voice, and agent analytics, or in a separate silo?
  • Org-owned attribution ladders. Can you show an auditor how each number maps to its source, with a consent record, using objects in the organization’s own account?
Orbit closes these gaps with three tenant-owned surfaces: the coverage catalog for self-serve inbound DIDs (Buy numbers), the Call tracking & DNI guide for pools and attribution, and the Compliance surfaces for consent and quiet-hours gates.

​
2. The scoring rubric

Score every candidate on the shortlist (CallRail, Invoca, Orbit, or the rest) on six weighted rows. A seller passes a row when the answer is “in your account,” not “behind our dashboard.” Score scale — 0 to 2 per row:
  • 2 — tenant-owned. The capability lives in the organization’s own account as objects you can export (pool configuration, DID assignments, consent records).
  • 1 — partial. The capability exists but export or custody is negotiated — delivered through a vendor report, an add-on, or a support flow rather than a self-serve API.
  • 0 — behind the vendor dashboard. The capability is a screen only the vendor controls; you cannot extract it without a support ticket.
Suggested weights (sum to 100; adjust to your audit exposure before you run the evaluation — the worked example below uses these defaults): Decision rule:
  • Monthly weighted score under 60 — hold the incumbent. Below that line the ownership case usually does not pay for the migration on its own; see the when-not-to-move FAQ.
  • 60–80 — run the parallel pilot. Section 4’s workflow; the checklist tells you what must move, and the pilot proves attribution parity before cutover.
  • Over 80 — the ownership argument carries the program. Plan the cutover with the incumbent still live as the fallback.
Weighted score = sum of (row score × row weight) across the six rows; the maximum is 200. Normalize it to a 0–100 score by dividing by two.

​
3. Tenant-owned checklist

The six rows, with the question that separates a 2 from a 0:
  • Number ownership (25). Tenant-held inbound DIDs you can port, not a vendor-rented pool.
  • Source mapping (20). Pool configuration in the organization’s own account, exportable, not a vendor-side setting.
  • Read-side attribution (15). Rollups resolved from tenant objects at read time, not baked vendor reports.
  • Consent posture (15). Per-pool tenant-controlled recording consent, not vendor policy.
  • Channel adjacency (15). Tracking pools on the same account as the numbers and voice they attribute, not separate procurement per channel.
  • Auditability (10). API export of pool configuration and assignments, not support tickets.

​
4. Worked example: CallRail vs Invoca vs Orbit

The same rubric applied to a typical three-vendor shortlist, using the public feature sets of each seller. Cells answer the page’s pass criterion — “in your account” versus “behind our dashboard” — at the level of the published product surface; your own account audit may move a cell up or down. Read the table as a starting hypothesis, not a verdict: re-score the rows against a live trial of each candidate with the workflow below, and write your own evidence into the auditor checklist in section 6.

​
5. Evaluation workflow

Run the checklist as a five-step evaluation, with the incumbent untouched until the last step:
  1. Export the incumbent’s number inventory. Pull every tracking number in the current tool, the source or campaign each one maps to, and the monthly call volume per number. This list is the scope of the migration — and the bill of DID inventory to price.
  2. Map sources before you buy a single DID. Write the pool per source first: name, source, campaign, and the match rules (UTM parameters, referrer, gclid) that decide which visitors see its numbers. The Call tracking & DNI guide covers pool configuration; quotas and catch-all behavior are in Tracking pools & DNI.
  3. Compare attribution read-side. Run both systems against the same call window: the incumbent’s report versus Orbit’s GET /insights/call-attribution (or Insights → Call attribution in the dashboard). Because Orbit’s join is read-time, re-assigning a DID re-attributes its historical calls — confirm the incumbent report and the Orbit rollup agree on source-level call counts before you trust the new mapping.
  4. Run a parallel pilot. Provision tenant-held DIDs for one source, run the pool alongside the incumbent pool on the same campaign, and swap a slice of traffic through the DNI snippet. Keep volumes small enough that a wrong match rule costs a week of attribution, not a quarter.
  5. Cut over only what scored. Retire an incumbent pool when its replacement’s checklist rows read “in your account” and the read-side comparison in step 3 matched. Keep any row that scored 0 or 1 — for example a static main-line pool — on the incumbent without guilt; the FAQ below is why.

​
6. Sellers of call tracking vs Orbit: parity and divergence

​
7. Adoption playbook

Follow the Call tracking & DNI guide end to end: create one pool per source, assign tenant-held DIDs, wire the DNI resolve snippet on your site, set per-pool consent posture, and verify the attribution read under Insights against a test call per DID. Constraints and quotas are in the Tracking pools & DNI guide.

​
8. Evidence checklist for auditors

When chain-of-custody is the reason for the move, collect this evidence from the organization’s own account — not from vendor screenshots:
  • Org-owned DID inventory. The list of tenant-held inbound numbers with their purchase records — provisioned from the coverage catalog per Buy numbers.
  • Pool configuration export. Every tracking pool with its source, campaign, match rules, and DID assignments, pulled via the API — the Call tracking & DNI guide covers both the export calls and the assignment rules.
  • Consent records. Per-pool recording-consent posture with revision history — Recording consent and Consent management.
  • Quiet-hours gates. The tenant-configured quiet-hours policy that governs time-of-day treatment — Quiet hours preview and the opt-out and suppression surfaces.
  • Attribution drill-down. The read-side attribution export (GET /insights/call-attribution) that re-joins DID → pool → source from live tenant objects, so the ladder an auditor follows resolves from your account, not a vendor’s archive.

​
9. When NOT to move (FAQ)

Should we move away from CallRail or Invoca? Not if the program is small and static, marketing is the only consumer, the rented pool’s contract beats the cost of a DID inventory at your volume, or no audit will ever ask for chain-of-custody. Run the rubric above; a weighted score under 60 is the checklist telling you the ownership case does not pay for the migration. Do we have to give up the incumbent tool while we evaluate? No. Tracking pools are additive: provision tenant-held DIDs, run the parallel pilot in section 5 alongside the incumbent, and retire the old pool only if the scoring table confirms ownership has moved.