Course timing
Built in. Send the appetisers now, mains paced behind them. The kitchen sees the courses, not one wall of dishes.
Waiter Mobile App
The order goes to the kitchen from the table.
Modifiers, course timing, splits, transfers, payment-at-table — in the operator's hand, on a phone they already own.
One device. The whole floor.
The phone is the workstation.
A server takes the order at Table 12 — three covers, two starters, a main with no onions, a kids' pasta. Fires it to the kitchen. The KDS sees the ticket before the server has turned around. On the walk back, the server stops at Table 9 to close out the previous party — runs the payment on the same phone, drops the receipt by email, and is on the floor again.
Same device. Same shift. No tablet at the pass, no second handheld for payments, no run back to the POS to punch it in.
This is the operator outcome the waiter app is built for: fewer steps between the guest and the kitchen, fewer steps between the guest and the bill.
Table-side order entry
The way servers actually take orders.
Open the table. Add covers. Tap the dish. Pick the modifier (no onions, sauce on the side, gluten-free pasta). Move to the next cover. The screen reads like a check pad, not a database.
Item recommendations
Sit next to the current dish — pairings the operator chose, not a black box. The server adds them if the table is interested; the server skips them if not.
Low-stock alerts
On the same screen. If we 86'd the lamb at 8:47pm, every server's phone knows by 8:47pm. No promising a dish that's gone.
Adding an item takes the same number of taps it would take on paper. The point isn't a fancy ordering interface — the point is the ticket lands in the kitchen the second the table finishes ordering.
Fire the ticket — and know it landed
Table → phone → KDS → phone again.
The server hits send. The kitchen display lights up. The waiter app shows the ticket as fired, with a timer running from the moment the kitchen accepted it.
No "did it go through?" anxiety. The status on the server's phone matches the status on the KDS, because they're reading the same row in the same queue. When the kitchen bumps the ticket, the waiter app sees it bumped. When the kitchen flags an item delayed, the server knows before the guest asks.
That's the whole loop: one source of truth, one queue, all the way through.
Splits, moves, transfers
The three things that break elsewhere.
The party at Table 9 wants to split four ways. Two of them ordered together; two of them paid separately. One round of drinks moves to Table 12 when the second group joins them. A solo guest at the bar shifts to a booth halfway through dinner. This is restaurant reality. The waiter app handles it without re-keying anything.
Split the check
By cover, by item, or evenly across however many cards land on the tray.
Move items
Between tables, between tabs, between covers — without losing the kitchen history.
Transfer a tab
From server to server at shift change. The receiving server picks up the table with every modifier, every coursed item, every fired ticket intact.
The check stays clean. The kitchen history stays attached. Nobody re-prints, nobody re-fires, nobody re-explains the order to the cook.
Payment at the table
We orchestrate the device, you keep the relationship.
dojofood is not a financial intermediary. We don't hold your money. When the server taps "take payment," the waiter app talks to your POS device, the POS device talks to your processor, and the receipt comes back to the phone.
Card-present at the table
On your existing terminal. The server doesn't disappear to the back with the card.
Tip handling
On the device — preset percentages, custom amount, no tip — the server doesn't ask, the guest taps.
Receipt
By email, by SMS, or printed. Three taps from "settle" to "have a good night."
We orchestrate the payment flow; your POS and your processor do the rest. No middleman on your settlement. No payment-processing lock-in. Switch processors without switching dojofood.
The specific scene we built for
Not a feature list. A scene.
Server at Table 12 takes the order. Fires it to the KDS. Kitchen starts prep. Server walks to Table 9, takes payment for the previous party, drops the receipt, clears the table. Both flows on one device, one shift, one phone the server already has in their apron.
That's the design target.
Works offline
Syncs the second WiFi returns.
This is the one we hear loudest from operators about their old POS: the app drops out at peak service and the floor freezes. We built the offline behaviour specifically for that scene.
If the WiFi goes down mid-shift, the waiter app keeps taking orders. Tickets queue locally on the phone. When the connection returns, they sync to the kitchen, to the POS, to the marketplace integrations, in the same order they were taken. The server never sees an error screen at the table.
No "system is down, please wait." No re-entering orders from memory after service. No apologising to the guest while the screen spins.
Standard hardware
The phone the server already has.
iPhone or Android. iOS 16+ or Android 12+. BYO. No proprietary handhelds, no rental hardware, no "you have to use ours."
If you want to issue dedicated phones for the floor, fine — we'll help you spec them. If you want servers to use their own, also fine — the app sandboxes the operation. Either way, there's no extra hardware line on the bill.
The hardware that breaks the most at 7pm Friday is the hardware nobody fixes. Standard phones get fixed at the corner shop.
Shift handoff and the boring details that matter
The unflashy details decide whether the system survives a Friday night.
Shift handoff
The outgoing server hands open tables to the incoming server with every modifier, fired ticket, and split intact. No re-explaining at the pass.
Role-based access
What a server sees vs. a host vs. a manager. Voids, comps, and discounts route to whoever you set as the approver.
Audit log per table
Who took the order, who fired it, who took the payment. End-of-night reconciliation reads as one story per table, not five.
Offline-mode log
Every ticket that queued locally during a WiFi drop is visible end-of-shift, with the sync time stamped.
20 minutes with our team
See the order land in the kitchen before the server reaches the next table.
Bring your floor plan, your covers per shift, and the phone you'd put in a server's apron. We'll show you the order go from Table 12 to the KDS, then take payment for Table 9 on the same device. Real human, your language, under 2 hours if it ever breaks. iPhone or Android. No proprietary handhelds. No payment-processing lock-in.