Every location has its own hours, sold-out board, coupons, and quirks. Fire It scopes menus, agents, and reporting per location — with a group-level dashboard for owners.
Multi-location restaurant phone ordering requires per-location menu, hours, sold-out state, and reporting — plus a group-level view for the owner. Fire It's data model is scoped by organization and location, and RLS ensures no location can see another's calls or orders.
Multi-location operators live and die by the details that differ between shops: which store closes at 10 and which at 11, which shop 86'd sausage on Wednesday, which manager runs a $2-off Tuesday. Fire It treats those as per-location settings, not group-wide compromises.
Row-Level Security policies enforce these boundaries in the database, not just in the UI. A staff member at Location A cannot see calls or orders at Location B, even if they know a URL.
The owner view aggregates plan usage, call volume, and captured orders across locations. Drilling in requires the same authorization checks as opening a single-location dashboard. We don't compute cross-location metrics that would leak counts of individual protected records.
Multi-location Fire It works because membership is a first-class object. A person can be an admin at one shop, a manager at another, and staff at a third — each membership carrying its own role and its own scope. The dashboard reflects the current membership context, and switching between shops is an explicit action that resets permission scope. The database backs that model with row-level policies, so a UI bug can't leak data across locations even if the client made the wrong request.
The temptation with group reporting is to average everything across locations. Fire It intentionally resists that pattern. Owner dashboards show per-location numbers side by side, with the group total only where the math is defensible — captured ticket count, minutes used, plan overage. Averages that would blur meaningful per-shop differences are omitted deliberately. That lets an owner spot the one shop dragging the group down instead of celebrating a group average that hides it.
The most common multi-location failure is enabling a second shop before the first is running clean. Fire It's rollout guidance is deliberately conservative: run the pilot shop for two weeks, review daily transcripts, tune aliases, and only then clone the configuration into a second location. Cloning copies menu structure and settings but not sold-out state or hours — because those are per-shop facts the second location has to own from the first day.
The habit that separates functional multi-location Fire It rollouts from stalled ones is a fifteen-minute Wednesday morning review the owner runs across every shop in the group. Open the dashboard, sort the location list by captured tickets last week, and read three transcripts from the lowest-performing shop. Nine times out of ten the problem is a stale alias, a mispriced modifier, or an hours override that never got turned off after a holiday. Fix the one thing that stands out, note it in the shared operations log, and move on. The point isn't to audit every call — it's to keep the drift between shops small enough that the group configuration stays honest instead of quietly forking. Owners who skip this ritual watch their best shop's numbers drag toward the worst shop's numbers within a quarter; owners who keep it watch the reverse. Cross-links worth bookmarking during the review: the group-wide implementation checklist at /resources/tools/implementation-checklist, the ROI reconciliation at /resources/tools/roi-calculator, and the fit criteria at /solutions/pizzerias/multi-location for pizza-forward groups.
Start on Fire It or try the live Neon Slice demo — no card required.