Many one-off outbound sends — a payment reminder, a reschedule notice, a document request — start the same way: you open the contact list, pick a person, and hit send. If your picker decides the channel for you, the decision is invisible at exactly the moment it matters. Direct Send on Devotel Orbit makes that decision explicit. This guide walks through the problem it solves, the shipped behavior, a channel decision matrix, and a worked example you can try on your own contacts.
The problem: pickers that silently route to one channel
A contact record often carries more than one reachable identifier — a phone number and an email address, sometimes more. Older contact pickers (in Orbit and in most CRM-style send surfaces) looked at that row, picked the first identifier, and committed to the matching channel without asking. If a phone number was present, the message went out as SMS even when email was the right choice — and the picker never showed the email address it was ignoring.
Two things go wrong when that happens. First, cost: SMS is priced per message and the billable segment count adds up, while an email to the same person costs a fraction of that. Second, consent: your recipient's opt-in and opt-out posture is per-channel — someone who consented to service emails but not to SMS marketing gets a texting-through message when the picker auto-routes. Neither failure is visible at send time, which is exactly why the routing should never be silent.
The shipped answer: every reachable identifier, an explicit choice
Outbound → Direct Send (in the dashboard, under Outbound → Direct send) is Orbit's one-off send surface: send to a CSV list, or pick a single contact. When you pick a single contact, the picker now lists every reachable identifier the contact record holds — phone and email both shown — and, when more than one channel is reachable, presents an explicit channel selector alongside the identifiers before you can continue.
The default pre-selection still exists (a phone-first order keeps the common case one click), but it is a pre-selection, not a commitment: you see the reachable set and confirm or change it before the send. Contacts with no reachable identifier are visibly disabled rather than silently skipped. For reachability across channels more broadly, the omnichannel channel-selection matrix is the wider buyer-level view; the channel fallback matrix covers what happens when a chosen channel cannot deliver.
The pick-the-channel decision matrix
Direct Send routes to the channels whose composers accept a recipient prefill. The current reachable set, in pre-selection order:
| Reachable identifier | Channel | Notes |
|---|---|---|
| Phone number | SMS | Pre-selected first when present |
| Email address | Selectable as an explicit override |
WhatsApp is deliberately absent from the selector. Business-initiated WhatsApp sends have to ride an approved template through the WhatsApp Business channel composer, which owns its own recipient entry — a generic recipient prefill would bypass the template step, so the picker does not offer it (the channel-shortcut row on the Direct Send page jumps straight to the WhatsApp composer when that is the channel you want). The decision matrix in practice: SMS when delivery speed and phone-first reach dominate, Email when the content is long, the cost matters, or consent sits on email, and WhatsApp only via its own composer path.
Why the explicit selector matters
The earlier version of this picker collapsed every contact to one channel and hid the rest. That was a real defect, not a style choice: operators routinely sent SMS to contacts whose deliverable channel was email, and payment-reminder traffic landed on a per-message-priced channel by accident. An explicit selector fixes the cost side (the cheaper channel is one click away) and the consent side (the choice is deliberate and auditable, and per-channel opt-out checks run on the channel you actually picked). It is the same principle the fallback matrix applies to chains: routing decisions you cannot see are routing decisions you cannot govern.
A worked example: a payment reminder over email, not SMS
Say you run monthly payment reminders and a customer's record carries both a phone number and an email. The old behavior sends the reminder as SMS to the phone every time. Here is the explicit flow on Direct Send:
- Open Outbound → Direct send and choose Send to one contact.
- Search the contact. The result row shows both identifiers (
+1 415 … · name@example.com), so you can see the reachable set before you pick. - Select the contact. The channel selector lists SMS and Email with the identifier each will send to.
- Choose Email — the reminder text is long, the link to the invoice renders readably, and the channel cost is a fraction of an SMS.
- Confirm. The email composer opens with the recipient prefilled and the contact attached; the send is charged and logged as email.
If the contact had only a phone number, the picker would show a single-channel "Sending via" line instead of a choice — the routing stays visible even when there is nothing to decide.
Related guides
- Omnichannel channel-selection matrix — the strategic sibling: which channel opens which use case.
- Channel fallback capability matrix — what happens when the channel you picked cannot deliver.
- Loyalty, referrals, and the outbound capability overview — where Direct Send sits in the full outbound surface.