Choose the KDS vendor that can show you usable order history, offer a support path during your busiest hours and name who coordinates an investigation when connected systems disagree. A polished ticket screen is not enough. Before buying, ask each vendor to demonstrate the evidence an authorized person can retrieve and put its response and escalation commitments in writing.
The strongest choice may not be the vendor with the longest feature list. It is the one whose support matches your service hours, your staff's ability to investigate a problem and the systems that send orders to the kitchen. Use the same questions and simulated scenario for every quote.
Define the support you need during service
Start with the moments when a missing or delayed ticket would be hardest to handle. A lunch counter with one screen and a quiet evening has a different support need from a restaurant running a busy dinner across several preparation stations.
Write down your opening hours, busiest order periods and any hours spent preparing scheduled orders before opening. Include weekends and holidays if you trade then. Ask whether support is available during those periods, through which channels, and whether the same team can investigate technical issues throughout the coverage window.
Distinguish an initial response from a resolution. A message acknowledging your case may be useful, but it does not tell you when someone will start investigating or when a complex issue will be fixed. Ask what the vendor commits to for each severity level, how that severity is assigned and what happens if the first response does not move the case forward.
Also decide who can make the call. During a rush, a cook may be able to report that a ticket is absent but may not have time or permission to access logs. The manager may need a short list of facts to collect: approximate time, affected station, order reference and whether other tickets are appearing. Ask the vendor what information is essential for opening a case and what its support team can retrieve itself.
Build a fallback plan alongside the purchase decision. Who tells the kitchen about an order if a display cannot be trusted? Who checks for duplicates before food is prepared? Who decides when to return to the usual workflow? Keep that plan simple enough to use during service, and do not assume a particular system supports recall, rerouting or cancellation handling without a demonstration.
Compare diagnostic history and access
A useful history helps you answer a narrow question: what happened to this order, at which point, and when? Ask vendors to show a sample timeline from an order entering the connected system through its appearance and handling at the relevant kitchen station. The events available will depend on the products and configuration, so request a demonstration using your intended setup.
Look for timestamps that help separate stages. For example, an order-created time alone cannot establish whether an order reached a display. Ask whether the history identifies when the order was sent toward a station, displayed, changed or marked complete, and how the system records a failed or delayed step. If an event is not recorded, note that gap rather than treating a blank field as proof that nothing happened.
Ask how long each type of history remains available. Screen history, support logs and exported records may have different retention periods. A restaurant that discovers a pattern during a weekly review needs access beyond the immediate shift. Also ask whether the retention period changes by plan, device or connected service.
Access matters as much as retention. Can an authorized manager view the history without waiting for support? Can the restaurant export a sanitized event history, or must the vendor supply it? Ask for the format, typical request process and any charge. A screenshot may help explain a single ticket, while a structured export may be more useful for comparing several orders.
Check what the record identifies: the order reference, station, device and time zone are practical starting points. Ask whether clocks are synchronized and how corrections appear. For a changed order, can an authorized user distinguish the original details from a later modification? For a canceled order, ask what evidence remains and what the kitchen sees. Do not assume every product records these events in the same way.
Use a fictional order in a vendor-supported training environment. Have the vendor show the screen and the resulting history, then explain what would be visible to your manager versus its support team. The exercise should not trigger a real card payment, guest message or courier dispatch. Follow up on missing fields with specific questions, not a general request for more logging.
For context on the kitchen workflow you want to examine, review kitchen order management and map the steps your staff actually performs. A display can show useful order details without necessarily giving your team every diagnostic event it wants; assess those separately.
Assign responsibility across connected systems
A KDS rarely operates alone. Orders may pass through an ordering channel or POS, a network and one or more kitchen displays. When separate companies supply those pieces, the difficult question is not simply whose component failed. It is who owns the case while the cause is still unknown.
Ask each vendor to describe the first contact for an order that appears in the POS but not at the expected station. Then ask what happens if that vendor cannot find a fault in its own component. Will it coordinate with the other provider, provide evidence for your manager to pass on, or close the case? Get the escalation contacts and handoff expectations in writing.
A practical responsibility map should name the restaurant's contact, each provider's support channel and the person or team responsible for coordinating the case. It should also state what evidence each party can provide. For instance, the POS provider may be asked for the order reference and its available send history; the KDS provider may be asked for its available station and display events. Confirm the actual records each can supply rather than assuming either has a complete timeline.
Ask how network and device issues enter the process. If your restaurant manages its own network, who can help distinguish a connectivity issue from an application issue? If a third party supplies the hardware, who decides when that provider should be involved? Your manager should not have to become a technical referee between three support desks during a dinner rush.
A single supplier for more components can simplify the contact list, but it does not by itself prove faster support or complete diagnostic access. Conversely, separate suppliers can work well if the handoffs are clear. Compare the written process, not just the number of vendor names on the invoice.
For product context, Square describes kitchen tickets, timers, station routing and expeditor functions. Toast offers a kitchen display product. Fleksa offers a kitchen display system linked to restaurant orders; its public page describes order types, items, quantities, modifiers, future held orders and configurable timing and color indications. Ask each supplier to demonstrate support and history for your configuration rather than inferring them from the ticket display.
Score support before signing
Give every vendor the same questionnaire and record the answer, date, evidence and any open question. Use a demonstration for visible workflow and a written quote or agreement for commitments. An answer such as “support is available” is too broad to score highly unless you know the hours, channel and scope.
The table below is a hypothetical scoring example for one restaurant that trades during weekend evenings and has a manager, but no dedicated technical staff, on shift. Each category is worth 0 to 2 points: 0 means unanswered, 1 means partly answered, and 2 means demonstrated or clearly committed in writing. It compares support evidence, not product prices or overall operating cost.
| Category | What earns 2 points | Vendor A | Vendor B |
|---|---|---|---|
| Service-hour response | Written coverage and escalation fit the restaurant's peak hours | 2: weekend coverage stated | 1: weekend escalation unclear |
| Event history | Relevant order and station events shown with retention periods | 1: retention for one event unclear | 2: events and retention shown |
| Evidence access | Manager access or a documented route to a sanitized export | 2: export route documented | 1: export process unanswered |
| Fault ownership | Named case coordinator and handoff process across providers | 2: coordinator and handoff stated | 0: no owner identified |
| Total | Maximum 8 points | 7 | 4 |
Under these assumptions, Vendor A is the better-supported choice for this restaurant: its stated weekend coverage and case coordination address the restaurant's highest-risk periods and limited technical capacity. Its unresolved retention question still matters. Ask for that answer before signing; a score is not a substitute for a minimum requirement. If a longer history is essential to your operation, make it a pass-or-fail condition even if the vendor scores well elsewhere.
Use these questions to complete your own scorecard:
- Which support hours and channels apply to our location and plan, including holidays? What is the escalation path outside those hours?
- What are the initial response commitments by severity, and who decides the severity?
- Which order, station and device events are recorded? How long is each retained?
- Who can view or export a sanitized history, in what format, and at what cost?
- Who coordinates a case involving the POS, network and display? What evidence is shared at each handoff?
- Which commitments appear in the agreement, and what exclusions or additional charges apply?
Keep unanswered items visible next to the vendor's name. Date each demonstration and written answer, and ask for the agreement to reflect the commitments that affect your decision. Compare quoted support, equipment and other operating charges on the same basis; a support score does not tell you the total cost.
Before rollout, rehearse the agreed workflow with staff in a vendor-supported training environment using fictional orders. Practice collecting an order reference, opening a support case and checking a sanitized history without sending a real payment, guest message or courier dispatch. A supervised service period afterward is a live pilot, not a simulation: use the real operating process, assign a manager to monitor it and keep your fallback plan ready.
Map your current order path using your restaurant POS system and the guide to routing tickets by preparation station. Then ask Fleksa to demonstrate its kitchen display and applicable support and history capabilities against the same scorecard you give other vendors.
Frequently asked questions
How long should a KDS retain diagnostic history?
Choose a period that covers how and when you review problems. Ask for retention by event type and confirm whether your team can access the records or must request them from support.
Does a fast support response mean the issue will be fixed quickly?
No. Initial response, investigation and resolution are different stages. Ask for written response commitments, escalation steps and any resolution commitments or exclusions.
Who should handle a KDS issue when the POS and display have different vendors?
Agree on a case coordinator before purchase. Each provider should explain what evidence it can supply and how it hands the case to another provider when the cause is not yet clear.
