Freitagvormittag, kurz vor 11 Uhr. Im Kundenservicecenter eines regionalen Stadtwerks klingeln die Leitungen im Stundentakt. Drei Mitarbeitende nehmen Anrufe entgegen. Zwei der Gespräche sind identisch: Zählerstandsmeldung und Frage nach der Abschlagshöhe. Das dritte ist eine echte Beratungsanfrage zu einem Wärmepumpen-Tarif.
Das ist kein Einzelfall. In vielen Stadtwerken machen Routineanfragen 55–70 % des eingehenden Kontaktvolumens aus — laut Benchmarks des BDEW. Und diese Anfragen landen entweder im Telefonsupport oder in einem Postfach, das zweimal täglich geleert wird.
AI-Readiness ist nicht die Antwort auf alle Fragen. Aber sie ist die technische Grundlage dafür, dass Routinelast automatisiert aufgefangen werden kann — und komplexe Anliegen wieder bei Menschen landen, die dafür Zeit haben.
Zwei parallele Entwicklungen, die Stadtwerke gleichzeitig treffen
Stadtwerke befinden sich gerade in einer technologischen Zwickmühle, die zwei Entwicklungen gleichzeitig erzeugt.
Auf der Kundenseite nutzen immer mehr Menschen KI-Assistenten als erste Anlaufstelle. Nicht nur für Informationen — sondern für Aktionen. „Stell mir einen Erinnerung für die Zählerstandsmeldung Ende des Monats“ ist schon heute Alltag. „Meld meinen Zählerstand direkt beim Stadtwerk“ kommt als nächstes. Dieser Schritt setzt voraus, dass das Stadtwerk eine Schnittstelle hat, die ein Agent ansprechen kann. Ohne diese Schnittstelle delegiert der Assistent weiter: „Rufen Sie bitte selbst an.“
Auf der Infrastrukturseite arbeiten viele Stadtwerke mit gewachsenen Systemlandschaften: SAP IS-U oder alternative Branchensysteme, separate Abrechnungsplattformen, eigenentwickelte oder lizenzierte Kundenportale, dazu E-Mail-gestützter First-Level-Support. Integration ist teuer, und neue Kanäle schaffen ohne Datenbeschichtung nur neue Medienbrüche.
Das Ergebnis: Digitale Projekte scheitern nicht an fehlendem Willen, sondern an fehlender Datenstruktur. Chatbots als Overlay auf einer unstrukturierten Website beantworten Fragen, die sie nicht verlässlich beantworten können. Der Kunde ruft trotzdem an.
Was ein KI-Assistent braucht, um Stadtwerk-Kundenservice wirklich zu entlasten
Der entscheidende Unterschied zwischen einem KI-Assistent, der hilft, und einem, der frustriert, liegt nicht im Sprachmodell. Er liegt in den Daten, die das Sprachmodell abrufen kann.
Stellen Sie sich vor, ein Kunde fragt seinen Assistenten: „Wie hoch ist mein aktueller Stromabschlag, und kann ich den für den Sommer um 15 Euro senken?“
Zwei Szenarien:
Szenario A — kein AI-Ready-System: Der Assistent öffnet das Kundenportal, trifft auf eine JavaScript-Anwendung mit Session-Authentifizierung, scheitert am Login, gibt zurück: „Ich kann auf das Portal nicht zugreifen. Bitte loggen Sie sich selbst ein.“
Szenario B — AI-Ready-System: Der Assistent authentifiziert sich via OAuth 2.0 mit einem Scoped Token, das der Kunde einmalig autorisiert hat. Er ruft GET /api/v2/contracts/current ab, liest den Abschlagsbetrag aus dem strukturierten JSON-Response, prüft gegen POST /api/v2/payment-adjustments ob eine Änderung möglich ist, und antwortet: „Ihr aktueller Abschlag beträgt 87 Euro. Eine Senkung auf 72 Euro ist möglich. Soll ich die Änderung direkt beauftragen?“
Der Unterschied ist nicht marginal. Im ersten Szenario hat der Assistent nichts geleistet. Im zweiten hat er eine Aufgabe übernommen, für die sonst ein Anruf oder ein Portal-Login nötig gewesen wäre.
Was technisch dahintersteckt
AI-Ready bedeutet für ein Stadtwerk-Kundenservice-System konkret fünf Dinge:
Maschinenlesbare Servicedaten — Nicht als HTML-Fließtext, sondern als strukturierte Endpunkte oder wenigstens als Schema.org-Markup: Servicetypen, Zuständigkeiten, Öffnungszeiten, Einzugsgebiet, Tarifkategorien.
Standardisierte Authentifizierung — OAuth 2.0 mit Scopes, die granular definieren, welche Aktionen ein Agent im Auftrag eines Kunden ausführen darf. Scoped Token sind widerrufbar, auditierbar und zeitlich begrenzbar — sicherer als ein Portal-Login mit wiederverwendetem Passwort.
Versionierte API-Endpunkte — Lese-Endpunkte für Vertragsdaten, Rechnungshistorie, Zählerstandshistorie und Tarifdetails. Schreib-Endpunkte für Aktionen, die Kunden bisher anrufen mussten: Zählerstand melden, Abschlag anpassen, Bankverbindung ändern, Beratungstermin anfordern.
Discovery-Datei — /.well-known/agents.json mit einer strukturierten Beschreibung aller verfügbaren Tools, Authentifizierungsarten und Scopes. Ein KI-Assistent, der diese Datei findet, weiß sofort: Was kann ich hier tun, und wie muss ich mich dafür ausweisen?
Event-Webhooks — Nicht nur reaktiv auf Kundenanfragen reagieren, sondern proaktiv signalisieren: Rechnung bereitgestellt, Abrechnung erstellt, Entstörung abgeschlossen, Tarif ausgelaufen. Der Assistent des Kunden kann dann aktiv informieren — bevor der Kunde anruft.
Was das intern bedeutet: Weniger Routine, mehr Kompetenz
AI-Readiness wirkt nicht nur auf externe Agenten. Sie verändert auch die internen Abläufe.
Ein Stadtwerk-Mitarbeitender im First-Level-Support, der Zugriff auf einen internen KI-Assistenten mit API-Anbindung ans ERP-System hat, bearbeitet eine Kundenanfrage in 90 Sekunden statt in 4 Minuten. Nicht weil der Assistent antwortet statt des Mitarbeitenden — sondern weil er die Informationen aus vier verschiedenen Systemen sofort zusammengeführt hat und der Mitarbeitende nur noch beurteilen und kommunizieren muss.
Das ist der realistischere und unmittelbarere Hebel. Nicht der externe Kundenagent, der selbstständig Zählerstände meldet. Sondern der interne Assistent, der den Servicecenter-Mitarbeitenden mit kontextuellen Informationen versorgt, bevor das Gespräch richtig begonnen hat.
Beide Anwendungsfälle setzen dieselbe Grundlage voraus: strukturierte, maschinenlesbar angebundene Daten.
DSGVO und Datensicherheit: kein Hindernis, sondern Designvorgabe
Stadtwerke verarbeiten besonders schutzwürdige Daten. Verbrauchsprofile lassen Rückschlüsse auf Lebensgewohnheiten zu. Zahlungshistorien sind sensibel. Vertragsdaten unterliegen Aufbewahrungspflichten.
Das ist kein Argument gegen AI-Readiness. Es ist die Designvorgabe dafür.
Scoped OAuth-Tokens erzwingen, dass ein Agent niemals mehr Daten abruft als explizit autorisiert. Wenn ein Kunde seinen Assistenten nur für meter:write und invoices:read autorisiert, bleibt alles andere — Zahlungshistorie, Bankdaten, Verbrauchsanalyse — außerhalb seines Zugriffsbereichs. Diese Trennung ist architektonisch, nicht prozessual.
Öffentliche Informationsendpunkte — Servicekatalog, Öffnungszeiten, allgemeine Tarifübersichten — enthalten keine personenbezogenen Daten und sind strukturell vom Kundenportal getrennt. Was nach außen geht, ist by design anonym.
API-Logs geben darüber hinaus lückenlose Auskunft darüber, welcher Agent zu welchem Zeitpunkt welchen Endpunkt mit welchem Scope aufgerufen hat. Das ist ein Audit-Trail, den Sessionbasiertes Portal-Login nicht liefern kann.
Drei Phasen zur AI-Ready Stadtwerk-Plattform
Kein Stadtwerk muss diesen Weg in einem Schritt gehen. Die sinnvolle Reihenfolge:
Phase 1 — Sofort umsetzbar, hoher Doppelnutzen (2–4 Wochen)
Schema.org-Auszeichnung für alle öffentlichen Servicedaten: Servicetypen als Service, Öffnungszeiten als OpeningHoursSpecification, Standorte als LocalBusiness, häufige Fragen als FAQPage. Das verbessert unmittelbar die Google-Darstellung, reduziert Anrufe zu Routinefragen und schafft die Datenbasis für spätere API-Endpunkte. Investition: überschaubar, Nutzen: sofort messbar.
Phase 2 — Authentifizierungsschicht und öffentliche APIs (4–8 Wochen)
OAuth 2.0 auf dem bestehenden Identity-Provider (empfolen Stadtwerk-eigenes CIAM), erste Lese-Endpunkte für Vertragsdaten, Rechnungsübersicht und Zählerstandshistorie. agents.json als Discovery-Datei. CORS-Konfiguration für Agent-Origins. An dieser Stelle können erste externe Agenten autorisiert werden — und der Datentransfer ist vollständig unter Kontrolle.
Phase 3 — Schreib-Endpunkte, Webhooks, Monitoring (laufend)
Schrittweiser Aufbau von Schreib-Endpunkten: Zählerstand melden, Abschlag anpassen, Termin anfordern. Webhook-System für Ereignis-Benachrichtigungen. Dediziertes Monitoring für API-Traffic getrennt vom Portal-Analytics. A2A-fähigkeit für Szenarien, in denen Agenten untereinander kommunizieren — etwa wenn ein Stadtwerk-Agent direkt mit dem Assistenten des Kunden Rückfragen klärt.
Direkter Vergleich: jetzt vs. AI-Ready
| Kundenszenario | Heute | AI-Ready |
|---|---|---|
| Zählerstand melden | Anruf oder Portal-Login | Agent meldet direkt via meter:write |
| Abschlag prüfen und anpassen | Portal-Login, 3 Klicks | Agent ruft ab, schlägt Änderung vor, wartet auf Bestätigung |
| Tarifwechsel anfragen | Formular, Wartezeit auf Rückmeldung | Termin-API oder direkte Anfrage, strukturierte Bestätigung |
| Störung melden | Hotline, oft Wartezeit | Webhook-Signal an Agenten, bevor Kunde anruft |
| Rechnung kommt | Kunde bemerkt sie nicht oder zu spät | Webhook → Assistent informiert proaktiv |
| Öffnungszeiten abfragen | Google oder Anruf | Schema.org → Assistent antwortet direkt |
| FAQ-Frage zu Zählerwechsel | Suche auf Website, manchmal Anruf | Strukturierte FAQ-Daten → Sofortantwort ohne Anruf |
Was ich für Sie entwickle
Stadtwerke brauchen keine neues CRM und kein neues Kundenportal, um diesen Weg zu gehen. Was gebraucht wird, sind saubere APIs auf dem, was bereits existiert, und die richtigen strukturellen Ergänzungen.
Schema.org-Auszeichnung Ihres Servicekatalogs — Vollständige strukturierte Auszeichnung aller Servicetypen, Öffnungszeiten, Zuständigkeiten und FAQ-Inhalte. Direkte Auswirkung auf Google-Sichtbarkeit und KI-Auffindbarkeit.
OAuth-2.0-Authentifizierungsschicht — Scoped-Token-Infrastruktur auf Ihrem bestehenden Identity-Provider, getrennt von der Portal-Authentifizierung. Sicher, auditierbar, DSGVO-konform.
API-Gateway auf SAP IS-U oder Schleupen CS.ERP — Strukturierte REST-API-Endpunkte auf Ihrem Branchensystem — Lese- und Schreiboperationen für die häufigsten Kundeninteraktionen, versioniert und vollständig dokumentiert.
Discovery-Dokumente — agents.json nach aktuellem Standard, damit jeder KI-Assistent Ihre Plattform sofort erkennt, versteht und korrekt nutzt.
Interner KI-Assistent für First-Level-Support — Optional: Anbindung eines internen Assistenten an Ihre API-Schicht, damit Servicecenter-Mitarbeitende kontextuale Kundeninformationen in Sekunden abrufen können — ohne zwischen vier Systemen zu wechseln.
Die bestehende Portal-Oberfläche bleibt unverändert. Kunden sehen keinen Unterschied — bis sie merken, dass ihr Assistent auf einmal funktioniert.
Fazit
Der Stadtwerk-Kundenservice steht vor einer Entlastungsaufgabe, nicht vor einer Digitalisierungsromantik. Routineanfragen blockieren Kapazitäten, die für echte Beratung gebraucht werden. AI-Readiness löst dieses Problem nicht aus dem Nichts — aber sie legt die technische Grundlage dafür, dass Automatisierung dort angreift, wo der Hebel am größten ist.
Wer heute strukturierte Daten, OAuth-Authentifizierung und versionierte APIs aufbaut, senkt kurzfristig das Routineaufkommen und investiert langfristig in die einzige Infrastruktur, die mit wachsendem KI-Agenten-Traffic skaliert.
Wenn Sie analysieren möchten, wo Ihre aktuelle Systemlandschaft steht und welche Schritte für Ihr Stadtwerk zuerst sinnvoll sind, sprechen Sie mich an. API-Strategie, Integration auf Branchensystemen, OAuth-Infrastruktur — ich berate konkret, nicht pauschal.
