Die Build-Schwelle ist verschoben: Helpdesk in 7 Tagen

Monatelang hatten wir innerhalb unserer eigenen Wände agentisch gebaut. Market Intel als Pipeline für Wettbewerbsinformationen. Interne Helfer für Vertrieb und Betrieb. Prototypen und Werkzeuge, die bewiesen, dass wir mit Agenten funktionierende Software ausliefern können.

Keines davon hatte Kundenkontakt.

Das war die fehlende Schwelle. Eine interne App verträgt eine raue Kante. Das Team kennt den Kontext, füllt Lücken und arbeitet um das Werkzeug herum, während es besser wird. Ein System für Kunden hat einen anderen Maßstab.

Externe Nutzer kommen mit echten Erwartungen, nicht mit interner Nachsicht. Die Integration muss in den Kanälen ankommen, die sie bereits nutzen: in ihren Slack-Workspaces, ihren E-Mails, ihren Sitzungen im Portal. Und sobald ein Werkzeug einen Pilotbetrieb erreicht, kommt das Feedback sofort. Kunden sagen Ihnen an dem Tag, an dem etwas nicht funktioniert, dass es nicht funktioniert, nicht erst im Sprint Review.

Der Kunden-Helpdesk war dieser Test.

Die Version nach 7 Tagen. Am Ende von Tag 7 hatten wir einen ersten funktionsfähigen Helpdesk, den das Team von Anfang bis Ende nutzen konnte. Er umfasste ein Kundenportal mit Anmeldung und Registrierung, eine Agent-UI mit Dashboard und Ticket-Warteschlangen, CRUD für Tickets, Kommentare, Anhänge, Organisationen, Kontakte, einen Audit-Trail und eine SLA-Engine, die Geschäftszeiten und Feiertage berücksichtigt.

Dazu kamen bidirektionale E-Mail über Microsoft Graph mit Threads und eingebetteten Bildern, bidirektionales Slack über die Events API, eine Infrastruktur für die Wissensbasis mit Schema, Embedding-Dienst, Such-API und automatischer Aufnahme geschlossener Tickets. Die Agent-UI enthielt bereits KI-Klassifizierung, eine KI-Werkzeugleiste zur Textverbesserung, einen Dark Mode und eine Grundlage aus Design Tokens.

Es war das erste laufende System.

Was sich nach Tag 7 geändert hat. Zwei Monate Entwicklung machten aus diesem Fundament das Pilotsystem, das heute läuft. Der Helpdesk-Bot auf RAG-Basis läuft jetzt im Portal als ChatWidget und antwortet mit nativen Zitaten aus der KB. Die Pipeline zur Befüllung der KB verarbeitete 577 Artikel von help.dawiso.com: 1.107 Chunks und 620 Bilder, die durch Vision-Modelle liefen. Slack Q/A Monitoring durchsucht die Support-Kanäle täglich, sortiert nützliche Q/A-Threads vor und macht daraus KB-Artikel, mit anonymisierten personenbezogenen Daten. @helpdesk remember speichert jeden Slack-Thread als KB-Artikel. Ein Intent-Klassifikator entscheidet, wann der Bot anbieten sollte, ein Ticket anzulegen, statt jede Konversation in Richtung Support zu schieben.

Außerdem haben wir den Stack von der ursprünglichen Einrichtung auf Cloudflare Workers auf unsere Standard-Infrastruktur in Azure umgezogen: K8s, PostgreSQL, Redis/BullMQ und Azure Blob Storage. Unser Infrastrukturteam hat ihn nach Azure gebracht. Wir haben einen Sicherheitsdurchgang gemacht und das Designsystem neu gebaut.

Die Zahlen heute. 564 Commits in rund zwei Monaten. 701 Tests in 54 Testdateien. 16 Tabellen in PostgreSQL. 80+ React-Komponenten. 3 bidirektionale Kanäle: Portal, E-Mail und Slack. 577 Hilfeartikel plus 266 geprüfte Q/A-Artikel in der KB.

Eine Person hat den Kern gemeinsam mit KI-Agenten gebaut. Die breitere Engineering-Arbeit an Infrastruktur, Sicherheit und Produktqualität hat ihn für einen Pilotbetrieb bei Kunden tauglich gemacht.

Die Tippgeschwindigkeit war nie der Engpass.

Drei Dinge zusammen haben die Arbeit möglich gemacht.

1. Vorbereitung im Voraus. Ein ausführliches PRD, die Architektur, das Datenmodell und die gestalterische Identität kamen vor der ersten Zeile Code, die ein Agent schrieb. Das Paradox der agentischen Entwicklung ist, dass ein Agent umso schneller arbeitet, je mehr Zeit man in die Vorbereitung steckt. Agenten brauchen keine Meetings. Sie brauchen klaren Kontext.

2. Testdisziplin als Sicherheitsnetz. 701 Tests in 54 Testdateien sind das, was den Agenten mutig ändern lässt. Wir prüfen jede Änderung sofort. Ohne Tests wird agentische Entwicklung in diesem Umfang zum Ratespiel. Tests sind der Weg, auf dem der Agent erfährt, ob seine letzte Änderung drei Dateien weiter etwas kaputtgemacht hat.

