N NoBullshit.wiki 中文

Fast food customer service - platform rating rescue checklist: pull the sub-scores first and treat only the weakest two, press the new-bad-review rate and let the rolling window do the rest - and fake orders are the hard red line

Works with:Claude / GPT-4 classCategories:Fast Food RestaurantLevel:Intermediate Updated

You are a delivery operations consultant for a fast
food restaurant. My store's rating on a delivery
platform has fallen to [4.X] and traffic is being
cut. Give me a 7-day rescue checklist, advancing by
day, each action stating: who does it / what they
do / what to verify that same day.

The mechanics first (every action derives from
them): the platform rating is a rolling [30]-day
window - old bad reviews scroll out of the
calculation, new ones keep scrolling in. A rescue
is exactly two things: press the rate of new bad
reviews, and repair the basics that generate them -
then let the window roll. Misunderstand this and
every action below gets done wrong.

Day 1: locate, do not act
- Pull the rating breakdown: the platform's
  merchant sub-scores (taste / service / delivery
  / item quality - per the actual back-office
  columns), and identify the lowest [2]. If the
  breakdown cannot be pulled, read all bad
  reviews from the last 30 days and hand-sort
  them by content instead - skipping diagnosis
  and jumping to fixes is forbidden
- Quick census: bad reviews last 7 days vs. the 7
  before - is this "new bad reviews accelerating"
  or "old good reviews scrolling out"? The two
  need different rescues

Days 2-3: treat (only the two weakest sub-scores;
touch nothing else)
- Product sub-score low: cross-check the specific
  items named in the last two weeks' refunds and
  reviews; any item named [3]+ times gets a same-
  day quality self-check (portion, temperature,
  packaging); repeatedly-named items are
  candidates for temporary delisting - one line
  of action, no whole-menu overhaul
- Service / missing-item sub-score low: add one
  hand-off check (packed order reconciled against
  the ticket), with easy-to-miss items (sides,
  drinks) printed at the top of the check sheet
- Delivery sub-score low: check whether hand-off
  times are eating the courier's clock - slow
  hand-off converts courier lateness into customer
  bad reviews; rider supply is the platform's
  side, and the store's only lever is prep pulled
  earlier

Days 4-7: stop the bleeding, then hold
- Reply backlog to zero: every unreplied review
  answered per the typed reply scripts (rules not
  repeated here); new reviews answered same-day
- Peak check: record peak hand-off times for [3]
  consecutive days against the platform's
  estimated prep time - "waited forever" reviews
  split into hand-off vs. road before anything
  else
- One number a day: today's new bad-review count,
  posted in the manager channel - the only metric
  that needs daily eyes

Absolute red line (end of the checklist, bold):
- Fake orders, bought reviews, refund-for-rating
  offers - platforms that confirm this respond
  with suspension and demotion, and a rating
  rescue becomes a store rescue. This line has
  no "depends on the situation" exceptions
- No blanket discounting to chase volume - a
  volume spike multiplies every process's error
  rate, and the rating fills with new bad reviews
  before it recovers

Output format: day / action / owner / same-day
verification (a number or a state anyone can
check); close with "how to tell on day 8 whether
the rescue worked": not the total score (the
window hasn't rolled; the total won't move), but
whether the new-bad-review rate has fallen back
to its pre-drop level

Constraints:
- Cite no specific platform rule numbers - back-
  office columns and scoring differ; everything
  carries "per the actual back-office columns"
- No "back to 4.X within 7 days" promises - the
  rolling window prices recovery in weeks;
  promising days means not understanding the
  mechanism
- No invented industry benchmarks; every
  threshold (3 times, 3 days) is a [blank] I set
  for this store

Why it is written this way

Day 1's "locate only" is the brake on the whole checklist. A falling rating triggers anxiety, and anxiety demands immediate action - apologize everywhere, overhaul everything, launch a discount - but the rating is a weighted composite, and treating an unknown factor is chemotherapy without a diagnosis. Writing "hand-sort 30 days of reviews if the breakdown can't be pulled" as a non-skippable step is deliberate: two hours of manual sorting outperform six days of frenzied blind fixing.

"Judge the rescue by the new-review rate, not the score" teaches a counter-intuitive acceptance test: before the window rolls, doing everything right still won't move the total - graded on the total, the team concludes by day five that nothing worked and quits. The one daily metric is today's new bad-review count because it is the only input with same-day causality: yesterday's fixes speak first in today's rate.

Fake orders sit in the hard red line with consequences attached because the rescue scenario grows this temptation naturally: legitimate actions price in weeks, bought reviews promise overnight. The checklist doesn't moralize - it does mechanics: confirmed manipulation means suspension and demotion, rescue becomes closure, and that arithmetic leaves no "depends" room. The blanket-discount ban is the same math: a volume spike multiplies error rates everywhere, and the rating drowns in fresh bad reviews before it recovers.

Variables

Variable Notes
Rating line & window This platform's traffic line (e.g. 4.5) and rolling-window days - per the platform's rules page, quoted at the top of the checklist
Sub-score structure The platform's actual back-office columns - they differ; redraw the day-1 diagnosis table to match reality
Threshold set Item-name tolerance line, days of peak checks - scaled to store volume; small-volume stores can drop "3 times" to 2

platform ratingdeliveryrescue checklist