Build the menu around the user’s goal
People usually come to place an order, get an answer or check progress, not admire a complex bot. Start with those goals and short, understandable steps. Plan back navigation, corrections, unfinished requests and operator handoff. Messages should explain what has been saved and what comes next. A bot might collect essential information and pass it to staff, for example, without making the customer repeat the same story in another conversation.
History and reliability matter more than button count
A person may tap twice, upload a file instead of text or return the next day. Handlers need to account for these situations and persist state beyond one running process. With webhooks, verify incoming requests and handle repeated events. Action logs should support diagnosis without exposing unnecessary personal information. The result should be a predictable journey that survives a service restart and avoids duplicate orders when an event is delivered again.
Connect the bot to the team’s working system
Requests can flow into a CRM or an operator panel, with confirmed updates returned to the customer. Agree where the authoritative record lives and who may change it. Account for Telegram and third-party limitations rather than promising unlimited messaging or access to arbitrary conversations. Handover includes bot ownership, source code, configuration and instructions. Pricing follows the journeys, integrations and support requirements, not merely the number of menu items.
Two useful questions
Can an operator take over the conversation?
Yes. Define when handoff occurs, the operator interface and what the bot does while a person replies. The conversation history should remain attached to the enquiry.
Would you keep our existing bot or create a new one?
Either can work. We first review code, access and existing journeys. Replacing a bot is not always necessary and should not surprise its users.