What a Telegram bot is good for

A Telegram bot for business is a good fit when the group is already known and the commands are short. Status, intake, and alerts are the jobs it does well. Someone asks where a request stands. Someone sends a structured note to start a job. Someone gets a ping when a person needs to step in. The bot answers in a few lines, in the chat people already have open.

It is a poor substitute for a product. If your customers have not asked to do their work inside a messenger, a bot that tries to become the product will feel like a maze made of messages. Chat is a narrow door. Use it for the trips that fit through the door. Keep the wider work on a page that was designed for it.

The jobs it does well

Status is the clearest job. A known person asks a question with a known shape: where is my order, did the file arrive, is the build on staging. The bot looks up one record and replies with the state and the next step. It does not speculate. If the record is missing, it says so and tells them how to reach a person. A short, true reply is the whole product.

Intake is the second job. The bot asks a fixed set of questions: name, what they need, the constraint that matters. It writes the answers into a queue a person already checks. The questions are the interface. Three is a good number. Eight starts to feel like a form that ran away from the website, which is a sign you wanted a form.

Alerts are the third. A payment failed, a deploy finished, a client left a file in the portal. The people who need to know are in a group, and the group is small enough that an alert is welcome. Write the alert as a fact plus an action. "Staging is updated. Review this link." An alert that is only a mood, or a daily dump of everything, will be muted, and then the useful ones will be muted with it.

Hanabi builds Telegram bots as one of the small automations beside product and site work. The fit is this list. A bot that reports status, takes a structured request, or pings a known channel. The studio's standard still applies inside the chat: clarity over complexity, and a path to a person when the script ends.

The jobs it should refuse

Refuse to recreate your app as a conversation. A dashboard that people scan, a catalog they compare, a document they edit: these need layout. A bot can send someone to that layout. It should not ask them to type "next" through a grid they cannot see. Trade Moai, a public Hanabi interface organized around scanning, is the kind of screen that belongs in a product, not in a thread. The bot can say that something in it needs attention. The scan stays on the screen.

Refuse open-ended advice as the default. A bot that answers any question will answer some of them wrongly, with the same tone it uses for the right ones. Limit it to the commands you named. When a message does not match, say what the commands are. A menu of four choices is more trustworthy than a paragraph that guesses.

Refuse to pretend the bot is an employee. Give it a name that sounds like a tool. Say, in the description and in the first reply, that it is a bot and what it can do. People in a known group will forgive a narrow tool. They will not forgive a persona that invents a commitment.

Google's guidance on helpful, people-first content is about web pages, and two of its questions are the right test for a reply in chat. Was this made to help the person reading it? Is the use of automation evident? A status bot passes both when the reply is short, true, and obviously from a bot. A bot that writes long, confident essays in a human voice fails both, even if the group found it clever on the first day.

Commands are a small interface

Design the command list the way you would design a tiny product.

• Each command does one thing. /status checks a record. /request starts intake. /human reaches a person.
• Each command has a one-line description the person can read without a manual.
• The bot repeats what it heard before it writes anything final. "I have this as a request for a homepage rewrite, due Friday. Send it?"
• Errors say what to fix. "I need a request number" is a useful error. "Something went wrong" is how people leave.

Keep the language in the company's voice, which for a careful studio means plain words and no fake urgency. A button on a website and a command in a chat should sound like the same company. If the site is quiet and the bot is full of exclamation points, the bot was written by the tool's template.

Help should be a command, not a wall of text on first contact. People who already know the bot do not want the manual again. People who are lost will ask. /help lists the commands in a few lines. That list is the onboarding.

A person at the edge of the script

Every bot needs a way out. The way out is a named command and a named place the message lands: an inbox, a channel a person watches, a ticket. Tell the user what happens next and how soon a person usually sees it. If you cannot staff that watch, do not offer the command. A /human that nobody reads is worse than no bot, because it borrows the promise of a reply.

Decide what the bot must never do alone. Send a price. Promise a date. Tell a customer their complaint is resolved. Those actions can be prepared as a draft for the person who got the handoff. The confirmation step from the command list is the same idea, pointed at your own team. The bot collects. A person commits.

Write down the hours. If the group is in one time zone and you read the queue in the morning, say that. A bot that implies instant human help at any hour will create the disappointment you built it to avoid. Status lookups can be instant because they read a record. Human help is only as instant as the person.

What still lives outside the chat

The bot is a door, not the room. The record it updates should live in a system you own: a table, a repository, the client portal where brand files and project updates already sit. Chat history is a poor database. Export the structured fields. You will need them when the messenger is not the place a new teammate looks.

When intake needs more than three answers, send the person to a page. The page can be short. It still needs labels, a visible focus state, and text that can be read. The W3C's Web Content Accessibility Guidelines are the reference for that page, under the same principles as any other page you ship: perceivable and operable. The bot's job is to link to it and to confirm that the submission arrived. The page's job is the form.

If the known group actually lives in Discord, the shape changes. The commands may be similar, and the room they live in is a community rather than a private thread. That neighboring decision is Discord bots as a product surface. Read it when the audience is already gathered there.

When the group, the commands, and the handoff are this specific, a bot is a reasonable build. Hanabi's services include Telegram bots alongside the sites and product interfaces they should stay attached to. Bring the three commands you want. That list is the brief.