After a purchase, customers usually need answers to specific questions: has the order been accepted, when was it dispatched, where are the documents and how can they report a problem? A Telegram bot can bring these actions into one conversation if it receives reliable data and identifies the customer correctly.
Before development, describe the journey from connecting to the bot through to resolving a support request. Pay particular attention to situations where the status is still unknown or an employee is needed.
Plan how customers connect to the bot
Offer a link to the bot on the order page, in the customer portal or in a purchase message. Explain which tasks it handles and what the customer needs to do to connect.
For a standard conversation, plan for the user to start the bot. Telegram describes the Start button and passing launch parameters through special links in its bot features documentation.
A launch link must not, by itself, open someone else's order. Verify the customer's right to a specific purchase through an agreed confirmation process. Do not rely solely on a name, an entered email or a known order number. The article on customer portals in Telegram Mini Apps describes linking users to the CRM in more detail.
Show statuses from the system of record
Identify the source: the online store, CRM, warehouse system or delivery service. Agree how their statuses translate into messages customers understand.
“Order created”, “paid”, “dispatched” and “delivered” represent different events. The bot must not report delivery simply because the product was handed to a carrier or an estimated date has arrived.
If updates are delayed, show the time of the last check. When an integration is unavailable, explain that the current status has not yet been retrieved and offer a next step. Do not replace uncertainty with an invented timeframe.
Separate notifications from user requests
Customers can check the status through a button and receive messages when an important order change occurs. Choose genuinely useful events: payment confirmation, dispatch, a revised timeframe or readiness for collection.
Store notification settings separately from marketing preferences. Being able to respond about an order should not become a basis for arbitrary promotional messages.
Record events already sent so that repeated synchronisation does not create duplicate notifications. If the company also uses email, align the channels' tasks using the principles of post-purchase emails. Customers should not receive conflicting statuses.
Provide documents with access checks
Establish which materials customers need: an invoice, instructions, order confirmation or a service document. Instructions must match the purchased model, configuration and language.
For personal documents, check permissions every time they are provided. Decide when to send a file and when to use a protected page that checks access again. Do not send internal comments or other buyers' documents.
Agree how corrected documents will be replaced. A file already saved by a customer cannot be treated as automatically updated when the CRM document changes.
Transfer complex questions to an employee with context
For support, link the question to the order, clarify the problem and request an attachment if necessary. Do not make people re-enter information already verified.
Create the request in the working system and provide its reference number only after successful registration. If submission fails, preserve a clear pending state and offer an alternative contact.
The employee needs the order number, latest status, question, attachments and action history. Define the queue, responsible person and rules for returning to automated replies. The article on handing a bot conversation over to an employee explains the process.
Order support planning card
- Where does the customer connect to the bot and verify their right to the order?
- Which system holds the current status?
- Which events trigger notifications?
- How are preferences and duplicate sends handled?
- Which documents are available, and how are permissions checked?
- Which questions does the bot answer using approved data?
- When is a request created for an employee, and which context is transferred?
- What happens during a failure, and who is responsible for ongoing support?
Illustrative example. A buyer connects to the bot from their customer portal and confirms the order link. The bot displays the dispatch status and instructions for the purchased product. When damage is reported, it creates a request with an attachment and transfers it to an employee without independently promising a replacement timeframe.
The Telegram bots and Mini Apps proposal provides a starting point for discussing integrations, documents and post-purchase support. Use this planning card to define the first version and its acceptance conditions.