For a small restaurant, an AI implementation plan fits on one page: two or three jobs chosen after a week of tracking where time leaks, an owner for each, the tool and its monthly cost, a 90-day trial with one measure per job, and a written list of what AI won't touch, such as allergen answers.
What follows is one illustrative restaurant's plan from start to finish: the week of tracking, the jobs chosen and rejected, the plan itself, six months of rollout, the numbers at day 90 and what changed along the way. The restaurant and its figures are invented to show the method. Swap in your own numbers as you go.
The restaurant before the plan
Say it's a 48-cover neighbourhood restaurant, open Wednesday to Sunday, with twelve staff including part-timers. The owner is also head chef. A front-of-house manager runs the floor and the diary. The restaurant uses a cloud POS that includes an AI assistant, an online booking platform, and a shared office suite for email and documents.
The owner's complaints were familiar. The phone rings through service and the host can't answer it while seating guests. Supplier orders get written at midnight on Sunday. The rota eats the manager's Sunday evening. Online reviews go unanswered for weeks, and the owner feels guilty about it. Before choosing any tool, the manager tracked one full week.
| Task | Time in the tracked week | Notes |
|---|---|---|
| Phone calls during service | About 9 hours answered, plus 22 missed | Missed calls clustered between 6.30 and 8.30pm |
| Supplier ordering and emails | 5 hours | Owner, late at night, from memory and a notebook |
| Rota and shift swaps | 4 hours | Manager, mostly messages about swaps |
| Review replies | None | 31 reviews unanswered across two review platforms |
| Menu and specials copy | 2 hours | Written from scratch each change |
| Social media posts | 3 hours | Owner, irregular |
Tracking first matters because it replaces "we're always busy" with a list you can rank. If your week looks similar, where AI actually saves time in a small restaurant shows which of these jobs usually respond best.
Choosing three jobs and ruling out four
The owner scored each job on hours involved, money at stake and what happens if AI gets it wrong. Three went into the plan. Four were ruled out on purpose, and writing those down turned out to be as useful as the chosen three.
| Job | Why | Decision |
|---|---|---|
| Phone overflow during service | 22 missed calls a week; many look like booking attempts | In: answering-only line first |
| Review replies | Big backlog; low risk if a person approves each reply | In |
| Supplier order drafts | 5 hours of the owner's week; sales data already in the POS | In |
| Rota and labour forecasting | 4 hours a week, but needs a paid scheduling tier | Deferred to month 6 |
| Allergen and dietary answers | Safety risk; must go through the kitchen | Out, permanently |
| AI-generated food photos | Guests expect the plate they see | Out |
| Automatic menu price changes | Low volume, loyal regulars, reputational risk | Out |
| AI screening of job applicants | Risk of unfair filtering; small numbers anyway | Out |
The allergen decision follows the reasoning in whether an AI chatbot should answer allergen questions. The hiring decision reflects the risks in AI bias in hiring, pricing and credit.
Social posts, three hours of the owner's week, didn't make either list, and the reason is worth copying. Scored 1 to 5, they came out at 3 for hours, 1 for money at stake (nobody could link a post to a booking) and 1 for risk if AI got it wrong. That's a low-risk, low-value job, and the business assistant seats bought for review replies could handle it informally. So it went into the plan as a note rather than a job: "Owner may use the assistant for post drafts; not measured." Giving it a measure would have meant tracking something the restaurant couldn't act on, and a fourth measured job in month one was more than the manager had time for.
The one-page plan
This is the document the owner and manager signed off. It's short on purpose; the format follows the idea behind a one-page AI strategy.
RESTAURANT AI PLAN Owner: owner-chef
Start: [date] Review: day 30, day 90, month 6
GOALS FOR THE NEXT SIX MONTHS
- Take the phone off the floor during service
- Answer every review within 3 days
- Halve the time spent on supplier orders
JOB 1 Phone overflow
Owner: front-of-house manager
Tool: AI phone line, answering only; calls forward to it
when unanswered after 4 rings
Cost: $150/month, billed monthly during the trial
Measure: missed calls per week (baseline 22) Target: under 5
JOB 2 Review replies
Owner: front-of-house manager
Tool: business chat assistant, saved prompt in the house voice;
every reply approved before posting
Measure: days to reply (baseline: 31 unanswered) Target: 3 days max
JOB 3 Supplier order drafts
Owner: owner-chef
Tool: POS AI assistant (included) + chat assistant with a
par-level sheet
Measure: ordering hours per week (baseline 5) Target: 2.5
AI WILL NOT BE USED FOR
- Allergen or dietary answers (always a person, checked with kitchen)
- Hiring decisions or screening applicants
- Menu photos
- Replies to complaints about illness or injury (owner replies)
DATA RULES
- Business plan for the assistant (no training on our data by default)
- No card details or guest phone numbers pasted into the assistant
BUDGET
- Trial: about $200/month Ceiling: $350/month
DECISIONS AT MONTH 6
- Upgrade the phone line to take bookings?
- Add rota forecasting?
The $200 was the answering-only phone plan at $150 a month on monthly billing, plus two business assistant seats at $25 each. The POS's AI assistant cost nothing extra.
Month by month
Month 1: baseline, setup and the phone line
The manager counted calls for two more weeks to confirm the baseline, then spent about six hours writing the phone line's knowledge: opening hours, directions and parking, the booking link, how to handle large parties, and one fixed line for any allergy mention ("I'll pass this to the team, who'll call you back before your visit"). The line went live on overflow in week three, after one catch in testing. The manager rang in posing as a parent whose child has a sesame allergy. The assistant replied: "No problem, the team will call you back to confirm the dish is safe for your child." The meaning had shifted from "we'll check" to "we'll confirm it's safe", which is a promise the kitchen might not be able to keep. The fix was marking the allergy line in the knowledge base as a script to be read word for word, then ringing again with three differently worded allergy questions until every reply matched it. The review backlog was cleared over two evenings using the assistant, with the manager approving each reply. For the day-by-day detail of a first month like this, see your first 30 days of AI in a restaurant.
Month 2: ordering drafts, tested in the background
The owner built a par-level sheet (the stock level to top up to for each item) and asked the POS assistant for sales by dish for the past four weeks. The chat assistant turned sales, pars and the booking count into a draft order for each supplier. For three weeks, the owner wrote orders the old way as well and compared. Only when the drafts matched closely did they start sending them, after a check.
The weekly request for the vegetable supplier looked like this, trimmed to four lines of the par sheet:
Draft next week's order for our vegetable supplier.
Par levels for a normal week of about 260 covers:
Shallots, kg, 6
Tenderstem broccoli, kg, 8
Lemons, each, 60
Flat-leaf parsley, bunches, 20
In stock tonight: shallots 2 kg, broccoli 1 kg, lemons 22, parsley 4.
Bookings next week: 310 covers.
Scale each par to the covers, subtract stock, round UP.
Show the working for every line.
A typical draft (illustrative):
Shallots: 6 x 1.19 = 7.2 kg needed, 2 in stock -> order 6 kg
Broccoli: 8 x 1.19 = 9.5 kg needed, 1 in stock -> order 8 kg
Lemons: 60 x 1.19 = 72 needed, 22 in stock -> order 50
Parsley: 20 x 1.19 = 24 bunches, 4 in stock -> order 20
Asking for the working is what made it checkable in a minute. Broccoli needed 8.5 kg and the draft rounded down to 8, despite the instruction, so it became 9. Lemons only come in boxes of 80, which the assistant couldn't know, so the owner added a "supplier unit" column to the par sheet and the problem didn't recur. Those two catches in the first week are why the parallel run lasted three weeks rather than one.
Month 3: the day-90 review
Each job was marked keep, fix or cancel against its measure. All three were kept; two were fixed (details below). The review note the owner and manager signed read:
DAY-90 REVIEW
Job 1 Phone overflow 22 -> 6 missed calls/week (target under 5)
KEEP + FIX Holiday hours go on the weekly closing
checklist. Price the booking tier: 17
booking messages a month need callbacks.
Job 2 Review replies 31 unanswered -> 0; 2 days on average
KEEP + FIX Replies sound alike. Rewrite the prompt
with 10 of the owner's past replies.
Job 3 Supplier orders 5 -> 3 hrs/week (target 2.5)
KEEP Supplier-unit column added. Watch the
autumn menu change for new dishes.
Spend About $200/month, ceiling $350. No change.
Next review: month 6
Writing "target not met" next to two jobs and keeping them anyway is normal. The measures were set as targets, not pass marks, and both were moving the right way with a clear fix.
Months 4 to 6: the phase-two decisions
With three months of data, the owner looked at the deferred jobs. The phone line's call summaries showed about 17 booking messages a month that the manager was calling back the next morning. That made the case for upgrading to a tier that books directly. Rota forecasting was trialled on the scheduling app's higher tier for one month, linked to the covers forecast described in forecasting covers and cutting food waste with AI.
The numbers at day 90
| Measure | Baseline | Day 90 (illustrative) | Target met? |
|---|---|---|---|
| Missed calls per week | 22 | 6 | No (target under 5), but close |
| Calls interrupting staff during service | About 38 a week | About 21 a week | Not a target; welcome side effect |
| Unanswered reviews | 31 | 0; replies within 2 days on average | Yes |
| Supplier ordering time | 5 hours a week | 3 hours a week | No (target 2.5) |
| AI spend | $0 | About $200 a month | Within budget |
The money side is less certain than the time side. The phone line flagged about four callbacks a week as booking attempts that became bookings, roughly 17 a month. At 2.4 covers per booking and $42 a head, that's about $1,710 of revenue, or around $1,110 after food and drink costs at a 65% margin. Some of those guests would have rung back anyway, so the owner counted half, about $550 a month, against $200 of spend. Two hours a week of the owner's ordering time went back into menu development, which is harder to value but was the point.
The 17 is only worth using because it was checked. Once a week the manager exported the phone line's call summaries tagged "booking request", took each caller's number, and searched the booking platform for a reservation under that number made within two days of the call. Of 19 flagged calls in one month, 17 had matching bookings; one was a duplicate of a booking already made online and one never booked. Without that match, the owner would have been counting every call the AI heard about a table as revenue it had won.
What the plan cost in hours, not only dollars
The $200 a month was the easy number. The owner also logged the hours the plan took, because in a restaurant this size staff time is the scarcer resource.
| Work | Who | Time |
|---|---|---|
| Extra two weeks of call counting | Manager | About 1 hour in total, using the phone log |
| Writing the phone line's knowledge | Manager, checked by owner | 6 hours, once |
| Review prompt and clearing the backlog | Manager | 4 hours, once |
| Par-level sheet and three weeks of parallel ordering | Owner | About 10 hours, once |
| Updating the phone line for hours and specials | Manager | About 20 minutes a week |
| Approving review replies | Manager | About 10 minutes, three times a week |
That's roughly 21 hours up front and under an hour a week afterwards. Against it, the owner got about two hours a week back from ordering, and the floor lost around 17 phone interruptions a week during service. The up-front hours were paid back in roughly the first three months. Seeing the setup cost written down also explains why the plan chose only three jobs: a fourth would have doubled the up-front work in a month when the manager had none to spare.
What changed in the plan along the way
- The phone line gave wrong hours twice in week one, after a public-holiday change to opening times that nobody updated. "Update the phone line" joined the weekly closing checklist, next to the specials board.
- Callbacks became a chore. An answering-only line turns booking calls into messages. That was fine for a trial, but it's why the month-6 upgrade happened.
- Review replies started to sound the same. After a month, the manager rewrote the prompt with ten of the owner's own past replies as examples and a rule to vary openings. Guests noticed the difference in tone; so did the owner. Three openings from the same week, before and after, show what changed:
Before: "Thank you so much for taking the time to leave such a lovely review!" / "Thank you so much for your wonderful review!" / "Thank you so much for your kind words!"
After: "The lamb shoulder is my favourite thing on the menu too, so that made my week." / "Sorry the wait for mains dragged on Saturday. We've changed how we pace the kitchen on full nights." / "Glad the birthday went well, and thanks for mentioning the team by name."
The new rule that did most of the work: open with the specific thing the guest mentioned, never with "thank you". - Order drafts went wrong when the menu changed. New dishes had no sales history, so the assistant under-ordered their ingredients. The owner now adds an expected-portions figure for any new dish in its first two weeks.
- The host worried about being replaced. The owner explained at a team meeting that the line only catches calls nobody could answer, and that the host's time was going into greeting guests and managing the floor. What was actually said, more or less: "The phone line only picks up after four rings when nobody's free. Nobody's hours change. The difference is you get to stay with the table in front of you instead of running to the phone." Saying it early, in those plain terms, stopped a rumour.
Adapting this plan to your restaurant
- Counter-service café: swap the phone line for replies to Instagram and website messages, where most of your enquiries arrive. Job 1 might read: Owner: shift lead. Tool: Meta's Business Agent answering hours, menu and collection-time questions in Instagram direct messages, with anything about allergens, complaints or catering orders handed to a person. Cost: Meta has charged it per token since August 2026, which it puts at roughly 4 to 5 cents a message, so about 200 messages a month is around $8 to $10. Measure: messages unanswered after two hours (baseline from one week's count).
- Takeaway-heavy restaurant: go straight to a phone tier that takes orders into the POS, because messages are useless for orders. The measure changes too: count order errors per 100 phone orders (wrong item, missed modifier, wrong collection time) as well as missed calls, and in the first fortnight have someone read every order ticket against the call summary before it reaches the kitchen.
- Fine dining: keep the phone human for longer and put AI on review replies, guest-note summaries and supplier admin.
- Two or more sites: keep the same plan, but give each job an owner at each site and compare the measures between them.
The structure stays the same whatever you change: track a week, choose few jobs, write down what's off-limits, give each job an owner and a number, and review at 90 days. If you'd rather build that plan with someone, that's what my AI implementation consultation covers.
Further reads
- How Much Does AI Cost a Small Restaurant Each Month? — Price the tools in your own plan line by line.
- Restaurant AI Tools: 12 Questions to Ask Before You Sign Up — Twelve questions to put to each vendor the plan names.
- How to Train Front-of-House Staff to Work Alongside AI — Bring hosts and servers along with the phone line.
- How to Answer Restaurant Complaints With AI Without Escalating — Extend the review-reply job to complaints safely.
- How to Build a Restaurant Staff Rota With AI Demand Forecasts — The phase-two job this restaurant deferred.
- AI Phone Answering for Restaurants: What It Costs and Pays Back — Decide whether a booking-tier phone line pays for you.
- AI Menu Engineering: Which Dishes to Promote, Reprice or Drop — Run the classic menu engineering matrix with AI on your own till data, with a worked ten-dish example and a price-test calculation you can copy.
- AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.
Sources: Maple, OpenAI (ChatGPT Business) and Toast product and pricing pages, checked September 2026. The restaurant, its figures and results are an illustration, not a client case.