Postiz Support Bot
Der Postiz-Support als Software. Discord für Kundinnen und Kunden, Intercom für Agenten.
Jede Supportanfrage wird zu einem privaten Discord-Thread, der zu Intercom gebrückt ist — Kundinnen und Kunden bleiben, wo die Community ist, Agenten in echten Support-Werkzeugen. Dazu trägt er die Inaktivitäts-Automatisierung, die Intercom für per API angelegte Konversationen nicht leisten kann, und eine vollständige Stripe-Abrechnungskonsole.
Was es ist
Der Support hinter Postiz, als Software.
Jede Supportanfrage wird zu einem privaten Discord-Thread, der zu Intercom gebrückt ist. Discord ist der Kanal der Kundschaft, weil dort die Community ohnehin schon ist. Intercom ist der Kanal der Agenten, weil dort Support-Werkzeuge tatsächlich zu Hause sind. Der Bot ist das, was verhindert, dass aus diesen zwei Wahrheiten zwei Postfächer werden.
Die Aufteilung, die es funktionieren lässt
Eine frühere Fassung hatte Agenten, die Tickets innerhalb von Discord bearbeiteten, mit Slash-Befehlen für Status, Notizen, Erinnerungen, Eskalation, vorgefertigte Antworten und Berichte.
All das wurde entfernt. Agenten arbeiten jetzt in Intercom, und der Bot behält vier Befehle, die Intercom tatsächlich nicht abdecken kann: Einrichtung, Konfiguration, Ticketsuche und die Abrechnungskonsole.
Den Großteil der eigenen Funktionsfläche zu löschen ist kein angenehmes Release. Es war das richtige. Jeder abgeschaffte Befehl war eine schlechtere Fassung von etwas, das Intercom bereits ordentlich konnte, und schlechtere Fassungen fremder Funktionen zu pflegen ist der Weg, auf dem aus einem Support-Bot ein Support-Produkt wird, um das niemand gebeten hat.
Die Automatisierung, die Intercom nicht kann
Die Workflow-Auslöser von Intercom greifen nicht bei Konversationen, die über dessen API angelegt wurden — und das ist jede Konversation, die diese Brücke erzeugt. Also musste die Inaktivitäts-Automatisierung hierher.
Gebrückte Tickets bekommen Erinnerungseinstellungen je Status. Ein Anstoß bei Kundenstille pingt die Kundin im Discord-Thread. Ein Anstoß bei Agentenstille schreibt stattdessen eine interne Notiz und öffnet die Intercom-Konversation wieder — denn die Kundin wegen des Schweigens des Agenten zu behelligen ist nicht das Verhalten, das irgendwer will.
Native Intercom-Konversationen, die nie gebrückt wurden, bekommen einen eigenen Durchlauf, mit Notizen bei Agentenstille, Anstößen bei Kundenstille und automatischem Schließen nach einer festgelegten Zahl unbeantworteter. Native Tickets bekommen nur Notizen und werden nie automatisch geschlossen.
Abrechnung
Eine vollständige Stripe-Konsole sitzt in Discord.
Kundinnen und Kunden bekommen Selbstbedienung für Erstattung und Kündigung, mit Leitplanken: eine Betragsobergrenze, eine Geschwindigkeitsgrenze je 24 Stunden, global und je Person, und ein Mindestalter der Mitgliedschaft. Das Team bekommt dahinter ein deutlich größeres Verwaltungspanel.
Webhooks für Rückbuchungen und frühe Betrugswarnungen werden programmatisch registriert statt über das Stripe-Dashboard, sodass zum Aufsetzen kein Konsolenzugang nötig ist. Tickets zu Erstattungsanfragen bleiben ausschließlich in Discord und werden nie zu Intercom gespiegelt.
Nachweise bei Rückbuchungen, gegen die echte Quelle verfasst
Nachweise für eine Rückbuchung zu verfassen ist die eine Stelle, an der sich ein LLM hier verdient macht.
Der Bot startet eine Coding-CLI, deren Arbeitsverzeichnis auf einen lokalen Klon des Postiz-Quelltexts und der Dokumentation zeigt. Aussagen zu Richtlinien im Nachweis sind darin verankert, was Code und Dokumentation tatsächlich sagen, statt darin, was sich ein Modell über ein nie gesehenes Produkt merkt. Ein Scheduler frischt diese Momentaufnahmen auf, indem er das Tarball herunterlädt und atomar tauscht — das Laufzeit-Image hat kein git-Binary.
Kurze Zusammenfassungen zu Rückbuchungen laufen über ein günstigeres Modell an der direkten API. Modellwahl und Ratenbegrenzungen werden zur Laufzeit konfiguriert, nicht beim Deployment.
Alles Dauerhafte läuft auf Temporal
Es gibt keinen prozessinternen Scheduler und keinen Cron-Rückfall. Langlebige Workflows je Ticket tragen Erinnerungen, automatisches Schließen, das Wiedereröffnungsfenster und die Intercom-Ausgangspumpe. Schleifende Singletons erledigen die Auffrischung der Wissensdatenbank, Momentaufnahmen, Aufräumen, Rückbuchungen, den Inaktivitätsdurchlauf und die SLA-Uhr.
Temporal abzuschalten ist eine Pause, keine Umgehung. Der Worker läuft leer, Hintergrundarbeit hält an, Fire-and-forget-Signale landen weiterhin serverseitig und werden bei Wiederaufnahme verarbeitet, und synchrone Aktionen wie Statuswechsel und Erstattungen fallen darauf zurück, im Prozess zu laufen.
Die Datenbank legt sich selbst an
Die Auslieferungsumgebung kann die Prisma-CLI nicht ausführen, also baut und aktualisiert die Anwendung ihr eigenes Schema beim Start über idempotente Anweisungen und prüft die tatsächlichen Spalten danach gegen ein Manifest. Abweichungen erzeugen standardmäßig eine Warnung und lassen sich in Entwicklung und CI zum Abbruch machen.
So würde niemand Migrationen freiwillig machen. Es ist, was die Randbedingung zuließ, und die ausdrückliche Abweichungsprüfung ist das, was es ehrlich hält.
Beobachtbarkeit
Sentry für Fehler, Spans und breite Ereignisprotokolle. Ein optionaler InfluxDB-Exporter trägt Abrechnungsereignisse, Rückbuchungsstände, KI-Nutzung und Kosten je Lauf, den Zustand der Brücke und einen Heartbeat, mit Grafana-Dashboards darüber. Der Sentry-Release ist dieselbe sechsstellige Kennung wie die Deployment-Version des Temporal-Workers, sodass sich ein Fehler und der Worker, der ihn erzeugt hat, ohne Raten in Deckung bringen lassen.
Nahezu jede Einstellung liegt in einem Konfigurationspanel zur Laufzeit statt in Umgebungsvariablen, weil das Deployment keine bearbeitbare Umgebung hat.