Telegram-Bot: Anfrage zweimal erhalten, Aktion einmal ausführen

Für den Support von Developers Map habe ich einen Telegram-Bot, eine Mini App und eine Bedienoberfläche gebaut. Eine Aufgabe war, den Ticketzustand zu erhalten, wenn eine Anfrage wiederholt wurde oder Telegram eine Antwort annahm, das Programm aber keine Bestätigung bekam.

Eine Anfrage kann sich wiederholen. Ein Operator kann erneut klicken. Telegram kann eine Nachricht annehmen und die Verbindung abreißen, bevor unser Programm vom Erfolg erfährt. Gleichzeitig eröffnet der Nutzer ein zweites Ticket im selben Chat. Böse Absicht braucht es nicht: Eine normale Verbindung schafft ihre kleine Krise allein.

Vom Menü zum Arbeitsablauf

Für Developers Map habe ich einen Telegram-Bot, eine Mini App und eine Support-Bedienoberfläche gebaut. Das ist ein eigenständiges Werkzeug neben dem Hauptdienst; es macht mich nicht zum Autor von Developers Map und gibt dem Bot kein Recht, Nutzerkonten der Hauptplattform zu ändern.

Diese Ansicht zeigt die ursprüngliche Support-Oberfläche mit vorbereiteten Tickets. Sie macht den Arbeitsbereich neben dem Bot sichtbar, nicht nur dessen Menü.

Support-Übersicht

Archivierte Oberfläche · Demodaten

Es gibt eine freigegebene Antwortbasis auf Russisch und Englisch, mehrere Tickets in einem Chat und Anhänge im privaten R2. AI-Antworten sind in dieser Umsetzung deaktiviert. Nutzer erhalten vorhersehbaren Support statt freier Modell-Erfindungen über ein fremdes Produkt.

Im Ticket ist ein Demo-Gespräch zu sehen. Verfügbare lokale Operator-Aktionen können geprüft werden; echte Telegram-Nutzer erhalten nichts aus dieser Demo.

Ticket-Gespräch

Archivierte Oberfläche · Demodaten

Erst das Ereignis, dann die Aktion

Eingehende Ereignisse werden in D1 gespeichert. Eine Queue und ein periodischer Handler führen sie zum Chat-Koordinator auf Durable Objects. Die Engine aktualisiert dann den Ticketzustand und schreibt die ausgehende Aktion in die outbox, eine Tabelle vorbereiteter Sendungen.

So wird eine Ticketänderung in einem Datenbankvorgang mit der Absicht verknüpft, eine Nachricht zu senden. Sonst entsteht womöglich eine seltsame Zwischenwelt: Die Nachricht ist schon angekommen, das System glaubt aber noch, nichts sei passiert. Oder umgekehrt.

Mini-App-Befehle haben eine stabile ID und eine Versionsprüfung. Wiederholte Anfragen werden erkannt; eine Aktion auf veraltetem Zustand darf neuere Operator-Arbeit nicht still überschreiben.

Der interessanteste Zustand: „Ergebnis unbekannt“

Wenn eine externe Sendung bereits erfolgt sein könnte, kann automatisches Wiederholen ein Duplikat erzeugen. Ein ungewisser Ausgang wird deshalb nicht als normaler Fehler mit sofortigem Neuversuch behandelt. Wiederholen ist dann eine eigene Operator-Entscheidung im Bewusstsein des Risikos.

Das ist kein Versprechen mathematisch perfekter Zustellung. Es ist ein Weg, Unsicherheit nicht länger hinter einem grünen Indikator zu verstecken.

Eine funktionierende Instanz ist für den Piloten bereitgestellt; die vollständige Nutzerabnahme bleibt ein eigener Schritt. WhatsApp und E-Mail werden nicht allein deshalb zu angebundenen Kanälen, weil sie einmal im Plan standen.

Eine funktionierende Instanz ist für den Piloten bereitgestellt. In der Demo führt der Weg von der Ticketliste zum Operator-Gespräch; die vollständige Nutzerabnahme ist noch offen. WhatsApp und E-Mail sind nicht angeschlossen, AI-Antworten sind in dieser Umsetzung deaktiviert.

Verwandte Geschichten: Das Produktkonzept von Developers Map.