Footfall to rota: using venue data to staff and plan
Footfall to rota means using how many people are in your venue, hour by hour, to decide how many staff you schedule. It extends to space, conversion and planning: the venue's data answers business questions once it is joined to sales, bookings and the rota. The data is the easy part. The joining and the question are the work.
- Purple WiFi data, first class
- Footfall joined to sales and rota
- Aggregated, not individual
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 does it mean to use venue data in business decisions?
It means treating the people-in-the-building signal as an input to a business question, such as staffing, space or conversion, rather than a number to admire. The signal becomes useful once it is joined to sales, bookings and the rota, because the question always spans systems.
A footfall chart on its own is a curiosity. It tells you Saturday is busier than Tuesday, which you knew. The same chart becomes a decision when it sits beside the till and the rota: Saturday lunch has 420 visits and five people on shift, Tuesday has 90 visits and four, and one of those is wrong.
This guide is about that second step. How WiFi footfall is measured, and what Purple's network records about visits and dwell time, is covered in the WiFi analytics guide on purple.ai. Here the question is what you do with the numbers once you have them, which is a business problem, not a measurement one.
Venue signal
Visits and dwell time by hour
Then: Join to the business
Join to the business
Sales, bookings, rota, calendar
Then: A business question
A business question
How many staff? Which room is empty?
Then: A decision
A decision
Publish the rota, release the room
Then: Weekly check
Weekly check
Forecast against what happened
Improve: Venue signal
| Question | Join | Measure | Decision |
|---|---|---|---|
| How many staff do we need? | Visits, sales, rota | Visits by hour, transactions per staff hour | The rota for next week |
| Are visitors buying? | Visits, sales | Conversion | Offer, pricing, queueing, staffing |
| Is this space earning its cost? | Occupancy, bookings, calendar, lease | Used hours as a share of available hours | Release, resize or sublet |
| What should we plan for? | Visits history, bookings, events | Forecast visits by day and hour | Opening hours, deliveries, hiring |
How do you staff from a footfall forecast?
Forecast visits by hour from the last several weeks, turn visits into transactions with your conversion rate, turn transactions into labour hours with the number one person serves per hour, then set the staff for the peak window. Compare the forecast with what happened every week and adjust.
Most rotas are built from last week's rota. That carries last week's mistakes forward and cannot see a change in demand. A footfall-led rota starts from demand instead, and the method is short enough to do on one sheet.
Take the Saturday lunch peak. The last eight Saturdays at this site averaged 420 visits across the 12:00 to 16:00 window. Conversion at this site is 35 percent, so about 147 visits become transactions. A person at the till or on the floor handles about nine transactions an hour at this site, which makes 16.3 staff hours of demand across a four-hour window, or about four people, and the next whole number up is five. The calculator below does the same sum with your numbers.
Footfall to rota calculator
Turn a forecast number of visits into the staff you need for a peak window.
- Transactions expected
- 147
- Staff hours of demand
- 16.3 hours
- People on shift for the window
- 5
- Rounded up to a whole person
Worked example. At the defaults, 420 forecast visits with 35 percent conversion give 147 transactions. At 9 transactions per person per hour that is 16.3 staff hours across a 4-hour window, so the window needs 5 people on shift.
How the numbers are built
- Visits come from the same weekday and hour over the last several weeks, adjusted for events and bookings.
- Conversion is transactions divided by visits for the same site and window.
- Transactions per person per hour is measured at the site, not taken from a general figure.
- The result is the staff for demand. Breaks, minimum cover and skills mix come after.
Footfall to rota, week by week
Collect eight to twelve weeks of visits by hour
Take visits per site per hour from the venue data, with the trading date and the site's time zone applied.
Check: Every open hour of every week has a value.
Build the profile for each weekday and hour
Average the same weekday and hour across the weeks. Mark weeks distorted by an event, a closure or weather.
Check: A typical Saturday lunch is a single number you trust.
Convert visits to transactions
Use the site's own conversion for that window: transactions divided by visits.
Check: Forecast transactions are within a sensible range of last week's.
Convert transactions to staff hours
Divide by the transactions one person handles per hour at that site.
Check: The staff hours match what the best recent shift needed.
Draft the rota shell and add bookings and events
Lay out the shifts, then add known demand the history cannot see, such as a large booking.
Check: Every peak window has cover and no shift breaks a rest rule.
Publish, then compare forecast with actuals
Each week put forecast and actual visits and hours side by side. Fix the pattern behind any gap larger than you expected.
Check: The gap narrows over four weeks.
How do you combine footfall with sales conversion?
Divide transactions by visits for the same site and window. Then read it with visits, not alone. High visits with low conversion points at the offer, the queue or staffing. Low visits with high conversion points at awareness. A conversion trend that moves with staffing is the one to act on.
Conversion is the simplest measure that needs two systems: transactions from the till, visits from the venue data. Used alone it misleads, because a rise can mean more buyers or fewer window-shoppers. Used with visits it tells you where to look.
| Case | Visits | Conversion | Usually means | First thing to check |
|---|---|---|---|---|
| Busy, not buying | High | Low | Queues, price, offer or staffing are losing sales | Queue length and staff on shift in the peak |
| Busy and buying | High | High | The site is working | Whether staffing can hold the peak |
| Quiet, buying well | Low | High | The product is right, traffic is not | Local marketing, opening hours, visibility |
| Quiet, not buying | Low | Low | Both traffic and offer need attention | Start with traffic, then the offer |
Compare a site with its own history and its peer group. A fixed benchmark across unlike sites is rarely meaningful.
What do dwell time and peak-hour data tell you?
Dwell time shows how long people stay, which separates a quick visit from a long one and tells you about queues, layout and comfort. Peak-hour data shows when demand concentrates, so staffing, deliveries and opening hours follow it. Both need a purpose: report them against a decision.
Dwell time is easy to report and easy to misuse. A rising dwell time can mean customers are enjoying the venue or waiting too long at the counter. The measure tells you something only when you pair it with a second one: sales per visit, queue length or a customer score.
Peak-hour data is more directly useful. Most venues have a demand curve that is sharper than their rota, with a lunch or Friday-evening peak that needs more people than the rest of the day combined. Seeing the curve by hour makes the mismatch visible.
| Measure | Tells you | Read with | Decision |
|---|---|---|---|
| Visits by hour | When demand concentrates | Rota, deliveries | Staffing, opening hours |
| Dwell time | How long people stay | Sales per visit, queue length | Layout, service speed, seating |
| Repeat visits | How often people return | Spend per visit | Whether the offer brings people back |
| Peak to average ratio | How sharp the demand curve is | Labour per hour | Split shifts, flexible cover |
| Occupancy against capacity | How full the space gets | Bookings | Capacity, queuing, comfort |
How do you use occupancy to plan space?
Compare booked use with actual use, hour by hour. Rooms booked but empty can be released after a set time. Space used a small share of the time can be resized or shared. Judge a lease by the hours it is actually used, not the hours it is available.
Universities, offices and coworking operators share one problem: the timetable or the booking system says a room is in use, and nobody checks. A venue signal such as WiFi occupancy shows whether people were actually there, so booked and actual can sit side by side.
Two uses pay for themselves quickly. The first is releasing rooms nobody turned up for. If occupancy shows nobody present fifteen minutes into a booking, a workflow can release the room and tell the person who is waiting for one. The second is judging space on used hours. A floor that is booked solidly but occupied a third of the time is a different asset from one that is full.
Space use calculator
How much of the space you pay for is actually used?
- Space use
- 38%
- Desk hours used each week
- 1,900 hours
- Desk hours paid for but empty each week
- 3,100 hours
Worked example. At the defaults, 38 of 100 desks are occupied on average across a 50-hour week. That is 38 percent space use, 1,900 desk hours used and 3,100 desk hours paid for but empty each week.
How the numbers are built
- Average occupied is taken across the hours the space is open, from occupancy data rather than bookings.
- To value the empty hours, multiply by your own cost per desk hour.
- A short peak can hide a low average, so also look at the busiest hour against capacity.
| Question | Data | Measure | Decision |
|---|---|---|---|
| Are booked rooms used? | Bookings, occupancy | Booked versus actual | Release unused bookings |
| Is the space full when it matters? | Occupancy, capacity | Peak occupancy against capacity | Resize or add capacity |
| Is the lease earning its cost? | Occupancy, lease | Used hours per unit of cost | Renew, sublet or downsize |
| Does the timetable match reality? | Timetable, occupancy | Scheduled versus occupied time | Rewrite the timetable |
How accurate is WiFi occupancy data, and what are its limits?
WiFi counts the devices it sees, so it is a strong sample of the people in a venue, not a headcount. It under-counts people with no device or WiFi off and can over-count anyone carrying two. Use it for trends and comparisons, and calibrate it once against a door count.
Accuracy claims for WiFi-based counting vary widely, and the honest answer is that it depends on the venue, the method and what you use it for. Three facts hold almost everywhere. Not everyone has a phone with WiFi switched on. Some people carry more than one device. And modern phones randomise their hardware address, so methods that count raw addresses seen over the air tend to over-count the same person across visits; counting sessions that actually connect and sign in is steadier.
What matters for decisions is not absolute accuracy but consistency. If the sample is a stable share of visitors, then Saturday lunch at one site is reliably comparable with Saturday lunch at another, and this week with last. That is enough to build a rota and judge a lease. Where you need an exact figure, such as a licensing capacity, use a door counter.
| Limit | Why it happens | What to do |
|---|---|---|
| Under-counts visitors | Not everyone carries a device or has WiFi on | Treat it as a sample; compare like with like |
| Over-counts some people | Some carry two devices; address randomisation inflates raw counts | Use session-based counts rather than raw address counts |
| Counts staff and neighbours | Devices of staff and nearby premises are seen too | Exclude known staff devices; check the edge of coverage |
| Uneven coverage | Dead zones and thick walls change what is seen | Review access point placement for the areas you measure |
| Differs between sites | Venue layout and coverage differ | Calibrate each site once against a door count for a week |
The WiFi analytics guide on purple.ai explains how Purple measures visits and dwell time.
How do you use venue data without tracking individuals?
Use aggregated counts, not people. Staffing, space and conversion decisions need how many, when and for how long, never who. Keep individual-level data out of the reporting layer, minimise what you hold and set a retention period, which also keeps you inside UK GDPR.
Almost every decision in this guide needs a count, not a person. The rota needs the number of people at lunch. The lease decision needs the average number of desks occupied. Conversion needs visits and transactions. None needs to know who the visitor was.
That makes privacy a design choice rather than a constraint. Aggregate at the point where the data enters the reporting layer, so the dashboards, agents and apps that read it only ever see counts by site and hour. Apply data minimisation under UK GDPR Article 5(1)(c): hold the fields the purpose needs and no more. Where individual-level data exists for another lawful purpose, such as a guest's own sign-in for the WiFi service, keep it out of operational reporting, and set a retention period for it.
| Question | Needs individuals? | Use |
|---|---|---|
| How many staff on Saturday lunch? | No | Visits by site and hour |
| Is this room used? | No | Occupancy by room and hour |
| What is conversion? | No | Transactions and visits, aggregated |
| Which lease earns its cost? | No | Average occupied space |
| Which guests return? | Yes, with a lawful basis | A marketing question, handled in Engage, not in operations reporting |
How do you put venue data in board reporting?
Show the few measures a board can act on, each beside the business result it explains: visits against sales, conversion by peer group, space use against cost. Keep the definitions the same as the operating dashboard, and let the figures link back to their source.
Boards do not need the venue data. They need the answers it gives. Three views carry most of the value: the estate's visits and conversion against last year, the space the business pays for against the space it uses, and the sites outside their usual range with the reason. Each should sit next to the financial result it explains, so a drop in sales is read with the drop in visits that caused it.
Use the same definitions as the operating dashboard, and draft the pack from the same connected data. An agent can prepare the draft each period and a person approves it, with every figure traceable.
| Measure | The board's question | How to show it |
|---|---|---|
| Visits against last year | Is demand growing? | Estate and peer-group trend beside like-for-like sales |
| Conversion | Are visitors buying? | By peer group, with the outliers named |
| Space use against cost | Are we paying for space we do not use? | Used hours against lease cost by site |
| Peak against capacity | Do we need more room? | Busiest-hour occupancy as a share of capacity |
| Forecast against actual | Can we plan on this data? | A single accuracy figure, improving |
Can you forecast footfall for operations planning?
Yes, in steps that each add value. Start with the average of the same weekday and hour over recent weeks, then add trend, known events, bookings and weather. A simple forecast checked weekly beats a complex one nobody checks. Measure the gap between forecast and actual every week.
Forecasting does not need a data science team. A same-weekday, same-hour average over the last eight weeks beats guessing, and it is a good baseline. Each addition after that earns its place only if it narrows the gap to actual: a growth trend, a calendar of local events, advance bookings, weather for outdoor venues.
Whatever you add, run the same weekly check: forecast against actual, by site and day. The check is what turns a forecast into a tool, because the pattern in the gaps tells you what to add next. An agent can prepare the forecast and flag the sites where the gap is widening, for a person to review.
Review
Forecast against actuals
Forecast
Visits by site and hour
Draft the rota
From demand
Publish
With notice to staff
Adjust
Bookings and events
Record
Actuals for next week
How does Purple Build use venue data?
Purple WiFi footfall, visits and dwell time plug into Purple Build as a first-class source beside your tills, bookings and rota. You describe the dashboard, the rota app, the agent or the workflow, and it is created on that joined data, with every run on record.
Purple runs WiFi and guest data for 80,000+ venues in 90 countries, and about 2 million people are onboarded every day. That is the one signal that tells you who came through the door, and it is the signal most business tools start without.
In Purple Build it is a source like any other, which is what makes the examples in this guide a description rather than a project. A staff rota app built from your bookings and WiFi data follows the busy hours at every site, so nobody staffs a quiet Tuesday like a Saturday. A workflow releases rooms nobody turned up for. An agent drafts the weekly forecast and flags the sites whose gap is widening. A dashboard puts conversion beside visits.
Network visibility and reporting as a network job, such as authentication logs and audit evidence, belong to Purple Access. Purple Build takes the venue's data as one source among many, and uses it to answer a business question. We run Purple this way ourselves.
Footfall and occupancy become useful beside sales and rota on one multi-location dashboard, joined at site and hour through connected business data.
The options side by side
| Route | Purple Build | A separate footfall tool | Door counters | A spreadsheet of exports |
|---|---|---|---|---|
| Joined to sales, bookings and rota | Yes, one place, 1,000+ connectors | Separate; export and join by hand | Separate; export and join by hand | By hand, every week |
| Tells you who was in the building | Yes: Purple WiFi, a first-class source | Counts only | Counts only | Whatever you paste in |
| Exact headcount | A strong sample; calibrate to a door count | Varies by method | Yes, at the door | No |
| Builds the rota or releases a room | Yes: apps, agents and workflows on the data | No | No | No |
| Aggregated by design | Yes, by site and hour | Varies | Yes | Depends on the file |
| Every run on record | Yes | Not applicable | Not applicable | No |
Purple Build runs on the same credits as Purple Engage, with a free tier.
Venue data in decisions
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.
Footfall and rota
Using footfall and dwell time to plan staffing and queues.
Space and occupancy
Booked versus actual room use, no-shows and lease cost.
Accuracy and privacy
What WiFi occupancy data can and cannot tell you, and how to report it responsibly.
Venue data in decisions
The terms, defined
- Footfall
- A count of the people who visit a venue in a period.
- Visits
- The number of times people entered or were present in a venue, by site and hour.
- Dwell time
- How long a visitor stays in a venue or a zone.
- Conversion
- Transactions as a share of visits.
- Occupancy
- How many people are in a space at a given time.
- Space use
- Occupied time as a share of available time, also called utilisation.
- Peak window
- The hours of a day or week when demand is highest.
- Rota
- The schedule of who works which shifts.
- Address randomisation
- Phones changing their hardware address so they cannot be tracked across networks.
- Calibration
- Comparing a measure with a known count once, to learn the ratio between them.
FAQ
Questions operators ask
How do I use footfall data to schedule staff?
Forecast visits by hour from the last eight to twelve weeks, turn visits into transactions with your conversion rate, then divide by the transactions one person handles per hour to get staff hours. Set the staff for the peak window, add known bookings and events, and compare forecast with actual every week.
What is conversion and how do I calculate it?
Conversion is transactions divided by visits for the same site and time window. Read it with visits: high visits with low conversion points at the offer, queue or staffing, while low visits with high conversion points at awareness. Compare a site with its own history rather than a fixed benchmark.
How accurate is WiFi occupancy data?
It is a strong sample of the people in a venue, not a headcount. It misses people with no device or WiFi off and can double-count anyone carrying two. For decisions, consistency matters more than exactness. Calibrate once against a door count, and use a door counter where you need an exact figure.
Can I release meeting rooms nobody turns up for?
Yes. Compare bookings with occupancy, and if nobody is present a set time into a booking, release the room and tell whoever is waiting. In Purple Build you describe that as a workflow on your calendar and WiFi occupancy data, and every release is on record.
How do I judge whether a lease is worth its cost?
Measure the hours the space is actually used, not the hours it is booked or available. Divide occupied desk hours by available desk hours, and value the empty hours at your cost per desk hour. A short peak can hide a low average, so also check the busiest hour against capacity.
Do I need individual customer data to make these decisions?
No. Staffing, space and conversion decisions need counts by site and hour, never who the visitor was. Aggregate where data enters the reporting layer, apply data minimisation, and keep individual-level data out of operations reporting. That also keeps you inside UK GDPR.
How do I forecast footfall?
Start with the average of the same weekday and hour over the last eight weeks. Add a trend, known events, advance bookings and weather only if each narrows the gap to actual. Check forecast against actual every week; the pattern in the gaps tells you what to add next.
Can Purple Build build the rota for me?
Purple Build creates a rota app from your bookings and WiFi data on a description, so the rota follows the busy hours at every site. The app flags rest and break rules, and a person approves the rota. To change it you say what to change.
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
- GOV.UK: maximum weekly working hours
- GOV.UK: rest breaks at work
- UK GDPR, Article 5: principles relating to processing
- ICO: data protection principles, including data minimisation
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.