Auto-NPS console (Settings → NPS)

Auto-NPS is its own console at Settings → NPS, not a sub-tab of Settings → CSAT. This guide covers that page: why the NPS track is configured separately, what each control decides, the exact auto_nps settings block the page reads and writes, and where the answers land once they come in.

1. Why NPS gets its own console

CSAT and NPS measure different things on different scales — CSAT scores 1–5 satisfaction, NPS scores 0–10 loyalty — so the platform treats them as two independent tracks:

Own enable flag — you can pause NPS without touching CSAT, or run both.
Own template slot — a close can arm an NPS survey and a CSAT survey in parallel; a single shared slot could only fire one.
Own dispatch trigger — the NPS dispatcher polls closes stamped for NPS and sends after the NPS-specific delay, not the CSAT one.
Own detractor bands and reporting — NPS answers classify against the 0–6 detractor band and roll up under the NPS columns of the scorecards, never under CSAT.

Running both tracks at once is supported, and one throttling rule spans the two: the per-contact cooldown counts a survey answered on either track, so a contact who got yesterday’s NPS is protected from today’s CSAT.

2. Prerequisites

You need an NPS-ready survey template before this console can fire anything — the picker lists your existing templates, and until one is selected every close skips the NPS arm silently. Author the template first with POST /api/v1/surveys (type nps, csat, or ces all show up in the picker; NPS is the intended type here) as covered in surveys end to end. An empty template space is the one configuration mistake that produces an orphan console: the page saves fine, nothing dispatches.

3. Where it lives

Open Settings → NPS in the dashboard (owner or admin role). Everything on the page persists to one organization settings block (auto_nps), consumed by the close path when a conversation closes and by the one-per-minute dispatch sweep.

4. The `auto_nps` settings block

The console reads and writes a single auto_nps object under GET/PUT /api/v1/settings/general (see the settings API reference). The full block, with each field’s write-boundary rule:

Field	Type	Rule	Default
`enabled`	boolean	Master toggle. `false` pauses NPS without losing the rest of the block. Absent ⇒ treated as `true`.	`true`
`template_id`	string (UUID)	Survey row to dispatch. `null` ⇒ every close skips the NPS arm.	`null`
`delay_minutes`	integer	Minutes from close to send. Clamped to 1–1440 on save.	`5`
`smart_trigger`	boolean	On ⇒ skip negative-sentiment conversations and contacts inside the cooldown window. Absent ⇒ treated as `true`.	`true`
`cooldown_days`	integer	Per-contact fatigue window, counted across every survey track (CSAT included). Clamped to 7–90 on save.	`14`

The sibling auto_csat block carries the same five fields plus two CSAT-only extras — a conditions matcher list and a detractor rescue block (its own csat key) — so set NPS independently and leave the CSAT block untouched. Both blocks survive one settings payload untouched.

curl "https://api.orbit.devotel.io/api/v1/settings/general" \
  -H "X-API-Key: $ORBIT_API_KEY"

Response (NPS-relevant excerpt):

{
  "settings": {
    "auto_nps": {
      "enabled": true,
      "template_id": "sv_9f2c…",
      "delay_minutes": 30,
      "smart_trigger": true,
      "cooldown_days": 14
    }
  }
}

Update it with a PUT /settings/general carrying the updated auto_nps object. The write boundary clamps delay_minutes to 1–1440 and cooldown_days to 7–90, matching the console sliders. Invalid values get normalised on save rather than rejected, so a malformed slider can’t disable the cooldown (0) or fatigue-bomb a contact (way above 90).

5. Configure the page

Setting	What it decides	Default
Enable auto-NPS	Master toggle. Off pauses auto-NPS without losing the template or delay configuration.	On
Survey template	Which survey fires on close. The picker lists your `nps`, `csat`, and `ces` templates; NPS is the intended type here, but the broader list covers tenants who label their loyalty survey differently. Until you pick one, conversations close normally and no survey is sent.	None
Dispatch delay after resolve	Minutes to wait between close and send. Range 1–1440 (1 minute → 24 hours). 5–30 minutes is typical for transactional support; longer delays reduce reply rates.	5 min
Smart NPS triggering	When on, the dispatcher skips conversations the sentiment analysis marked `negative` and contacts inside the cooldown window. Off fires on every close regardless of sentiment or recent history.	On
Per-contact cooldown	Minimum days between surveys for the same contact, counted across every template — CSAT included. Range 7–90 days.	14 days

