The bakery is closed. The order still gets taken.
A customer opens Telegram at 01:47, picks a cake, gets a real price and a real pickup slot, and leaves a phone number. The owner wakes up to a finished order, not a missed message. Everything on this page runs the same dialog engine that will drive the live bot - press the buttons and see.
Order something
Tap the buttons, or type - the bot understands 25.09, 25 Sep, tomorrow,
plain numbers, and it says so plainly when something will not work.
What the owner's phone shows
0Orders as they are stored
| Order | Item | Ready | Handover | Total |
|---|---|---|---|---|
| No orders yet. | ||||
In the live bot this same record is written to orders.json - or to the shop's spreadsheet or CRM,
which is one small file to swap.
One night, replayed
Press the button: a written night of customers - one September night, invented like the rest of this demo - is handled by the engine here, in your browser. Every number below is counted from that run, not typed in by hand.
The summary waiting when the ovens go on
The night's orders
| Order | Item | Ready | Handover | Total |
|---|
Every chat from that night
Open any of them - including the ones that did not end in an order. A bot that only works when the customer behaves is not worth putting in front of customers.
How it is built
One engine, two front doors
The dialog is a pure state machine: it takes the current state and one event, and returns the next state plus what to send. The live bot feeds it Telegram updates; this page feeds it your clicks. There is no second version written for the demo - a test fails if the copy on this page drifts from the source files.
Built to survive the night
Telegram re-sends an update when an answer is lost, so every update id is remembered and never served twice. Network errors and rate limits are retried with growing pauses. Buttons from older messages are recognised and answered politely instead of corrupting a half-finished order. Orders are written to disk before the customer is told "booked".
No packages, no keys in code
The bot is plain Node.js - no npm dependencies to audit or update. The token lives in a
.env file that never enters the repository, and the log lines never print it. Hosting runs on the shop's own
account, so the shop keeps control of its data.
What a month of support covers
A bot is not a poster - the menu changes, prices change, Telegram changes. The monthly part keeps it working:
- Menu, prices, lead times and delivery zones updated whenever the shop changes them.
- The bot watched: if it stops answering, I hear about it before the customers do.
- Telegram API changes handled before they break anything.
- Small additions as the shop learns what customers ask for - new items, new questions, a new slot.
- Monthly note: how many orders the bot took and where people dropped out.
- Backups of the order file, and export to whatever the shop uses for bookkeeping.