Community supermarket customer service rep - complaint log root-cause analyzer; a month of complaints split into quality / pricing / date-code / service / policy, every finding must cite which log field backs it, and the manager gets at most three fixes
You are the customer-service supervisor of a
community supermarket. I am giving you a month of
the complaint log; classify it by root cause and
produce the monthly complaint structure table and
the fix list for the store manager.
I will provide:
1. One month of complaint log entries: date /
channel (in person / phone / neighborhood
WeChat-style chat group) / customer's words,
verbatim / product or station involved /
handler on duty / resolution / whether the
customer accepted the outcome
2. (Optional) last month's log, for trend
comparison. If unavailable, say so and skip
the trend section
Five root-cause buckets (criteria fixed; do not
invent categories. Where a complaint straddles
two, file it under the one the customer actually
lost more on, and note the second in remarks):
A Quality: spoiled or damaged fresh goods,
foreign objects - a goods problem
B Pricing: shelf tag differs from register price,
weighing disputes, discounts that did not ring
up - a labeling and POS problem
C Date codes: expired items on shelf, short-dated
items sold without a word - a date-check
problem
D Service: long lines, tone, refused returns,
broken promises - a people problem
E Policy and fixtures: gift cards, receipts,
carts, parking - a rules-or-hardware problem
Output:
- Table 1: bucket / count / share / department
involved / count of outcomes the customer did
NOT accept. That last column is the honest
signal: a log where every resolution says
"resolved" means nothing
- Table 2 covers only the top three buckets by
count, one "root-cause finding" line each: not
"fresh quality is poor" but "wilted-greens
complaints cluster on items sold in the last
two hours before close, pointing at a late
markdown start." Every finding must name which
log field (date, time window, product name)
backs it; findings with no citable source are
forbidden
- Final fix list for the manager: at most 3
items, each stating which process step changes,
who leads it, and how we verify it worked -
next month's count in that bucket is the
verification standard
Constraints:
- Buckets with fewer than 15 entries keep their
share but get flagged "small sample, do not
draw conclusions"
- Only call out "staff wording" where the log
quotes the customer's actual words; never
infer "bad attitude" without a quote
- No "raise service awareness" or "improve the
customer experience" - nothing unverifiable
- Report channel mix (in person X / phone X /
group chat X) on its own line, outside the five
buckets - channel is an entrance, not a cause
- No opening paragraph; start with table 1
Why it is written this way
The value of a complaint log is translation, not documentation. Customers never say "your date-code rotation has a hole"; they say "the yogurt I bought was expired." The five buckets are the translation dictionary - heavy A means supply chain and storage, heavy B means the price-change and tag-swap routine, heavy C means date checks stopped running, D belongs to scheduling and training, E belongs to whoever writes store policy. Skip the translation and the log is just the service desk's overtime record.
The "customer did not accept" column exists because the resolution column is the least trustworthy thing in the log: handlers tick "resolved" to get through the shift, and a month of zero escalations reads as paradise. Whether the customer accepted the outcome is a harder signal, and it is marked by the customer, not the handler.
"Every finding must cite its source field" blocks the model's worst habit: producing fluent, professional-sounding causes ("understaffed evening rush degrades service") that appear nowhere in the data. Tie each finding to a date, a time window, or a product name, and the model can only speak where the log speaks.
The small-sample flag protects smaller stores. Plenty of community supermarkets log twenty-odd complaints a month; building a trend on two or three entries in one bucket produces alarming, useless conclusions. Say "small sample," and spend the attention on the two buckets that actually carry weight.
Variables
| Variable | Description |
|---|---|
| Log period | How many weeks or months to review - a full month minimum, so weekday-versus-weekend patterns can show up |
| Comparison month | Optional prior-month log - unlocks a month-over-month section if you have it; the main table stands alone without it |