Design multi-step Telegram bots: state, cancellation, and timeouts

Registration, support intake, booking, and data-collection bots rarely finish in one message. A bot asks for a name, then a date, and finally confirmation. Meanwhile, the user may send invalid input, disappear for hours, post an unrelated message in a group, or run /start again. If the requirement only says “ask these questions in order,” the deployed bot can mix up answers, trap users in a flow, or carry stale data into a new request.

A multi-step bot needs an explicit state machine: what step is active, what input is valid there, and where each outcome leads. This is not tied to one framework. aiogram's FSM documentation describes transitions between finite states, while grammY Conversations covers waiting for selected updates, timeouts, storage keys, and concurrent conversations.

Define a finite set of steps

For an event registration bot, specify the input, stored value, and exit condition for every step.

| State | Accepted input | Stored value | Next state | | --- | --- | --- | --- | | idle | /signup | New draft | ask_name | | ask_name | Non-empty text | Name | ask_date | | ask_date | Valid date or Back | Date | confirm | | confirm | Confirm, Edit, or Cancel | Commit or keep editing | done / previous / cancelled |

Also define what does not count. If a photo arrives while the bot expects a date, should it show a format hint and remain on the same step, or hand that photo to another feature? Without an answer, an unrelated message can become accidental form data.

Scope state to the right identity

A private-chat flow can often isolate state by user. In a group, the key usually needs both the chat and user, or two members completing the same form may overwrite one another. If one user can open several tickets at once, add a flow or ticket identifier too.

A useful requirement states that:

• private drafts are keyed by user and flow;
• group drafts are keyed by chat, user, and flow;
• drafts remain separate from committed business records;
• a record is created only after confirmation;
• starting again offers Resume, Restart, or Cancel instead of silently replacing the active draft.

Do not treat “the bot eventually asked every question” as proof of isolation. Interleave answers from two accounts and verify that names, dates, and confirmations remain separate.

Give every flow a way back, out, and forward

People change their minds and leave conversations. A recoverable flow needs at least three exits:

1. Back returns to the previous step and explains whether the old value remains.
2. Cancel closes the active draft without deleting previously completed records.
3. Timeout expires an abandoned draft; a late answer receives a clear expiration message instead of being written into a new flow.

grammY Conversations supports maximum wait times and exit events when a conversation times out or is halted. Your bot does not need grammY, but its requirement should define equivalent user-visible behavior.

Decide what survives restarts and releases

State held only in memory disappears when an instance restarts. In a serverless environment, the next update may not reach the same warm process. If a flow must span several messages, persist the minimum state in storage that the platform actually supports, with explicit retention and size limits.

A new release must also account for existing drafts:

• Can the new code read old state names and fields?
• If a step is removed, what happens to users paused there?
• If migration is impossible, does the bot safely cancel and explain how to restart?
• If code is rolled back, is current business data still compatible with the old version?

A verified deployment is not the same as a verified conversation. Pause midway through a flow, publish a compatible version, and then finish the flow as an acceptance test.

A requirement template you can adapt

Build an event registration bot. After /signup, ask for a name and date, then show a summary for confirmation. Isolate each user's draft; in groups, isolate by chat and user. Every step supports Back and /cancel. Invalid text or dates keep the current step and show an example. Expire an inactive draft after 30 minutes and tell the user to restart if a late answer arrives. Create the final record only after confirmation, and never create a second record from a repeated confirmation. An unexpired draft should survive a restart and a compatible release.

Replace the fields, timeout, and concurrency rules with the real business policy. “Make a registration bot” is not enough.

Acceptance checklist

• Interleave answers from two users without mixing data.
• Start the same flow for one user in two groups without mixing state.
• Test empty input, the wrong content type, Back, and Cancel at every step.
• Reply once before and once after timeout.
• Send two answers rapidly; the flow neither skips a step nor double-submits.
• Press Confirm twice; only one committed record exists.
• Restart midway; the bot either recovers or explains the failure.
• Publish a new version midway; old drafts follow the compatibility rule.
• Logs identify the flow and state without copying unnecessary sensitive content.

How this relates to BotFatherV2

BotFatherV2 uses an AI conversation to create and modify Telegram Serverless bots. Including state scope, timeouts, cancellation, and acceptance scenarios gives the generated version a much clearer target than describing screens alone.

This does not mean BotFatherV2 automatically bundles arbitrary conversation frameworks, queues, or external databases. Its public AI-development documentation describes a fixed SDK surface without arbitrary npm packages or Node/Bun runtime APIs, and the initial release does not add paid-AI runtime capabilities. aiogram and grammY are cited here for design patterns, not as packages that generated bots will install. BotFatherV2 is independent and is not affiliated with Telegram's official BotFather.

Sources

• aiogram, Finite State Machine, documentation version 3.31.0, accessed October 13, 2026.
• grammY, Conversations, accessed October 13, 2026.
• BitBear Studio, Develop with AI, accessed October 13, 2026.