POS Deployment
A POS rollout is judged at the counter during the busiest hour. Everything in the plan works backwards from that.
Industry-specific POS rollout for retail, restaurant, salon, clinic, and car wash, with hardware integration (scanner, scale, printer, IoT box) and offline mode.
Back-office software gets a second chance. A till does not. If it is slow, if the receipt printer stalls, if the connection drops and the queue stops moving, the staff invent a workaround the same day and you spend the next month unpicking it. So the whole approach is built around what happens at the counter under pressure, not around a feature list.
Two things decide the outcome more than anything else. Hardware has to be proved with the actual devices you will use, because printers, scanners, scales and payment terminals behave differently in the room than in a specification. And the offline behaviour has to be demonstrated to the staff, not just enabled, so nobody panics when the connection drops.
We prove it in one pilot site first, run it through a full trading week including the busy periods, and only then roll out. A pilot that has survived a Saturday is worth more than any amount of testing on a quiet weekday.
What is included
- โ Industry-specific POS configuration
- โ Hardware integration (scanner, scale, printer)
- โ IoT box & direct-USB devices
- โ Offline-first operation
- โ Multi-store & multi-currency
- โ Loyalty, gift card, membership
- โ Kitchen display system (KDS)
- โ ZATCA / FBR POS compliance
How the engagement runs
- 1
Site and operations survey
Understand the counter before configuring anything.
- Observe an actual shift: what happens at peak, what the exceptions are, where the queue forms
- Inventory the hardware in use and the connectivity at each site, including the wireless coverage
- Establish the payment methods actually taken, including the informal ones
- Identify the operations that must work offline, since these differ by business
You end up with: A site profile per location with hardware, connectivity and peak-hour observations.
- 2
Product, menu and pricing setup
Build a till layout the staff can work at speed.
- Product or menu structure organised for speed of selection, not for the accountant's hierarchy
- Variants, modifiers, combos and options set up the way orders are actually taken
- Pricing, promotions and loyalty configured, and tested against real till scenarios
- Screen layout arranged so the top sellers are reachable without hunting
You end up with: A configured till layout reviewed by the people who will use it.
- 3
Hardware proving
Prove the physical setup with the actual devices, at the actual site.
- Receipt printers, kitchen printers, scanners, scales and cash drawers tested end to end
- Payment terminal integration tested including the failure cases: declines, timeouts, partial payments
- Display and kitchen screens verified in position, under the real lighting and the real noise
- Connectivity tested at the counter, not at the office router
You end up with: A signed hardware checklist per site, with model numbers recorded.
- 4
Pilot store
Run a full trading week on one site before committing the estate.
- Train the pilot staff and let them run real trading, with support present at peak
- Deliberately drop the connection during a quiet period so staff see offline behaviour working
- Reconcile the till against cash and against the ledger daily during the pilot
- Collect the changes the staff ask for, and apply the ones that survive a second look
You end up with: A pilot site trading normally, with a punch list cleared and a reconciliation history.
- 5
Multi-site rollout
Repeat the pilot as a routine, not as a fresh project per site.
- A per-site checklist covering hardware, network, staff training and opening-day support
- Configuration held centrally so a change does not have to be repeated per till
- Store-level reporting and reconciliation set up as sites come on
- Support presence for the first trading day at each site, tapering as the pattern proves itself
You end up with: Every site live on a repeatable checklist, with central reporting across the estate.
What you need to provide
The schedule slips on these more often than on anything technical.
- โ Access to the sites during trading, so we can observe the real operation rather than a description of it
- โ The exact hardware models in use or planned, since compatibility is decided by model and not by category
- โ Product or menu data with prices, including the modifiers and options
- โ Staff availability for training, scheduled around trading rather than in the middle of it
- โ Merchant details for the payment terminals, obtained from your provider
- โ A decision on which site is the pilot, and a commitment not to skip it
Decisions you will be asked to make
Which site pilots
The instinct is the quietest site, and it is the wrong one. A moderately busy site with capable staff exposes the real problems while there is still time to fix them, which is what a pilot is for.
How much the till can do without a connection
Full offline selling is achievable and it constrains what else the till can do live. What has to keep working when the line drops is a business decision, and it should be an explicit one.
One product structure or per-site variation
Central control keeps the estate consistent and makes reporting comparable. Per-site freedom suits businesses whose sites genuinely differ. Choosing accidentally is the problem, not choosing either.
How payments are reconciled
Terminal totals, cash counts and the ledger have to agree at the end of every day. Deciding who reconciles and how before go-live is what stops small differences becoming a monthly investigation.
Where this goes wrong
The failure modes we plan around, and what the plan does about each one.
Hardware assumed rather than proved
Devices that meet a specification still misbehave in the room. Every printer, scanner, scale and terminal is tested at the site with the model you will actually use, and the model numbers go on the checklist.
Configuring for the accountant instead of the cashier
A till organised by the reporting hierarchy is slow to use, and slow means a queue. The layout is built for speed of selection and reviewed by the staff who work it.
Offline mode enabled but never demonstrated
Staff who have not seen the connection drop will assume the system is broken and start writing on paper. It is demonstrated deliberately during the pilot, in a quiet period.
Rolling out without a pilot
Every problem gets multiplied by the number of sites, on the same day. The pilot runs a full trading week including the busy periods, and the rollout waits.
Training during a shift
Nobody learns anything while serving customers. Training is scheduled outside trading, and someone is present at the counter on the first busy day.
Ignoring the exceptions at the counter
Refunds, exchanges, voids, split bills and staff discounts are where the workarounds start. They are configured and taught rather than left for staff to work out themselves.
No daily reconciliation
Small differences accumulate quietly until a month has to be investigated. Daily till reconciliation is set up as part of the rollout, not added when the first problem appears.
Not included
Stated up front so the proposal has no soft edges.
- ร Hardware supply, cabling and network installation, which are quoted separately or bought by you
- ร Payment provider contracts, merchant onboarding and terminal fees
- ร Site works, furniture and counter layout
- ร Menu photography, product imagery and printed signage
- ร Trading losses during rollout: we manage risk with a pilot, we do not carry it
- ร Ongoing till support, which belongs in a support agreement
How this is priced
Priced as a first-site build plus a per-site rollout figure, because the second site costs a fraction of the first once the checklist exists. Hardware, terminals and network work sit outside the software quote.
See the published bands โModules that come up on this work
Ready-built modules from our own catalogue. Where one of these covers the requirement, installing it beats writing it.
WT POS Analytics Dashboard
Enterprise POS Analytics Dashboard - KPIs, Charts, Filters, Comparison & Export for Odoo 19
Why here: Multi-site operators need comparable numbers per store, and that is usually the first thing asked for after go-live.
Point of SalePOS Kitchen Display System
Preparation screens for kitchens and bars, split by product category, with preparation time measured per ticket and per product.
Why here: Restaurant rollouts live or die on the pacing between counter and kitchen, which needs screens rather than printed tickets.
Sales/Point of SaleRestaurant Table Reservation
Take table bookings from your website, with an engine that combines small tables for big parties, paces the kitchen and never double-books.
Why here: Table service sites need bookings and table combination handled before the pilot, not bolted on after.
Sales/Point of SaleRestaurant & Cloud Kitchen Management
Multi-outlet restaurant ERP - menu engineering with recipe food cost, QR table ordering, kitchen display, dine-in, takeaway, delivery and aggregator orders, riders, reservations, wastage and fiscal receipts (ZATCA / GST / EU ready).
Why here: Multi-outlet food operations need recipe costing and outlet-level control beyond what a till alone gives.
Services/RestaurantWT POS Delivery Driver
Delivery driver management in POS - assign drivers, auto fee, validation, PDF report
Why here: Delivery is a normal part of retail and food operations now, and driver handling has to be part of the till flow.
Point of SaleBarcode Price Checker Kiosk - Self-Service & Offline
Self-service barcode price checker kiosk for retail & supermarket stores - customers scan any item and instantly see its price & stock. Full-screen, works 100% offline with any USB/Bluetooth scanner; self-healing cache, auto-refresh.
Why here: Price-check queries at the counter slow the queue, and moving them to a self-service point is the cheapest fix.
Inventory/InventoryWT POS Salon
Salon appointments and services in POS - integrates with Salon Management
Why here: Appointment-led counters work differently from retail ones, and the till has to know about the booking.
Point of SaleWhere we deliver this
Fiscal requirements at the till differ by market and are covered on the country pages, which are sourced and reviewed separately.
POS Deployment: common questions
Does Odoo POS work offline?
Yes, and it should be demonstrated to staff before go-live rather than described to them. How much the till can still do without a connection is a design decision worth making explicitly, because it constrains other things the till can do while online.
Which hardware do you support?
Compatibility is decided by exact model rather than by category, which is why hardware proving is its own phase. Tell us the models you have or plan to buy and we test them at the site. Devices that meet a written specification still behave differently in the room.
How long does a multi-site rollout take?
The first site takes the longest because it produces the checklist. After that, sites go live on a repeatable routine and the pace is set by staff availability and by how many opening days you want covered, rather than by configuration.
Can we run different industries on one system?
Yes. Retail, restaurant, salon, clinic and similar operations run on the same platform with different configuration, and a group with mixed formats can hold them in one database with shared reporting. The setup per format is genuinely different, so each needs its own pilot rather than a copy of another.
What about local fiscal requirements at the till?
Those vary by market and are covered on our country pages, which are sourced and maintained separately. Where they apply, they are settled before the pilot rather than after, because retrofitting them across an estate is far more work than including them at the start.
Do you support kitchen displays and table service?
Yes. Kitchen displays, preparation screens, table plans and reservations are normal parts of a restaurant rollout. They belong in the pilot, because the pacing between the counter and the kitchen is exactly the thing that only shows up under real service.
Read next
Odoo Implementation
End-to-end Odoo deployment, from discovery to go-live.
Odoo Support & Maintenance
24/7 monitoring, bug fixes, performance tuning.
Odoo Integration
Connect Odoo with your stack and third-party APIs.
Odoo Training
Role-based training for users, admins, developers.
Odoo Localization
Country-specific compliance out of the box.
Tell us what you are trying to fix
A 30-minute call is usually enough to tell you whether this is a small piece of work or a project, and to say so before anyone writes a proposal.