Short answer: you call whoever owns the integration, and on most restaurant technology stacks that person does not exist. A typical multi-unit venue runs six or more vendors — POS, kitchen display, payments, printers, network, and a booking or property system — and when the seam between two of them fails, each vendor can truthfully say the problem is not theirs. Support architecture is who is accountable for the seams, and it belongs in your evaluation alongside price.
The Failure Mode Nobody Demos
Software demos show you the happy path. What decides whether you are happy in year two is the unhappy path: it is 7:40pm on a Saturday, the kitchen display has stopped receiving tickets, and you have to decide who to call before the tickets stack up.
A multi-unit Texas operator — a 400-seat flagship plus a quick-service site and eight travel centers — described the exact experience, unprompted, in the middle of a product conversation:
"The last thing I want to do is worry about my gear not going to the KDS. Who do I call? … And see, that's the issue I experienced. The KDS is not working. They just called me yesterday. I'm like, call the POS company. You need to call the KDS company. I mean, this is a stupid problem to have."
He was not describing a bug. Both vendors were probably working correctly in isolation. He was describing an architecture problem — two companies, one seam, and no owner. His conclusion was four words: "One system to rule them all."
That is not a preference for fewer features. It is a preference for a shorter phone tree.
Why Does The Finger-Point Happen So Reliably?
Because every vendor's support organisation is scoped to their own product, and integrations live between products. When a printer stops firing, the honest answers from each party are all technically correct:
- The POS vendor sees the ticket leaving their system.
- The hardware vendor sees a device that responds to a test page.
- The network provider sees a link that is up.
Nothing is broken, and your kitchen is still not printing. Operators experience this as being handed around. One brewery operator described being told by a POS vendor's support line that a printer issue was the manufacturer's problem: "the lady was saying, oh, you know, you'll have to speak to Epson."
The number of possible seams grows faster than the number of vendors. Three vendors give you three pairs. Six give you fifteen. That is the real reason stack sprawl gets expensive, and it does not show up on any pricing comparison.
What Does "Integration Ownership" Actually Mean?
Ask a vendor whether they integrate with your kitchen display, your booking platform, your property management system. Everyone says yes. The useful question is narrower: when that integration breaks, whose ticket is it?
There are four meaningfully different answers, and vendors use the same word for all of them:
| What they say | What it means when it breaks |
|---|---|
| "We have an open API" | Yours. You or your integrator built it; support will help with their side only. |
| "We have a partnership" | Shared, in practice unowned. Two support queues, no joint SLA. |
| "It's a certified integration" | Theirs to triage, usually with a named partner contact. Better. |
| "It's native — we built it" | Theirs entirely. One ticket, one owner, no handoff. |
None of these is wrong to buy. What is wrong is buying the first and believing you bought the fourth. Get the answer in writing per integration, not as a general statement about the platform.
What Is A Black Screen Actually Worth?
Hardware failure is the part of support with arithmetic attached, and it is worth doing the arithmetic before you need it. An operator opening a three-concept venue asked the question the right way round:
"If three months or four months in, I got a KDS screen that all of a sudden just is black every day and doesn't turn on anymore, how fast is it going to take them to get me a new one? Are they going to overnight it like they promised me in my demo, or is it going to take two weeks?"
Run your own version. A venue doing $18,000 on a Saturday across a twelve-hour service is turning roughly $1,500 an hour. A dead expo screen does not take the whole $1,500 — but it slows every ticket through the pass, and two weeks of degraded throughput is a materially different number from one overnight shipment.
So the questions to settle are concrete: is there advance replacement or do you ship the dead unit first? Who pays freight? Is there a spare-unit policy for multi-site groups, and does the vendor hold stock in your region? For a group, a small on-site spares pool is usually cheaper than any SLA you can buy — but you need to know whether the vendor will sell you one.
Does The Escalation Path In The Deck Exist In Real Life?
Every vendor's deck has a tiered support diagram. The question is what happens at 7:40pm on that Saturday.
A resort operator with a 22,000 square foot banquet operation put the failure mode simply: "it's really challenging when we're struggling with our systems to get a hold of anyone at our current organization." A four-location entertainment group evaluating a replacement for a legacy enterprise platform was blunter about why they were shopping at all — "where a lot of our shortcomings are coming with our current system is definitely on support."
Two properties separate a real escalation path from a diagram:
- A path that starts in the venue. If the fastest route to help requires a manager to leave the floor, find a laptop and log a portal ticket, it will not be used during service. In-app or in-terminal contact is not a convenience feature; it is the difference between a path that gets used and one that does not.
- A defined trigger for human escalation. Not "we escalate as needed" — an actual condition. Site down, revenue-affecting, more than N minutes.
Where AI-First Support Helps, And Where Operators Stop Trusting It
Most vendors have put a bot in front of their support queue. For "how do I add a modifier," that is a genuine improvement — instant, and available at 2am when a manager is doing prep for tomorrow.
It stops working at the exact moment you need it most. A catering operator with 22 years in business described the tipping point: "You have to ask an AI bot all the time, which is annoying… it's not something that I trust or rely on."
Note the word trust. The complaint is not that the bot is unhelpful. It is that when something is actually wrong, an operator needs to believe the answer, and a confident wrong answer during service is worse than a queue.
The reasonable test for a vendor: can you reach a human without arguing with a bot first, when the issue is revenue-affecting? If the honest answer is no, you have learned something useful about year two.
Support That Teaches Versus Support That Fixes
There is a quieter distinction that matters more at multi-unit scale than most buyers realise. An eatertainment operator described a pattern that will be familiar to anyone who has run a growing group:
"Every time I call support, I'm like, is there a training class or something I can do online to learn? … The guy will get on, take control of the computer and do it and then be like, there. There you go. And I'm like, no, that's not teaching me anything."
Remote-fix support feels responsive and creates permanent dependency. At one location that is an annoyance. At twelve it is a tax — every configuration change becomes a ticket, and your own team never develops the competence to run the system.
Ask whether the vendor's model is to fix it for you or to make your team able to fix it, and whether documentation and training are included or billed. The second model is slower on any single call and dramatically cheaper across a portfolio.
The Question About Where Support Sits
Operators raise this constantly and are often slightly apologetic about it. An Australian multi-venue group, near the end of an evaluation: "And in terms of online support and that — I don't have to speak to America, do I?" A US operator, in the same week, on the same subject from the other direction: "You had me sold on working in the United States."
Both are asking the same practical question rather than making a political one: is support awake when my venue is open, and does the person understand my operation? Time zone coverage during your actual service hours is the substance. Regional context — knowing what a bottle shop is, or what happens at a stadium on an event day — is the rest.
What Good Looks Like, In Numbers
Vague commitments are unenforceable. These are the figures worth getting a vendor to commit to in writing, and reasonable targets for a multi-unit operator:
| Measure | Ask for | Why it matters |
|---|---|---|
| First response, revenue-affecting, during service | Under 5 minutes | Longer than this and the manager has already improvised a workaround |
| First response, non-urgent | Same business day | Configuration questions should not wait a week |
| Escalation to a named engineer | Within 30 minutes of a site-down | Tier 1 scripts do not resolve integration failures |
| Hardware advance replacement | Next business day, freight paid | Two weeks of a dead expo screen is a throughput problem, not an inconvenience |
| Support hours in your time zone | Full service coverage, 7 days | Weekend evenings are when venues actually break |
| Integrations with a named owner | 100% of the ones you rely on | Any gap here is a future finger-point |
Ten Questions To Put In Your RFP
Copy these into your evaluation. The answers are more predictive of year two than any feature matrix.
- When an integration between your system and a third party fails, whose ticket is it? Name the owner per integration.
- What is your target response time for a revenue-affecting issue during service hours, and what is it at 9pm on a Saturday?
- Can a manager reach support from the terminal without leaving the floor?
- What condition triggers escalation to a human, and to a named engineer?
- Is hardware replacement advance-ship or return-first? Who pays freight?
- Do you hold hardware stock in our region, and can we buy a spares pool?
- Which of our integrations are native, certified, partnered, or API-only? Give the list.
- Is training and documentation included, or billed per session?
- Where is your support team located, and what hours do they cover in our time zone?
- Can we speak to two current customers of our size and venue type about support specifically?
Question ten is the one vendors like least and operators value most. A club operator opening a 32,000 square foot venue asked for exactly that during evaluation — "I would need three or four places that use your products quite similar to me. I don't want to call up the Ritz Carlton of a thousand." Peer references at your scale tell you more about support than any SLA document.
The Point
Price is knowable in an afternoon. Features converge — an operator evaluating three platforms for a new build said it flatly: "All of the systems basically do the same thing. They check all the boxes… so for us it's going to come down to price and customer service availability after we sign a contract."
He is right about the boxes and right about what is left. Support is the part of the purchase you cannot evaluate from a demo and cannot easily change afterwards. Evaluate it deliberately, in writing, before you sign.
GoTab's support reaches operators from inside the platform, and our integrations are supported by the team that built them. See how GoTab supports enterprise operators, or review our integrations.
