Restaurant workflow automation for multi-site operators
Workflow automation moves work between systems and people without anyone doing the hand-offs. A trigger starts it, each step runs in order, exceptions go to a named person and every run is on record. For a multi-site operator it means the checklist, the approval and the alert happen the same way at every site.
- Every step visible
- Exceptions go to a person
- Every run on record
Proof
- 80,000+
- venues on Purple, in 90 countries
- 500 million
- logins across the Purple network a year
- 2 million
- people onboarded every day
- 1,000+
- connectors
Purple runs WiFi and guest data for brands such as McDonald's, JPMorgan, Whitbread, Premier Inn, SoFi Stadium, Pizza Express, Stonegate.
What is workflow automation for a multi-site business?
It is a repeatable path that starts on a trigger, reads and writes across your systems, sends exceptions to a named person and records every run. It replaces the hand-offs in a process, such as the opening checklist or the approval, so each site does it the same way without chasing.
Every multi-site business already runs on workflows. Most are just carried by people: the manager who remembers to send the closing figures, the area lead who chases the checklist, the finance clerk who copies the booking into the rota. They work until someone is on holiday, a site is added, or the volume doubles.
Automating a workflow does not remove the people. It removes the carrying. The steps that are the same every time run on their own, at every site, at the same time, and the person is pulled in only for the part that needs them: the exception, the approval, the decision.
Four things start a workflow. A schedule: every morning at six. An event: a booking is cancelled. A request: a manager asks for the weekly report. A threshold: labour crosses plan. Most useful multi-site workflows are triggered by an event or a threshold in the data, which is why they need the data connected first.
Trigger
Schedule, event, request or threshold
Then: Read the data
Read the data
From the connected systems
Then: Apply the rule
Apply the rule
Fixed steps, no judgement
Then: Act; Cannot decide: Named person
Act
Write, send or create a task
Then: Record the run
Named person
Handles the exception
Record the run
What ran, when, on which data
Which workflows should you automate first?
Start with high-frequency, rule-based work that crosses systems and wastes manager time: opening and closing checklists, low-stock and labour alerts, booking reminders, holiday and invoice approvals, and maintenance requests. Choose ones where the steps never change and an exception has an obvious owner.
| Workflow | Trigger | What it does | Exception goes to | Systems |
|---|---|---|---|---|
| Opening and closing checklists | Schedule at open and close | Sends the checklist, chases overdue items, logs completion | Area manager | Checklists, calendar |
| Low-stock alert | Stock below the reorder level | Alerts the manager with a suggested order | Site manager | Till, stock |
| Labour overrun alert | Labour above plan mid-week | Flags the site and the likely cause | Area manager | Rota, till |
| Booking reminder and no-show chase | Booking 24 hours away | Sends a reminder, flags unconfirmed bookings | Host or reception | Bookings, email |
| Holiday request approval | A request is submitted | Checks cover, routes to the approver, updates the rota | Site manager | Rota, calendar |
| New starter onboarding | Offer accepted | Creates tasks, accounts, induction slots | People team | HR, email, calendar |
| Maintenance request to engineer | Issue reported | Creates a job, notifies the engineer, tracks to closure | Facilities lead | Checklists, email |
| Supplier invoice match | Invoice received | Matches to the delivery, flags mismatches | Finance | Finance, stock |
| Weekly site report | Schedule on Monday | Compiles each site's numbers, sends for approval | Area manager | Till, bookings, rota, footfall |
| Compliance check escalation | A check is overdue | Reminds, then escalates up one level after a set time | Regional manager | Checklists |
The pattern across the list is the same. The trigger is clear, the steps do not change, the data lives in two or three systems, and a specific person owns the exception. That is the profile of a good first workflow. A workflow that needs judgement at every run is an agent's job, and one where a person enters information is an app's.
How do you map a process before you automate it?
Walk the process as it is done today, write each step with who does it, in which system and how long it takes, mark every hand-off and every exception, then remove steps before you automate any. A map made at a desk misses the workarounds that matter.
Process mapping has a bad reputation because it is often done in a workshop with a whiteboard and produces a tidy diagram of a process nobody follows. The useful kind is done standing next to the person doing the work. Ask what they do when the till is slow, when the supplier changes the delivery, when the checklist is not signed. The answers are your exceptions, and they are most of the design.
The second discipline is deletion. Every step you automate becomes something that must be maintained, so automate only steps that deserve to exist. If a report is produced and nobody reads it, the workflow is to stop producing it.
| Step | Who today | System | Time | What goes wrong | Keep, change or delete |
|---|---|---|---|---|---|
| Export sales | Site manager | Till | 20 min | Export times out on busy weeks | Automate |
| Export bookings | Site manager | Bookings | 15 min | Different date format | Automate |
| Combine in a sheet | Site manager | Spreadsheet | 60 min | Formulas broken by a new row | Delete: the connection joins them |
| Check the numbers | Site manager | Spreadsheet | 15 min | Totals do not match the till | Keep, as a review |
| Email to area manager | Site manager | 5 min | Sent late or to the wrong person | Automate | |
| Read and chase | Area manager | Half a day | Missing reports | Delete: every report arrives |
Map a process in six steps
Walk it with the person who does it
Stand next to them for one full run. Write down what they actually do, including the workaround.
Check: The map includes at least one step nobody wrote down before.
Record who, where and how long for each step
Name the person, the system and the minutes. Time it rather than asking.
Check: Every step has a duration.
Mark every hand-off
A hand-off is where work moves between people or systems. They are where delay and loss live.
Check: Each hand-off is marked.
List the exceptions
For each step ask what goes wrong and who fixes it.
Check: Every exception has an owner.
Delete before you automate
Strike steps that exist only because of the old process. Do not automate waste.
Check: The map is shorter than when you started.
Decide the owner, the trigger and the record
Name who owns the workflow, what starts it and what gets logged.
Check: A one-paragraph workflow description exists.
How do you handle exceptions and failures?
Design for the failure before the success. Retry a few times with a pause, then alert a named owner with what failed and what the workflow already did, then let them fix, skip or stop it. Each workflow runs once per trigger, so a retry never double-sends or double-books.
Vendor guidance on workflow automation concentrates on the happy path. At 40 sites the happy path is the easy part. What decides whether the workflow survives its first month is what it does when the till API is slow, a booking arrives with no site, or the approver is on holiday.
Three properties matter. Workflows should retry transient failures automatically, with a pause that grows, because most outages clear on their own. A run should be safe to repeat: running twice must have the same effect as running once, a property called idempotency, so a retry never sends two reminders or books two rooms. And every failure should reach a person with enough context to act: what failed, at which site, which steps already ran and what is left.
A step fails
Source slow or data missing
Then: Retry with a pause
Retry with a pause
A few times, each longer
Still failing: Alert the owner; Recovers: Outcome recorded
Alert the owner
What failed, where, what already ran
Then: Owner decides
Owner decides
Fix and resume, skip or stop
Then: Outcome recorded
Outcome recorded
On the run's record
| Failure | Automatic response | Human decides |
|---|---|---|
| Source system unavailable | Retry with growing pauses; hold dependent steps | Owner, if it lasts past the retry window |
| Data missing or unmatched site | Stop that site's run; continue the rest | Data owner fixes the mapping |
| Rule cannot decide | Route to the named person with the facts | The exception owner |
| Approval not given | Remind, then escalate one level after the set time | The next approver |
| Duplicate trigger | Ignore: a run is safe to repeat | Nobody |
| Action rejected by the target | Record, alert and do not retry blindly | Owner of the target system |
Who owns an automated workflow?
A named person, with a backup, who reviews the run record on a fixed day and is the only one who can change it. Ownerless workflows drift: nobody notices when they stop, and nobody dares switch them off. Write the owner on the workflow card.
Ownership is the most skipped part of workflow design and the most common reason a workflow quietly dies. A workflow with no owner keeps running after the process changed, or stops without anyone noticing, and the first sign is a missed report weeks later.
The fix is a one-page card for each workflow, kept beside the run record, and a rule that a workflow without a card does not run.
| Field | Example |
|---|---|
| Purpose | Make sure every site completes daily compliance checks |
| Trigger | A check is more than two hours overdue |
| Steps | Remind the site manager; after two hours, notify the area manager |
| Owner and backup | Facilities lead; regional manager |
| Exception route | Site closed or system down goes to the facilities lead |
| Review | Run record, every Monday |
| How to stop it | Owner switches it off from the workflow page; the record shows when and by whom |
| Data and permissions | Reads checklist status only; writes reminders and notes |
Workflow automation, RPA or an agent: which should you use?
Use a workflow when the steps are fixed and the systems have connections. Use an agent when the steps change with the data. Use RPA, software that clicks through screens like a user, only when a system offers no connection at all, because it breaks whenever the screen changes.
| Approach | How it works | Strength | Weakness | Use when |
|---|---|---|---|---|
| Workflow | Steps run in order through each system's connection | Stable, fast, easy to audit | Cannot handle variation without a new branch | Steps are fixed and the systems have connections |
| RPA | A software robot operates the screen as a user would | Works with systems that have no connection | Breaks when a screen changes; slow; hard to monitor | A legacy system offers no other way in |
| Agent | Decides which steps to take, inside permissions | Handles variation and judgement | Needs guardrails and review | The answer changes with the data |
| Internal app | A person enters or approves in a screen | Structured input, one place | Does nothing unless a person acts | A person must provide or decide something |
The decision is rarely either-or. A common pattern is a workflow that carries the fixed steps and calls an agent for the one step that needs judgement, such as deciding which of a site's overnight alerts matter. Keep the agent's step narrow, with the workflow around it supplying the schedule, the permissions and the record.
How do you automate approvals across sites?
Define each approval once: who approves, up to what limit, how long they have and who it escalates to. Route requests to the right approver by site and amount, remind before the deadline, escalate one level after it, and keep the record. The workflow handles routing; people still decide.
Approvals are where multi-site businesses lose days. A request waits in an inbox, the approver is away, nobody knows the rule for who covers, and by the time it moves the moment has passed. Automating the routing fixes that without taking the decision from the person.
The design work is the matrix: for each type of request, who approves it, up to which limit, how long they have and who is next. Once that is written down the workflow is mechanical, and the same matrix works at every site.
| Request | Approver | Limit | Time allowed | Escalates to |
|---|---|---|---|---|
| Holiday request | Site manager | Cover maintained | 48 hours | Area manager |
| Extra shift | Site manager | Within labour plan | 24 hours | Area manager |
| Stock order | Site manager | Up to the site's weekly limit | Same day | Area manager |
| Supplier invoice | Finance | Up to the payer's limit | 3 working days | Finance director |
| Maintenance spend | Facilities lead | Up to the repair limit | 24 hours | Operations director |
| New starter | People team | Within headcount plan | 2 working days | Head of people |
Limits and times are examples. Set yours from your own delegation of authority.
How do you set alerts that site managers act on?
Every alert needs an owner, a threshold and an action. Send one alert per issue, to the person who can fix it, with the likely cause and what to do. Alerts that fire constantly or reach everyone are muted within a week, so set fewer and make each count.
Alert fatigue is a design failure. The cause is nearly always the same: thresholds set so tight they fire daily, alerts sent to a group, and no instruction on what to do. After a week of that, managers filter them to a folder.
Good alerts are rare, specific and actionable. They fire when the data crosses a line that matters, name the site and the measure, say how far over or under it is, suggest the likely cause from the other connected data, and go to the one person who can act.
| Alert | Fires when | Goes to | Action it asks for |
|---|---|---|---|
| Low stock | A key item falls below its reorder level | Site manager | Approve the suggested order |
| Labour overrun | Labour cost percentage is above plan by a set margin mid-week | Area manager | Review the rota for the rest of the week |
| No-show spike | No-shows run well above the site's normal rate | Host or site manager | Chase unconfirmed bookings |
| Checks overdue | A compliance check is overdue by the set time | Site manager, then area manager | Complete the check |
| Footfall drop | Visits fall well below the site's usual for that day | Area manager | Check for a local cause: weather, closure, event |
Alert hygiene checklist
0 of 6 done
What does a workflow save?
Multiply the runs by the minutes each saves, then take away the time spent on exceptions. At 40 sites running 14 checks a week, each saving 10 minutes, with 5 percent of runs needing 15 minutes of attention, a workflow returns about 86 hours a week.
Workflow time-saved calculator
Count the runs, the minutes each one saves and the exceptions a person still handles.
- Hours saved each week before exceptions
- 93.3 hours
- Hours spent on exceptions each week
- 7.0 hours
- Net hours saved each week
- 86.3 hours
- Net hours saved a year
- 4,489 hours
Worked example. At the defaults, 40 sites each running 14 checks a week save 93.3 hours before exceptions. With 5 percent of runs needing 15 minutes of attention, exceptions cost 7.0 hours, so the net saving is 86.3 hours a week, or 4,489 hours over a 52-week year.
How the numbers are built
- Minutes saved per run is what the run took by hand, not what you hope it takes.
- An exception is any run a person has to touch, including a quick look.
- The calculation counts hours only. Consistency across sites and fewer missed checks are extra.
How do you start with workflow automation?
Pick one workflow that runs often, follows fixed steps and has an obvious owner. Map it, write its card, run it at three sites for two weeks with a person checking, then roll it to the rest. Add the next workflow only when the first one's record is clean.
Your first workflow, in seven steps
Choose a high-frequency, rule-based process
Opening and closing checklists are the usual first choice: frequent, fixed and easy to check.
Check: You can state the trigger and the steps in two sentences.
Map it with the person who does it
Use the process map template. Mark the exceptions and delete what does not need to exist.
Check: The map is shorter than the process was.
Write the workflow card
Purpose, trigger, steps, owner and backup, exception route, review day and how to stop it.
Check: A colleague could run the process from the card.
Connect only the systems it needs
Read what it reads, write what it writes, and nothing else.
Check: Every connection appears on the card.
Pilot at three sites with a person checking
Run it for two weeks while someone confirms each run did what it should.
Check: Every difference from the manual way is explained.
Roll out to the rest of the estate
Switch on the other sites in waves, and watch the run record for failures.
Check: The run record is clean for the first full week.
Review monthly, then add the next
Check runs, exceptions and time saved. Start the next workflow only when this one needs no attention.
Check: The owner signs off the review.
How does Purple Build create workflows?
You describe the workflow in plain English and Purple Build creates it on your connected data: scheduled or triggered, reading from one system and writing to another, with each step shown so you can see what ran, when and why. Exceptions go to the person you name.
Purple Build treats a workflow as one of the four things you make, alongside dashboards, apps and agents, all on the same connected data. That matters because a workflow rarely stands alone: the trigger is often a threshold on a dashboard measure, the exception is handled in an app, and the one step that needs judgement is an agent.
You describe the process the way you would brief a colleague. Purple Build creates the workflow with each step visible, so you can follow what happened and fix it by saying what to change. Every run is on record, a failed run shows straight away, and production systems stay protected: what you make works on your data without putting the systems your business runs on at risk. Permissions are respected, so a workflow cannot reach data its owner is not allowed to see.
Purple WiFi data is a first-class source and trigger, so a workflow can start from footfall, visits or dwell time as readily as from a till or a booking. We run Purple this way ourselves.
Workflows need connected data to trigger on, so start with connecting your business data. Some steps need judgement that an agent can supply under approval, covered in AI agents for business, and steps where people enter data belong in an internal business app.
The options side by side
| Route | Purple Build | A general automation tool | RPA | Developer scripts |
|---|---|---|---|---|
| Who builds a workflow | The person who runs the process, from a description | A technical user, from a flowchart | A specialist developer | A developer |
| Multi-site by design | Yes: site IDs, role views and permissions shared | Per workflow, built by hand | Per robot | In code |
| Each step visible | Yes, and every run on record | Run history; detail varies | Limited | If logging was written |
| Exceptions to a named person | Yes, per workflow | Possible, built per workflow | Limited | If built |
| WiFi footfall as a trigger | First class, from Purple | A custom feed | No | A custom feed |
| When a system changes | You say what changed | Edit the flow | Rebuild the robot | A developer |
Purple Build runs on the same credits as Purple Engage, with a free tier.
Multi-site workflow automation
All guides in this pillar
Each guide takes one question in this pillar all the way down, with the diagrams, tables and worked examples to act on it.
Workflows by sector
Workflow automation for retail, hotels and leisure operators.
Design
Mapping the process, owning failures and keeping a person in the loop.
Everyday flows
Approvals, alerts and checklists that run across sites.
Multi-site workflow automation
The terms, defined
- Workflow
- A repeatable sequence of steps that starts on a trigger and moves work between systems and people.
- Trigger
- The event, schedule, request or threshold that starts a run.
- Exception
- A run or step the rules cannot handle, sent to a named person.
- Idempotent
- Safe to repeat: running it twice has the same effect as running it once.
- Retry
- Running a failed step again, usually after a short, growing pause.
- Escalation
- Passing a request to the next person when the first does not act in time.
- RPA
- Robotic process automation: software that operates a screen the way a person would.
- Approval matrix
- A table of who approves each type of request, up to which limit and how long they have.
- Workflow card
- A one-page record of a workflow's purpose, trigger, steps, owner and exception route.
- Run record
- The log of one run: what ran, when, on which data and with what result.
FAQ
Questions operators ask
What is workflow automation for a multi-site business?
It is a repeatable path that starts on a trigger, reads and writes across your systems, sends exceptions to a named person and records every run. It removes the hand-offs in a process, such as the opening checklist or an approval, so every site does it the same way without anyone chasing.
Which restaurant workflows should I automate first?
Start with frequent, rule-based work: opening and closing checklists, low-stock alerts, labour overrun alerts, booking reminders, holiday approvals and maintenance requests. Choose ones where the steps never change and an exception has an obvious owner. A good first workflow runs daily and is easy to check.
What is the difference between workflow automation and RPA?
A workflow moves work through each system's own connection, so it is stable and easy to monitor. RPA operates the screen like a person, so it works with systems that have no connection but breaks when a screen changes. Use a workflow wherever a connection exists and RPA only as a last resort.
When should I use an AI agent instead of a workflow?
Use a workflow when the steps are fixed, and an agent when the steps change with the data and a judgement is needed, such as deciding which alerts matter. Many processes combine them: a workflow carries the schedule, permissions and record, and calls an agent for the one step that needs judgement.
How do I handle workflow failures?
Plan for them first. Retry transient failures with a growing pause, make each run safe to repeat so a retry never double-sends, and alert a named owner with what failed, at which site and which steps already ran. The owner then fixes and resumes, skips or stops, and the outcome is recorded.
Who should own an automated workflow?
A named person with a backup, who reviews the run record on a fixed day and is the only one who can change the workflow. Write the owner on a workflow card kept beside the record. Workflows without an owner drift, and nobody notices when they stop.
How do I stop alert fatigue?
Give every alert an owner, a threshold set from the site's own history and an action, send one alert per issue and add a quiet period after it fires. Review monthly how many alerts led to an action, and retire the ones that did not. Fewer, specific alerts are acted on; constant ones are muted.
How much time does workflow automation save?
Multiply runs by the minutes each saves, then subtract time spent on exceptions. At 40 sites each running 14 checks a week, saving 10 minutes per run with 5 percent of runs needing 15 minutes of attention, the net saving is about 86 hours a week. Use the calculator with your own figures.
Can I create workflows in Purple Build without a developer?
Yes. You describe the workflow in plain English and Purple Build creates it on your connected data, scheduled or triggered, with each step visible and every run on record. To change it you say what to change. Your IT team keeps control of what connects and who sees what.
What does Purple Build cost?
Purple Build runs on the same credits as Purple Engage, so one balance covers both, and there is a free tier to start on. You do not need any other Purple product. Waitlist members get early access first, with the systems they name connected first.
Where to go next
Sources and standards
- UK GDPR, Article 5: principles relating to processing
- RFC 9110: HTTP semantics, idempotent methods
- NIST AI Risk Management Framework
Reviewed on 9 October 2026.
Run your whole business from one place
Name your systems, tell us your first build, and they are connected first when early access opens. Or talk it through with the Purple team today.
- Join the waitlistLeave your details and you are first in for early access.
- Tell us what to connectTell us which systems you want to connect and what you would build first, and we connect yours first.
- Get early access firstWaitlist members get early access before anyone else, with a free tier to start on.
Early access
Get your systems connected first
Two questions: which systems you run, and what you would build first. That is all it takes.