Restaurant order workflow guide

What is a kitchen display system?

A kitchen display system, commonly shortened to KDS, is a digital order screen used by restaurant teams to receive, organize, prepare, and complete kitchen tickets. It can replace or supplement printed tickets by sending order information from a point-of-sale or ordering workflow to one or more back-of-house displays.

A KDS is not the same thing as a payment terminal, and the screen alone does not determine which ordering or payment tools will work with it. The useful question is whether the complete system can reliably move the restaurant's actual orders, modifiers, timing details, and completion updates through the stations that need them.

How a kitchen display system works

When an order is entered through a connected ordering channel, the system creates a digital ticket and routes it according to the restaurant's configuration. A ticket can show the ordered items, modifiers, dining or fulfillment details, and elapsed time. Kitchen staff then work from the screen and mark individual items or the complete ticket as prepared.

Current documentation from Toast and Square illustrates a common pattern: orders can be shown on preparation stations, while an expeditor or expo station provides a broader view for coordinating the final handoff. The precise workflow, supported order sources, and available controls differ by product and configuration, so restaurants should verify them with the responsible POS or KDS provider.

  1. Order entry: A staff member or approved digital channel creates an order in the restaurant's ordering system.
  2. Ticket routing: Configured rules send the relevant items to the correct display or station.
  3. Preparation: Cooks view the ticket, modifiers, and timing information while preparing the order.
  4. Completion: Staff mark items or tickets complete, allowing the next station to see the updated status.
  5. Handoff: An expo, service, pickup, or delivery workflow uses the completed order status to continue fulfillment.

Prep screens and expo screens serve different jobs

A preparation screen usually focuses on the items assigned to a particular work area, such as grill, fry, pantry, beverage, or dessert. This keeps a station from sorting through every item on every order. Routing must reflect the menu and the way the kitchen actually divides work.

An expo screen is commonly used to see a more complete order, coordinate items from multiple prep stations, and confirm that the order is ready for its next handoff. Toast's current platform guide describes prep and expediter KDS roles, while Square's setup documentation distinguishes Prep and Expeditor devices. Those examples show the general concept without establishing that every product uses the same labels or completion behavior.

A small operation may need only one useful view. A higher-volume or multi-station kitchen may need separate screens and completion rules. More displays are not automatically better; each one should have a defined owner, viewing angle, routing purpose, and fallback procedure.

Features to evaluate around the restaurant's workflow

Feature lists are most useful when they are tied to a real service problem. Restaurants comparing systems can use the following categories to structure demonstrations and trials:

  • Order-source visibility: Identify which counter, table-service, kiosk, online, pickup, and delivery orders must appear, then verify each supported path with the provider.
  • Station routing: Confirm whether items can be directed by category, prep station, fulfillment type, or another rule the kitchen can maintain.
  • Ticket readability: Review text size, modifier emphasis, alerts, colors, and the number of tickets visible during a rush.
  • Timing and prioritization: Determine how the system shows ticket age, scheduled orders, priority changes, and items with different preparation times.
  • Completion and recall: Test how staff mark an item or ticket complete, correct an accidental completion, and communicate status across stations.
  • Reporting: Ask what preparation-time or kitchen-performance information is available and how the business should interpret it.
  • Hardware resilience: Evaluate mounting, power, network access, heat, grease, moisture, cleaning, touch controls, and any kitchen-grade requirements for the planned environment.

Do not assume a feature shown in one provider's documentation is universal. Ask for a demonstration using the restaurant's menu structure and order channels, and have the responsible provider confirm the supported hardware and software configuration.

When a KDS may be useful

A KDS may be worth evaluating when paper tickets are difficult to sort, orders arrive through several approved channels, staff need clearer station assignments, modifiers are frequently missed, or managers lack a consistent view of preparation status. It can also help a restaurant formalize how an order moves from entry to preparation and final handoff.

The system does not fix an unclear kitchen process by itself. If menu items are assigned inconsistently, staff use undocumented workarounds, or order channels bypass the main workflow, a new display can reproduce the same confusion digitally. Map the current process before choosing technology: who enters the order, which station prepares each item, who coordinates the completed order, and what happens when a ticket changes or disappears?

Restaurants should also retain an approved contingency for a display, device, network, or service interruption. The provider should explain the documented fallback behavior for the exact configuration; staff should not invent a process during a busy service.

A practical KDS evaluation checklist

  1. Draw the order path. List every order source and trace it through prep, expo, guest pickup, table service, or delivery handoff.
  2. Define station responsibilities. Decide which items and details each station needs and who may change routing or completion settings.
  3. Test representative tickets. Include modifiers, voids, changed items, split preparation, scheduled orders, and multiple fulfillment types where they belong in the real operation.
  4. Observe a peak-volume simulation. Check readability, ticket ordering, alerts, screen capacity, and staff actions under realistic load instead of relying only on a quiet demonstration.
  5. Verify the full configuration. Ask the responsible providers to confirm supported order sources, POS connection, device requirements, network needs, update process, and support boundaries.
  6. Plan the physical installation. Confirm power, mounting, cable protection, reach, sight lines, ventilation, cleaning instructions, and protection from kitchen hazards.
  7. Document the fallback. Train staff on the approved process for missing tickets, lost connectivity, a failed screen, and restoring normal operation.
  8. Assign review measures. Choose observable signals such as missed modifiers, remake causes, ticket-age patterns, or handoff delays, while avoiding promises that the system will guarantee a particular result.

Roll out the system with clear operating rules

Start with a documented station map and a controlled test before changing the entire kitchen. Name each device by its function, verify its assigned order sources, and give staff a simple definition of what completing a ticket means. A prep cook, expeditor, server, and manager may each interpret that action differently unless the handoff is explicit.

Test corrections as carefully as normal orders. Staff should know how the selected system handles a changed item, void, recall, duplicate display, or ticket that was completed too early. Review alert volume as well: too few alerts can hide changes, while too many can be ignored during a rush. Keep configuration access limited to assigned roles and record material routing changes so troubleshooting starts from a known setup.

Keep support requests privacy-safe

A kitchen ticket may contain customer names, order notes, contact details, or other information that should be visible only where the workflow requires it. Position screens thoughtfully, apply role-based access where available, and follow the provider's current instructions for device accounts, updates, locks, and remote administration.

When requesting help, share only the minimum non-sensitive information needed to identify the affected device, station, order path, and error. Do not put cardholder data, full account numbers, security codes, passwords, bank credentials, or secret API keys into screenshots, email, chat, or a general contact form. Use approved provider support channels for system logs or transaction-specific investigation.

Related restaurant and POS resources

Start with the POS systems and integrated payments FAQ hub for broader planning context. Review what a cloud POS system is to understand a common deployment model, and compare the workflow with the national restaurants and food service guide. The payment processing glossary can help teams align terminology before speaking with providers.

Map the kitchen before comparing systems

Document the restaurant's order sources, prep stations, expo process, peak-volume conditions, physical environment, and fallback needs. Then ask each responsible POS or KDS provider to demonstrate that exact workflow and confirm the supported configuration in writing. Payments Max can help organize restaurant payment and POS requirements, while the product provider must verify current functionality, device support, and setup details.

Discuss your restaurant workflow

To learn more about how TSYS can help improve the way your organization accepts payments, markets to new customers, or manages its HR responsibilities, get in touch by calling 585-981-8463 to get started.

CONTACT US