Restaurant POS
The till keeps working
when the internet doesn't.
RestroSync POS runs in the browser — nothing to install — and it is built offline-first by architecture, not as a fallback mode. Open a URL, pair the terminal once, and take orders on a dead line.
Every action appends an event, on the device, instantly.
No network? The event waits in an ordered outbox on the terminal.
On reconnect the cloud folds every terminal's events in time order.
Nothing overwritten, nothing lost, full audit trail.
The offline model
Most systems overwrite.
This one keeps a ledger.
Ordinary POS software saves the current state of a bill. When two devices edit the same table offline, the last one to reach the server wins and the other's items disappear. RestroSync never saves state — it appends what happened, and computes the bill from that.
Friday night, Wi-Fi drops at 8:00 PM
Captain A · queued offlineQueued
Captain B · queued offline, other tabletQueued
Cloud folds by client time — neither overwritesApplied
Bill Desk · nothing lost₹300
What staff actually see
Honest about what offline cannot do
- Billing needs no server
Totals, tax and charges compute on the device from the cached tax profile. No round trip, no spinner in front of a guest. - Cash settles offline
At the till, the receipt prints over USB and the drawer opens. The payment reaches the ledger when the line is back. - A refresh doesn't lose the queue
Operations waiting to sync are stored on the device, so reloading the page mid-service keeps them — and the terminal stays paired to its outlet.
One app, every role
The PIN decides
what the screen becomes.
Not six apps to install and update. One build; the terminal is paired to an outlet once, and each PIN opens the screen that person needs — with the actions they are not allowed to take simply absent, not greyed out.
- Search that matches how staff think
Item name, category chip, or the short code called across the pass — type 214, get Butter Chicken. - Fire once, the kitchen splits it
One tap sends the order; the cloud routes each line to grill, bar or pantry from the published routing rules. - The menu changes itself at 11:30
Lunch and dinner windows come down inside the menu snapshot, so the pad switches on the device clock — no network needed. - Prices freeze when the item is added
A price published mid-meal never rewrites a seated table's bill.
- Discount ceilings are set centrally
A cashier's limit comes from the published role config. Above it, a manager approves on the same screen with a reason — both signatures land on the event. - Voids after firing leave a trail
The line is never deleted. It stays in the ledger with who, when, why and who approved. - Split, merge, reprint
By item or by cover; a reprint counts as a copy rather than quietly replacing the first bill.
- 2 × Butter Chicken
- 1 × Dal Makhani
- 1 × Mutton Biryani
- 3 × Paneer Tikka
- Bar never sees grill traffic
Each screen subscribes to its own station. Assigning this TV to a station is a setting on the device itself. - Bump one ticket, not the whole order
Drinks go out while the steak cooks — the runner sees "1 of 2 tickets ready" instead of waiting for everything. - 86 an item and the floor knows
Marked unavailable from the kitchen or bar; every pad greys it out. Manual 86s clear at the start of the next business day. - Late tickets are labelled late
A ticket fired while offline arrives flagged with the time it was actually rung in, so the kitchen isn't blamed for the gap.
- A queue built from bumps, not guesses
Food appears on the runner's screen the moment the kitchen bumps it, with the table it belongs to. - Partial orders are visible as partial
"1 of 2 tickets ready" — so nobody carries out half a table thinking it's complete. - An expo hold lane for plating
Bumped but not yet carried out sits in its own lane, so the pass and the floor agree on what's still waiting. - Runners cannot fire orders
By design. The screen has what the job needs and nothing else. - Host seats, then hands off
Covers and table go on the order, the captain picks it up. Waitlist with a quoted time for the door. - Transfers keep the same order
Move T04 to T12 or merge two tables; fired tickets follow, and a printed bill needs an approval to reopen.
- One board for the room
Open tables, ticket age, covers and the shift's sales so far — tap through to the screen that fixes it. - Approvals happen where the problem is
The same approval box everywhere: manager PIN, reason, and both names recorded on the event. - Day close that refuses to lie
See cash control below — the day cannot close while a terminal is still holding unsent operations.
Floor & service
From the door
to the table to the bill.
The host seats a party, the captain picks it up, tables move when the room changes, and every one of those steps stays on the same order — so nothing is retyped and nothing is lost in the hand-off.
The door
Seat party · T07
The room
- Transfers keep the order intact
Move a table or merge two; fired tickets follow the same order and only the table label changes. A printed bill needs an approval before it reopens. - Dine-in, takeaway and delivery on one pad
One queue, one running total, one day-end — the counter doesn't switch screens to serve a different kind of guest. - Captains see their own work first
Filter to mine, or the whole room. Draft, fired and printed are separated so nobody fires the same course twice.
Cash control & day close
The day can't close
on a guess.
Two controls do most of the work here. The cashier counts the drawer without being shown what the system expects. And the business day refuses to close while any terminal is still holding operations it hasn't sent.
Blind count
Sync barrier before Z
- Nothing is deleted, ever
Voids, comps, discounts, reprints, drawer opens and transfers are appended with an actor. There is no button that removes the trace. - Two payments on one table both survive
If a table gets settled twice offline, neither payment is dropped — the bill is flagged overpaid for a manager to refund. - Z resets the room, not just the report
Closing the day locks the numbers, snapshots them for reprinting years later, resets ticket numbers and rolls the business date on every terminal.
The manager console
The till is a till.
Setup happens somewhere else.
Menus, prices, day-parts, kitchen stations and routing are authored in a separate console on a desktop, by whoever is allowed to — then published to the terminals. Nobody edits a price on a tablet during service, because the tablet cannot.
Changes in this version
- Day-parts with a timeline
Lunch 11:30–15:30 weekdays, dinner 18:00–23:00 — drawn against the outlet's own timezone, with overlaps refused at the point of entry. - Items, categories, modifiers, combos
Price, day-parts, short code for the counter, and an optional station override per item. Modifier groups and combos where you need them. - Stations you define
Grill, bar, pantry, expo — whatever the kitchen is actually laid out as. - Routing rules, not a spreadsheet
Item override first, then a category rule, then the bar split, then a default. One order of precedence, applied identically in the console preview and on the terminal. - Version history you can point at
Every publish is kept: version, time, who did it, what changed. Any historical bill can be explained from the version it was rung in on. - Per-outlet, always
Every draft is scoped to one outlet, so a group can run different menus and different kitchens without cross-contaminating.
- Console
Desktop, email login. Authoring and publishing. Never a billing screen.
- Terminal
Tablet, PIN and pairing. Consumes published versions. Cannot author anything except its own hardware.
- Why it matters
Most price and routing mistakes are made by the wrong person on the wrong device mid-service. This split removes the opportunity.
Hardware & setup
Browser-based,
but it drives real hardware.
A web app can't reach a printer on your local network by itself. So there are three paths, and we pick per surface rather than pretending one covers everything.
- Receipt printer & cash drawer
Connected by USB to the billing terminal and driven straight from the browser. This is the path that keeps printing and opening the drawer with the internet down.
- Kitchen ticket printers
Cloud-capable printers fetch their own jobs, so there is nothing to install in the kitchen. Tickets arrive within a few seconds while the line is up.
- Older network printers
A small on-site bridge handles legacy LAN printers and instant printing, for outlets that need it.
A7X-92M
Setting up a tablet takes a code, not a technician
Open the outlet's URL, add it to the home screen, read out the six-character code. A manager approves it and names the terminal. No API keys typed on the floor, and no device-management software.
The device is identified separately from the person. Signing out or rebooting doesn't unpair it — and if a tablet walks out of the building, revoking it wipes the cached menu, the queued operations and the token, leaving a blank browser. Whoever has it still needs a staff PIN to see anything.
Reports & exceptions
What sold, and
what came off the bill.
Two reports do the daily work: what actually sold this shift, and every discount, comp, void and refund with the name of whoever did it and whoever approved it.
Item sales · this shift
Exceptions · this shift
Logged
- Printers you can test from the floor
Map bill, ticket and label printers per terminal, switch one off when it jams, and fire a test print to prove it before service. - Drawer and scanner checks
Pulse the drawer and test the scanner from the settings screen, so opening problems are found at 11 am rather than 9 pm. - Alerts that name the problem
A disabled bill printer, an item still 86'd, a ticket past its time, a terminal offline — on one board for the manager on shift.
India first
Built for how the
counter actually works here.
Patchy connectivity is a design assumption, not an edge case. So are UPI, GST, a kitchen that runs on tickets, and a group that runs six outlets off one console.
- Cash, UPI and card in one drawer count
Tender recorded per bill and reconciled per shift, with the variance computed from the ledger rather than a manager's memory. - GST computed on the device
Rates and charges are configured per outlet and published to the terminals, so the same bill totals identically offline and online — to the paisa. - Service charge is a setting
On, off, or removable on the bill. Your policy, not our default.
- Dine-in, takeaway and delivery together
One order book and one day-end across channels, instead of a second screen on the counter. - Weekend volume and the kitchen
Tickets routed per station by rules you set, with an expo lane for the pass when the room is full. - Offline billing as standard
Not an add-on module. It is how the till is built.
- Groups, not just outlets
Menus, stations and routing authored per outlet from one console, so a group can run six kitchens without six systems. - Switching outlet means re-pairing
A daily PIN can never move a terminal to another outlet — the most common source of misposted sales. - Your business day, not midnight
The day closes when your kitchen closes. Ticket numbers reset and the business date rolls on every terminal at once.
Why this one
The differences that
show up on a bad night.
| Installed legacy POS | Cloud POS with an offline mode | RestroSync POS | |
|---|---|---|---|
| Two devices, one table, no internet | Local server decides | Last device to sync wins — items vanish | Both sets of items survive; nothing overwritten |
| Getting a new tablet running | Technician visit | App store install and login | Open a URL, read out a six-character code |
| Updates | Scheduled downtime | Per-device app updates | Refresh — every terminal is on the current build |
| Menu price change mid-service | Risky; often after close | Can rewrite open bills | Versioned publish; open bills keep quoted prices |
| Day close with a terminal offline | Manual tally | Closes anyway, numbers drift | Blocked until it syncs, or a recorded force close |
| Voids and comps | Editable rows | Soft-deleted | Appended with actor, reason and approver |
| Who can change a price | Anyone with the manager key | Anyone logged into the till | Nobody on the till — authoring lives in the console |
| Knowing which station a dish prints to | Trial and error in service | Buried in item settings | Previewed per item before you publish |
| Stolen tablet | Physical risk | Remote wipe if MDM exists | Revoke; device wipes itself to a blank browser |
On the terminal
Every screen
the floor needs.
Grouped the way the side rail is grouped. Each PIN sees the groups its role is allowed to open, and nothing else.
Home
- Live board
- Shift strip
- Alerts
Orders
- Order pad
- Open orders
- New order · dine-in, takeaway, delivery
- Fire with per-station tickets
Billing
- Open bills
- Bill preview
- Settle
- Discounts & no-charge
- Void & refund
- Split & merge
- Print & reprint
- Till open / blind close
Floor
- Floor plan
- Seat party
- Waitlist
- Transfer & merge tables
Kitchen & runner
- Station display with bump
- Ticket queue by age
- Ready-to-run queue
- Expo hold
Menu ops
- Live menu as the terminal sees it
- 86 / un-86 with daily clear
- Station config, read-only
Shift & cash
- Shift open with float
- Cash in / out with reasons
- Manager override, everywhere it's needed
Reports
- X report, mid-shift
- Z report with sync barrier
- Item sales
- Voids, comps & discounts
Terminal settings
- Device pairing & re-pair
- Printers with test print
- Drawer & scanner tests
- Kitchen screen assignment
- Sync diagnostics
Questions operators ask
Before you
change your till.
What exactly still works with the internet down?
If it's a website, what happens when the browser tab closes?
Can a cashier give an unauthorised discount?
Do you support my printers?
How does GST and service charge get calculated?
Can I move off my current POS without losing history?
What happens on the first Saturday?
See it fail
gracefully.
Ask us to pull the internet during the demo. That is the part worth watching, and it is the part most POS demos avoid.
- 30 minutes, on your menu and your tax setup
- We will price the hardware you actually need
- Migration from your current POS, handled by us
Prefer to talk? +91 00000 00000