The Dinner Rush Your Dashboard Missed

By Ehab Al Dissi · 13 November 2026

It’s 6 p.m. Customers can’t order. The account manager is about to launch a promotion. What should happen first?

Support needs evidence to act, and the account manager needs to know when the merchant can handle more demand. This workflow puts both teams on the same case, from the first alert to the growth decision.

What the account team should see at 6:10 p.m.

In this fictional example, a café is scheduled open at 6 p.m. Two fresh checks show customers can’t order. The merchant hasn’t logged a planned closure. At 6:10, Merchant Support gets one case with the store, the time the problem began, links to both checks, and the next person responsible. When a repeat event comes in, it updates that case rather than creating a second one.

By 7:30, the store has been unavailable for 90 minutes. On comparable evenings, it averages 12 orders an hour at $24 an order. This window recorded no fulfilled sales. The replay estimates a $432 gross sales gap: 1.5 × 12 × $24 − $0. It’s a triage estimate, not confirmed lost revenue, profit, or money the platform can claim it recovered. Some customers may have ordered elsewhere on the platform or come back later.

Here’s the judgment call: if a merchant paused orders because the kitchen was overloaded, turning the store back on can make the problem worse. Confirm the reason with the right owner. Once orders can be fulfilled again, verify the recovery before asking the merchant to take on more demand.

Build the account workflow

1. Read one reliable signal. Start with a status export or a permitted integration for one location. Pull opening hours, holiday exceptions and the last observed orderability status. Store the event time and the time you received it separately. A quiet order log alone cannot tell you the store was closed.
2. Decide with rules. If the feed is stale, send a data check to Integration Ops. If the closure is planned, log it. If ordering is offline during scheduled hours and you have two fresh observations or a confirmed incident, route a recovery case to Merchant Support. Use local time for opening hours and UTC for events, including on daylight-saving transitions.
3. Keep one case open. Put evidence and a next action on the same record. Use a unique event ID to ignore retries and a database constraint to keep one active case per merchant, location and issue type. Upsert the case atomically; reject older updates if a newer state is already recorded. Keep an explicit reopen path for a new outage.
4. Give AI a narrow job. Pass the model the case record and approved policy. Ask it to summarize the evidence, explain what it can’t confirm and draft the next question. Validate the result against the record. A failed model call should leave the case available with a basic template. The model gets no credentials to open stores, issue credits, change prices, buy ads or send messages.
5. Prove service is back. The sample requires two healthy checks and three fulfilled orders since recovery. Set your own threshold by volume and risk. For a low-volume supplier, a verified end-to-end test with the merchant may be more useful than waiting for three real orders. If service fails again, keep growth on hold and reopen support.
6. Give the account manager one growth decision. Propose a small test only when the merchant confirms capacity, fulfillment is stable and expected incremental contribution is positive. Start with a tightly scoped change, like making a recovered menu visible to returning customers in one area. A person approves the proposal; the case still works without a campaign.

What to put in the case record

Keep tenant_id, merchant_id, location_id, event_id, observed_at, local schedule and override, orderability and reason, the evidence links, and the last successful fulfillment. Add an owner, next action, review status, and time the decision was made. Use numbers or links the reviewer can verify. Keep customer details, payment data and credentials out of the model input, and enforce access per tenant before any evidence is loaded.

A draft an account manager can actually use: “We saw ordering unavailable for your Market Street location at 6:00 and 6:10 while your schedule showed you open. Did you pause orders, or should our support team check the connection? We’ll leave promotions on hold until you confirm capacity.” The account manager checks the location and timestamps before sending anything.

Run a four-week pilot

Week 1: Use a small set of locations and manually label real pauses, real incidents, and ambiguous records. Replay those decisions with no messages or changes to merchant settings. Compare with when the current team first spotted the issue. Week 2: Let the workflow open internal cases only. Check every case for the right location, owner, and reason. Review false alerts, duplicate cases, and genuine outages it missed.

Week 3: Track verified recovery, median time to detect and median time to restore. Report how many cases were actually reviewed and count missing data separately. Week 4: If the support workflow is reliable, test one growth action. Randomly hold back comparable eligible stores if there are enough. Compare fulfilled orders and contribution after discounts and costs. If the sample is too small, show raw results and say the incremental effect is uncertain.

Use contribution to make the call. Suppose eligible test stores generate 8 more fulfilled orders per store than the comparable holdout over the same period. At $6 contribution per added order before campaign costs, $48 − $16 in incremental incentives − $12 in added operating costs leaves $20 estimated incremental contribution per store. That is a worked example. Define whose economics you’re tracking: the platform, the merchant, or both. Stop the test if cancellations rise, delivery misses increase or contribution turns negative. Never withhold support from the comparison group.

Start with a spreadsheet if you need to. Download the CSV and add two tabs: incoming status and cases. Set a recurring export or ask one operator to record scheduled hours and verified status for five locations. Once the review process works, wire an n8n Schedule Trigger to a read-only source, route the rules, and write internal cases to a database. The Postgres node can execute a parameterized upsert; put deduplication and account isolation in the database. Keep draft review in the existing case queue.

How it changes for grocery and building supplies

Restaurant delivery: a store stops taking orders

Support: check scheduled hours, the merchant’s pause reason and the ordering system. Growth: propose one local demand test after fulfillment and capacity are verified. Uber documents store status and offline reasons; status-change notifications require scope access. Use an approved integration or your own system data.

Grocery marketplace: the item is on the shelf but missing from the app

Support: compare the store’s stock count, item ID, inventory feed timestamp and ordering availability. Check a small sample with the store before changing stock. Growth: restore a category placement only when availability is stable and substitution and cancellation rates are in bounds. Instacart documents availability fields; DoorDash documents inventory, hours and store activation as separate onboarding steps.

Building materials marketplace: a contractor is still waiting for a quote

Support: flag a request for quote before its deadline, confirm the unit and quantity, verify stock and delivery lead time, and route it to a supplier rep. Draft a quote update from the approved record. Growth: offer repeat ordering or an additional supplier only after price, inventory and delivery have held up. Procore’s RFQ guide illustrates the deadline and response states; it does not validate this marketplace workflow.

The examples use published documentation for data and integration constraints. The browser replay runs fixed rules on fictional records. It hasn’t been connected to a merchant or tested on live sales. The starter thresholds are yours to calibrate.

Start tomorrow: choose five merchant locations, pull one week of status changes, and have Support and Account Management independently label each one. The disagreements tell you what to fix before you automate.

Related: Build a stockout alert · Build the weekly business review · See the other automation workflows.