3. Der Takt der Sitzungen. Jede Sitzung hatte eine klare Form: den Projektkontext laden, eine begrenzte Aufgabe ausführen, den Diff prüfen, mergen. Die Skills, die Design Tokens, die Typsicherheit, CI/CD und die Disziplin beim Review rund um den Agenten machen ihn produktiv. Der Agent ist der Ausführende. Das System um ihn herum ist die Engineering-Praxis.

Das System wird mit jeder Konversation besser, die es bearbeitet, ohne dass jedes Mal neue Funktionen gebaut werden müssen. Das ist der Teil, der sich verstärkt.

Die Wissensbasis steht im Zentrum des Helpdesks und wächst aus fünf Quellen zugleich.

• Erste Befüllung. 577 Artikel von help.dawiso.com, für RAG aufbereitet: 1.107 Chunks und 620 Bilder, die durch Vision-Modelle liefen.
• Laufende Extraktion. Slack Q/A Monitoring durchsucht die Support-Kanäle täglich. Eine heuristische Bewertung erkennt echte Q/A-Threads, eine KI-Vorsortierung entscheidet, ob extrahiert wird, der Extraktionsschritt schreibt den Artikel, und eine Deduplizierung hält die KB sauber. Personenbezogene Daten durchlaufen eine Anonymisierung: Namen werden zu Rollenbezeichnungen, Kundennamen zu „der Kunde“, und Erwähnungen in Slack werden entfernt.
• Manuelle Qualitätsprüfung. Als 567 aus Slack gewonnene Artikel geprüft werden mussten, stellte ein Prüfdurchgang mit langem Kontext die vollständige Hilfedokumentation daneben und traf Entscheidungen: 301 löschen, 156 mit KI-Umformulierung verbessern, 80 behalten. Eine laufende Prüfung hält das Niveau.
• Verankerung des Bots. Antworten kommen mit nativen Zitaten aus der KB, nicht als freie Generierung. Daumen hoch oder runter je Nachricht und Sternebewertungen am Ende des Chats liefern Rückmeldung. Ein Intent-Klassifikator entscheidet, ob ein Ticket angeboten wird, damit der Chat keine Tickets aufdrängt, wenn eine Frage eine Antwort verdient.
• Kurzbefehle für Agenten. @helpdesk remember speichert jeden Slack-Thread als KB-Artikel. Jedes geschlossene Ticket wird automatisch in die KB aufgenommen.

Für andere Gründer. Überlegen Sie, welche Systeme in Ihrem Stack jetzt in Reichweite eines Eigenbaus liegen. Die Linie zwischen „selbst bauen“ und „kaufen“ liegt nicht mehr dort, wo sie vor 18 Monaten lag. Werkzeuge, für die früher ein kleines Team nötig war, sind jetzt womöglich für eine Person mit Agenten erreichbar, wenn die Engineering-Praxis darum herum stark genug ist.

Für Käufer in Unternehmen. Einfache fachliche Abläufe werden innerhalb der eigenen Wände baubar. Das macht Anbieter nicht überflüssig. Es verändert, was der Wert eines Anbieters bedeuten muss. Der verbleibende Burggraben sind anspruchsvolle Integration, Governance, Compliance, Skalierung, Sicherheit, betriebliches Vertrauen und tiefe Fachkenntnis.

Dort stößt agentisches Selbermachen noch an Wände.

Jetzt live. Zwei Kunden sind seit 14 Tagen im Pilotbetrieb. Der Bot antwortet selbstständig in den Slack-Kanälen der Kunden und im Portal. Bis Ende Mai rollen wir ihn auf den übrigen Kundenstamm aus. Der Pilotbetrieb tut, was ein Pilot tun soll: Er zeigt, was als Nächstes gebaut werden muss.

Nach vorn im Helpdesk. Mehr Branchen im bestehenden Kundenstamm. Mehr KB, befüllt aus echten Interaktionen mit Kunden zusätzlich zur Grundlage aus der Hilfedokumentation. Mehr Kanäle, wenn Kunden danach fragen. Je länger es läuft, desto besser werden die Antworten.

Die Build-Schwelle hat sich verschoben. Historisch hielt Open Source einen Großteil der Linie zwischen „selbst bauen“ und „kaufen“: Vieles, was sich zur Massenware machen ließ, wanderte dorthin, während der Rest im Revier der Anbieter blieb. Agentisches Programmieren verschiebt diese Linie erneut.

Für Softwareunternehmen ist das unbequem. Mehr Software lässt sich schneller und mit kleineren Teams bauen. Manche Produktflächen, die früher eine eigene Kategorie von Anbietern rechtfertigten, werden zu internen Abläufen.

Die andere Seite ist aber eine echte Chance. Dieselben Agenten, die die Kosten des Eigenbaus senken, heben auch die Messlatte dafür, was ein Produkt leisten muss, damit sich der Kauf lohnt.

Je agentischer wir arbeiten, desto wichtiger wird Data Governance. Dorthin geht der nächste Beitrag.