Click Save changes; the button stays disabled until you modify a value.

6. How the channel is picked

Recipients are implicit: the survey goes to the contact on the closed conversation. The dispatcher resolves the channel in this order:

The conversation’s last-used channel — when the template allows it, the survey goes out on the same channel the close ran on.
The first template-allowed channel the contact can be reached on — when the conversation’s own channel isn’t one the template lists (or the conversation carries a mixed channel history), the dispatcher walks the template’s allowed list in order until one matches a reachable address. A phone-capable channel needs a contact phone number; email needs a contact email.
Skip deliberately — a close with no reachable channel is skipped and recorded as such, not retried.

Inbound history never pins the channel choice: the conversation’s last-used channel is tried first, and the fallback walks the template’s list even when earlier turns used different channels together.

7. Where the results land

Answered NPS surveys roll up with CSAT answers in the same surveys analytics, but under separate measures, so the two tracks never pollute each other’s averages:

Insights → Surveys — answered surveys attach to the survey, the contact, and the conversation that triggered them. Filter by the NPS template to trend loyalty separately from satisfaction.
Scorecards (GET /api/v1/surveys/scorecards) — pass survey_type=nps to restrict the rollup to the NPS track. Each row reports an nps (promoters minus detractors) and nps_responses next to the CSAT-only average.

curl "https://api.orbit.devotel.io/api/v1/surveys/scorecards?group_by=queue&survey_type=nps&from=2026-08-01T00:00:00Z" \
  -H "X-API-Key: $ORBIT_API_KEY"

Response (one queue bucket):

{
  "data": {
    "scorecards": [
      {
        "key": "q_support_tier1",
        "responses": 147,
        "satisfied_count": 121,
        "satisfaction_pct": 82.31,
        "avg_score": 7.86,
        "csat_avg_score": null,
        "nps": 41.5,
        "nps_responses": 147
      }
    ]
  }
}

The NPS-side fields, and how the server computes them:

Field	Definition
`nps`	`(promoters − detractors) / NPS answers × 100`, where a promoter scored 9–10 and a detractor scored 0–6 (7–8 are passives and do not enter the numerator). Null when the bucket has no NPS answers. Range −100 to +100.
`nps_responses`	Count of NPS-type answers in the bucket. Return shape pairs this with `nps` so a null-but-zero response set never reads like data.
`responses`	All answered surveys in the bucket, NPS and (when `survey_type=all`) CSAT mixed.
`satisfied_count` / `satisfaction_pct`	Answers at score ≥ 4; the percentage is null on a zero-count bucket.
`avg_score`	Mean across mixed-scale scores; `csat_avg_score` is the CSAT-only mean and `null` on an NPS-restricted query.

Filter survey_type=nps to read only NPS rows; the queue-level bucket (group_by=queue, default) or agent bucket (group_by=agent) groups the same rollup.

Auto-CSAT/NPS dispatch — the close-triggered dispatch mechanics (arming sequence, sweep cadence, channel-pick order, quiet-hours hold) for both tracks. Until this page existed, that guide was the only mention of auto-NPS; it treats NPS as a side bullet of the CSAT track, which this page disambiguates.
CSAT and NPS settings consoles — the operator-facing map of both Settings pages, including per-conversation and per-queue overrides.
Surveys end to end — manual, audience-targeted distribution; use it for a one-off NPS pulse to a segment instead of the close-triggered loop, and author the template this console needs.
Settings API reference — the full GET/PUT /settings/general surface this console sits on.

WhatsApp

Developer console

Contact center

Guides

Messaging Controls

Audience & Support Tools

Auto-NPS console: a dedicated Settings → NPS page for the loyalty track

Auto-NPS console (Settings → NPS)

1. Why NPS gets its own console

2. Prerequisites

3. Where it lives

4. The `auto_nps` settings block

5. Configure the page

6. How the channel is picked

7. Where the results land

​Auto-NPS console (Settings → NPS)

​1. Why NPS gets its own console

​2. Prerequisites

​3. Where it lives

​4. The auto_nps settings block

​5. Configure the page

​6. How the channel is picked

​7. Where the results land

​8. Related guides

Auto-NPS console (Settings → NPS)

1. Why NPS gets its own console

2. Prerequisites

3. Where it lives

4. The `auto_nps` settings block

5. Configure the page

6. How the channel is picked

7. Where the results land

8. Related guides