How to Classify Customer Feedback and Product Reviews with AI

The feedback gap

Product teams have more customer feedback than ever. NPS surveys, in-app prompts, support ticket closings, app store reviews, G2 ratings, Intercom conversations. The data is there. The problem is that almost all of it is unstructured text, and no one has time to read thousands of freeform responses and count what people are complaining about.

So the feedback sits. Maybe someone exports it to a spreadsheet once a quarter and skims a sample. Maybe it informs the roadmap in vague, impressionistic ways. The signal is there but the mechanism to extract it systematically is missing.

AI classification is that mechanism. Send each response to the API, get a label back, and now your feedback is a structured dataset you can query, aggregate, and route - at any volume and in real time.

Designing your feedback categories

The quality of your categories determines the quality of your output. Generic categories like "positive" and "negative" tell you almost nothing. Specific categories that map to your product and your team structure are what actually drive action.

A useful starting set for a SaaS product:

• bug_report - something is broken or behaving unexpectedly
• feature_request - the user wants something that doesn't exist yet
• onboarding_friction - confusion during setup, first use, or learning the product
• billing_issue - pricing concerns, invoice questions, charge disputes
• praise - explicit positive feedback about the product or team
• general_question - how-to questions or documentation requests
• needs_review - catch-all for low-confidence responses

These map cleanly to internal owners: bug_report goes to engineering, feature_request goes to product, billing_issue goes to finance or customer success. When your categories have clear owners, the routing decisions write themselves.

A real classification request

A user submits the following response to an in-app feedback prompt after their first week:

"The core functionality is great but I spent two hours trying to
figure out how to connect my Slack workspace. The docs weren't
helpful and I ended up just guessing. It would be great if there
was a setup wizard or at least a video walkthrough."

You send it to classifaily:

curl -X POST https://api.classifaily.com/v1/classify \
  -H "Authorization: Bearer cai_live_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "input": "The core functionality is great but I spent two hours trying to figure out how to connect my Slack workspace. The docs weren'\''t helpful and I ended up just guessing. It would be great if there was a setup wizard or at least a video walkthrough.",
    "categories": ["bug_report", "feature_request", "onboarding_friction", "billing_issue", "praise", "general_question", "needs_review"],
    "explain": true
  }'

Response:

{
  "label": "onboarding_friction",
  "confidence": 0.93,
  "reasoning": "User describes difficulty completing a setup task (Slack connection), cites unhelpful documentation, and requests guided onboarding resources. No bug or missing feature is implied - the friction is in the learning path.",
  "request_id": "req_01kc..."
}

Route this to your onboarding team or tag it in your product tool under the Slack integration documentation issue. Repeat that for 500 responses and you have a quantified picture of where users are getting stuck.

Classifying NPS open-ended responses

NPS surveys give you a number and a text field. Most teams look at the number and ignore the text. The text is where the actual signal lives.

The standard NPS question is "what's the main reason for your score?" - which means the open-ended response is almost always an explanation of a problem or a piece of praise. Classification turns that into a topic label you can cross-reference with the score.

A detractor (score 0-6) who writes about billing_issue needs a different response than a detractor who writes about bug_report. A promoter (score 9-10) who writes feature_request is giving you a product signal, not a complaint. Knowing the topic alongside the score lets you prioritize follow-up and segment feedback by what people actually care about.

The API call is identical - you're just passing the open-ended NPS field as the input. You can include the score in your request for additional context:

{
  "input": "NPS score: 3\nComment: The product works well when it works but we've had three outages in the last month and no communication from your team about what happened.",
  "categories": ["bug_report", "feature_request", "onboarding_friction", "billing_issue", "praise", "reliability_concern", "needs_review"]
}

Routing feedback to the right team

Once you have a label, the routing logic is straightforward. You can implement it in your own backend, in an automation tool like n8n or Make, or directly in your product's webhook handler:

• bug_report → create a GitHub issue or Linear ticket, tag it as customer-reported
• feature_request → add a row to your product roadmap tool (Notion, Canny, ProductBoard) with the full text
• onboarding_friction → tag in your onboarding analytics dashboard, notify the CS team lead
• billing_issue → create a task in your billing queue, alert the finance or CS team
• praise → log it (don't ignore your wins), optionally pipe to a team Slack channel
• needs_review → add to a human review queue for anything below your confidence threshold

The routing destinations are up to you. The point is that each category has a clear owner and action, so nothing gets lost in a generic inbox.

Batch processing existing reviews

If you have a backlog of app store reviews, G2 responses, or historical survey data you've never systematically analyzed, classifaily's batch endpoint lets you send up to 25 items in a single request:

curl -X POST https://api.classifaily.com/v1/batch \
  -H "Authorization: Bearer cai_live_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "items": [
      { "id": "review_001", "input": "Love the product, billing is confusing." },
      { "id": "review_002", "input": "Crashed twice this week during export." },
      { "id": "review_003", "input": "Wish you had a mobile app." }
    ],
    "categories": ["bug_report", "feature_request", "onboarding_friction", "billing_issue", "praise", "needs_review"]
  }'

Each item gets its own label and confidence score. Run through thousands of historical reviews in a scheduled job and you have a baseline view of what your customers have been asking for - categorized and queryable.

Aggregating results for reporting

The real value of classification at scale is what you can do with the aggregate. Once every piece of feedback is labeled, you can answer questions that were previously impossible to answer without reading everything manually:

• What percentage of feedback this month was bug_report vs. feature_request?
• Did onboarding_friction reports increase after we shipped the new signup flow?
• What do detractors (NPS 0-6) write about most often?
• Which feature areas are generating the most feature_request feedback from enterprise customers vs. free users?

These are product strategy questions. Classification is what makes them answerable with data instead of guesswork.

Using schemas for consistent categorization

If you're classifying feedback from multiple sources - in-app surveys, email responses, app store reviews - save your categories as a named schema in classifaily and reference the schema ID in every request:

{
  "input": "...",
  "schema_id": "sch_feedback_v1"
}

This guarantees every source uses exactly the same categories. When you update the schema - adding a new category, renaming an existing one - all integrations pick up the change automatically. Your historical data stays consistent and your reporting stays clean.

Getting started

The free plan includes 100 classification requests per month, which is enough to prototype this against a real dataset. If you have a CSV of existing reviews or survey responses, you can run the entire batch through the API, inspect the results, and tune your categories before building any automation.

The full API reference, including batch endpoint documentation and schema management, is in the API documentation.