Quick answer: An outbound program that cannot prove which calls produced which outcomes is flying on gut feel. Devotel Orbit closes that loop with two surfaces most buyers never see in a demo: Goals & attribution (/outbound/goals), where a conversion goal plus a chosen attribution model turns delivered, answered, and converted into per-campaign ROI — and Route preview (/outbound/route-preview), which shows the path a message or call will take before you commit a send. Underneath both is answered-number provenance — the answer to "whose number did this call come from, and can we prove it?" — which is why the voice-broadcast wizard treats implicit caller ID as a footgun and STIR/SHAKEN attestation as the layer that cryptographically backs the provenance claim.
This is the buyer-facing walkthrough. It connects four things that usually get explained in isolation — goals, attribution models, route pre-flight, and caller-ID provenance — into the single narrative your outbound dashboard already ships.
Why provenance matters in outbound voice
Every outbound call carries an implicit claim: "I am who my caller ID says I am." When that claim is unverifiable, the recipient's carrier makes the decision for you — and the decision is a "Spam Likely" label. Provenance is the discipline of making the claim provable at every hop.
In Orbit, provenance is not a marketing word. It answers three concrete questions for every call in a broadcast:
- Which of your numbers originated it? A guaranteed trace to a DID your org owns, leases, or has registered via a delegate certificate.
- Which campaign drove it? The broadcast or journey the call belongs to, so answered-versus-converted math lands on the right row.
- Who signed the identity? The STIR/SHAKEN attestation level (A, B, or C) Devotel's wholesale softswitch signs at, computed from Orbit's ownership records.
A program that can answer all three can defend its answer rates. A program that cannot is one bad carrier-analytics sweep away from being classified as robocall traffic.
Where goals and attribution live
The surface is Outbound > Goals & attribution (/outbound/goals). The same module backs the analytics-first view at Insights > Goals, so operators who think of goals as "analytics" and operators who think of them as "outbound" land on the same definitions either way — no duplicated surface, no drift.
A goal in Orbit is simple: a named conversion event — a page visit, a tag applied, a webhook hit, a manual flag, a custom event — optionally carrying a monetary value. What turns it into attribution is the model you attach to it. Four models ship, and the choice is yours per goal:
| Model | Behavior | When it answers your question |
|---|---|---|
| Last touch | 100% of the credit goes to the final touchpoint before conversion | "Which campaign closes?" — the outbound dialer's natural question |
| First touch | 100% of the credit goes to the first touchpoint | "Which audience source fills the funnel?" — the acquisition question |
| Linear | Credit splits evenly across every touchpoint | "What's the true cost of the whole journey?" — the blended view |
| Time decay | Recent touchpoints weigh more than older ones | "Which touches matter most in long cycles?" — the nurture question |
The read is where the value lands: each goal renders a funnel (reached → delivered → engaged → converted) and a per-model attribution breakdown, so the same campaign answers "how many?" and "which effort earned it?" from one row. Attach a value to the goal and the breakdown becomes revenue attribution — the difference between "we made calls" and "this campaign returned 4.2x its dial cost."
Route preview — pre-flight the path a call takes
Goals tell you what happened after the fact. Route preview (/outbound/route-preview) is the pre-flight check — the surface that answers "what route will this send actually take?" before it goes out.
Give the preview a recipient, a message type, and an urgency, and Orbit's smart router returns the recommendation it would commit to: the channel it picks (SMS, WhatsApp, RCS, email, voice), the reason it picked it, the ordered fallback chain if the primary route degrades, a per-tenant cost estimate, and a predicted engagement score. The mechanics are deliberately honest:
- The recommendation reasons are shown, not hidden. When the router picks WhatsApp over SMS for a transactional send, the reason caption says so — "channel available + cost-optimize bias" — rather than presenting a verdict with no rationale.
- The fallback chain is ordered and visible. If RCS is unavailable for a recipient, you see the exact downgrade sequence (RCS → SMS, or however your flags resolve) instead of discovering it at delivery time.
- Cost and engagement are estimates you can plan against. The per-unit cost uses your tenant's actual billing posture; the engagement score gives a directional read, not a promise.
- Edge cases render, not crash. A recipient with every channel flag off returns the router's documented default with its diagnostic reason rendered verbatim — the page is built to explain, never to swallow an error.
Why a standalone surface rather than a widget in every compose dialog: the recommendation math is dense, and the 95% of sends where the operator already knows the channel should not pay for it in clutter. Route preview is the planning tool you reach for when the routing decision is the question — validating a cost-optimize toggle, sanity-checking a new country, or proving the fallback chain does what you told compliance it does.
Answered-number provenance in the broadcast wizard
The place where provenance bites hardest is the voice-broadcast wizard, and the wizard is deliberately opinionated about it. When you step through the broadcast creator, the caller-ID picker is an explicit, required choice — the wizard does not silently inherit whichever DID the platform happens to find first. The reasoning is blunt: operators with multiple voice DIDs control which number every broadcast call appears to originate from, and leaving that choice implicit makes the broadcast indistinguishable from every other outbound stream your account runs.
That "indistinguishable" failure is the provenance failure. When the originating number is implicit:
- The branded-call display your recipients' carriers render has no stable identity to attach to, so the registration effort flatlines.
- Your own attribution math blurs — answered and converted fold into the same bucket as every other campaign sharing the accidental number.
- The audit trail you would hand a carrier, an auditor, or your own compliance review cannot tie a specific call to a deliberate origination decision, because there wasn't one.
Explicit caller ID converts all three: the broadcast is identity-stable, attribution lands on the right campaign, and the call trace reads as "org chose DID X for campaign Y" instead of "org's calls emerge from a pool." For a broadcast of any real size, that is not a nicety — it is the difference between a program that can defend its outbound and one that cannot.
STIR/SHAKEN attestation layering on top
The caller-ID choice names the number. STIR/SHAKEN attestation is the layer that proves the number is yours to use, and it is layered, not binary, in Orbit:
- Owned numbers attest at A (full). A DID your org purchased or ported into Orbit is provider-verified by construction — the long pole every other step leans on.
- Leased pool numbers and delegate certificates cap at B (partial). Legitimate remediation where ownership genuinely is not possible — deliberately never A, so a self-registered certificate cannot launder full attestation.
- Anything else falls to C (gateway). The traffic "Spam Likely" labels are built from.
The tenant-owned controls around it — the target attestation level, how below-target numbers are flagged, and the inbound verification floor — are settable posture knobs, not gates: they make the gap visible and measurable. Underneath, Devotel's wholesale softswitch signs at exactly the level Orbit attests; it never signs higher, and no policy PUT moves the level for you. The full mechanics, policy fields, and the playbook for raising A-attested share are in the STIR/SHAKEN attestation guide.
Frequently asked questions
What is the difference between goals and attribution in Outbound?
A goal is the definition of a conversion — the named event you count as success. Attribution is the model that decides which of your touches earns credit for that conversion. You set the goal first (what counts), then pick the model (who gets the credit), and the dashboard reads both as one funnel with an attribution breakdown.
Which attribution model should an outbound voice campaign use?
Last touch is the working default for voice: the dial is usually the closing touchpoint on a call-centric funnel, so credit lands where the outcome actually happened. Reach for time decay when your sales cycle spans multiple touches and the recent ones carry the conversion, linear when finance wants a fair split across a blended journey, and first touch when the question is which source seeded the contact, not which closed it.
Does route preview change where my message goes, or only report it?
It only reports. Route preview calls the same smart-router recommendation your send would commit to — the same channel, reason, fallback chain, cost estimate, and engagement read — and returns it without placing any traffic. Use it to validate routing decisions before a send, not to steer one after the fact.
Why does the broadcast wizard force an explicit caller ID instead of picking one for me?
Because the choice is the provenance. A broadcast whose originating number the platform guessed is indistinguishable from any other outbound your account runs — branded-call display has no stable identity to attach to, and your attribution cannot separate this campaign's answers from the pool's. An explicit pick ties the broadcast to a deliberate origination decision your audit trail can point at.
Can I raise my STIR/SHAKEN attestation level from a setting in the dashboard?
No — and that ceiling is deliberate. Attestation level is computed from ownership: owned DIDs reach A, leased and delegate-certificate numbers cap at B, everything else is C. The attestation policy knobs (target level, downgrade handling, inbound floor) are reporting and intent, not a gate — they surface the gap, they do not close it. The only move that raises a number to A is owning it through Orbit; the full playbook is in the attestation guide linked above.
Does any of this block or gate an outbound send?
No. Route preview is read-only; goals and attribution are post-hoc reporting; caller-ID choice is a wizard decision; attestation reporting is posture, not a dial-time gate. Every control here is one you own, and none of them interpose on a send — they exist to make outcomes attributable and provenance provable, not to stand between you and the dial.
The takeaway
An outbound program earns the right to report ROI when it can do three things in sequence: pre-flight the route (route preview), originate from a provable identity (explicit caller ID plus STIR/SHAKEN), and close the loop on outcome (a goal with an attribution model attached). Orbit ships all three in the outbound surface today — the gap is almost never capability, it is the narrative that ties them into one program. Run them together and "we made calls" turns into "this campaign, from this number, signed at this level, returned this multiple."