Every restaurant that runs a real operating cadence has some version of the daily close report. Closing manager sits down at the end of the shift, opens Toast, opens 7shifts, opens the cash log, opens the notebook, writes a summary of the day, sends it up. Forty-five minutes. Every night. Every unit.

In a 21-unit region that is roughly 15 hours of closing manager time per day, most of it retyping the same numbers with slightly different words. It is also 15 hours during which the manager is not on the floor doing the actual close, which is a real service and safety issue.

Automating this workflow is the single highest-value AI automation in most multi-unit operations. It is also one of the simplest. Here is the pattern.

What a daily close report should contain

Before the automation, agree on what the report should say. Every one I have built has the same structure. Six sections. Under 300 words total.

  1. Sales versus forecast. Yesterday's number, the forecast, the variance, one sentence on why.
  2. Labor as a percent of sales. Yesterday's number, the target, the variance, one sentence on why.
  3. Food cost variance. Week to date against theoretical.
  4. Cash controls. Drawer counts, tender variance, deposit total.
  5. Comps and voids. Dollar amount, count, any anomaly.
  6. Notable events. Anything the numbers do not show. VIP dinner, service recovery, equipment issue, staff incident. One paragraph.

That is it. Everything else is decoration. Six sections, one page equivalent, delivered before the area director wakes up.

The automation pattern

The close report pipeline Toastcloses midnight 7shiftslabor 12:30am Cash log · Airtable Make scenario2am merge Claude APIdraft narrative Manager DMSlack · 5am Ops channelSlack · 6:30am

Fig. 1 · From midnight close to morning Slack post.

Step 1: overnight extract

At 2am local time, a Make scenario (or Zapier, or n8n) pulls yesterday's data from three sources. Toast API returns sales, comps, voids, tender types, menu mix. 7shifts API returns labor hours, cost, punch variances, no-shows. An Airtable base holds the cash control log from the closing manager's manual entry (drawer counts, deposit, over/short).

All three feed into one structured JSON blob per unit. Roughly 30 fields.

Step 2: AI draft

The JSON gets passed to Claude via the API with a fixed prompt. The prompt specifies:

  • The six-section format.
  • The word limit per section (rough).
  • The unit's operator voice (via three example past reports pasted into the prompt).
  • Anomaly rules (flag if labor variance exceeds a threshold, if comps exceed a threshold, if cash is over/short beyond a threshold).
  • What not to do (no recommendations, no personnel commentary, no speculation about causes beyond what the data shows).

Claude returns the draft as structured markdown. Roughly 250 to 300 words.

Step 3: manager review

The draft lands in the closing manager's Slack DM at 5am. They see it when they wake up. The DM has three buttons: "Approve as written," "Edit and post," "Reject and rewrite."

Approve as written posts it to the ops channel immediately. Edit and post opens a Slack thread where the manager can add the notable events paragraph and correct any facts. Reject and rewrite flags it for a fresh draft (rare, mostly a signal that the data is wrong upstream).

Ninety-plus percent of drafts get approved with a small edit inside two minutes.

Step 4: post

Final report posts to the regional ops Slack channel at or before 6:30am. Same format across all units. Area director opens Slack, sees 21 posts in the same shape, scans in five minutes.

The prompt that matters

Half the quality of this automation is in the prompt. Here is the shape that has worked for me.

You are drafting a daily close report for a restaurant closing manager. Follow the six-section format exactly. Match the operator's voice from the three example reports below. Do not recommend actions. Do not speculate about causes beyond what the data shows. Flag any anomaly using the rules below. Keep total length under 300 words.

Then paste in three example past reports the operator wrote themselves. Then paste in the anomaly rules. Then paste in the JSON. The output is close enough that most managers approve with a one-sentence edit.

Where operators go wrong automating this

Cutting the manager out

Some operators try to fully automate the report and post directly. Bad idea. The AI can only report what the data shows. It cannot know that the reason sales missed was a power outage at 8pm, or that the reason comps were high was a genuine service recovery for a repeat VIP. Those context lines are what make the report useful. Keep the manager in the loop.

Letting the AI write recommendations

AI-generated recommendations sound plausible and are usually wrong. "Recommend increasing lunch staffing tomorrow" written by an AI that has no idea about the reservation book, the promo calendar, or the weather forecast. Restrict the AI to facts and anomaly flags. Judgment stays with humans.

Making the report too long

The first version of this I built ran 600 words. Managers stopped reading it. Version two capped at 300. Adoption jumped. The area director's job in the morning is to scan 20 reports fast. If each takes three minutes to read, the whole rhythm falls apart.

Not versioning the prompt

The prompt will evolve. Every time you change it, log the change and why. Otherwise in six months you will not know why the reports feel different, and rolling back is painful.

What it actually costs

Software:

  • Make: about $50 to $100 per month for a 20-unit operation running one scenario per unit per night.
  • Claude API: about $30 to $60 per month at scale, since each report is a small call.
  • Slack: assumed already present.
  • Airtable for the cash log: about $20 per seat per month.

Total software: about $100 to $200 per month for a mid-sized operation. Return: 12 to 15 hours of closing-manager time per day recovered. That math is not close.

The rollout sequence

  1. Week 1: Agree on the six-section format with the operator team. Not before.
  2. Week 2: Build the data extract from Toast and 7shifts. Test with one unit's data.
  3. Week 3: Build the prompt and iterate against three past reports from a strong closing manager. Get the voice right.
  4. Week 4: Roll out to one unit as a pilot. Closing manager reviews for one week and gives feedback.
  5. Week 5: Iterate. Fix the top three complaints from the pilot manager.
  6. Week 6 to 8: Roll out to remaining units, three per week.
  7. Week 9 onward: Monthly review of the prompt. Retire the manual template.

The point

Daily close reports are one of the highest-frequency, lowest-variance writing tasks in a restaurant operation. That combination is the perfect target for AI automation. The manager is still the author. The blank page is gone. The area director gets a consistent morning read across every unit.

If you are running any AI stack at all, this is where I would start. Nine out of ten operators who build it never turn it off.