Development

A Telegram bot for business: what it really does

A bot handles short, repetitive operations well and complex consultations badly. Scenarios, the link to your CRM and when a bot is enough instead of an app.

A messenger bot is usually ordered after the phrase "all our clients are on Telegram". It's an accurate observation and a poor task statement: the communication channel exists, but what exactly the bot will do is undefined. Below are the scenarios where a bot works, the scenarios where it annoys, and the signs that tell you a bot is enough in your case and an app isn't needed.

How a bot differs from a website and an app

A bot lives in a conversation. It has no screen you can take in at a glance, no familiar navigation, no way to glance back. But it has two things a website doesn't: it's already on the person's phone, and it can write first.

Everything else follows from that. A bot is strong at short operations with a clear start and end. It's weak where you need to compare, study, scroll and make a decision that takes more than a minute.

A bot isn't a scaled-down website but a channel for short, repetitive actions. Anything that requires study should be sent where there's a screen.

What a bot handles well

Taking requests. A few questions in turn, button answers where the choice is limited, confirmation at the end. A request from a bot is usually more complete than one from a website form: psychologically, it's easier to answer five short questions in a row than to fill in five fields at once.

Notifications and statuses. This is a bot's strongest side. Order received, courier on the way, document ready, appointment confirmed. Instead of the client logging in to check, the system writes to them. Here a bot honestly replaces both emails nobody reads and calls that distract.

Checking your own status on request. Where's my order, what's my balance, when's my next appointment. One command, one short answer. An important condition: data must come from the system in real time, or the bot will start lying.

Answering frequent questions. Opening hours, address, delivery terms, what to bring. Here a bot beats a person on speed and works at night.

Internal tasks. Often the most useful bot isn't for clients but for staff: notifications about new requests, quick completion check-offs, shift reports. Such a bot pays off more quietly, but almost always.

Where a bot gets in the way

Complex consultations. Choosing equipment, a legal question, a medical topic, any "it depends" situation. At best, a bot gets the person to a specialist here; at worst, it makes them go through ten screens only to hear "please describe in more detail".

Choosing from a large catalogue. Scrolling through products with buttons in a chat is torture. The storefront is the website's job; a bot can send a link to the right product page, and that's the correct division of labour.

Long forms. Ten fields, half of them free text, turn into an interrogation in a messenger. If there's a lot of data, it's better to give a link to a page with a form.

Complex branching. A menu nested five levels deep is a sure sign the wrong task was chosen. People get lost in a conversation faster than on a page, because they can't see where they are.

And a general rule: if a user can get stuck at any step, the bot must have a "talk to a person" button that works during business hours. A bot with no way to reach an operator is the most common reason clients leave.

Connecting to the CRM and other systems

A bot on its own is an interface. Value appears when it's connected to wherever your data already lives.

What's usually connected:

  1. Requests → CRM. A bot conversation creates a deal with filled-in fields and a source. Without this, a manager retypes the data, and half the requests get lost in the chat.
  2. Statuses ← accounting system. A change in order status triggers a message to the client. This requires the system to be able to report changes, not just answer queries.
  3. Identifying the client. A messenger account and a client in the database are different entities. They need to be linked: by phone number, by a code from the account area, by a tagged link. Until they're linked, the bot can't show "your order" — it doesn't know whose.
  4. Payment. Payments can be accepted in a messenger, and for short, clear purchases it works. For complex carts, it doesn't.

A separate question is conversation history. Everything a client writes to the bot should go to the same place where the manager sees the rest of the communication. Otherwise you get a second channel nobody knows about. How this ties in with other processes is covered in the automation section.

A bot doesn't replace a website

This has to be said regularly. The reasons are concrete:

  • Search engines don't find a bot. Search engines index pages. People come to a messenger via a link they saw somewhere — most often on a website.
  • A bot isn't trusted as a first contact. An unfamiliar company with nothing but a chat raises questions. A website answers "who are you" before the conversation starts.
  • A bot can't be browsed. Studying services, comparing options, showing a colleague a link to a specific section — that's all the work of pages.
  • A bot depends on the platform. A messenger's rules change without your say. A website is your territory.

A working combination looks like this: the website handles search, research and trust; the bot handles operations once the person is already your client. The link to the bot sits on the website; the link to the right page sits in the bot. More about bots and AI scenarios is in this section.

When a bot is enough instead of an app

Sometimes a client comes for a mobile app when the task can be solved entirely by a bot. Signs of that situation:

  • The user has few actions, and they're short: check a status, mark something done, send a request, get a notification.
  • There are no complex screens: no tables, no charts, no offline work.
  • The audience is already in the messenger and has no reason to install a separate app.
  • The budget and timeline don't allow for two mobile platforms, app store publishing and ongoing version support.

Under these conditions, a bot delivers the same result noticeably cheaper and, more importantly, without the installation barrier: the user starts working straight away.

The opposite signs are clear too. If you need structured screens, offline work, access to the camera or sensors, and users spend hours rather than a minute in the product — a bot will become a limitation, and you'll find out in about a quarter.

What to decide before development

  1. Name three to five specific actions a person will open the bot for. If you can't put the list together, there's no task for a bot yet.
  2. Define where the bot gets data from and where it sends it. A bot connected to nothing is a questionnaire with buttons.
  3. Decide how the bot knows who it's talking to, and at which step the link to your database is made.
  4. Describe what happens when a scenario doesn't fit: which staff member picks up the conversation, and during what hours.
  5. Check every scenario for length. More than five or six steps — either cut it or send it to a page.
  6. Agree in advance who edits the bot's texts. Wording in conversations changes more often than it seems, and that should be a cheap operation.

Once points 1 and 2 are clear, the rest is simple to estimate: the bot is built around specific operations, not around a wish to be present in a messenger.