If you have ever watched a kitchen during a 200-cover dinner rush, you have seen what bad ticketing looks like: a single waiter shouting 'two paneer, one dal, no wait three dal, fire the bread later' across a hot line, while the bartender wonders if anyone ordered the Old Fashioned that was supposed to land before the mains.
KOT routing is the unglamorous software layer that makes this disappear. Here is what it actually does.
What is a KOT?
KOT stands for Kitchen Order Ticket. It is the printed (or displayed) instruction that tells one specific station what to make, for which table, in what sequence. A single guest order frequently produces 2–4 KOTs, one per station, each with a subset of the items.
- 2× Paneer Tikka — extra spicy
- 1× Tandoori Chicken (half)
- 3× Butter Naan
The station map
Every menu item is tagged with one or more station IDs: tandoor, curry line, cold kitchen, bar, dessert, expo. When an order is placed, the routing engine fans the items out to the correct printers or KDS screens. A Mojito goes to the bar. A Paneer Tikka goes to the tandoor. A Gulab Jamun goes to the dessert station — but only after the mains are fired, which leads us to the next problem.
Most failed POS rollouts start with a missing station map. Spend 30 minutes mapping every item to a station before you import the menu — it saves a week of rework.
Course timing
A guest does not want their starters and mains to land at the same time. They want appetizers within 8 minutes, mains 12 minutes after the appetizers clear, and dessert when they signal for it. The KOT system has to model this without the waiter having to think about it.
We do this by tagging each item with a course (1, 2, 3) and an inter-course delay. Course 1 fires immediately. Course 2 is held in the routing queue and released either after a fixed delay or when the waiter taps 'Fire mains'. Course 3 (dessert) is always held until manually fired.
- 1Order placed → Course 1 KOTs print at all relevant stations.
- 2Waiter (or auto-timer) fires Course 2 → Course 2 KOTs print.
- 3Guest signals for dessert → Waiter taps fire → Course 3 prints.
Modifier propagation
If a guest says 'extra spicy' on their Paneer Tikka, that modifier has to ride along on the KOT — visually loud, in caps, on its own line. If they later add 'no garlic', the modifier has to update the existing ticket without confusing the line cook. Most cheap POS systems get this wrong by reprinting the entire ticket; ours sends a delta KOT marked MODIFY in red.
When the printer dies
Thermal printers fail. Network drops. Power flickers. Real systems have to handle this gracefully. Indostra runs a heartbeat ping every 10 seconds against every registered printer. If a printer misses three heartbeats, the routing engine fails over to the secondary printer for that station, and posts an alert to the manager's phone.
Keep a duplicate ticket queue on the manager tablet. If both printers fail, staff can hand-write from the screen — but they should not have to remember the order from memory.
KDS or paper?
Kitchen Display Systems are objectively better than paper for high-volume venues — they are searchable, time-stamped, and never get lost in the slop. But they require the kitchen to look up at a screen, which not every line is built to do.
Our recommendation: paper for the tandoor and curry line (the hands-down, head-up stations); KDS for expo and the bar (where staff can glance up). Indostra supports both, on the same order, with no extra config.
Builds the KOT routing engine. Believes a kitchen is a real-time system, not a queue.