N NoBullshit.wiki 中文

Hotpot restaurant regional manager - store tiering and visit-time allocation tool: have a coding agent build a single-file page that turns eight stores and twenty-two days into a defensible plan

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

You are a coding agent. Build me a single-file HTML "store
tiering and visit-time allocation" tool for a hotpot chain
regional manager - double-click to open in a browser, no
network, no installs, no external resources of any kind.

Part 1 - Entry
Per store:
- Store name (free text)
- Margin level: trailing-quarter gross margin, plus the
  store's past four quarters of gross margin - the tool
  computes "position versus own history" (above / below own
  median); never compares across stores
- Trend direction: computed automatically from the last three
  month-over-month moves (rising streak / falling streak /
  mixed), with manual override allowed plus a one-line note
- Special flags: new store (open under [N] months) / new
  manager under three months / none - flags participate in
  tiering with adjustable weight

Part 2 - Automatic quadrant tiering (every rule shown on the
page; no hidden formulas)
- High margin x rising → "escort": visit little. Default
  visit focus: complaint-handling quality, key-staff morale -
  these stores don't die of losses, they die of drifting
- High margin x falling → "anti-slide": visit heavily.
  Default focus: competitive and neighborhood changes first,
  internals second - the cheapest store to save; catch it at
  half-slide and the rescue costs double
- Low margin x rising → "climb": normal-plus cadence.
  Default focus: the gap checklist versus ramp targets
- Low margin x falling → "turnaround": frequent visits or
  residency. Default focus: loss attribution and the
  invest-or-close call - this is due diligence before a
  capital decision, not inspection
- Every quadrant's visit-focus text is editable by the
  manager and persists in localStorage

Part 3 - Time allocation
- The manager sets the total pool: visit days available this
  month, store count
- The tool computes suggested days per store from quadrant
  templates (defaults editable: e.g., escort 0.5 days /
  anti-slide 2 / climb 1.5 / turnaround 4); when the total
  overruns the pool, it protects the higher priority
  (turnaround > anti-slide > climb > escort), cutting from
  the bottom, and states plainly who got cut
- Monthly draft: laid out by week (which week, which store,
  watch what), manually draggable; CSV export

Part 4 - Error handling and restraint
- Stores under [N] count or with less than a full quarter of
  data are marked "thin sample - schedule on the climb
  template," never force-tiered
- Every generated draft carries one reminder line: "stores
  cut to zero days last month, if any, listed here" - a
  store zeroed two months running must be handled by a human;
  silent disappearance is not allowed
- No forecasting of any operating metric; no data mutation;
  tiering consumes only what the manager entered

Interface: single column, desktop-first; quadrants visualized
one screen (store cards per quadrant), click a card to edit.
Deliver one complete HTML file with all CSS and JS inlined,
plus a usage note under two hundred words, in Chinese only.

Why it is written this way

Both quadrant dimensions measure against the store's own history rather than across stores, extending the basic discipline of multi-store analysis: comparability between hotpot locations is too weak - location swamps every management action. A neighborhood store at 58% margin may be at its personal peak while a mall store at 62% is halfway down a slope. Tier on absolutes and the quadrants map "good locations versus bad ones," which has nothing to do with management. Baking "compare with yourself" into the computation makes the quadrants reflect operating state, not site-selection luck.

Each quadrant carries a visit focus because tiering that never reaches "what to look at when you go" is still empty. "Escort stores visit little but watch complaints and key staff" is the counterintuitive one - high-margin rising stores don't die of losses, they die of drifting: key staff leaving, complaint handling getting perfunctory, the manager reporting sunshine only. Visiting such a store isn't inspecting performance; it's smelling the air. Hard-wiring these focuses into quadrants with edit rights turns regional-management experience into a transferable template - a new manager inheriting the region gets a defaulted, documented system, not a blank calendar.

The allocator's "protect the top, cut the bottom, and say who was cut" is the tool's conscience. Any allocator facing a shortfall cuts something; the only question is whether the cuts are visible - a store silently cut is a store vanished from management's field of view. Forcing a "zeroed-out stores" listing, with a human-handling requirement at two consecutive zero months, is the valve on the algorithm: it may suggest "skip this one this month," but it may not let a store slip out of oversight without a sound. The tool makes allocation suggestions, never allocation decisions.

"Visit focus editable, all weights displayed" is the tool's statement of its own boundary. The quadrants are a frame, not truth; different regions have different risk appetites - in some, complaints are the vital organ; in others, staff churn. Making every default visible and changeable means the manager isn't tuning parameters but calibrating the frame to the region's reality; a tool that hides its formulas looks professional and in fact strips the user of the right to correct it.

Variables

Variable Notes
Quadrant day templates Default days per store per quadrant - tune to your per-visit travel cost and region radius; one template edit applies region-wide, steadier than re-guessing per store every month
New-store threshold Months under which a store is force-treated as climbing - hotpot ramp periods generally run around half a year; set it from your brand's actual ramp history

store tieringtime allocationsingle-file tool