I'mBoardDocs
Board OntologyCustomers

NPS Responses

The number of survey responses the current `customers.nps_score` is computed from — the confidence qualifier the board must read alongside any NPS value. Per the NPS methodology (Reichheld/Bain), a score from a small or unrepresentative sample is unreliable; surfacing the response count lets the board discount low-n scores. Common pitfall: celebrating (or alarming at) an NPS swing that is actually a sample-size artifact — always read the score and the response count together. — Customers KPI, I'mBoard-authored (editorial tier).

I'mBoard-authored (editorial tier)

No public third-party standard anchors this KPI yet, so I'mBoard authors and maintains the definition — transparently labeled as editorial tier. See the ontology methodology for the published vs editorial tier system and the back-attribution workstream.

Rogue ID: customers.nps_responses Type: Number Domain: Customers

Definition

The number of survey responses the current customers.nps_score is computed from — the confidence qualifier the board must read alongside any NPS value. Per the NPS methodology (Reichheld/Bain), a score from a small or unrepresentative sample is unreliable; surfacing the response count lets the board discount low-n scores. Common pitfall: celebrating (or alarming at) an NPS swing that is actually a sample-size artifact — always read the score and the response count together.

Formula

Count of completed survey responses behind the period's NPS score. Response rate = nps_responses ÷ customers surveyed.

Why it matters

The confidence denominator under NPS — an NPS based on <50 responses or <10% response rate should be flagged low-confidence rather than trended.

How to interpret

Read with customers.nps_score and customers.nps_trend. A trend across periods with materially different response counts may be measurement noise, not a real movement.

Calculation policy

How an AI agent should compute this KPI from messy company data. Free-text rules consumed at reasoning time — not a deterministic DSL. The most common ways to get this wrong are listed under Common miscomputations.

Inclusion rules

  • Count completed survey responses behind the period's customers.nps_score — the confidence denominator under any NPS value.
  • Count one per completed response (a usable 0–10 score) within the survey window that produced the reported score.

Exclusion rules

  • Partial / abandoned surveys that did not yield a usable 0–10 score.
  • Responses outside the survey window for the reported score.
  • Customers surveyed but who did not respond — those belong to the response-rate denominator, not the response count.

Required inputs

  • Count of completed responses for the period's survey.
  • The number of customers surveyed (for the response-rate calculation).

Data-source priority

  • Survey platform (Delighted, Pendo, in-app NPS) response export.
  • Manual survey tally as a fallback.

Edge cases

  • Multiple surveys in one period: define whether the count is the latest survey or the pooled set, and keep it consistent with how nps_score is computed.
  • A response count materially different from prior periods means a trend may be measurement noise, not a real movement — flag it.

Validation checks

  • nps_responses ≥ promoters + passives + detractors used in the score.
  • Non-negative integer.
  • Flag the score low-confidence when nps_responses < ~50 or the response rate < ~10%.

Common miscomputations

  • Reporting nps_score without the response count — a swing on a tiny sample reads as signal when it is noise.
  • Counting customers surveyed (sent) as responses (received) — inflates confidence.
  • Pooling responses across surveys for the count but computing the score from a single survey (or vice versa).
  • customers.nps_score
  • customers.nps_trend

Source

I'mBoard editorial — authored and maintained by I'mBoard, first published 2026-04-01. No third-party standard is cited for this KPI; when one emerges, the definition is back-attributed and promoted to the published tier (a minor version bump). Read the ontology methodology for the published vs editorial tier system, attribution rules, and dispute process.

Stage relevance

Company stagePriority
Series ARecommended
Series BRecommended
Series C+Recommended
PublicRecommended

Suggested for stages: Series A, Series B, Series C+, Public.

Default owning functions

  • Product
  • Sales

Machine-readable

On this page