Skip to main content

​
Settings → CSAT / Settings → NPS consoles

Two settings consoles govern how conversation sentiment is collected and acted on in Orbit: Settings → CSAT (satisfaction, scored 1–5) and Settings → NPS (loyalty, scored 0–10). They expose the org-level defaults that decide who gets surveyed, when, and what happens to a bad rating — while the per-conversation overrides (an operator’s close action, a queue’s survey disposition) narrow or narrow-in nothing unless you explicitly scope them. This guide is the operator-facing map of both consoles: what each card sets, where the value persists, and where you read the result once it lands. This page covers only the tenant-owned defaults for sentiment collection. Orbit does not add a platform-side gate over CSAT/NPS — your organization decides its own tenant quiet-hours, survey cadence, cooldown, and detractor policy; the platform never imposes a compliance guard over survey dispatch. (The one platform-global guard anywhere in the platform is the US federal voice-dialing window for outbound voice; it does not touch these pages.)

​
1. Two planes: the ops console vs the sentiment score

Understand the split before you change a single slider.
  • Ops plane — the day-to-day contact-center surfaces: incidents, SLA adherence, breach signals, queue load. Those live under the operations console family, not under Settings → CSAT/NPS.
  • Sentiment plane — the post-contact score your CSAT and NPS consoles configure: who gets a survey, how long after the close, whether the unhappy rating flips the conversation back open, and how long a contact is protected from repeat surveys.
The settings pages below occupy the sentiment plane only. Changing an SLA timer in the ops plane never touches your CSAT template, and changing the CSAT delay never changes your queue SLA — but the two planes read each other’s output: an insights sentiment rollup folds the scores your console dispatched into the same per-queue view an SLA timer is measured against, so a queue can at once carry good on-time adherence and a falling satisfaction score.

​
2. What each console configures

Open Settings → CSAT (owner or admin role). Every card persists into one organization settings block and is consumed by the close-triggered dispatch loop. Settings → NPS exposes the same knob set on its own page — an independent enable flag, template, delay, smart trigger, cooldown, conditions, and detractor-rescue band — so the two tracks carry separate cadences. What the NPS console does not duplicate: the intakes classify NPS against the NPS band you set here (0–6 default, slider allowed up to 9), never against the CSAT band. For the dispatch mechanics after a close — the exact arming sequence, the sweep cadence, the channel-pick order, and the quiet-hours hold — see Auto-CSAT/NPS dispatch. This page’s contribution is the settings surface itself.

​
3. Per-conversation / per-queue overrides vs the org-level default

The pages above set org-level defaults. A single conversation can deviate from the org default at close time; a single queue can not override the org CSAT/NPS config in its own settings page — there is no per-queue CSAT override surface in this console family. What is per-conversation:
  • The conditions list is the scoping mechanism — scope auto-dispatch to a channel, an assignee set, or a disposition taxonomy, and any conversation outside that scope silently skips. This is how you pilot CSAT on one queue or exclude a channel without touching the org-wide toggle.
  • An operator’s manual close action can always reopen a conversation by hand regardless of the detractor-rescue setting; rescue is the automatic version of that action.
  • A conversation that reopens and closes again re-arms the survey under the current org default, not under a frozen copy of the setting at first close.
The result: you tune the org default on these pages, and you narrow its reach with conditions — never by editing a queue’s own page. The scorecards below then group by queue or by agent so the org default is still sliced per queue when you read it, even though it was never configured per queue.

​
4. Read paths — where the configured values surface

Your CSAT/NPS configuration is not just a stored JSONB block — every dispatch and every answer it produces surfaces in three places:
  • Insights → Sentiment — the org’s sentiment rollup; the score history your dispatch delay, template, and conditions actually produce.
  • Insights → Account scores — the per-account rollup of CSAT and NPS over the interactions your console dispatched; this is where the accumulated score of a queue or a contact lands.
  • Insights → Sentiment → Anomalies — the anomaly surface over that same score stream; a falling-NPS queue or a sudden detractor spike shows here.
The answers also aggregate into the per-queue / per-agent scorecards over GET /api/v1/surveys/scorecards — rows bucketed by group_by=queue or group_by=agent, each reporting the response count, top-2-box satisfaction percentage, average score, CSAT-only average, and the NPS over NPS rows. The detractor-rescue threshold you set in the console is what the classification uses to decide whether a rating counts as a detractor: it directly drives the auto-reopen, and it is the same value the anomaly surface reads to call a queue’s detractor share unusual.

​
5. API hooks

Both consoles persist through the same org-settings pair the other settings pages use, plus the scorecards read:
group_by=queue|agent picks the bucket, survey_type=csat|nps|all restricts the rollup to one metric, queue_id / agent_user_id narrow to one bucket, and from / to bound the window. A bucket appears only once it has at least one answered response — sampled-off or unanswered sends never surface as zero-divide rows.

​
See also