Classify feedback and route it to the right team
A template for product and support teams that turns feedback from forms and email into a structured log with topics and sentiment.
How this works
A template for product and support teams that turns feedback from forms and email into a structured log with topics and sentiment.
Classify the meaning of feedback before routing it. One message may contain a bug and a feature request, and sentiment should not override explicit urgency or a customer’s reported inability to complete a task.
Before you start
Defined operating scope
Customer feedback arrives through multiple entry points and needs a responsible team.
Required source material
Obtain Feedback from forms and email; Feedback categories; Channels for the responsible teams. If connectors are unavailable, use authorized files with the same fields.
Decision and exception rules
A message contains multiple actionable topics. Split issue components and route each to its appropriate team.
Prepare the inputs
- feedback_id
- Required
Stable message or form ID
Keep channel and original text.
- category_rules
- Required
Topics and positive/negative examples
Define multi-label and uncertain handling.
- routing_map
- Required
Category to team and destination
Use approved recipients only.
- urgency_rules
- Required
Observable impact conditions
Do not infer severity from negative tone alone.
Implementation, step by step
Establish the working record
- Confirm the selected records, effective versions and responsible owner.
- Check feedback_id, category_rules, routing_map, urgency_rules before beginning. Record the source version and the selected scope; an unavailable value stays unknown rather than becoming an inferred fact.
Checkpoint: The input record identifies the selected feedback_id and any missing required fields.
Receive feedback and extract the message
- Normalize incoming text while retaining the original message and attachments needed to understand the issue.
- Check that every issue component preserves the customer’s stated meaning.
Checkpoint: A saved intermediate result for: Receive feedback and extract the message.
Identify its topic, sentiment, and main point
- Extract distinct issues and assign topic labels with evidence; sentiment is an optional descriptive field, not a diagnosis.
- Reconcile source IDs, saved records and notification receipts to detect dropped or duplicate items.
Checkpoint: A saved intermediate result for: Identify its topic, sentiment, and main point.
Save the record to a spreadsheet
- Write one stable feedback record with separate issue components and duplicate links where appropriate.
- Check that every issue component preserves the customer’s stated meaning.
Checkpoint: A saved intermediate result for: Save the record to a spreadsheet.
Route a notification by category to team chat or email
- Prepare notifications for the responsible teams, including impact, missing details and the original context rather than an isolated negative phrase.
- Reconcile source IDs, saved records and notification receipts to detect dropped or duplicate items.
Checkpoint: A saved intermediate result for: Route a notification by category to team chat or email.
Package the result and unresolved work
- Check classification and urgency. The team decides how to handle each issue.
- Route within approved team visibility; do not broadcast private feedback indiscriminately.
Checkpoint: A feedback log and notifications about bugs, feature requests, and usability issues. Unresolved items remain visible in the review record.
Decisions along the way
A message contains multiple actionable topics.
Split issue components and route each to its appropriate team.
The category is uncertain.
Send it to the designated triage queue rather than choosing a random team.
A notification fails after the record was saved.
Retry only the failed delivery using the existing feedback ID; do not duplicate the record.
What you will produce
customer-feedback-routing-result.json
JSONA feedback log and notifications about bugs, feature requests, and usability issues. Label proposed and completed states separately.
Include: feedback_id · issue_components · categories · reported_impact · route · delivery_status · status · evidence_reference · review_note
customer-feedback-routing-review.md
MarkdownKeep the evidence and unresolved decisions needed to apply this result, including exceptions involving urgency_rules.
Include: source_reference · question · owner · next_action
Check the result
- Check that every issue component preserves the customer’s stated meaning.
- Reconcile source IDs, saved records and notification receipts to detect dropped or duplicate items.
- Inspect feedback_id and category_rules in both the original and output; confirm that record identity and interpretation survived the transformation.
- Check classification and urgency. The team decides how to handle each issue.
When something goes wrong
A message contains multiple actionable topics.
Split issue components and route each to its appropriate team. Retain the affected evidence and recovery status.
The category is uncertain.
Send it to the designated triage queue rather than choosing a random team. Retain the affected evidence and recovery status.
A notification fails after the record was saved.
Retry only the failed delivery using the existing feedback ID; do not duplicate the record. Retain the affected evidence and recovery status.
A worked example
SYNTHETIC EXAMPLE · NOT A REPORTED BUSINESS RESULT
Request
Classify feedback and route it to the right team for the following bounded example; prepare the result for review.
Inputs
Synthetic example: Feedback F-6 says checkout crashes and also asks for dark mode. The crash prevents payment; the tone is polite.
Expected result
Synthetic expected result: Create a checkout bug with blocked-purchase impact and a separate dark-mode request. Route by issue type; politeness does not reduce the crash’s priority.
Run a small pilot
Start small
Trial a representative batch containing the ordinary case and the exception demonstrated above.
Record the baseline
Record current preparation time, review effort and correction types for the same records.
Agree success criteria
Agree acceptable review and error limits; measure correct routing rate; time from receipt to owner assignment.
Stop or revise
A notification fails after the record was saved. Pause affected records and apply this recovery: Retry only the failed delivery using the existing feedback ID; do not duplicate the record.
Keep the scope clear
- Route within approved team visibility; do not broadcast private feedback indiscriminately.
- The team decides severity and action; classification does not establish a product defect.
Check before using
Check classification and urgency. The team decides how to handle each issue.
Business activities
- Resolve customer questions
- Plan products and business changes
FROM A RECIPE TO YOUR WORKFLOW
Bring the company context together.
This workflow needs reliable inputs before it needs a better prompt. Moat8 Vault brings working information into a readable archive for the AI tools you use.
For this recipe: Feedback from forms and email · Feedback categories · Channels for the responsible teams
Start with one recurring task, agree which sources to use, and review the first result with your team.
Discuss this workflow