Chatbot-Implementierung im Stadtwerk: Leitfaden vom ersten Use Case bis zum laufenden Betrieb

Ein normaler Mittwoch im Januar. Im Servicecenter eines mittleren Stadtwerks stapeln sich seit drei Tagen die Anrufe — Jahresabrechnung, Abschlagsanpassung, Zählerstand. Die Warteschleife liegt bei 18 Minuten. Im Hintergrund haben drei Sachbearbeiter parallel das CRM, das Abrechnungssystem und das Mailpostfach offen. Ein Anrufer fragt zum dritten Mal innerhalb von zwei Wochen, warum sein Abschlag von 142 auf 198 Euro gestiegen ist. Genau die Frage steht in der Antwortvorlage. Aber niemand kommt durch, weil im Hintergrund noch 240 Mails offen sind.

So sieht der Alltag in vielen Stadtwerken aus, wenn die saisonale Welle anrollt. Ein Chatbot löst dieses Problem nicht über Nacht — aber er kann die Hälfte der Standardanfragen abfangen, bevor sie das Servicecenter überhaupt erreichen. Vorausgesetzt, das Projekt wird nicht wie ein Marketing-Gadget aufgesetzt, sondern wie ein Stück operative Infrastruktur. Dieser Leitfaden zeigt, wie das geht — Schritt für Schritt, mit den Stolperstellen, die ich in EVU-Projekten regelmäßig sehe.

Warum Stadtwerke jetzt nicht mehr warten sollten

Der Kontaktdruck im Kundenservice steigt seit 2022 strukturell — Energiepreiskrise, Soforthilfe, Strom- und Gaspreisbremse, dann Smart-Meter-Rollout, jetzt Wärmeplanung und PV-Boom. Jede dieser Wellen erzeugt eigene Anfragetypen, und jede landet ohne Filter im Servicecenter.

Parallel kämpfen fast alle EVU mit denselben strukturellen Problemen:

• Fachkräftemangel im Kundenservice — die Lücken in den Schichten werden größer
• Hohe Saisonalität — 1. Quartal Abrechnung, 3./4. Quartal Heizperiode und Tarifwechsel
• Wiederkehrende Standardfragen, die 60–75 % der Last ausmachen
• Steigende Erwartung an Self-Service, gerade bei Kunden unter 45 Jahren
• Komplexe Datenlage — Abrechnungssystem, CRM, Geräteverwaltung, Portal liegen meist getrennt

Ein gut implementierter Chatbot ist hier kein nettes Add-on. Er ist der einzige Hebel, der ohne Personalaufbau die Last spürbar reduziert — wenn die Vorarbeit stimmt. Und genau dort scheitern die meisten Projekte.

Phase 1 — Anfragenanalyse: Welche Themen lohnen sich überhaupt

Bevor irgendeine Plattform-Demo bestellt wird, gehört der Blick ins Servicecenter-Backlog. Konkret: die letzten 6 Monate Tickets, Kontaktarten-Statistik aus dem CRM, häufigste Mail-Betreffzeilen, Top-Themen aus der Telefonie. Ziel ist eine ehrliche Aufstellung der 30–40 häufigsten Anliegen mit Volumen, durchschnittlicher Bearbeitungszeit und Automatisierbarkeit.

Typische Stadtwerk-Themen nach Häufigkeit

Diese Verteilung ist nicht repräsentativ für jedes Haus — sie soll das Vorgehen illustrieren. Die ehrliche eigene Auswertung ist Pflicht. Wer die nicht hat, hat keine Grundlage für ein Chatbot-Projekt.

Drei Schubladen pro Anliegen

Jedes Thema bekommt eine von drei Klassifikationen:

• Voll automatisierbar — Antwort steht im System oder lässt sich aus Stammdaten ableiten
• Vorbereitend automatisierbar — Bot sammelt Daten, ein Mitarbeiter erledigt die Endbearbeitung
• Nur menschlich — Beschwerden, Sperrungen, Insolvenz, soziale Härtefälle

Realistisch landen 55–70 % der Anfragen in der ersten Schublade, weitere 15–25 % in der zweiten. Das ist die rechnerische Obergrenze für die Entlastung — nicht die, die ein Anbieter im Sales-Pitch verspricht.

