“A bot that takes orders” swells when the work starts as an admin panel instead of a path. Version one needs one path: the person confirms the lines, and the person who fulfills the order sees them in a staff chat and does not lose them.
What belongs in that version, and what to leave out. Enough to put the bot to work, not into a third month of agreement.
Write the path first
Write the dialogue the way a real order will walk it. Start with two actions: see the catalog, open the current order. Then a category if there are more than ten items. A card: name, price, “add.” A cart: plus, minus, remove. Confirmation is one message: lines, total, contact, comment.
Leave free text for the comment. Address, contact method, and the lines themselves are buttons. Otherwise the order arrives as “call me sometime” and an address a courier cannot read.
A catalog that holds
Up to ten items, one list is enough. More than that, use categories, not a wall. Each item has a name, a price, and a stock state you mean: in stock, to order, gone. “Ask us” on half the cards means the catalog is not ready and the bot will forward every question to a manager.
Add a picture when people mix items up without it. Do not add it because stores do. Every photo is weight in the message and one more thing to update.
Statuses, or the morning is chaos
- New: just confirmed
- Accepted: someone on the team saw it and took it
- Paid, or “no payment needed”: if those are different
- Cancelled: with a short reason, or cancellations pile up in silence
Four statuses are enough while orders are a few a day. A twelve-step funnel is for after these four stop getting lost. Until then a new stage only hides the hole.
Payment
Three honest branches at the start: a pay link, an invoice file, or “a manager will confirm and write.” Card payments inside the bot make sense when there are dozens of orders a week and manual confirmation slows delivery. Before that, a gateway is its own project: test charges, refunds, receipts. Do not hide it inside “just a bot.”
Write what the person sees after “pay.” Silence after payment looks like lost money, even if the order was saved.
Where the order lands
The alert has to arrive where it will be read on a shift: a shared chat, not the direct messages of someone on leave. The message carries a number, the lines, the total, a contact, the comment, the status. Not “new order” with no lines.
Site leads belong in the same chat if the site and the bot are one service. Otherwise you grow a second queue that gets forgotten. The bot token lives on the server. It must not be in the page source: anyone who opens the code can then post as your bot.
What to postpone
- Loyalty and promo codes
- Roles for operator, lead, and accountant in a separate admin
- Broadcasts to the whole base before orders are even stored
- A second language if nobody will maintain it
- Funnel analytics while statuses still jump
Not never. After the first live orders, when you can see where people get stuck. Before that, every extra branch is another way not to ship.
How to accept the bot
- A person with no instructions gets from start to confirmation
- The staff chat received the lines and a contact
- An order can be cancelled, and that is visible
- Coming back shows the cart, not an empty dialogue
- There is no step where the bot stays silent longer than it takes to read a button
Walk it on a phone with a bad connection. If you get lost, the client will get lost sooner. When the catalog no longer fits buttons, the next format is not “more admin.” It is the choice between pages and a screen inside Telegram, covered in store or bot.
If you need a site beside the dialogue, start with a landing page or with what the scope is made of. To build the loop for your orders: use the contact form.