USSD is the one channel that reaches a subscriber with no data plan, on a 2G network, on a handset that cost under twenty dollars. That single fact decides where it belongs in an omnichannel stack: not as a legacy fallback, but as the entry channel for markets where smartphone penetration is uneven — West Africa, East Africa, parts of South and Southeast Asia. This guide maps USSD's place in a Devotel Orbit deployment: which buyer flows it carries, how its sessions fit alongside SMS and WhatsApp in one reporting surface, and where the candid trade-offs sit.
What USSD still solves
The channel's value has not declined; the set of problems it is the only answer to has narrowed. Today that set is:
- Zero-data reach. The GSM session channel works on 2G coverage and needs no data plan. Where IP coverage is the constraint — rural coverage maps, roaming subscribers, congested urban cells — USSD sessions get through.
- Feature-phone UX. A USSD menu is the only interactive experience a basic handset can render: numbered screens, keypad input, no app install. For a subscriber base still on feature phones, nothing else qualifies.
- Synchronous two-way session. Unlike SMS, USSD holds a live session open: every keypress round-trips your application and the next screen returns within the session. That gives it interactive-menu behaviour with SMS's universality.
A candid posture: USSD is not a growth channel for smartphone-first markets, and a long survey, rich content, or anything over ~160 characters per screen hands off to SMS or voice by design. The USSD channel documentation spells out the terminal-screen rules, navigation limits, and the ~182-character screen cap that force that design. Where the channel fits, it is the only fit.
Typical buyer flows
Three flow shapes dominate the deployments we see, and all three are live patterns on Orbit's session engine:
- Mobile money and balance checks. The canonical USSD use case. A subscriber dials a short code, picks
BalanceorTop upfrom a menu, and the answer returns in-session. These menus are shallow by design — two or three branches deep, terminal screens delivering the answer. - Session-based IVR replacement. In markets where call-centre IVR is expensive to terminate and feature phones are the subscriber base, a USSD menu takes the self-service IVR role: account status, order tracking, branch hours. The subscriber avoids a call; the business avoids the voice leg.
- Network-initiated push. Orbit also supports the inverse direction: your application opens a USSD session on the subscriber's handset for balance prompts, mobile-money confirmations, and feature-phone OTP. Push sessions run through your own aggregator endpoint, configured per tenant.
All three share one property that shapes how you build: the USSD menu is a tree of screens with numbered options, and the session ends on a terminal screen. Orbit models it as exactly that — a menu tree with a root, navigable nodes, and CON/END replies — so the flow you sketch on paper maps directly onto the object you configure.
How USSD sessions map to Orbit flows and analytics
The omnichannel argument for USSD is a reporting one: the channel is worth adding only if its sessions land on the same analytics surface as your SMS and WhatsApp traffic, not in a second dashboard.
- Same tenant, same API key. USSD callbacks arrive on a tenant-scoped webhook, and every step is tagged with a request id inside the same workspace as your messaging channels. There is no parallel platform to reconcile.
- Same graph discipline as other channels. If you already keep flows for SMS or voice in the Flows API, the USSD menu tree is the same branch-and-navigate graph thinking applied to a keypad-driven tree, configured as one purpose-fit object.
- One contact, one history. A subscriber's balance-check menu sits on the same contact record as their SMS conversations, so channel analytics and the contact history converge instead of fragmenting by channel.
The result: sessions are cheap for the carrier and survive roaming where IP does not, and the reporting spine stays unified. The flow-builder guide walks the tree end to end — including the sandbox numbers that test any follow-up SMS, email, or voice confirmation a menu branch triggers.
Frequently asked questions
When should I choose USSD over SMS?
Choose USSD when the subscriber needs a menu of a few choices inside a live session, on a network where SMS delivery is fine but data is not. USSD holds the session open, so each keypress gets an immediate next-screen response; SMS is better for one-way notifications or longer content where session cost is not worth paying.
Does Orbit handle the mobile-operator shortcode?
No — the shortcode belongs to a mobile network operator or a USSD aggregator (Africa's Talking, Infobip, or a regional equivalent). You provision the code with your aggregator, then point its session callback at Orbit's tenant-scoped webhook. Orbit resolves each step of the session; the aggregator bills the session minutes separately.
Can a USSD session hand off to another channel?
Yes, and it is the recommended pattern for anything beyond a few menu choices. A terminal USSD screen can trigger a follow-up SMS, email, or voice confirmation — the follow-up leg runs over your normal channel configuration, and sandbox numbers let you test that handoff deterministically before going live.
Is USSD still worth adding if my market is mostly smartphones?
Usually no. USSD earns its place when the subscriber base still includes feature phones or no-data coverage — typical in West and East African deployments and parts of South and Southeast Asia. In a smartphone-first market, RCS, WhatsApp, or an app will serve the interactive use case better.
How is USSD usage billed?
Orbit charges a flat per-1M platform fee for USSD session callbacks; your aggregator bills the underlying session minutes separately. The pricing page has the current rate.