Phase 2 — Use-Case-Schnitt: öffentlich vs. authentifiziert

Die wichtigste architektonische Entscheidung im ersten Monat lautet: Was darf ein anonymer Webbesucher fragen, und wo muss der Kunde sich anmelden?

Öffentlicher Bot (kein Login): Tarifauskunft, Preisbestandteile, Wechsel zu Stadtwerk X, Öffnungszeiten, Hilfe zur Rechnungsstruktur, Störungsstatus auf Ortsteil-Ebene, allgemeine FAQ zu Smart Meter und PV.

Authentifizierter Bot (eingeloggt im Kundenportal oder über Single-Sign-on): Konkrete Abschlagsänderung, Bankverbindung, Adresse, Zählerstand mit Plausibilisierung, Vertragsstand, individuelle Rechnungsfragen.

Diese Trennung sauber zu ziehen erspart später viel DSGVO-Diskussion. Personenbezogene Verbrauchsdaten gehören nie in eine öffentliche Chat-Session. Wer den Bot trotzdem alles im öffentlichen Bereich machen lässt, baut sich ein Datenschutz-Problem ein, das spätestens beim ersten Audit auffliegt.

Empfohlener Schnitt für den Start

Im ersten Projektzyklus reichen 6–10 öffentliche Use Cases plus 2–4 authentifizierte. Mehr nicht. Eine breite Erstausstattung verzettelt das Projektteam und liefert mittelmäßige Antworten in allen Bereichen statt sehr guter in wenigen.

Phase 3 — Plattform und Architektur

Die Plattformfrage entscheidet nicht über den Erfolg — aber über den Aufwand. Drei Architekturmuster sind in Stadtwerken sinnvoll:

Muster A — Klassischer Regel-Bot mit RAG-Modul

Ein etabliertes Chatbot-System (z. B. ein deutscher Anbieter mit BSI-Zertifizierung) wird um eine Retrieval-Augmented-Generation-Schicht ergänzt. Die Wissensbasis bleibt strukturiert, das LLM beantwortet Freitextfragen. Gut für EVU mit klarer Compliance-Linie und vorhandenem Kundenportal.

Muster B — LLM-First mit kontrolliertem Toolzugriff

Modernes Setup mit Sprachmodell als Kern, das über definierte Werkzeuge auf Stammdaten, Tarifrechner und CRM zugreift. Mehr Flexibilität, mehr Verantwortung beim Prompt-Design. Sinnvoll, wenn ohnehin eigene Entwickler oder ein erfahrener Partner an Bord sind.

Muster C — Standard-SaaS für FAQ-Niveau

Reine FAQ-Bots ohne Systemanbindung. Nicht wirklich Implementierungsprojekt, sondern Konfigurationsaufgabe. Für sehr kleine EVU mit unter 25.000 Zählpunkten als Einstieg vertretbar, ab mittlerer Größe zu wenig.

Kriterien-Check vor der Plattformentscheidung

• DSGVO-Konformität, Hosting in Deutschland oder EU, Auftragsverarbeitungsvertrag im Standard
• Mandantenfähigkeit, wenn das Stadtwerk mehrere Marken oder Töchter hat
• Anbindung an das vorhandene Abrechnungssystem (SAP IS-U, Schleupen, Wilken, kVASy, Kisters) über API oder vorhandene Connectoren
• Single-Sign-on-Fähigkeit für das Kundenportal
• Protokollierung jeder Antwort mit Quelle (wichtig für spätere Audits)
• Klare Mechanik für Eskalation in das bestehende Ticket-System

Lassen Sie sich vor jedem Vertrag eine echte Referenz aus dem EVU-Umfeld zeigen. Verticals lernen sehr unterschiedlich — was im E-Commerce hervorragend läuft, scheitert in der Energiewirtschaft an Abrechnungslogik und Saisonalität.

Phase 4 — Wissensbasis: Was rein muss und was draußen bleibt

Die Wissensbasis ist das eigentliche Projekt — nicht der Chat. Wer hier spart, baut einen freundlichen Roboter, der über Kleinigkeiten stolpert.

