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
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 |