For Developers Map support, I built a Telegram bot, a Mini App and an operator interface. One task was to preserve ticket state when a request repeated or Telegram accepted a response but the program received no confirmation.
A request can repeat. An operator can press the button again. Telegram can accept a message and the connection can drop before our program learns it succeeded. Meanwhile, the user opens a second ticket in the same chat. No ill intent is needed: an ordinary connection can organise a small crisis all by itself.
From a menu to a workflow
For Developers Map I built a Telegram bot, a Mini App and a support operator interface. This is a separate tool beside the main service; it does not make me the author of Developers Map or give the bot permission to change user accounts on the main platform.
This screen shows the original support interface using prepared tickets. It reveals the workspace beside the bot, rather than only its menu.
Support overview
Archived interface · demo data
There is an approved answer base in Russian and English, several tickets within one chat and attachments in private R2 storage. AI replies are disabled in this implementation. Users receive predictable support, rather than a model freely inventing how someone else’s product works.
A demonstration conversation is visible inside a ticket. You can test the available local operator actions; real Telegram users receive nothing from this demo.
Ticket conversation
Archived interface · demo data
First the event, then the action
Incoming events are stored in D1. A queue and a periodic handler deliver them to a chat coordinator on Durable Objects. The engine then updates ticket state and writes the outgoing action to an outbox, a table of prepared sends.
This ties a ticket change to the intention to send a message in one database operation. Otherwise a strange intermediate world can appear: the person has received the message, but the system still thinks nothing happened. Or the reverse.
Mini App commands have a stable ID and a version check. Repeated requests are recognised, and an action against an old state must not silently overwrite an operator’s newer work.
The most interesting state is “outcome unknown”
If an external send may already have happened, retrying automatically can create a duplicate. An uncertain outcome is therefore not treated as an ordinary error that should be retried immediately. In this case, retrying is a separate operator decision made with an understanding of the risk.
This is not a promise of mathematically perfect delivery. It is a way to stop hiding uncertainty behind a green indicator.
A working instance is deployed for the pilot; full user acceptance remains a separate stage. WhatsApp and email do not become connected channels just because they once appeared in a plan.
A working instance is deployed for the pilot. The demo lets you move from the ticket list to an operator conversation; full user acceptance is not complete yet. WhatsApp and email are not connected, and AI replies are disabled in this implementation.
Related stories: The Developers Map product concept.
@nevsky_alexander
On Instagram: Dubai beyond the postcard — family, the city, discoveries and life between projects. On Threads: thinking out loud about design and AI. On YouTube: videos that need more room than a story. Follow me wherever you feel at home, and let’s keep in touch