Quellen, die rein müssen

• Aktuelle Preisblätter und Tarife (mit gültiger Versionierung)
• AGB, Sondervertragsbedingungen, Lieferbedingungen
• Prozessbeschreibungen für Standardanliegen — als kurze, abgegrenzte Bausteine, nicht als ganze Handbücher
• FAQ aus dem Servicecenter, inklusive bisheriger Mail-Antwort-Bausteine
• Informationen zum Versorgungsgebiet, Netzgebiet, Konzessionen
• Erläuterungen zu Rechnungsbestandteilen, Abschlagslogik, Verbrauchsabrechnung
• Stand zu Smart Meter, Rollout-Phase, gMSB-Zuständigkeit
• Aktuelle Förderprogramme und Beratungsangebote

Quellen, die explizit draußen bleiben

• Interne Anweisungen, die nicht für Kunden gedacht sind („Beim Kunden X immer zur Hotline weiterleiten“)
• Veraltete Tarife — sonst beantwortet der Bot Anfragen mit Konditionen aus 2023
• Halb-fertige Prozessbeschreibungen aus dem Wiki
• Rechtlich sensible Vorlagen ohne juristische Freigabe

Pflege-Konzept ab Tag 1

Eine Wissensbasis ohne Owner verfällt innerhalb von sechs Monaten. Pro Themenfeld braucht es einen fachlichen Verantwortlichen — Vertrieb verantwortet Tarife, Abrechnung verantwortet Rechnungsthemen, Netz verantwortet Störung und Smart Meter. Ohne diese Zuteilung wird die Wissensbasis veralten, und der Bot wird Fehler machen.

Phase 5 — Integration in die Servicecenter-Welt

Ein isolierter Bot, der nur antwortet, ist eine FAQ-Seite mit Avatar. Der eigentliche Hebel entsteht durch Anbindung.

Mindest-Integrationen

• CRM — jede Konversation wird dem Kundenobjekt zugeordnet, sobald authentifiziert
• Ticket-System — Eskalationen erzeugen ein vollständiges Ticket inklusive Chat-Verlauf und Kontext
• Kundenportal-SSO — kein doppeltes Login, kein Bruch
• Stammdaten-API — Adresse, Vertragsstand, Zähler, Abschlagshöhe lesbar
• Schreibender Zugriff — kontrolliert, mit Audit-Log, für definierte Vorgänge wie Bankdatenänderung

Eskalation als eigenes Subprojekt

Die Übergabe an einen menschlichen Mitarbeiter ist nicht „den Bot ausschalten“. Sie ist ein eigener Designschritt:

• Wann wird eskaliert? — Definierte Trigger, nicht „wenn der Kunde es will“
• An wen? — Skill-basiert in die richtige Queue, nicht in eine zentrale Sammelmailbox
• Mit welchem Kontext? — Chat-Verlauf, identifizierter Kunde, Vorgangstyp, Dringlichkeit
• Außerhalb der Servicezeiten? — Asynchrone Übergabe mit klarer Erwartung zum Rückruf

Wer Eskalation als Nebensache behandelt, verbrennt Kundenvertrauen genau an der Stelle, an der ein Mensch eigentlich noch retten könnte.

Phase 6 — Testen mit echten Anfragen, nicht mit Wunschdaten

Der häufigste Testfehler in EVU-Projekten: die Konversationen werden mit den Anfragen geprobt, die die Projektgruppe selbst formuliert. Das sind brave, klare, gut formulierte Sätze. Sie sehen aus wie eine FAQ-Liste, nur in ganzen Sätzen.

Echte Kundenanfragen sehen anders aus. Sie enthalten Tippfehler, Dialekt, fehlende Verben, lange Vorgeschichten, gemischte Themen, emotional aufgeladene Formulierungen. Genau damit muss getestet werden.

Drei Testebenen

Korpus-Test — 200–500 reale anonymisierte Anfragen aus Mail und Webformular durch den Bot laufen lassen, Antwortqualität von Fachbereich bewerten.

Shadow Mode — Bot läuft 1–2 Wochen unsichtbar parallel zu Mail und Chat. Mitarbeiter sehen Vorschläge, geben sie aber selbst an Kunden weiter. Liefert echte Trefferquote ohne Risiko.

