Code the comments behind your NPS

    For CX and in-house research teams: the themes behind every detractor and every promoter, with the same codebook in every wave.

    Your NPS tells you how much. The comments tell you why.

    The score calculates itself. The thousands of answers to “why did you give us that score?” end up in a spreadsheet an analyst categorizes by hand for days — and when the next wave arrives, it starts over.

    Days of spreadsheet work every wave

    Categories that change with whoever codes them, so waves can't be compared

    The report lands when the next wave is already due

    From spreadsheet to themes the same day

    Upload the export from your survey tool. Survey Coder builds the codebook — or uses yours — codes every comment, and lets you review the doubtful ones before you export. The next wave inherits the same codebook.

    Sentiment per mention: “great service but slow” isn't averaged into neutral

    What moves promoters and what holds detractors back

    The same themes compared across detractors, passives and promoters

    A codebook inherited wave after wave, so the trend is real

    Built for a continuous NPS program

    What a team that measures every month needs — not once

    Sentiment per mention

    Each theme carries its own sentiment. A comment that praises the service and criticizes the price isn't flattened into “neutral”.

    Generated codebook, or yours

    The AI proposes themes from your responses, or applies the codebook you already use. You review and adjust before coding.

    Drivers by segment

    What each group mentions, so you know what to protect and what to fix.

    From days to under an hour

    Thousands of comments coded in under an hour — not days in a spreadsheet.

    Detractors, passives and promoters

    Point to the score column and themes are crossed by group. Works with 0–10 scales and with 1–5 scales too.

    Comparable waves

    The next wave inherits the same codebook. If a theme rises, it's the customer who changed, not the way it was coded.

    NPS comment coding: a banking and airline example

    SurveyCoder codes open-ended comments into a controlled codebook, lets your team review the assignments, and exports results to Excel or SPSS. Research agencies and CX teams can use their own codebook or review one proposed by AI, then reuse it on the next wave.

    The comments and labels below are synthetic, manually prepared reference decisions. They are not customer results or an AI accuracy benchmark.

    Banking · score 4

    “The app works well but the transfer fee is too high.”

    Reference codes: 101 — Digital experience and 102 — Fees and charges. Keep both themes; a low recommendation score does not make every part of the comment negative.

    Airline · score 3

    “My flight was late and nobody explained the delay.”

    Reference codes: 103 — Service and communication and 104 — Waiting and delays. Separate the delay from the communication issue so both can be counted and reviewed.

    Try the workflow with an agreed reference

    1. Prepare a de-identified sample and agree on code definitions and multicoding rules.
    2. Code the comments and review differences against your human reference.
    3. Export the reviewed codes. Compare themes by NPS group only when the score column is available.
    4. Reuse the codebook on the next wave and reconcile any definition changes before comparing periods.

    Theme differences between promoters and detractors describe associations; they do not establish what caused the score. SurveyCoder supports the coding workflow; use your survey system to collect the feedback.

    These CSVs illustrate a handoff, rather than the exact product export. For a pilot, measure preparation time, review time and accepted codes on your own sample. Request a coding pilot.

    The welcome project: a real SurveyCoder coding run

    We processed the same 75 English retail comments and original codebook used by the welcome project in an isolated QA project. The comments are synthetic; this coding run and its native Excel exports are real.

    The initial run classified 72 comments and left 3 unclassified. Codex-assisted editorial review changed 15 responses and added 7 codes. The reviewed export contains all 75 classified comments. See the original output, the reviewed output and the reason for each change.

    Run on 6 October 2026 in STANDARD mode, using 75 credits. This is a workflow demonstration, not independent human validation or an accuracy benchmark. The codebook contains examples from the sample, and the dataset has no NPS scores.

    From NPS verbatims to action: the chain most teams break

    The NPS score is the easy part. The hard part is turning thousands of open-ended "why did you give us that score?" responses into something a CX or in-house research team can actually act on. The chain has five stages and each one breaks at predictable places:

    1. Verbatim cleaning: filter "I don't know", "n/a", spam and bot responses. Skip this and your codes are inflated with answers that say nothing.
    2. Stable codebook: 25-50 codes that reflect the real product themes, not what the analyst guessed. A codebook built ad-hoc in wave 1 stops working in wave 4 when new themes emerge. You need a process to incorporate new themes without breaking historical comparability.
    3. Correct multi-coding: "the price is fine but delivery is slow" touches two themes. Coding it as one loses one of the two. Coding it with indiscriminate duplication makes frequencies uninterpretable.
    4. Cross-tab by driver and segment: the real value emerges when codes are crossed with the score (detractor / passive / promoter) and demographics. Without cross-tabs the code ranking is decorative.
    5. Wave-over-wave traceability: in quarterly tracking, a 5% change in a code is either noise or a trend depending on whether the codebook was identical across waves. Without that guarantee you report changes that aren't real.

    What a services company found when it compared its coding with ours

    A services company compared our coding of its NPS with its own, across every response. They agreed on around 96% — and when they reviewed the differences, they realized several came from errors in their own coding, not ours.

    That is the hardest thing to see from the inside: when a person codes by hand for days, their inconsistencies don't show until something independent sits next to them.

    ~96% agreement

    Across every response. In several of the differences, the error was in the company's own coding.

    3-5 days → under 1 h

    Typical coding time for a study of 5,000 to 8,000 comments.

    Common mistakes when analyzing NPS without a structured pipeline

    • Reporting the % of mentions without filtering non-analyzable responses — the denominator is wrong and the driver ranking doesn't reflect reality.
    • Using the same code for "positive customer service" and "negative customer service" because the analyst doesn't want to duplicate — losing the sentiment dimension that's key in NPS.
    • Comparing waves without verifying the codebook was identical — changes between waves can be codebook drift, not consumer drift.
    How to start: with your next wave, upload the export from your survey tool (Excel, CSV or SPSS), use your codebook or let the AI propose one, review the doubtful comments, and export. Later waves inherit the same codebook. To see it with your own data before deciding, request a pilot or try 250 comments free with the free coder.

    Ready to Transform Your Analysis?

    Start coding open-ended responses with AI today. Free trial with 250 responses.