Choose one system to be responsible for the normal kitchen print job for each delivery channel at each location. That might be the POS, an order management system, or the channel’s own setup. The right choice is the path that sends complete tickets to the right station and gives staff a workable way to spot failures.
Then turn off competing automatic print paths where the systems allow it, and give one person responsibility for reconciling orders during service. A printer making noise is not proof that every order arrived, and two tickets are not necessarily two orders.
Map each order from channel to kitchen
Start with the channels your restaurant actually uses: marketplace delivery, direct online orders, and any orders staff enter manually. Make a separate map for each location. A setup that works at one store may use a different POS, network, printer, or kitchen layout at another.
For each channel, trace the order through every system that can receive it, then mark which system can send a ticket to a printer. Note where staff accept the order, where they check its status, and whether a kitchen display is also part of the process. A display can help the kitchen work, but it does not automatically answer who is responsible for a paper ticket.
Use this hypothetical example as a starting worksheet. The names and routes describe a restaurant’s intended setup, not a claim that any particular integration works this way.
| Order source | Intended route | Print owner | Check before approval |
|---|---|---|---|
| Marketplace A | Marketplace → order manager → POS → kitchen printer | POS | Can the order manager’s automatic print be disabled for this route? |
| Marketplace B | Marketplace → order manager → kitchen printer | Order manager | Can staff match the ticket to the source order without a POS entry? |
| Direct website | Website → POS → kitchen printer | POS | Do modifiers and pickup details reach the ticket? |
The table separates the order route from print responsibility. Marketplace A passes through an order manager, but the POS is intended to print. If both systems print automatically, staff need a setting change or a different route before relying on the setup. If that change is not available, decide how the kitchen will distinguish the two outputs rather than assuming duplicates can be prevented.
Mark every unconfirmed connection and setting as an open question. Include backup printers and stations, too: a deliberate kitchen and bar split is different from two identical tickets reaching the same cook.
Check print control and ticket contents
Ask each vendor to show the complete flow using your exact marketplace, POS, location, and printer arrangement. Review the restaurant integrations directory as a starting point, then confirm the connection and setup you need. A listed integration does not settle who prints or what happens after a printer failure.
Otter describes an Order Manager that consolidates online and manual orders on a tablet, with automatic acceptance and printing and POS connections. Ask how those functions are configured for your particular channels and whether another connected system would also print.
Fleksa’s directory distinguishes live connections from connections available on request. Its marketplace examples include DoorDash, Uber Eats, and Grubhub, subject to restaurant setup and availability. Toast and Square POS connections are listed on request. For a specific channel, review the Uber Eats integration and confirm the required route with Fleksa.
Ask the vendor to demonstrate the controls, not just describe a general integration:
- Which system accepts the order, and which sends the print command? Can automatic printing be switched off independently for each channel?
- Does the ticket show the source order identifier, items, quantities, modifiers, promised time, and any notes the kitchen needs?
- Where can staff see the order total and any available status updates? Does a change or cancellation create a new ticket, update a display, or require a manual step?
- Can a staff member reprint intentionally? How is a reprint marked, and can the system show whether a print job was sent or actually completed?
- What happens when the printer, network, or receiving system is unavailable? Which recovery actions are supported, and which belong to staff?
Compare those answers with your menu. A ticket that drops a sauce choice or a preparation note can create as much work as a missing ticket. Also check whether prices and totals need to appear on the kitchen copy or only in the order screen. Staff should know where to find them either way.
Keep a short list of manual work beside the supported functions. For example, if a cancellation must be communicated verbally, name the person who checks for it and tells the kitchen. The related buying guide can help compare direct connections with a middle layer; here, the deciding question is what reaches the kitchen and who owns it.
Test the normal path and recovery
Before changing a live workflow, agree on acceptance criteria with the vendor and your shift lead. Use a sandbox or other vendor-confirmed safe test method. A simulated check must not create a real card charge, guest message, or courier dispatch. If the connected systems cannot safely simulate a step, walk through it without transmitting an order and record it as unverified.
For a hypothetical test, label the order TEST-42. It contains one sandwich, a modifier, and one drink, with a displayed total of $18. This is test data, not a charge or a cost comparison. The acceptance criteria are: one identifiable kitchen ticket at the intended station, the correct items and modifier, and the same $18 total visible in the order record. If the kitchen ticket is configured without prices, verify the total on the order screen instead.
- Run the normal route. Submit the safe test order. Match TEST-42 from the source record to the receiving system and kitchen result. Count tickets at the intended station and check the contents against the source.
- Interrupt the printer. With the vendor’s guidance, take the test printer offline and submit a second safe test identifier. Check what staff can see and whether an alert or pending status appears. Do not assume a print command means paper was produced.
- Restore and reconcile. Bring the printer back. Record whether the ticket prints automatically, needs an authorized reprint, or requires manual handling. Check for both a missing ticket and an extra copy.
- Try supported exceptions. Where safe and supported, check a change, cancellation, or reprint. If a case is intentionally unsupported, record the limitation and agree on the staff procedure rather than treating it as a failed feature every vendor must provide.
Record expected and observed results side by side, along with the channel, location, time, and person responsible for follow-up. Use test identifiers rather than private guest data. If a result is unclear, repeat the safe check after the setting is corrected; do not call the path ready just because the vendor expects it to work.
A live service pilot is a separate decision. Once the simulated checks and fallback are agreed, run any live pilot with staff actively monitoring real orders and a vendor-approved setup. Unlike the simulation, live service involves genuine orders and their normal consequences. Keep the pilot limited enough that someone can reconcile the source records with kitchen output throughout it.
Assign responsibility and reconcile every exception
Put the chosen path where the shift lead can use it. This simple responsibility diagram works for each channel:
Source order → receiving system → designated print owner → kitchen ticket → shift lead reconciliation
Exception → shift lead checks source and print status → controlled reprint or manual kitchen instruction → log the outcome
Reconciliation means matching an order in the source or designated order list to the kitchen result using its identifier. At handoff and during busy periods, the shift lead checks for orders with no corresponding kitchen result and for multiple tickets with the same identifier. Agree on the check interval before service; a long gap can leave a missed order undiscovered until a driver arrives.
If a ticket appears twice, do not discard it solely because the items look alike. Two guests can order the same meal. Compare identifiers and source records first. If the second copy is a reprint or duplicate, mark it according to the restaurant’s procedure and tell the kitchen which copy to follow.
If a ticket is missing, the shift lead should check the source order and receiving system before choosing a supported reprint. If printing is unavailable, use an agreed manual kitchen instruction that includes the order identifier, items, modifiers, and timing. Mark it as manual and note who passed it on. When printing returns, check whether the original job also produced a ticket before the kitchen prepares it again.
Decide who can change settings, who can authorize reprints, and who contacts the vendor. Keep open issues in a short log: the question, owner, next action, and decision needed. For the sample Marketplace A route, the decision is straightforward: use the POS as print owner if the order manager’s competing print can be disabled and the POS ticket passes the content and recovery checks. Otherwise, resolve the double-print handling or choose another supported route before rollout.
Bring your channel list, location details, printer map, and test cases to a Fleksa POS demo. Ask Fleksa to confirm availability for your location and show who controls printing for each route you want to use.
Frequently asked questions
Should the aggregator or POS print delivery orders?
Either can be the designated print owner if it supports the route and produces the information your kitchen needs. Choose one normal print path per channel and location, then check recovery and staff reconciliation before relying on it.
How can staff tell a duplicate from a second order?
Match the order identifier and source record rather than judging by the food alone. A deliberate reprint should follow a documented procedure so the kitchen knows which copy to use.
What should happen if the printer goes offline?
The shift lead should check the order record, follow the agreed reprint or manual fallback, and reconcile again after recovery. Ask the vendor which alerts and recovery actions the specific setup supports.
