In this article
People will write to you here whether or not you planned for it, because it is where they already are. A support desk built on Telegram is therefore less a project than an acknowledgement, and it has one genuine advantage nothing else offers: the customer does not have to go anywhere, install anything, or keep a tab open.
What it does not have is everything a helpdesk normally provides — assignment, status, history, any way to know whether somebody picked it up. Those are yours to build, and the ones that matter least are the technical ones.
What you will be able to do after this step
- check_circle Decide where conversations land and who appears to be answering.
- check_circle Write the acknowledgement that does more than any routing logic.
- check_circle Close tickets, which is the failure nobody plans for.
- check_circle Measure the two numbers worth measuring.
Four decisions, in the order they bite
The first two are structural and the last two are the ones that determine whether anybody is happy.
One room, or a thread per conversation
With two people answering and a handful of messages a day, a single staff room works and anything else is overhead. Past that, a single room interleaves every conversation at once and becomes impossible to follow — two customers, three colleagues and a half-answered question all in the same scroll.
Topics are the structure that fixes it (Step 057): one thread per conversation, created when somebody writes in, with the customer's messages relayed into it and staff replies relayed back. Everything that makes a group work applies inside each thread, including being able to ignore the ones that are not yours.
The cost is that threads accumulate, which is the fourth tab. A support group that has been running for a year without closing anything is a list of several hundred topics in which the live ones are invisible.
Under two people, one room. Above that, a thread per conversation — and a plan for ending them, decided at the same time.
A relay, or people replying from their own accounts
Replying directly is warmer and needs nothing built. It also means the conversation lives in one person's chat, invisible to everyone else — so when they are away, nobody knows what was said, and it means your colleagues' personal accounts are handed to strangers, which is a thing to ask them about rather than assume.
A relay puts a bot between them: the customer talks to the bot, staff reply through it, and the exchange sits where the team can see it. Identities stay private, coverage does not depend on one person, and the record exists. What you lose is the human name at the other end — worth countering by having staff sign their replies, which costs nothing and changes the tone entirely.
For anything with more than one person answering, the relay is correct. The mistake is building it and then leaving it faceless, so that customers feel they are talking to a wall that occasionally produces text.
More than one person answering means a relay. Then put a name back on it — "Sam here" at the top of a reply does most of the work.
The acknowledgement is worth more than the routing
This is the least technical decision in the step and the one that determines satisfaction. A person who writes in and hears nothing assumes they were not received; a person who is told "we have this, somebody will reply by tomorrow afternoon" waits calmly, even if the eventual answer takes exactly as long as it would have anyway.
Three rules make an automatic acknowledgement useful rather than irritating. Say it is automatic — a templated line pretending to be a person is worse than silence. Give a real time, not "as soon as possible", and give one you will beat rather than one you would like to hit. Ask for the one thing you always end up asking for — the order number, the account, the screenshot — so that the first human reply is an answer rather than a request.
And state the hours. A desk that is open on weekdays and says so is a functioning desk; a desk that is silent at the weekend without explanation looks broken.
One honest acknowledgement with a real time beats every piece of routing logic in this step. Write it before you build anything.
Nobody closes tickets
This is the failure that arrives in month three and is never designed for. Conversations get answered and are never marked as finished, because closing something is a step with no immediate reward. The list grows, the live conversations become invisible among the dead ones, and the team stops trusting the view.
Close automatically after silence, and say so when you do: a short message telling the customer the conversation has been closed and that writing again reopens it. That last part is what makes automatic closing acceptable rather than dismissive — nothing is lost, and the person is not required to do anything.
Two refinements worth having. A conversation waiting on the customer should close sooner than one waiting on you. And a reopened conversation should come back to the same thread rather than starting a new one, so that whoever picks it up can see what happened last time.
A queue that never empties stops being read. Automatic closing with an easy reopen is the difference between a working desk and an archive.
person_search The person writing in is not your customer record
A message arrives from an account with a first name and possibly a username. That is everything you know. It is not an email address, not an order number, and not reliably the name on the account they are asking about.
So the first thing the desk must do, every time, is obtain the one identifier that lets you look them up — and the place to ask is the automatic acknowledgement, not the third exchange. Anything else produces the familiar loop where a customer explains their problem in detail and is then asked for an order number they have to go and find.
Two related habits. Do not ask for more than the one identifier, because a form is not what somebody came to a chat application for. And never accept a screenshot as proof of a payment, an order or an account — it is trivially faked, as Step 094 notes, and the identifier plus your own records is the check.
visibility What the staff room can see
A relay copies what the customer sent into a room your colleagues are in. That is the point, and it deserves a moment of thought before it is switched on.
Customers send things they did not mean to: a screenshot with another conversation visible, a document with more in it than the page they meant, a voice message recorded somewhere private. All of it lands in a staff room, stays there, and is searchable by everyone in it. Nothing in this step suggests not doing it — it suggests that the staff room's membership is a decision, that leavers should be removed the day they leave, and that whatever you keep should be kept on purpose (Step 093).
Say something about it, too. One line in the acknowledgement — that messages are handled by a support team rather than one person — costs nothing and is honest about who is reading.
touch_app Try it now — five minutes
Four steps, and the first is worth doing even if you never build any of this.
- Write the acknowledgement Three sentences: we have it, a person replies by when, and here is the one thing to send us now.
- Say when you are open In the bot's description, where it is read before the first message rather than after.
- Decide the closing rule How long silence lasts before a conversation closes, and the sentence that says how to reopen it.
- Write down who reads the staff room Including the people who joined for a project last year. Remove the ones who should not be there.
query_stats Two numbers, and the ones to ignore
Support dashboards are full of measurements that describe activity rather than service. Two are worth watching.
Time to first reply. Not to resolution — to the first human response. It is what a customer actually experiences as responsiveness, it is the number your acknowledgement makes a promise about, and it is the one that predicts whether somebody writes again or gives up.
Conversations that never got a reply at all. A small number, usually, and the one that does real damage. These are the people who wrote in, heard nothing, and concluded something about you. No average will surface them, because averages are dominated by the ones that went fine.
What to ignore: volume as a performance measure, since a good month and a bad month can look identical; and satisfaction surveys sent after every exchange, which are answered by the delighted and the furious and by nobody in between. If you want to know how it is going, read five closed conversations at random each week. It takes ten minutes and tells you more than any chart.
help Common questions at this stage
Should support run through a bot or through a group people can join?
A bot, for anything involving an individual's account, order or problem — those conversations should not be public and other customers should not be reading them. A public group is a different and complementary thing: a place for questions with general answers, where other members help each other and one answer serves many. Plenty of communities run both, and the mistake is using the group for the cases that belong in a private conversation.
Can I connect this to the helpdesk we already use?
Yes, and it is often the right architecture: Telegram becomes the front door and the existing system remains the record, so that assignment, history and reporting stay where they already work. Step 092's caution applies — customer messages then pass through whatever sits in between. The alternative, running support entirely inside Telegram, is genuinely fine for a small team and stops scaling at the point where you need to know who owns what.
How do we handle several languages?
The same way Step 084 answers it for channels: the constraint is who can reply, not who can publish. Machine translation is genuinely useful for understanding an incoming message and dangerous for sending an answer about money, deadlines or anything with a number in it. If a language is a meaningful share of your customers, the honest options are somebody who speaks it or an acknowledgement that says plainly which languages you can answer in.
Should the bot try to answer before a human does?
For genuinely repetitive factual questions — opening hours, where to find something, how to reset something — a few buttons before the message box save everybody time. For anything else it delays the answer while appearing to help, which is the worst combination. The test is whether you could put the answer on a page and be confident it is complete; if not, it needs a person and the automation should get out of the way quickly.
What happens when the bot is down?
People write in and nothing happens, and they cannot tell the difference between a broken bot and being ignored. Two mitigations: the failure alerting from Step 092 so you find out quickly, and a second route published somewhere stable — an email address in the bot's description or a pinned message in your channel. A support system with exactly one door is one outage away from silence.
Is it rude to close a conversation automatically?
Only if closing means anything is lost. A message saying the conversation is closed and that writing again brings it straight back is simply housekeeping, and most people never notice it. What is genuinely rude is the alternative that teams drift into instead: leaving everything open, losing track of which are live, and eventually failing to answer somebody who was still waiting. Closing is what protects the conversations that are real.
At a glance
- 1Where chats land
One room for a small team, topics for more, a relay bot for several agents.
- 2Acknowledge honestly
An automatic reply with a real response time beats clever routing.
- 3Close the loop
End quiet tickets automatically and let a new message reopen them.
Updated
