What POS Integration Actually Costs a Multi-Location Restaurant
Online ordering that doesn't talk to your POS costs you ninety minutes a night and a food cost number you can't trust. Here's what the integration involves and what it's worth.
If you run two or more restaurants, you almost certainly have this problem: orders arrive through three or four channels, and none of them talk to your POS.
Someone re-keys them. Every night. Across every location.
The cost nobody puts on a spreadsheet
Ask an operator what manual re-keying costs and you usually get a shrug. Ask them how long it takes and the number is startling.
Thirty minutes a night per location is typical for a group doing moderate delivery volume. Across four sites that is two hours a day, roughly sixty hours a month. That is most of a full-time salary, spent retyping things that already exist in another system.
And that is only the visible cost. The invisible one is worse: every re-key is a chance to get it wrong. A transposed quantity, a missed modifier, a wrong address. Each mistake costs a remake, a refund, or a review.
Why food cost drifts
Here is the part that actually damages margin.
If stock counts happen on paper once a week, they are already stale by the time anyone enters them. Ordering then happens on instinct. Food cost stops being a number you read and becomes a number you discover afterwards.
We routinely see groups running a seven-point swing month to month, 31% one month and 38% the next, with no clear explanation. That range is not variance. It is the absence of data.
At $2M in annual food purchases, seven points is $140,000 of uncertainty. You are not necessarily losing all of it. You just cannot see which part you are losing.
What a real integration involves
Most people imagine it as connecting two things with a cable. It is closer to translation between two systems that were never designed to agree.
Catalogue sync. Your POS holds products, categories, taxes and modifiers. The storefront needs all of it, accurately, at all times. A price changed at the terminal has to be right online within minutes.
Handling customisation without breaking sync. This is the hard part. Merchants want better photos and descriptions online than the POS holds. But if a sync overwrites those edits every night, nobody uses the system twice.
The fix is architectural: POS data lands in immutable reference tables, merchant edits live alongside it, and the two are joined at read time. A sync can never clobber a custom description because it never touches that table.
Orders pushing back. The order has to arrive in the POS the way a staff-entered order would: right modifiers, right tender type, right revenue centre, so reporting is not split across two systems.
Sync frequency without hammering the API. Full catalogue pulls every few minutes will get you rate-limited. Delta sync, which asks only for what changed since the last run, typically cuts API traffic by around 80% while keeping data fresher.
Failures that recover on their own. APIs go down. The integration needs retries with backoff, execution history, and a way to see sync health without calling anyone.
What it costs
For a group of two to ten locations, a POS-connected ordering system with catalogue sync, order push-back and per-location roles is a fixed-price build quoted against a written scope. What moves the number is the number of sites, whether your POS has a usable API, and how much of your menu relies on modifiers.
Where you sit in that range depends on:
- How many locations, and whether they share a menu
- Whether your POS has a documented API or needs reverse-engineering
- How many payment gateways you need
- Whether you want recipe-level costing in the first phase or later
Two things worth knowing. First, an integration that "already exists" for your POS is usually a generic connector that will not handle your modifiers correctly. The generic ones fail on exactly the customisations that make your menu yours. Second, anyone quoting this hourly is transferring the risk of their own estimate onto you.
Whether it's worth it
Rough arithmetic for a four-location group:
- Re-keying eliminated: ~60 hours a month
- Order errors down: fewer remakes, fewer refunds
- Food cost variance tightened from seven points to under one
The labour saving alone usually covers the build inside a year. The food cost visibility is the part that keeps paying, because you stop guessing at your single largest controllable expense.
The honest caveat
This is not worth doing for a single location. One site, one menu, low delivery volume: the manual process is annoying, but it is not costing you enough to justify the build. Spend the money elsewhere.
It starts paying at two locations and becomes obvious at four, because the pain scales with sites while the build cost mostly does not.
Run two or more locations? Tell us how orders reach your kitchen today and we'll tell you honestly whether this is worth doing for you.