Edge-Case-Set — gezielte Tests mit Beschwerden, Sperr-Androhungen, Sozialhärtefällen, juristischen Drohungen, Suizid-Andeutungen. Hier muss der Bot zuverlässig eskalieren, niemals beraten.

Ohne diese drei Ebenen geht kein Bot bei einem Stadtwerk in Produktion. Punkt.

Phase 7 — Go-Live: gestaffelt, nicht knall auf Fall

Niemand schaltet ein neues System in einem EVU an einem Montag in voller Sichtbarkeit frei. Das gilt für SAP-Updates, das gilt für Portal-Releases, und es gilt für Chatbots.

Sinnvolle Staffelung

• Tag 1–7 — Sichtbarkeit nur auf zwei bis drei Seiten (Tarif-Seite, Kontakt-Seite, FAQ). Limitierte Öffnungszeit, parallel hohe Mitarbeiter-Aufmerksamkeit, tägliches Review.
• Tag 8–21 — Ausweitung auf alle öffentlichen Seiten. Tägliches Monitoring der Fallback-Rate und Eskalationen.
• Ab Tag 22 — Vollbetrieb inklusive authentifizierter Use Cases im Kundenportal. Wöchentliches Reporting an Bereichsleitung.

In dieser Phase wird die Trefferquote anfangs niedriger sein als in den Tests — das ist normal. Die Reibung mit echten Anfragen zeigt, was die Wissensbasis nicht abdeckt. Genau das ist der Lerngewinn.

Phase 8 — Betrieb: Was nach dem Launch passieren muss

Ein Chatbot ist Software in Produktion. Er braucht Pflege, sonst veraltet er.

Wöchentlich

• Fallback-Konversationen sichten, neue FAQ-Lücken identifizieren
• Eskalationen reviewen, sind die richtigen Fälle eskaliert worden
• Top-5-Neuthemen aus dem Servicecenter abgleichen

Monatlich

• Trefferquote, Eskalationsquote, Kundenzufriedenheit auswerten
• Wissensbasis aktualisieren — neue Preisblätter, geänderte Prozesse, neue Förderlinien
• Sprachmodell-Antworten stichprobenweise gegen die Quellen prüfen

Quartalsweise

• Voll-Audit mit Datenschutz und Revision
• Use-Case-Backlog priorisieren — was kommt als nächstes dazu
• Reporting an die Geschäftsleitung mit harten KPIs

Der häufigste Fehler nach Go-Live: das Projekt wird formal abgeschlossen, niemand fühlt sich verantwortlich, in sechs Monaten ist die Wissensbasis veraltet, die Trefferquote sinkt, und der Bot bekommt intern den Stempel „funktioniert eh nicht“.

Typische Fallen, die ich in EVU-Projekten sehe

Wissensbasis ohne Fachbereichs-Ownership. Wenn niemand im Vertrieb sich für die Tariftexte zuständig fühlt, veralten sie. Innerhalb eines Quartals sind 20 % falsch.

Bot wird vor dem Kundenportal-SSO gestartet. Konsequenz: kein authentifizierter Use Case möglich, der Bot bleibt FAQ-Niveau, der Business Case fällt halb weg.

Zu viele Themen im ersten Release. Statt zehn solider Antworten gibt es vierzig mittelmäßige. Die Kundenzufriedenheit sinkt, das Projekt wird intern abgewertet.

Kein klarer Eskalationspfad. Bot übergibt an eine Sammelmailbox, dort liegt der Vorgang drei Tage. Kunde ruft trotzdem an. Die Last verschiebt sich, statt zu sinken.

KI-Kennzeichnung vergessen. Der EU AI Act verlangt eine klare Kenntlichmachung. Wer das übersieht, riskiert Abmahnungen und Imageschaden — beides vermeidbar mit drei Zeilen Disclaimer.

Kein Notfall-Schalter. Wenn das LLM Unsinn produziert oder ein Datenleck auffällt, muss der Bot innerhalb von Minuten deaktivierbar sein. Diese Funktion fehlt erstaunlich oft.

