Analyze Customer Feedback

Convert unstructured feedback into evidence-backed themes, priorities, and actions. Preserve the distinction between what customers said, what the analysis infers, and what the team should test next.

Privacy and evidence rules

Use only feedback the user is authorized to analyze.
Remove or mask phone numbers, email addresses, addresses, account IDs, and other unnecessary identifiers.
Preserve stable source IDs so findings can be audited without exposing identity.
Do not fabricate counts, quotations, customer attributes, causes, or market size.
Quote only the minimum excerpt needed as evidence.
Treat sentiment as a signal, not a substitute for problem analysis.
Label low-sample or low-confidence conclusions clearly.

Workflow

1. Define the decision

Clarify what the analysis must support: defect triage, roadmap planning, service improvement, churn reduction, campaign review, product launch assessment, or another decision. Record the time range, channels, products, markets, and segments included.

2. Profile the dataset

Report total records, usable records, source distribution, date coverage, language mix, missing fields, duplicates, suspected spam, and sampling limitations. Do not silently discard records; record each exclusion rule and excluded count.

3. Normalize without erasing meaning

Standardize dates, channel names, product names, and obvious encoding issues. Keep the original text. Merge exact duplicates and near-duplicate campaign or bot messages only when the rule is documented.

4. Code feedback at the record level

Read references/analysis-schema.md. For each usable record, assign:

product or journey stage;
feedback type;
problem or desired outcome;
theme and subtheme;
severity when supported;
sentiment;
evidence excerpt;
confidence;
relevant segment and date.

Allow multiple codes when one record contains multiple distinct issues. Split them rather than forcing one dominant label.

5. Build and validate themes

Start with provisional themes, then merge or split them based on evidence. A useful theme is specific enough to act on and broad enough to recur. Avoid vague buckets such as “体验不好” when the evidence supports “支付结果页未明确显示是否成功”.

For each theme, calculate or report:

record count and share of usable feedback;
affected channels, products, and segments;
trend by period when timestamps exist;
severity distribution;
representative evidence;
contradictory or positive evidence;
confidence and sampling caveats.

6. Prioritize transparently

Use an explicit method agreed with the user. When none is provided, score each theme from 1 to 5 on:

frequency;
user harm or task blockage;
business impact;
trend urgency;
evidence confidence.

Show the component scores. Do not collapse them into unexplained “AI priority”. Separate quick fixes from strategic opportunities.

7. Recommend actions as tests

For every priority theme, provide:

evidence-backed problem statement;
affected user and context;
likely cause, explicitly labeled as a hypothesis;
proposed action;
owner or function;
success metric;
validation method;
confidence and dependency.

Do not treat a customer-requested feature as the only possible solution. Restate the underlying job or friction first.

Required outputs

dataset and methodology summary;
ranked theme table;
evidence appendix with source IDs;
segment or period comparison where supported;
top actions with metrics and validation plans;
exclusions, limitations, and unresolved questions.

Quality gate

Verify that:

all counts reconcile to usable, excluded, and duplicate records;
every theme has traceable evidence;
quotations are authentic and minimally identifying;
percentages include a denominator;
small samples are not presented as population truth;
hypotheses are not written as confirmed causes;
recommendations connect to a measurable outcome.