If your EPOS support contract reads “next business day”, stop reading this and go check it. In hospitality, next business day is another way of saying “you lost Saturday”. And if you are running a Saturday service without a working till, you are not just losing covers - you are losing the regulars who decide, quietly, that they will try the place across the road next time.
This guide is for operators, GMs and IT managers who already know that EPOS is the spine of the restaurant. The question in 2026 is not whether you need support. The question is what good support actually looks like, who provides it, and how to stop paying for a contract that will let you down on the only night that matters.
What EPOS Support Actually Covers in 2026
Five years ago, EPOS support was largely about fixing the till when it stopped printing. That definition is now far too narrow. A modern EPOS estate is a small distributed system. The terminal at the pass is one node. Behind it sit kitchen display screens, kitchen printers, payment terminals, the back-office server (or its cloud equivalent), the PMS, the reservation platform, the loyalty integration, the stock system, the accounts feed, and the reporting layer the finance director looks at on a Monday morning.
EPOS support in 2026 means keeping all of that talking to itself, all the time. In practice that breaks down into:
- Hardware support for terminals, printers, cash drawers, KDS screens and handhelds
- Software support for the EPOS application itself, including patching, menu engineering and version upgrades
- Network and connectivity issues affecting the EPOS estate, which we cover under managed network
- Payment terminal troubleshooting and PED swap-outs
- Integration support across the third-party stack (PMS, reservations, loyalty, accounts, gift cards)
- PCI DSS compliance work, which is now inseparable from EPOS support
- Reporting, user management and menu changes for operators who do not want to handle this in-house
If your current support arrangement only covers the first item on that list, you do not have EPOS support. You have a hardware warranty.
The Major EPOS Platforms in UK Hospitality
Every operator we speak to wants to know which EPOS we recommend. The honest answer is that the right platform depends on the operating model, not on a leaderboard. Here is how the main platforms in the UK market actually behave when you have to support them day to day.
Oracle Micros Simphony
Still the dominant platform across larger restaurant groups, hotel F&B and premium casual dining. Simphony is mature, deeply configurable and integrates with practically everything in the enterprise hospitality stack. The strengths are stability, reporting depth, multi-property control and a serious approach to PCI scope reduction. The gotchas are configuration complexity and the fact that small changes often need someone who genuinely knows the platform - Simphony rewards specialists and punishes generalists. Licensing is also not cheap, and version upgrades need planning.
Zonal Aztec and Zonal Tills
Zonal remains the default for a large slice of UK pubs, branded casual dining and managed estates. Aztec is a solid evolution of the platform with a more modern UI and tighter integration to the wider Zonal ecosystem (loyalty, ordering, stock, reservations). The strength is that you can run a multi-site operation almost entirely on Zonal-native components, which simplifies integration. The gotcha is that the deeper you go into the ecosystem, the harder it is to swap one component out without rethinking several others.
Tevalis
Strong in premium hospitality, members’ clubs and operators who want flexibility without going full enterprise. Tevalis has built a reputation for being responsive on integrations and willing to work closely with third parties. The strength is configurability and the partner ecosystem. The gotcha is that, as with any flexible platform, the quality of your install depends heavily on how well it was set up on day one.
Lightspeed Restaurant L-Series and K-Series
Lightspeed sits in an interesting spot. The L-Series (formerly iKentoo) is well suited to independents and small groups who want a clean, modern interface and decent reporting without a lot of overhead. The K-Series (formerly Kounta) tends to suit slightly larger operations with multi-site needs. Both are cloud-first, both integrate sensibly with the usual reservation and payment platforms. The gotcha is that “cloud-first” still means the local network has to be solid - when the connection drops, offline mode is your friend, but only if it has been tested.
Toast
Toast is a serious player in the US and now properly active in the UK. The hardware is purpose-built for hospitality, the software is opinionated in a useful way, and the integrations are growing fast. The strength is that the whole thing is designed as one stack. The gotcha for UK operators is that the local payment, accounting and PMS integration ecosystem is still maturing relative to incumbents - worth checking against your specific stack before committing.
Square for Restaurants
Square fits independents and smaller groups well. It is quick to deploy, the hardware is cheap, and the back office is approachable. The strength is genuinely low friction. The gotcha is that as you scale into multi-site, complex menus or heavy integration requirements, you start to outgrow it. That is not a criticism of Square - it is a criticism of using any platform outside its sweet spot.
The summary: there is no bad choice on this list. There are choices that fit your operation and choices that do not.
Cloud vs On-Premise EPOS - The Current State of Play
In 2026 the cloud-versus-on-premise debate is largely settled in favour of cloud, but with caveats that matter. New deployments are overwhelmingly cloud-based or hybrid. The reasons are familiar: easier multi-site management, simpler updates, less hardware to babysit, and a smaller PCI DSS footprint when scoped properly.
The caveats are also familiar. Cloud EPOS depends absolutely on the network. A cloud till with a dead WAN is a paperweight, unless offline mode has been configured, tested and rehearsed. We see operators who have technically enabled offline mode but have never put it through a real service, which is the worst of both worlds - you think you are covered, and you are not.
On-premise still has a role in larger sites with complex configurations, hotel environments where the F&B system needs to talk tightly to the PMS at the local level, and operators who want to keep control of the back-office server. Hybrid setups, where the database is local but management and reporting are cloud, are increasingly common and often the most pragmatic answer.
Whichever model you run, the network underneath has to be designed for it. If you are operating in central London, the practicalities of getting a reliable circuit into a listed building on a side street are not trivial - this is a recurring conversation with operators we look after across Soho and the West End.
What Good EPOS Support Looks Like
Strip away the marketing and it comes down to a small number of measurable things.
24/7 Cover That Actually Means 24/7
Hospitality runs evenings, weekends and bank holidays. Your support cover has to match. “24/7” on a contract means nothing if the out-of-hours line routes to a voicemail that is checked on Monday. Ask for the rota. Ask who answers the phone at 22:30 on a Saturday. Ask how many engineers are on call.
SLAs That Match the Risk
Response times should be measured in minutes, not hours, for anything that stops trading. A reasonable target for a P1 (cannot take payment, cannot take orders) is a live engineer on the phone inside fifteen minutes and remote diagnosis underway immediately. On-site response should be defined in hours, not days, and the geography should be realistic - promising a four-hour on-site response to a site three hours from the nearest engineer is theatre.
Real Coverage of the Whole Stack
Good support covers the printer at the pass, the KDS in the kitchen, the handheld on the floor, the payment terminal, and the integrations behind them. It does not stop at the EPOS application and tell you that the printer is “a hardware issue” or that the payment terminal is “the acquirer’s problem”. The operator does not care whose fault it is at 19:45 on a Friday. The operator wants it fixed.
Change Management That Does Not Require a Ticket Marathon
Menu changes, price updates, new user accounts, tax rate changes - these should be straightforward, fast and logged. If your support partner needs three working days to add a new menu item, you have the wrong partner.
PCI DSS 4.0 and EPOS - The Compliance Angle
PCI DSS 4.0 is now in full effect, with the future-dated requirements active from 31 March 2025 firmly in the rear-view mirror. For restaurant operators the practical implications are unavoidable.
Scope is everything. The smaller you can make your cardholder data environment, the less PCI work you have to do. Modern EPOS and P2PE-validated payment terminals can take card data almost entirely out of scope at the till, which is the goal. If your current setup does not do this, that is your first conversation.
Beyond scope reduction, 4.0 raises the bar on authentication, logging, vulnerability management and the documented evidence that controls are actually working. Quarterly scans, annual assessments, change logs, user access reviews - none of this is glamorous, but all of it sits on the EPOS estate.
This is where EPOS support and cyber security stop being separate disciplines. The same endpoints that take orders also process payments. The same network carries guest WiFi and PED traffic. Treating them as separate problems is how operators end up with breaches and fines. Your support partner needs to think about both at once.
The Integration Web
A modern restaurant runs on integrations. EPOS to KDS. KDS to kitchen printer. EPOS to payment terminal. EPOS to PMS in a hotel. EPOS to reservation platform. EPOS to loyalty. EPOS to stock. EPOS to accounts. EPOS to reporting. Sometimes EPOS to a kiosk or to an online ordering channel that lands orders straight into the kitchen.
When something breaks in this web, the symptom is rarely where the problem is. An order that prints to the wrong printer might be a KDS routing issue, a menu configuration issue, a network issue, or a misconfigured printer queue. A payment that does not post back to the EPOS might be a tokenisation problem, a clock drift between two devices, or a failed integration handshake.
The diagnostic skill that matters in 2026 is being able to look at the whole web rather than the individual component. That is the difference between a vendor who supports their own product and a hospitality IT partner who supports the operation. It is also the most common reason operators end up combining vendor support (for the deep platform issues) with a specialist hospitality IT partner for everything else.
Specialist Partner vs Vendor Support
EPOS vendors offer their own support, and for some issues - deep platform bugs, version upgrades, licensing - they are the right people to talk to. For everything else, a specialist hospitality IT partner is usually the better bet, for three reasons.
First, the partner owns the whole stack. They will not hand you off to the printer manufacturer, the payment provider or the network supplier. They will fix it.
Second, the partner is local and on-site when it matters. A vendor’s UK support team may be excellent on the phone, but they are not driving to your site at 20:00 on a Saturday. A specialist partner with engineers in the right cities is.
Third, the partner sees the same problems across many operators. They know what breaks, why it breaks, and how to stop it breaking again. Vendor support, by design, sees only their own product.
The pattern that works for most multi-site operators is a specialist partner as the first line for everything, escalating to the EPOS vendor for genuine platform issues. This gives you a single number to call, faster resolution, and a partner who understands that a broken till is not a ticket - it is a service in trouble.
The Real Cost of Downtime
Operators underestimate this consistently. Take a mid-size London restaurant doing £45,000 a week, roughly half of that on Friday and Saturday evenings. A two-hour EPOS outage on a Saturday at 19:30 is not two-fifteenths of the day’s revenue. It is the peak of the peak. Realistically you lose somewhere between £2,500 and £4,500 in covers you cannot turn, drinks you cannot ring through, and tables you have to apologise out of the door.
That is the visible cost. The invisible costs are larger. Comp’d meals to keep the regulars sweet. Staff overtime to manually reconcile the night. A finance team spending two days unpicking the cash-up. An ops director writing an apology to a private dining client. And the regulars - the ones you actually built the business on - who quietly stop coming.
A reasonable EPOS support contract for a site like that costs a small fraction of one such incident per year. If the contract prevents one Saturday-night outage in twelve months, it has paid for itself several times over. If it prevents two, it is the cheapest line on the P&L.
Conclusion
EPOS support in 2026 is not a hardware warranty. It is the quiet infrastructure that keeps a restaurant trading on the nights that matter, keeps the payment estate compliant, keeps the integrations honest, and keeps the operator out of the weeds. The platforms are mature, the integrations are deep, and the compliance bar is high. Good support reflects all three.
If you are not sure your current arrangement clears that bar, the test is simple. Pick a Saturday, call the support line at 20:00, and see what happens. The answer will tell you everything.
CloudMatters provides specialist hospitality IT support to restaurants, hotels and multi-site operators across London and the UK. If you would like a straightforward review of your EPOS estate and support arrangements, get in touch - no slide decks, no jargon, just a useful conversation.