Erwartungsmanagement gegenüber dem Servicecenter fehlt. Mitarbeiter erwarten, dass der Bot ihnen sofort 50 % Last abnimmt. Realistisch sind im ersten Quartal 15–25 %, mit klarer Steigerung bei sauberem Betrieb. Wer das nicht vorab kommuniziert, erlebt Frust im Team.

Realistischer Zeitplan für ein mittleres Stadtwerk

Realistische Gesamtprojektdauer: 10–14 Wochen bis stabiler Vollbetrieb. Kürzer geht — aber nur, wenn man Abstriche bei Tests oder Integration macht. Beides rächt sich später.

Was ich für Sie entwickle

Ich begleite Stadtwerke und kleinere EVU bei genau diesem Implementierungspfad — vom Anfragen-Audit bis zum stabilen Betrieb. Der Fokus liegt darauf, dass der Bot nicht als IT-Projekt isoliert läuft, sondern als operatives Werkzeug im Servicecenter ankommt.

Anfragen-Audit und Use-Case-Schnitt — strukturierte Auswertung von Mail-, Telefon- und Portal-Anfragen, Klassifikation in vollautomatisierbar, vorbereitend und nur menschlich. Ergebnis: priorisierter Use-Case-Plan mit realistischem Business Case.

Architektur und Plattformauswahl — Bewertung der vorhandenen Systemlandschaft (Abrechnungssystem, CRM, Portal, Ticket-System), Empfehlung eines passenden Plattform-Musters, Vorbereitung der Ausschreibung oder Direktvergabe.

Wissensbasis-Setup mit Fachbereichs-Ownership — Aufbau einer strukturierten Wissensbasis pro Themenfeld, Etablierung des Pflegeprozesses mit fachlichen Verantwortlichen, Anbindung an bestehende Quellsysteme.

Integration in Portal, CRM und Ticket-System — technische Anbindung über vorhandene APIs, SSO-Einbindung, sauber definierte Eskalationspfade in die richtigen Servicecenter-Queues.

Test-Setup mit echten Anfragen — Aufbau eines Test-Korpus aus anonymisierten realen Anfragen, Edge-Case-Katalog für sensible Themen, Shadow-Mode-Begleitung im Servicecenter.

Datenschutz- und AI-Act-Konformität — Verarbeitungsverzeichnis, DSFA, Kennzeichnungspflicht, Audit-Log, Notfall-Schalter — alles vor Go-Live geklärt, nicht danach.

Betriebsbegleitung in den ersten 90 Tagen — wöchentliche Reviews, Wissensbasis-Pflege, KPI-Reporting an Bereichsleitung, schrittweise Erweiterung des Use-Case-Sets.

Der Einstieg muss kein Großprojekt sein. Eine pragmatische erste Stufe mit fünf bis acht Use Cases lässt sich in zehn Wochen liefern und liefert einen sauberen Business Case für die nächste Ausbaustufe.

Fazit

Ein Chatbot in einem Stadtwerk ist kein Marketing-Gadget — er ist Betriebsmittel. Er funktioniert, wenn die Anfragenanalyse stimmt, die Wissensbasis fachlich verantwortet wird, die Integration ins Servicecenter sauber sitzt und das Erwartungsmanagement nicht überzogen ist. Er funktioniert nicht, wenn er als IT-Showcase ohne Betriebskonzept eingeführt wird.

Der ehrliche Pfad ist der kleinere Erstwurf mit klarer Skalierungsperspektive: wenige Use Cases, sauber umgesetzt, mit echtem Test, gestaffeltem Go-Live und einem Pflegekonzept ab Tag 1. Aus diesem Fundament lässt sich der Funktionsumfang über Quartale erweitern — vom Standard-FAQ über authentifizierte Vorgänge bis zur tiefen Integration mit Abrechnung und Netzbetrieb.

Wenn Sie über ein Chatbot-Projekt in Ihrem Haus nachdenken, hilft ein erstes strukturiertes Audit Ihrer realen Anfragelast. Innerhalb einer Woche steht damit, ob ein Bot in Ihrem Servicecenter Last nehmen kann — und wenn ja, an welchen Stellen zuerst.