N NoBullshit.wiki 中文

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

Works with:Claude / GPT-4 classCategories:Community SupermarketLevel:Intermediate Updated

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

complaintsroot cause analysisservice desk