The practical answer
Make a ticket when the reply creates work you cannot finish right now. If you can answer in two minutes, just answer: a ticket would only be an extra thing to close. If it needs a colleague, a deadline, or an investigation, it needs a ticket, because otherwise it lives in a chat window that somebody has to remember to scroll back to. Tickets are available on the Pro plan.
Everyone discovers this the same way. You start out answering everything in the inbox, which works beautifully until the week you promise four people you will get back to them and remember three.
The overcorrection is worse: ticketing every incoming message, so the queue fills with items like "replied to Marco" that somebody now has to tick off. That is not process, it is admin.
The line between the two is simpler than most teams make it.
The question: can you finish it now?
That is genuinely the whole test.
If you can answer the message and be done, answer it. Nothing else is needed and a ticket adds pure overhead. If finishing it requires something you do not have right now (information, a colleague, a decision from someone else, or simply a date in the future), then it is work, and work needs to live somewhere more reliable than a chat.
| What just came in | Ticket? | Why |
|---|---|---|
| A question you can answer immediately | No | Reply and move on |
| "I'll send you pricing on Thursday" | Yes | A promise with a date is work |
| Something a colleague has to handle | Yes | Otherwise it lives only in your head |
| A bug, a billing problem, an investigation | Yes | It will take more than one exchange |
| "Contact me again next quarter" | A reminder is enough | Use the lightest thing that works |
Write it for whoever opens it next
Including you, in three weeks, with no memory of the conversation.
- A title saying what needs to happen, not what the message was about. "Send Q2 pricing to Marco" beats "Marco enquiry".
- A name attached. A ticket owned by everyone is owned by nobody.
- A date, when a date exists. If you promised Thursday, put Thursday on it.
- The conversation linked. So the next person can read what was actually said instead of asking you.
Keep urgency and type apart. "Urgent billing issue" is a bad category, because next month it is a normal billing issue and your reporting no longer adds up. Type stays stable, urgency changes.
The statuses in TeleBoost
Six of them, and each one answers "what is stopping this from being finished?"
Waiting is the one people skip, and it is the most useful of the six. A ticket sitting in In Progress for a week because a client has not replied looks like your team is slow. Marked Waiting, it looks like exactly what it is, and you can see at a glance how much of your queue is not actually yours to move.
These are the underlying categories. Your workspace can put its own labels on top, so the workflow can read the way your team already talks.
| Status | What it means | It leaves when |
|---|---|---|
| Draft | Still being written up | It is ready for someone to pick up |
| Open | Accepted, not started | Somebody actually starts it |
| In Progress | Being worked on now | It is finished, or it is blocked |
| Waiting | Blocked on someone else's answer | The thing you were waiting for arrives |
| Done | Finished | You have told the contact it is finished |
| Cancelled | No longer needed | You have noted why, in one line |
Closing the loop means telling the person
A ticket marked Done that the contact never heard about is not done. It is abandoned with extra steps.
This is the single most common failure in support work: the internal task gets completed, the queue looks healthy, and the customer is still waiting for an answer nobody sent. The fix is to treat the message back to the contact as the last step of the work rather than an afterthought.
Keeping tickets linked to the original Telegram conversation helps because closing one puts the chat right there. In TeleBoost the ticket carries the conversation, the lead, and the campaign it came from, so the reply is one click rather than a search through the inbox.
A decent habit: before you mark anything Done, check that the last message in the thread is from you.
Keep the queue honest
Ticket systems rot in a predictable way, and it takes about ten minutes a month to prevent.
- Look at anything sitting in Waiting for more than a couple of weeks. It is usually dead, and cancelling it with a reason is more honest than letting it age.
- Merge categories nobody can tell apart. If two people file the same issue in two different places, the labels are the problem.
- Notice questions that keep coming back. Those belong in your documentation, not in the queue five more times.
- Be suspicious of a queue that only grows. It means things are being filed, not finished.
How we checked this guide
The statuses and workflow described here were checked against TeleBoost's current ticketing interface, and each workspace can customise the labels on top of them. Ticketing is a Pro plan feature.
Keep every reply moving
Look at the last month of work that actually mattered and ask how much of it was tracked anywhere. The gap between that and your ticket queue is the honest measure of whether the system is helping.
A ticket earns its place when it answers three things instantly: what needs to happen, who is doing it, and what finished looks like.
Keep the issue attached to the conversation: TeleBoost tickets and inbox link every ticket to the original Telegram chat, the lead, the account and the campaign it came from.
Keep learning