Connect POS data to a dashboard, and every other system
Connecting POS data to a dashboard means reading sales from the till through its API or a connector, matching every site to one permanent site ID, and joining the result to bookings, schedule and footfall on a shared date basis. The connection is the easy part. Site IDs, the trading day and reconciliation decide whether you can trust it.
- 1,000+ connectors
- Purple WiFi data, first class
- Permissions respected
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 connect POS data to a dashboard?
It means a live, repeatable path from the till to a screen: a connector reads sales, a clean-up step gives every row a site ID and a trading day, and the result is joined to your other sources. If the path breaks, you can see where. A one-off export is not a connection.
Most operators have connected data once, by hand: export a file from the till, open it, paste it somewhere. That works for a month. It stops working when someone is on holiday, when a site is added, when the till vendor changes a column name, or when the file is a week out of date and nobody notices.
A connection replaces the export with a path the system runs for you. The path has the same four stages wherever the data comes from: get it out of the source, put it in a stable shape, give every row the keys that let it join to other data, and check it before anyone relies on it.
Till or POS
Sales, voids, refunds, tenders
Then: Connector
Connector
API, webhook or scheduled file
Then: Clean and key
Clean and key
Site ID, trading day, time zone
Then: Quality check
Quality check
Complete, unique, reconciled
Then: Dashboard, app or agent; Fails: Clean and key
Dashboard, app or agent
Reads the joined data
| Method | How fresh | Effort | Where it breaks | Use when |
|---|---|---|---|---|
| Connector or API | Minutes to hours | Low with a ready connector | Source changes its API or limits calls | The system offers one: the default choice |
| Webhook | Seconds | Medium | Missed events if your end is down | Someone must act within the hour |
| Scheduled file export | Daily or hourly | Medium | Column or format changes; failed delivery | The system has no API, only exports |
| Direct database read | Near real time | High | Schema changes; rarely offered by hosted tills | You host the system yourself |
| Manual export | Whenever someone remembers | High, repeated | Everything: people, timing, versions | A one-off investigation, never routine reporting |
Why is business data stuck in silos?
Because every system was bought to do one job, by one team, at one time. The till sells, the bookings system fills tables, the schedule schedules staff, and none was built to answer a question that spans them. Acquisitions and site-by-site installs add more.
A hospitality or retail group typically runs several systems per site, bought at different times for different reasons. The bookings system came with the website. The schedule tool was chosen by operations. The till was inherited when you bought a chain of eight sites. Finance has its own package. Each is sensible alone, and none shares a customer, a site or a date with the others by default.
The result is that the questions that matter most are the ones nobody can answer without a person doing a week of stitching. How did labor compare with covers at the sites where footfall rose? Which sites are busy on paper but empty on the door? Each needs three or four systems joined, and every system holds its own version of the site's name.
Purple sees one of these gaps from a particular angle. The WiFi network records who walked in and how long they stayed across 80,000+ venues in 90 countries. That signal is rarely joined to the till or the schedule, so the people-in-the-building number and the money number sit in different places.
How do you audit your data sources before connecting them?
List every system that holds business data, then for each record the owner, what it holds, how data gets out, how often it changes, which key identifies a site and which sites it covers. The audit takes a day and removes weeks of surprises later.
The audit is a spreadsheet, and it is the one spreadsheet worth keeping. Its job is to surface the awkward facts before they cost you: the system with no export, the site that runs a different till, the field that is free text, the owner who left.
Below is a worked example for a 40-site restaurant group. The right-hand columns are the ones people forget and the ones that decide how long each connection takes.
| System | Owner | Holds | How data gets out | Changes | Site key | Covers |
|---|---|---|---|---|---|---|
| Till | Operations | Sales, voids, refunds, tenders | API | Continuously | Venue code | 34 of 40 sites |
| Till (acquired sites) | Operations | Same, older format | Scheduled file | Daily | Site name | 6 of 40 sites |
| Bookings | Marketing | Bookings, covers, no-shows | API | Continuously | Venue ID | 40 of 40 sites |
| Schedule and time clock | People | Hours planned and worked, cost | API | Daily | Location name | 40 of 40 sites |
| Finance | Finance | Costs, budgets, rent | Scheduled file | Monthly | Cost center | 40 of 40 sites |
| WiFi footfall | Operations | Visits, dwell, repeat visits | Connector | Hourly | Venue ID | 38 of 40 sites |
| Checklists | Facilities | Checks done, issues | API | Daily | Site name | 40 of 40 sites |
Seven rows, five different site keys. That is the normal state of an estate, and it is what the next section fixes.
Data source audit checklist
0 of 9 done
How do you build one list of sites?
Create a single table with one row per location and a permanent site ID that never changes or gets reused. Add the format, size band, region, time zone and opening and closing dates, then map every system's own identifier to that ID. Every join in the business then runs through it.
This is the highest-value hour in any data project. Without a master list, "Leeds Central" in the schedule, "LEEDS-01" in the till and "Leeds (Trinity)" in finance are three different places, and any report joining them silently drops or doubles a site. With one, the join is a lookup.
Three rules keep the list honest. IDs are permanent: a renamed or rebranded site keeps its ID, and a closed site's ID is retired, never reused for the next opening on the same street. Each source's identifier maps to exactly one site ID, held in the list rather than in someone's head. And one person owns the list, so a new site is added in one place on the day it opens.
| Column | Example | Why it is there |
|---|---|---|
| site_id | S-0042 | The permanent key every join uses |
| Name | Leeds Trinity | What people call it today; can change |
| Format and size band | Casual dining, medium | Builds peer groups for fair comparison |
| Region and area manager | North, A. Patel | Drives role views and permissions |
| Time zone | Europe/London | Fixes the trading day and daylight saving |
| Opening and closing dates | 2022-03-14, open | Keeps like-for-like honest |
| Till, bookings, schedule, finance, WiFi IDs | T-118, B-77, R-Leeds01, CC-4301, W-9912 | The mapping from each system to the site ID |
How do you handle dates, time zones and the trading day?
Decide the trading day, the time zone, the week start and how late transactions are treated once, and apply them to every source. A trading day that ends after midnight, daylight saving and refunds posted days later cause most of the small reconciliation differences.
Date handling is where two correct systems produce two different totals. A bar that trades past midnight records Friday night's sales on Saturday's date in a system keyed to the calendar day, and on Friday's in one keyed to the trading day. Add daylight saving, where one night has 23 hours and another 25, and a report that looked right all year is wrong twice.
The fix is not clever. Write the rules down on the definition card, keep a time zone on each site, and convert everything to the site's local trading day before it is joined.
| Trap | What it does | Rule |
|---|---|---|
| Trading day ends after midnight | Late sales land on the next date | Store the trading date from the till; fall back to a cut-off time per site |
| Daylight saving | One 23-hour day and one 25-hour day a year | Store timestamps in UTC; convert with the site's time zone |
| Different week starts | Week totals never match between systems | Pick one week start and apply it in the data, not in each chart |
| Late-posted refunds and voids | A day's total changes after you reported it | Refresh the last seven days on every run |
| Finance periods | Four-four-five or calendar months differ from trading weeks | Map each trading date to its finance period in one table |
| Multiple currencies | Totals add pounds to euros | Store the currency per row and convert once, at a stated rate |
How often should business data refresh?
As often as the fastest decision needs, and no more. Real time only where someone acts within the hour. Hourly for service-day operations, daily by early morning for reporting, weekly for planning. Faster feeds cost more and break more often without making decisions better.
How fresh does this data need to be?
Question 1
Does someone act on this data within the hour, during service?
Examples: a queue building, a table that has not been cleared, stock about to run out.
See every path as a list
- Does someone act on this data within the hour, during service? Yes (go to: Near real time, through a webhook or a short polling interval.); No (go to: Is it used to run the day, such as staffing or a decision before close?)
- Is it used to run the day, such as staffing or a decision before close? Yes (go to: Hourly.); No (go to: Is it for reporting on yesterday or last week?)
- Is it for reporting on yesterday or last week? Yes (go to: Daily, completed before the first person reads it.); No, it is for planning (go to: Weekly, or on demand.)
- Answer: Near real time, through a webhook or a short polling interval. Keep the list short. Each real-time feed needs monitoring, and a missed event needs a catch-up run.
- Answer: Hourly. Fresh enough to run the day, and cheap to recover if one run fails.
- Answer: Daily, completed before the first person reads it. Refresh the last seven days each run so late refunds and voids settle.
- Answer: Weekly, or on demand. Planning data such as budgets and schedule templates changes slowly. Do not pay for freshness nobody uses.
What quality checks should you run before building on the data?
Five checks: every site has data every day, nothing is duplicated, values are possible, totals agree across tables and the load finished on time. Then reconcile to the till's end-of-day total for each site. Run all of them automatically and show the result next to the dashboard.
| Check | The test | What it catches |
|---|---|---|
| Completeness | Every open site has rows for every trading day | A connection that stopped for one site |
| Uniqueness | No transaction ID appears twice | A load that ran twice and doubled sales |
| Validity | No negative covers, no future dates, no missing site IDs | Bad rows from a source change |
| Consistency | Item totals equal tender totals within a till | A partial load or a mapping error |
| Timeliness | Loaded before the agreed time | Slow or failed overnight runs |
Reconciliation is the check that earns trust. Every till can produce an end-of-day total, usually called the Z report. If the dashboard's net sales for a site and day equal that total, the pipeline is right for that site and day. If they differ, the difference has a cause, and finding it is the point.
Reconcile the dashboard to the till, step by step
Pick a trading day and three sites
Choose a busy day, a quiet day and one site on the older till if you have one. Variety finds more causes.
Check: You have the till's end-of-day report for each.
Compare net sales for each site
Put the dashboard figure beside the till's figure for the same trading day, both excluding tax.
Check: A difference column exists for every site and day.
Explain every difference
The usual causes are voids and refunds posted late, tips and service charge counted differently, a trading day that crosses midnight and tax treated differently between systems.
Check: Each difference is tagged with one of those causes.
Fix the rule, not the number
Change the definition or the mapping that caused the gap, so the difference disappears everywhere, not only on the day you checked.
Check: Re-running the load closes the gap.
Set a tolerance
Agree a small tolerance in money or percent for rounding. Anything outside it is a failure, not a footnote.
Check: The tolerance is written on the measure's definition card.
Automate it daily
Run the same comparison every morning for every site and show the result on the dashboard, so a break is seen the day it happens.
Check: A failed reconciliation is visible without anyone looking for it.
How do you join POS, bookings, schedule and footfall data?
Join every source at the same grain, usually site and hour, using the site ID and the local trading date. Then compute measures that need two sources: spend per cover from till and bookings, labor cost percentage from schedule and till, conversion from till and footfall.
Joining works when every source can be reduced to the same grain. Site and hour is the most useful: fine enough to staff against, coarse enough to be stable. A till row becomes sales for a site in an hour, a booking becomes covers expected for a site in an hour, a schedule shift becomes hours worked, and a WiFi visit becomes people present.
Purple WiFi data is a first-class source in Purple Build, so footfall, visits and dwell time join to the till and the schedule in the same place. It is the one source that says who came through the door, which is why it is the missing half of most conversion and staffing questions.
Till
Net sales, transactions
Then: Site and hour
Bookings
Covers booked and seated
Then: Site and hour
Schedule
Hours and cost
Then: Site and hour
WiFi footfall
Visits and dwell time
Then: Site and hour
Site and hour
One row per site per hour
Then: Measures
Measures
Spend per cover, labor percentage, conversion
| Measure | Sources | Formula | Watch for |
|---|---|---|---|
| Spend per cover | Till, bookings | Net sales ÷ covers seated | Walk-ins missing from bookings |
| Labor cost percentage | Schedule, till | Labor cost ÷ net sales × 100 | Agency staff held elsewhere |
| Conversion | Till, WiFi footfall | Transactions ÷ visits × 100 | WiFi counts devices seen, a sample of visitors |
| Sales per labor hour | Till, schedule | Net sales ÷ hours worked | Salaried hours counted or not |
| No-show rate | Bookings | No-shows ÷ bookings × 100 | Cancellation versus no-show |
| Space use | WiFi footfall, calendar | Occupied time ÷ available time × 100 | Rooms with no coverage |
What about customer data and UK GDPR across systems?
Connect only the personal data the purpose needs, keep it out of reporting layers that do not need it, set retention per source and make sure access and deletion requests reach every copy. Joining systems multiplies copies, so decide what is copied before you copy it.
Most multi-site reporting needs no personal data at all. Sales, covers, hours and visits are counts and sums. The moment you connect a customer record, a booking name or a staff member's pay, UK GDPR applies to how it is used across the systems you have joined.
Four habits keep you inside it. Apply data minimisation, Article 5(1)(c): connect the fields the measure needs and leave the rest. Keep personal data out of the shared reporting layer where aggregates will do. Set a retention period per source and delete on schedule, because a copy you forgot is still a copy. And make sure a request from a person to see or delete their data can reach every system that holds it, which is far easier when you hold one list of what is connected.
Purple Build respects the permissions of the person looking, so people see the data they are allowed to see and nothing more. Your data protection officer decides the lawful basis and retention for each source; the audit table in this guide gives them the inventory to decide against.
How does Purple Build connect your systems?
Through 1,000+ connectors to the systems multi-site businesses run on, in one place: point of sale, bookings, CRM and marketing tools, email, calendar and documents, and Purple WiFi footfall. You name your systems on the waitlist and they are connected first. Production systems stay protected.
Purple Build is built so the four stages in this guide are not four projects. You connect the systems, and the keys, clean-up and checks sit with the connection. You then describe the dashboard, app, agent or workflow you want, and it is created on the connected data, with permissions respected and every run on record.
The guardrails apply to the connection itself. Production systems are protected: what you build works on your data without putting the systems your business runs on at risk. Every number traces back to its source, because builds read your connected systems, not a one-off export. And when a source system changes, a failed run shows on record straight away, and you fix the build by saying what changed. No ticket, no developer.
We run Purple this way ourselves, with our own systems connected in one place, so this is the practice we use.
Once the data is connected, three things are built on it: multi-location dashboards, workflows that run across sites and venue data in decisions.
- 1,000+
- connectors
- 80,000+
- venues whose WiFi data plugs in as a first-class source
- 90
- countries Purple runs in
The options side by side
| Route | Purple Build | Manual exports | Developer-built integrations | A data warehouse project |
|---|---|---|---|---|
| Time to the first connected source | Connected first once you name it on the waitlist | Same day, repeated forever | Weeks per source | Months before the first dashboard |
| Who maintains it when a system changes | You say what changed | Whoever does the export | A developer | A data engineer |
| Site IDs and definitions | Held with the connection, shared by every build | In each person's sheet | In code | In the data model |
| WiFi footfall as a source | First class, from Purple | Separate export | Custom feed | Custom feed |
| Production systems protected | Yes, by design | Not applicable | Depends on the build | Depends on the build |
| Failures visible | Every run on record | When someone notices | If logging was built | In the pipeline's logs |
Purple Build runs on the same credits as Purple Engage, with a free tier.
Connect your business data
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.
Getting the data in
Auditing sources and connecting point of sale, bookings, property systems and WiFi.
Getting the data right
A single source of truth, master site lists, quality checks and refresh rates.
Privacy
Customer data across systems under GDPR, including retention.
Connect your business data
The terms, defined
- Connector
- A ready-made link that reads data from one system into another on a schedule or on events.
- API
- An application programming interface: the way one system lets another read or write its data in a controlled way.
- Webhook
- A message a system sends to another the moment an event happens, such as a sale or a booking.
- Site ID
- A permanent identifier for a location that every system's own identifier maps to.
- Master data
- The small, slow-changing reference tables, such as the list of sites, that every other table joins to.
- Trading day
- The business day a sale belongs to, which can end after midnight.
- Z report
- A till's end-of-day total, used to reconcile reported sales to the source.
- Reconciliation
- Comparing a reported figure with its source and explaining any difference.
- Grain
- The level one row represents, such as one site in one hour.
- Data silo
- A system whose data is not joined to the others, so questions across systems need manual work.
FAQ
Questions operators ask
How do I connect POS data to a dashboard?
Read sales from the till through its connector or API, give every row a site ID and the local trading date, check it, then join it to your other sources. A connector replaces the manual export, so the path runs every day without a person. Reconcile to the till's end-of-day total to prove it works.
What is a data source audit?
A list of every system that holds business data, with its owner, what it holds, how data gets out, how often it changes, the site identifier it uses and which sites it covers. It takes a day and shows the awkward facts, such as a site on a different till, before they delay a connection.
Why do my dashboard totals not match the till?
Usually one of five things: voids and refunds posted late, tips or service charge counted differently, a trading day that crosses midnight, tax treated differently between systems, or a site mapped to the wrong ID. Compare a day's net sales with the till's end-of-day report, tag each difference, and fix the rule.
What is a site ID and why do I need one?
A site ID is a permanent identifier for a location that never changes or gets reused. Each system names a site differently, so you hold one list of sites and map every system's identifier to its ID. Every join then runs through it, which stops sites being dropped or doubled in reports.
How often should business data refresh?
As often as the fastest decision needs. Near real time only where someone acts within the hour, hourly for running the service day, daily before the first person reads it for reporting, weekly for planning. Refresh the last seven days each run so late refunds and voids settle.
Can I connect WiFi footfall data alongside sales and bookings?
Yes. Purple WiFi footfall, visits and dwell time are a first-class source in Purple Build, joined to the till and the schedule at site and hour. It is the one source that shows who came through the door. WiFi counts devices it sees, so use it for trends and conversion comparisons.
Do I need a developer to connect my systems in Purple Build?
No. Purple Build connects through 1,000+ connectors, and you name your systems on the waitlist so they are connected first. When a source system changes you say what changed and the build is fixed, with no ticket and no developer. Your IT team keeps control of what connects.
Is connecting customer data across systems allowed under UK GDPR?
Yes, with a lawful basis and discipline. Connect only the fields the purpose needs, keep personal data out of shared reporting where aggregates will do, set a retention period per source and make sure access and deletion requests reach every copy. Most multi-site reporting needs no personal data at all.
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
- ICO: data protection principles, including data minimisation
- RFC 3339: date and time on the internet, timestamps
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.