Rogue Command Center — owner preview walkthrough
One clear picture of every location
Rogue Command Center brings location performance, exception reports, connection health and practical next steps into one workspace. Start with the group, focus on a restaurant, and move from a number to the reason it deserves attention.
This is a product preview. The shareable demonstration uses clearly labeled sample data. It does not expose live restaurant finances or send messages. The production workspace uses authorized data only and identifies missing, provisional or unverified results. A working preview is separate from a deployed, connected restaurant account.
A 60-second owner introduction
“Command Center gives us a shared place to see our restaurants, understand what changed, and follow up with a clear next step. Choose a location or the group, build a briefing, then open the detail behind a result. We can compare periods, review comp and void exceptions, and test rules before turning them on. This preview uses sample numbers; real reporting follows verified connections and reconciliation. The experience is ready to explore, and every live capability will show its source and status.”
Start with the decision, then explore the detail
The owner flow is simple: choose locations and dates, build a briefing, review what changed, and open the underlying report. Use a single restaurant for a focused conversation or several for a group view. Every number stays connected to its location, period and source quality.
A five-minute tour
1. Choose the question and the locations
Use the location selector to choose one restaurant or an approved group. Pick the business dates you want to review. A Copley manager should see Copley's permitted information; an authorized group owner can compare multiple locations.
Use one location to investigate an issue. Use several locations to understand patterns. Business dates follow the restaurant's timezone and closing boundary, so an after-midnight transaction is not automatically assigned to the wrong operating day.
2. Read the overview
Build an owner briefing to bring the selected period into focus. Qualified totals and location summaries sit alongside source health and useful next actions. Open the underlying report whenever you want the full detail.
A missing connection points you toward setup. Incomplete data calls for checking the missing dates or locations. A matched exception points to the relevant report.
Each recommendation connects what happened, where and when, why it deserves attention, and the next useful action. Start with the evidence, then use your operational judgment. The goal is a shorter path from finding an issue to understanding it.
3. Open a report
The report library explains each report's purpose and required sources. The initial working report families are:
| Report | What to use it for | Read the definition |
|---|---|---|
| Sales summary | Compare location-level order sales over the selected dates | The first Standard API version reports check sales before refunds, not fully reconciled accounting net sales. |
| Comps and voids | Review approved comp categories and uniquely counted voided items | Promotions are not automatically comps. Sale-day snapshots are distinct from an event-day audit ledger. |
| Product mix | See which items sold, quantities and observed sales by location | Identically named items remain separate until their identities are deliberately mapped. |
Finished reports appear before the template library, so the answer is easy to find. For sales and comps/voids, use the preceding-period comparison to see both periods and the change. A one-day selection compares with the preceding day; a seven-day selection compares with the immediately preceding seven days. This is a calendar-period comparison, not an adjustment for holidays, events or seasonality.
Both periods must have matching locations, currency and complete qualified data before a change is shown. A zero baseline is labeled instead of turning into a misleading percentage.
Each result shows coverage, source timing and limitations. Unavailable or partial results are labeled clearly, so you can distinguish a quiet day from a missing source. CSV exports use the same authorized scope as the on-screen report.
4. Turn a question into a rule
Start with a plain-language condition, choose ALL or ANY when combining conditions, set a threshold, and inspect the resulting rule before enabling it. Test against historical observations first.
Example: Town Tavern Copley comps plus voids above $120.
- Select Town Tavern Copley.
- Choose the qualified comp-plus-void metric and the greater than operator.
- Enter $120.00. Exactly $120 does not match; $120.01 does.
- Confirm which discount definitions are approved comps and which void valuation applies.
- Backtest the rule and inspect the evidence for matched dates.
- Leave email delivery pending while the owner clarifies James House's destination and scope. In-app simulation is available in the demo. Production email remains disabled until recipients are verified; the Donovan owner remains included.
- Enable only after the source, definition and delivery test are qualified.
The initial rule engine reviews completed sale-business days. A matching alert brings together the restaurant, date, threshold and observed amounts, with a route back to the authorized workspace. That makes follow-up specific and easy to explain. Tracking every change as it happens during the day is a separate future capability.
5. Understand the connection panel
The connection panel answers three different questions: Is the account configured? Can the required API be read? How current is the data? A saved setting alone is not a verified connection.
The production design runs the connection on the server, with a separate mapping for each restaurant, so no one needs to leave a browser open. Once deployed and enabled, the existing scheduler refreshes eligible locations in bounded batches. The last successful refresh and source status show how current the information is. The demo simulates this flow and does not run production refreshes.
6. Make the next decision
Use the report to decide where a human should look next: a surprising exception, a missing source, a menu item needing review, or a location worth comparing with its own history. Keep the evidence and the next step together.
The report library can grow with the connected sources
These templates have meaningful uses, but must remain visibly unavailable until their required sources and calculations are implemented and qualified:
| Template | Operational question | Additional requirement |
|---|---|---|
| Labor efficiency | How do sales and labor hours relate by location and period? | Authorized actual labor hours and wage definitions. |
| Scheduled versus actual staffing | Where did worked hours diverge from the published schedule? | Workforce schedule plus correctly matched time entries. |
| Overtime exposure | Which approved time patterns need a manager's attention? | Labor records and a reviewed overtime policy. |
| Menu margin | Which items contribute the most after defined ingredient costs? | Dated recipe/item costs and agreed margin definitions. |
| Delivery reconciliation | Do marketplace settlements agree with the relevant transactions? | Marketplace statements, payments, fees and refunds. |
| Cash over/short | Which closeouts need a cash reconciliation? | Cash-management closeout records. |
| Event and promotion comparisons | What changed around a promotion compared with an appropriate baseline? | Verified event dates and a matched comparison period; correlation is not causation. |
| Stockout exposure | Which unavailable items may be limiting sales? | Historical stock observations and item identity mapping. |
Cross-location reporting compares the same metric across permitted restaurants. Cross-source reporting adds another perspective—for example, actual sales alongside labor hours or a published staffing schedule. Those comparisons become available as the source connections, restaurant mappings and definitions are verified.
Menu changes and Toast IQ
Toast's public Menus API reads published menu information; it does not edit item names or prices. The supported path is to review a proposed change, edit and publish it in Toast Web or Toast IQ, then verify the published result. This keeps the source of the menu clear while giving operators a useful place to review its performance.
Toast IQ is useful for permitted questions and supported actions within Toast. No public external IQ assistant API was established in this review. The value of Command Center is its consistent multi-location workspace, explicit source quality, defined rules and future qualified cross-source reporting.
What is needed for live operation
- Standard API credentials and read access: verified for nine approved restaurants. This is access verification, separate from live reporting activation.
- Secure server provisioning and a verified restaurant-to-location map.
- Source calculations reconciled with Toast, including comp classifications.
- Deployment and a successful scheduled-refresh readback.
- Verified recipients, delivery policy and a controlled alert test before notifications are enabled.
Standard API is the starting point for Rogue's internal reporting. A public partner application is not required for that use. Analytics API is a separate option; it was disabled in the inspected account. Additional custom write access must be discussed with Toast for the specific action, and does not make the public Menus API writable.
Source notes
Reviewed against Toast's official Standard API overview, read-only Menus API contract, and Toast IQ menu capabilities. This walkthrough is revised as source, deployment and connection evidence changes.