A voice-of-customer (VoC) survey answers one question — how satisfied is this customer right now — with a short, scored prompt. The classic NPS "how likely are you to recommend us, 0–10?", a CSAT satisfaction rating, or a CES effort score. On Devotel Orbit, surveys run as a first-class capability: you design the survey, define the audience, and send it over SMS, WhatsApp, email, Viber, RCS, or push — with localization, frequency caps, and analytics built in. This explainer walks through what the surveys surface actually does and where each control lives.
Why own-channel surveys beat email for response rates
Email surveys arrive in a crowded inbox hours after an interaction. SMS and WhatsApp reach the lock screen within seconds, with open rates routinely above 90%, and the reply is one tap or one digit. When the survey rides the same channel you already use to message the customer, the survey becomes a continuation of the conversation rather than a separate program. On Orbit, a survey piggybacks on the exact same provider-signed, opt-out-aware, billed send path as every other outbound message — so a survey over SMS or WhatsApp IS a message, not a parallel silo.
Dispatch across SMS, WhatsApp, push, and friends
A survey defines the channels it supports (up to six of: sms, whatsapp, email, viber, rcs, push). You then trigger a send over one of those channels, addressing a single contact, a segment, or a list of contact IDs.
Push is special: instead of a phone number, the notification fans out to each of the contact's registered devices, and tapping it lands on a signed survey page — the same tap-through path the email channel uses. The other channels mint a per-recipient reply token so inbound answers ("8") map back to a specific survey attempt.
Two triggering modes exist:
- Batch send — the
POST /surveys/:id/sendcontroller resolves a whole audience, applies the frequency-cap partition, pre-creates all response records in one insert, and dispatches them. - Flow-driven single send — an automation node (post-interaction, lifecycle event, scheduled program) sends one survey to one contact, honoring the same dedupe and fatigue rules, so single-send and batch-send behave identically.
Every skip reason (unsupported channel, no reachable recipient, recent same survey, fatigued, failed send) is returned as a structured result rather than throwing — a flow keeps routing to its next step either way.
Localization — one survey, many languages
You can attach per-locale variants to a survey, up to fifty languages. Each variant overrides the question text, follow-up prompt, and per-question copy. At send time, each recipient's contact language resolves the best-matching variant:
- Exact tag match (case-insensitive,
pt_BRandpt-BRtreated the same), - Primary subtag match (
pt-PTfalls back to aptvariant), - The survey's default locale,
- The base copy — always the fallback, so an untranslated recipient still receives a survey.
A bilingual example: define the survey with English base copy and a fr-CA variant whose question reads "Comment évaluez-vous votre expérience ?". A recipient whose language is fr-CA gets the French question; a recipient with no matching variant gets the English base copy. The send-time and public form paths resolve locales identically, so the recipient sees the same language whether they answer from a message or a web page.
Frequency caps — a tenant-owned control
The one thing that ruins VoC data is over-surveying. Orbit separates frequency governance into two layers, both of which YOU control:
- Same-survey dedupe (24h, fixed) — a contact sent this same survey in the last 24 hours is skipped. This is a flat safety floor every send inherits.
- Cross-survey fatigue (configurable) — a contact sent ANY survey within a configurable window is skipped, so concurrent NPS, CSAT, and CES programs don't gang up on the same person. The default window is 72 hours; you can override it per send, extend it up to a year, or set it to 0 to disable cross-survey capping entirely.
Both layers return structured results (eligible, skippedRecent, skippedFatigue) so you can report back exactly which contacts were rested and why. This is the compliance posture too: Orbit never imposes a platform-mandated survey cadence on you. The control is tenant-owned, and the defaults are open.
Analytics: CSAT/NPS/CES scores with benchmarks
Results roll up per survey — your response count and average score. On top of that, the VoC analytics view classifies free-text comments with a deterministic lexicon (the same thresholds the conversation-sentiment surface uses, so a negative comment here is a negative comment there), extracts recurring themes and per-theme driver analysis, and builds a time-series trend.
A raw score tells you WHAT; benchmarks tell you HOW GOOD. The benchmark library holds published cross-industry CX distributions (Retently / Qualtrics / ACSI-class) for NPS, CSAT, and CES across verticals — SaaS, e-commerce, retail, financial services, insurance, telecom, healthcare, hospitality, education, or cross-industry. Given your measured score it returns an interpolated percentile rank, a quartile rating, and a signed delta versus the industry median: "your NPS of 42 sits in the top quartile for SaaS — about the 68th percentile, 6 points above the industry median of 36."
NPS benchmarks on the native −100…100 scale; CSAT and CES benchmark on a 0–10 average-score scale where higher is better (for CES, higher means lower effort under Orbit's scoring convention).
Response trait mapping — surveys feed the CDP
A survey score should not live and die in an analytics chart. When the first scored response arrives, two side effects fire:
- Trait writeback — merges
nps_score(orcsat_score/ces_score), anis_detractorflag, plussurvey_last_scoreandsurvey_last_responded_atinto the contact's attributes, so segment builders and computed-traits can reference them. - CDP event — a
survey_respondedtrack event lands on the per-tenant event bus, so a journey trigger can enroll the contact within about a second — for example, "enrol every detractor into a win-back flow."
Both are deliberately best-effort and never block the response submission: a contact whose message provider hiccups still has their score recorded.
What to take away
Surveys are one more channel on the same customer record. Send them over the channel the customer already answers, keep the frequency caps set (they are tenant-owned by design), read the score against an industry benchmark rather than in a vacuum, and let the response write back to the profile so the NEXT message a detractor receives is a targeted one, not another generic NPS.