Peak ordering
What decides a catering system is the lunch and dinner rush: whether a scan order lands immediately, whether add-ons vanish, where a ticket goes if the kitchen printer jams, and who sees a chase. We spend a peak shift with servers and the kitchen—shouted tickets or screens, how the pass splits stations, how voids and comps are recorded. Notes on doneness, allergies, packing, and waitlists look minor until they drop off the ticket once and the floor goes back to handwriting. The scope list must say which dishes go to hot, cold, or a stall, and after how many minutes a chase fires—not merely “kitchen management.”
One kitchen queue
If dine-in, delivery, and pickup each keep their own queue, the kitchen runs three tempos at once. Platform, mini-program, and in-store scan orders must share one fire sequence, with the ability to 86 a dish or stretch ticket times in the rush instead of the manager shouting in a chat. The bill cannot be vague either: merges, splits, whole-check discounts, item comps, and stored-value offsets, with permission by role and operator, reason, and time on the check. If month-end margin still depends on memory, recipes never unwind to ingredients and the owner only sees “we probably made money.”
Recipes and food cost
Catering stock is hard because consumption is reverse-calculated. A combo sold must explode to rice, oil, meat, and seasoning and then hit the storeroom; WIP, 86s, waste, and tastings that sit outside the same rules never match the physical count. We back-solve ingredient use from dish sales, suggest purchasing, and put waste through approval instead of a verbal “write it off.” Peak stockouts and off-peak waste are usually missing consumption facts, not a lazy buyer.
Discounts and margin
Merges, splits, whole-check discounts, item comps, and stored-value offsets split by role; a manager override at peak still needs a reason. Packaging, delivery fees, and platform commissions mixed into one dine-in income line flatten margin until you cannot see it. We book channel and dine-in revenue separately so 86s, late tickets, and table turns can be reviewed from the fire queue instead of the manager recalling whether today felt slow.
Pilot and hardware
Go-live usually runs order-into-kitchen and check-out-with-a-ticket first, then delivery channels and stored value, then cost. Hardware is tested by station: thermal printers, expo screens, cash drawers, and scan cradles under grease and peak concurrency. Training is for servers, runners, and the kitchen, not a demo for the manager only. If the floor will not use it, data never arrives; if data never arrives, margin cannot be counted.