Turn customer comments into actions you can explain.

Start with the question you need to answer

For this exercise, the question is: “What should the team investigate before the next round of client reporting?” That is more useful than asking an AI tool to summarize everything. The fictional product is Northstar Reports, used by agencies to create and share client reports.

Each row has a source ID, channel, and unchanged comment. Keep those fields when you export or copy the sample. A comment can mention several things, and a positive remark can sit beside a serious problem.

Code topics before writing the summary

The reference codebook has eight themes: getting started, documentation, reporting, integrations, permissions, price and billing, performance, and support. These are editorial labels for this exercise. Read their inclusion rules before applying them.

FB-008 mentions both an integration and inaccurate instructions, so it receives both labels. FB-013 says the CRM sync works but the saved date filter resets: integration is a positive mention, not an integration defect. FB-016 says only “It is fine, I guess.” Leave its theme unclassified.

Give AI a bounded analysis brief

Use an approved tool and permitted data. With this fictional sample, ask it to return one row per source ID, proposed themes, supporting text, and anything requiring review. Ask it to preserve unknowns and refuse to invent customer identities, revenue impact, causes, or missing quotes.

A useful instruction is: “Use the supplied codebook. Multiple themes are allowed. Quote the exact words supporting each proposed label. Mark insufficient evidence as unclassified. Separate observation from interpretation. Do not recommend a product change until you have shown its source IDs.”

Treat the first output as a draft. No keyword matcher is presented here as AI analysis; the included labels were written as a reference for learning and discussion.

Check the rows before trusting the totals

All 16 IDs must appear once in the row-level output. Quotes must match their original comment. Theme names must come from the codebook, and each theme must be supported by the text. Review the unclassified row rather than silently dropping it.

The reference analysis has 21 theme assignments across 15 classified comments. Reporting appears in five comments. That does not mean five complaints: the group includes praise and feature requests. Multiple labels make theme totals larger than the number of classified comments.

Make the action smaller than the claim

FB-004 reports another client’s project appearing beside a shared report. The next step is to investigate with test accounts and the product owner. Do not declare a confirmed disclosure from a comment alone.

FB-007 reports different refund handling in a download and dashboard. Compare the same refund records in both outputs before relying on the export. The comment supplies a testable discrepancy, not its technical cause.

FB-001 and FB-008 identify different instruction gaps. Review the import guide and integration guide separately, then ask a colleague to follow each corrected procedure. A broad instruction to “improve onboarding” would hide those distinct jobs.

Frequency is useful context, not the whole priority

A single reported access problem can deserve investigation before a more frequent cosmetic request. Consider consequence, strength of evidence, affected workflow, and the cost of learning more. Keep proposed owners and verification steps beside each action.

GOV.UK’s research guidance separates observations, findings, and actions. Its guidance on sharing findings also encourages supporting a finding with evidence such as a participant quote. This exercise applies that distinction to a small fictional feedback set.

Use the reference codebook, then inspect disagreements

These are editorial teaching rules for the fictional 16-response sample. Apply more than one theme when the evidence supports it; leave an unclear response unclassified rather than forcing a label.

Optional editorial description of the whole comment: positive, negative, mixed, neutral, or unclear. Mixed includes both praise and a problem. Neutral includes requests without clear evaluative language. Sentiment is distinct from theme, severity, and priority.

• Getting started (onboarding) — Include: Initial setup, first import, and reaching a first useful result. Exclude: Later report behavior without an initial-setup issue.
• Instructions and documentation (documentation) — Include: Explicit statements about instructions, a guide, or documentation. Exclude: Confusion alone without a documentation claim.
• Report output and behavior (reporting) — Include: Report usefulness, calculations, filters, presentation, and saved-report behavior. Exclude: Initial import without report behavior.
• Connections to other tools (integrations) — Include: CRM connections, integrations, and requests to replace manual transfers with a named connection. Exclude: A standalone first CSV import.
• Access and sharing controls (permissions) — Include: Who can see a project or report, recipient-access visibility, and sharing protections. Exclude: General setup without an access concern.
• Price and billing (pricing_billing) — Include: Price, value for money, invoices, and seat charges. Exclude: Time saved without discussion of price or value.
• Speed and responsiveness (performance) — Include: Waiting for software operations or reports to complete. Exclude: Waiting for a human support response.
• Support experience (support) — Include: Help from support, response delays, and usefulness of help. Exclude: Documentation without a support interaction.