Digitale Teilhabe 65 plus

Beobachtungen, Gedanken, Fragen und Tipps
zur Überwindung der Alterslücke bei der Nutzung von digitalen Medien

Portrait: Herbert Kubicek
Prof. Dr. Herbert Kubicek
Jahrgang 1946
Über mich
08.08.2026

Zum Stand des telefonischen OZG Support über 115 - Keine Eile beim Bürokratieaufbau und föderale Doppelarbeiten

Die Nutzung der Onlinedienste im eGovernment ist von Anfang an weit hinter den Erwartungen zurückgeblieben. Ich habe mehrfach darauf hingewiesen, dass dies auch an fehlendem Support liegt. Im Rahmen der Umsetzung des Online-Zugangs-Gesetzes (OZG) hat das auch der IT-Planungsrat erkannt und kam 2021 auf die Idee, dass ein solcher Support über die bundeseinheitliche Behördenrufnummer 115 erbracht werden könnte, die man heute schon bei Fragen zur analogen Nutzung von Verwaltungsdiensten anrufen kann. Dieser Service könnte zu einem Support unabhängig vom Zugangskanal, also auch bei der Online-Nutzung ausgebaut werden. Daher wurde der damalige Betreiber der 115, die Geschäfts- und Koordinierungsstelle 115 , gebeten, ein Konzept für ein solches Mehrkanalsystem zu erarbeiten. In der 34. Sitzung am 24.3.2021 wurde ein entsprechendes Eckpunktepapier gebilligt und die Geschäfts- und Koordinierungsstelle 115 um Umsetzung gebeten. Empfohlen wurde die Erweiterung der Lotsenfunktion als erste Anlaufstelle für alle Verwaltungsleistungen, auch die online angebotenen, und ein erweiterter Zugang neben den bisherigen persönlichen Auskünften durch ein Sprachdialogsystem (SDS) zur Qualifizierung und teilautomatisierten Beantwortung von Anrufen und ein Chatbot (regelbasiert bzw. intelligent). Als Ergebnis einer umfassenden Prüfung "wurden SDS und Chatbot als die Technologien identifiziert, die kurzfristig ein hohes Wirkungspotential, insbesondere auch bei der Bewältigung der pandemiebedingten Herausforderungen, für die 115 haben und mit vertretbarem Aufwand umsetzbar sind."

Ein verbindlicher Auftrag wurde erst nach dem Ende der Pandemie erteilt, der Chatbot gerade vor einem Monat nach längerer Erprobung für den Regelbetrieb den Mitgliedskommunen angeboten und für den First-Level Support hat der IT-Planungsrat in seiner 50. Sitzung am 17.6.2026 die inzwischen für 115 zuständige FITKO beauftragt, "bis zu seiner 52. Sitzung einen Umsetzungsplan inklusive Betriebskonzept für die flächendeckende Vollbeauskunftung der gemäß Nr. 1 nominierten Verwaltungsverfahren mit der Behördenrufnummer 115 zu erarbeiten und für eine Bewertung in den Portfolioprozess mit einzubringen." Einen Termin für die 52. Sitzung gibt es noch nicht. Sie wird für Frühjahr 2027 erwartet Dann wird aber erst über einen weiteren Umsetzungsplan entschieden - nach einer ganzen Reihe von Planungen und insgesamt mehr als 20 Beschlüssen zu diesem Thema in den vergangenen fünf Jahren.

Wie kann das sein? Zumal mit dem Online-Zugangs-Änderungsgesetz (OZGÄndG) im Juli 2024 in § 3a Bund und Länder zu einer "Beratung im Portalverbund" verpflichtet wurden:"Bund und Länder stellen für Nutzer im Portalverbund eine allgemeine fachunabhängige, barrierearme Beratung für die Abwicklung ihrer über Verwaltungsportale angebotenen, elektronischen Verwaltungsleistungen bereit und bestimmen dafür öffentliche Stellen. Diese öffentlichen Stellen unterstützen Nutzer bei der Abwicklung von Verwaltungsleistungen im Portalverbund." In der Gesetzesbegründung wird 115 als eine solche öffentliche Stelle genannt. Von dem für die OZG-Umsetzung zuständigen BMDS ist bisher nichts zur Umsetzung dieser gesetzlichen Verpflichtung zu finden.

Beginnen wir mit der halb guten Nachricht, dass der damals mit einem kurzfristig hohen Wirkungspotential bewertete Chatbot von den ersten Mitgliedskommunen nach mehr als fünf Jahren nun angeboten wird.

Support durch ChatBots

Der im März 2021 beauftragte Chatbot wurde in mehreren Stufen erprobt und gerade vor vier Wochen am 3. Juli in den Regelbetrieb überführt:

Zeitpunkt Entwicklung bei der 115
2021 Im Eckpunktepapier wird ein Chatbot als vergleichsweise schnell bzw. mit geringem Aufwand realisierbarer zusätzlicher Zugangskanal vorgeschlagen.
Nov. 2023 Die 115 startet erstmals einen eigenen regelbasierten Service-Chatbot in zehn Pilotkommunen. Grundlage ist die 115-Wissensdatenbank.
2024 Der Pilot läuft unter anderem in Frankfurt und im Bodenseekreis. Die FITKO koordiniert Entwicklung und Test zentral.
2025 Die regelbasierte Lösung wird durch einen KI-basierten 115-Chatbot weiterentwickelt. Im November 2025 startet ein neuer Pilot unter anderem in Berlin, Frankfurt, Aachen und Essen.
3. Juli 2026 Start des Regelbetriebs. Der KI-Chatbot wird allen interessierten Kommunen des 115-Verbunds kostenlos angeboten.

Details kann man der Pressemitteilung zum Regelbetrieb entnehmen. Daraus wird auch ersichtlich, dass dieser KI-basierte Chatbot keine Alternative zum telefonischen Support bei Problemen mit der Nutzung von Onlinediensten ist. Er ist die digitale Alternative und Ergänzung zu den telefonischen Auskunftsdiensten von 115, beantwortet also Fragen zur Zuständigkeit für Verwaltungsleistungen, Öffnungszeiten, erforderlichen Unterlagen und verbindet ggfs. zur Terminvereinbarung - und nun auch zu angebotenen Onlinediensten, URLs, Zugangsmöglichkeiten u.a.m. Auf der Serviceseite von 115 wird deutlich, das es sich bei dem Chatbot und dem Supportangebot um zwei verschiedene Produkte handelt. Der Chatbot arbeitet auf der Basis der Wissensdatenbank von 115, die durch lokale Angaben der jeweiligen Kommune ergänzt werden kann. Ein Support bei der Nutzung von Onlinediensten wird hingegen als individuelle Entwicklung für Kommunen und Landesverwaltungen angeboten.

Ich habe den 115 Chatbot für Berlin kurz getestet und ihn um Hilfe bei einem Login Problem mit meinem ePA auf dem Bundesportal gebeten. Die Antwort war, das könnte an der PIN für den ePA liegen und ich bekam Angaben, wo ich eine neue PIN bei einem Bezirksamt anfordern kann. Das System arbeitet eben vor allem mit Zuständigkeiten. Aber probiert es mal mit anderen Nutzungsproblemen aus.

Fazit mit Bezug auf das Eckpunktepapier von 2021: die schneller umsetzbare Option eines Chatbots hat fünf Jahre gedauert, ist dem ersten Anschein nach ein guter Auskunftsdienst, aber kein Supportdienst.

Was ist bisher beim telefonischen Support erreicht worden?

First Level Support - Viele Beschlüsse führen nicht zum Ziel

Seit dem Eckpunktepapier vom März 2021 hat sich der IT-Planungsrat rund 20 Mal mit einem First-Level-Support für die Onlinedienste im Rahmen des OZG beschäftigt. In der Anlage ist eine weitgehend vollständige Liste mit den Beschlüssen und Links zu den entsprechenden Dokumenten zu finden, die von Angaben auf der Homepage des IT-Planungsrats kopiert wurde. Hier die wichtigsten Etappen:

Ein falscher Ansatz im Wissensmanagement: deduktiv statt induktiv


Ich bin sicher, dass mit den vorgesehenen organisatorischen Veränderungen auch Ende 2027 keine wirksame Hilfe bei Nutzungsproblemen mit den EfA- oder Portaldiensten geleistet werden kann. Das liegt nach meiner Überzeugung daran, dass von Anfang an ein völlig falscher Ansatz im Wissensmanagement verfolgt worden ist und fortgesetzt werden soll – ein Ansatz, der in der Tradition der Beauskunftung durch die 115 gefangen ist: Mehrfach wird als Ziel angegeben, dass die zu entwickelnde Wissensdatenbank die Agents in den Servicecentern, die keine eigenen Erfahrungen mit den für den Support bestimmten Diensten und ihrer Nutzung haben, diese in die Lage versetzen soll, bei den unterschiedlichsten Problemen unmittelbar zu helfen. Dabei geht es um Nutzerinnen und Nutzer mit sehr unterschiedlichen digitalen Kompetenzen, die an ganz verschiedenen Stellen eines Online-Antragsprozesses auf Probleme stoßen können. Der Support soll ihnen so helfen, dass sie ihr jeweiliges Ziel erreichen. Und dieses Wissen sollen Entwickler bei der 115 bereitstellen, die selbst die betroffenen Online-Verfahren nicht kennen und auch noch nie in einem entsprechenden Support gearbeitet haben.

Soweit erkennbar, ist nie systematisch versucht worden, die Nutzendenperspektive einzunehmen und zu fragen: Mit welchen konkreten Problemen werden Nutzerinnen und Nutzer bei der 115 anrufen? Stattdessen geht man offenbar davon aus, dass aus einer möglichst vollständigen Beschreibung der fachlichen Leistung und ihrer Voraussetzungen, der organisatorischen Zuständigkeiten und der technischen Abläufe die passenden Antworten abgeleitet werden können – und zwar, wie gesagt, von Agents ohne eigene Kenntnisse der jeweiligen Anwendung. Ein solcher deduktiver Ansatz kann nicht funktionieren. Erst recht nicht, wenn, wie in einem Dokument beschrieben, für die technischen Informationen die erforderlichen Inhalte nicht näher spezifiziert und weder Quellen noch verantwortliche Redaktionen bestimmt sind.

Für die klassische Beauskunftung – etwa bei den Fragen, welche Behörde für mein Anliegen zuständig ist und welche Unterlagen ich für einen Antrag benötige – reichen fachliche und organisatorische Informationen weitgehend aus. Hier kann auch ein Chatbot funktionieren. Aber um Nutzungsprobleme zu antizipieren, reicht es nicht aus, den Soll-Ablauf eines Verfahrens zu erfassen. Man kann auf diese Weise zwar noch Fälle klären, in denen eine Online-Beantragung beispielsweise daran scheitert, dass noch nicht alle Personenstandsregister an die digitale Beantragung von Elterngeld angeschlossen sind, deshalb in einem bestimmten Fall keine Registerauskunft möglich ist und der Antrag nicht abgeschlossen werden kann. Aber aus einer noch so vollständigen und detaillierten Beschreibung eines Antragsprozesses kann man nicht ableiten, was Nutzende bei einzelnen Datenfeldern oder Navigationsbuttons falsch verstehen. Ebenso wenig lässt sich daraus ableiten, warum etwas mit einem bestimmten Gerät, Betriebssystem und Browser funktioniert und mit einem anderen nicht.

Eine Supportdatenbank soll eine problembezogene Lösungsdatenbank sein

Eine Supportdatenbank muss in erster Linie Lösungen für Nutzungsprobleme beinhalten. Ihre Entwickler benötigen dazu gute Kenntnisse der Anwendungen, bei deren Nutzung Hilfe ermöglicht werden soll. Fachkundige Agents müssen anschließend die Anfragen, die aufgetretenen Probleme und die gefundenen Lösungen dokumentieren. Sie müssen Tickets schreiben – aber nicht primär, um diese an andere Stellen weiterzugeben, sondern damit anschließend auf die dokumentierten Erfahrungen bei ähnlichen Anfragen zurückgegriffen werden kann und das System so lernt.

Ich habe schon in meinem ersten Beitrag zum telefonischen OZG-Support durch 115 gefragt, wo dieses Problemwissen herkommen soll, das bei 115 nicht vorhanden ist und bisher nicht erforderlich war. 115 liefert allgemeine Auskünfte, aber keine individuelle Hilfe beim Ausfüllen eines Formulars. Bei meiner Begleitung von Projekten im Rahmen der Bremer Digitalambulanzen mussten die Helfenden Kurzprotokolle über die aufgetretenen Probleme ausfüllen, die ich anschließend in der Auswertung kategorisiert habe. So hätten bei einer Fortsetzung FAQs erstellt werden können. Dasselbe gilt für die Begleitung der Digital Guides der Unterstützung bei der BundID und der AusweisApp, wie in dem entsprechenden Bericht nachzulesen ist. Ich hatte sogar vorgeschlagen, Digitallotsen, wie es sie beispielsweise in Hamburg dauerhaft gibt, gezielt als Quelle für die Generierung von Problemwissen einzusetzen. Denn zu ihnen kommen Bürgerinnen und Bürger, die ein konkretes Problem haben und für dieses Problem eine Lösung suchen. Bisher wird aus den höchst relevanten Erfahrungen der Digitallotsen mit EfA-Diensten wie der Ummeldung oder der Kfz-Anmeldung jedoch kein systematisches Wissen gewonnen, das mit anderen Supportstellen geteilt werden könnte.

Mich wundert auch, dass in den Dokumenten der FITKO zum Wissensmanagement offenbar nicht gefragt wird, wie die vielen bereits vorhandenen internen Supportdatenbanken und Ticketsysteme in den Verwaltungen entstanden sind und wie deren Wissensbestände ursprünglich aufgebaut wurden.

Wie kommt das Wissen in die Datenbank?

Jeder Helpdesk im internen IT-Support einer Verwaltung steht vor derselben Frage: Wie wird eine Lösungsdatenbank zunächst gefüllt, bevor sie anschließend auf der Grundlage der eingehenden Tickets erweitert und verbessert werden kann?

Empfohlen wird beispielsweise, in Benutzerhandbüchern nach Hinweisen auf typische Fehler zu suchen, Administratoren und erfahrene Supportkräfte zu befragen, bisherige Anfragen per E-Mail auszuwerten sowie vorhandene Fehlerprotokolle, FAQs und Supportdokumentationen einzubeziehen. Damit wird ein erster Wissensbestand geschaffen. Anschließend wird dieser durch die im laufenden Betrieb tatsächlich auftretenden Probleme und die dafür gefundenen Lösungen ergänzt und korrigiert.

Das ist ein induktiver, lernender Ansatz: Ausgangspunkt sind nicht allein Beschreibungen wie ein Verfahren funktionieren soll, sondern Feststellungen, wo und warum Nutzerinnen und Nutzer in der Praxis in einem Prozess tatsächlich scheitern.

Die Trennung von First- und Second-Level-Support als Hindernis

Die bei der 115 getroffene Unterscheidung zwischen First- und Second-Level-Support erschwert nach meiner Einschätzung ein solches induktives, lernendes Vorgehen. Ich halte die Trennung zwischen einem allgemeinen First-Level-Support und einem fach- bzw. anwendungsbezogenen Second-Level-Support für ein entscheidendes Hindernis auf dem Weg zu einem nutzungsbezogenen Supportwissen. Denn ich habe als Nutzer keinen „allgemeinen“ Supportbedarf. Mein Supportbedarf entsteht immer im Zusammenhang mit der Nutzung eines bestimmten Dienstes oder einer bestimmten Anwendung. Und dann möchte ich möglichst unmittelbar Hilfe erhalten – am besten von jemandem, der die jeweilige Anwendung kennt und weiß, wovon ich rede, wenn ich schildere, an welcher Stelle ich nicht hinein- oder weiterkomme.

Ein Beispiel: Ich wollte mit meinen BahnBonus-Punkten ein Upgrade in die erste Klasse für mich und für meine Frau buchen. Für mich war das kein Problem. Bei dem Buchungsversuch für meine Frau erschien jedoch der Button nicht, der entsprechend der Verfahrensbeschreibung hätte erscheinen sollen. Ich habe den Support angerufen. Der Agent wollte mir zunächst nicht glauben, durchlief dann aber gemeinsam mit mir den gesamten Buchungsprozess und hat dann festgestellt , dass der betreffende Button auch bei ihm nicht erscheint und offenbar im Zuge eines Updates verschwunden war. Das hat mir im konkreten Fall zwar nicht zum gewünschten Upgrade verholfen, aber es war ein angemessener Support: Der Mitarbeiter kannte den Vorgang, konnte mein Problem nachvollziehen, reproduzierte es selbst und stellte fest, dass nicht der Nutzer, sondern die Anwendung das Problem verursachte.

Demgegenüber konnte mir bei der Postbank niemand erklären, warum ich mich auf einem iMac mit macOS Sierra 10.12.6 nicht mehr einloggen kann, auf einem iMac mit macOS Tahoe hingegen schon. Sierra stammt aus dem Jahr 2016. Ich nutze es auf einem älteren iMac weiterhin, weil daran ein A4-Scanner angeschlossen ist, für dessen Treiber keine Updates mehr angeboten werden.

Solche Fälle zeigen die Grenzen eines Wissensmanagement, das primär von allgemeinen Verfahrensbeschreibungen ausgeht. Die Information, dass ein bestimmter Dienst mit einer bestimmten Kombination aus Gerät, Betriebssystem und Browser nicht mehr funktioniert, entsteht erst durch konkrete Nutzungserfahrungen. Sie muss im Support erkannt, dokumentiert, geprüft und anschließend anderen Agents zur Verfügung gestellt werden.

Ein wirksames Organisationsmodell: Jeder für sich

Der aktuelle Reorganisationsvorschlag für die Datenbereitstellung läuft nach meiner Wahrnehmung auf eine stärkere Zentralisierung bei FITKO heraus. Ich denke, das Gegenteil ist erforderlich. Es müssen nicht unterschiedliche Informationen aus verschiedenen Quellen abgestimmt und dann zentral bereitgestellt und gepflegt werden. Nicht einer für alle sondern jeder Betreiber für sich: Jede Stelle, die einen OZG-Dienst betreibt, soll selbst auch den Support dazu leisten. Dort ist das Verfahren bekannt und da auch Systemfehler und aktuelle Ausfälle (ad hoc Wissen). Man braucht dann dafür kein Meldeverfahren mit einem Datenaustauschformat und keine Unterscheidung zwischen First - und Second-Level Support. Der Weg dahin muss auch nicht in erster Linie über 115 führen. Sondern auf jeder einzelnen Seite eines Onlineverfahrens sollte ein Hilfebutton sein, der mich zunächst zu einem Chatbot führt und wenn ich nicht zufrieden bin mit einem Agent verbindet, der diesen Prozess kennt und sieht auf welcher Seite ich ein Problem habe. - Einfacher geht es nicht. Aber warum sollte FITKO das vorschlagen?

Umsetzung § 3a OZGÄndG

Spätestens mit der zitierten Verpflichtung von Bund und Ländern im Juli 2024 Nutzerinnen und Nutzer bei der Abwicklung von Verwaltungsleistungen zu unterstützen, hätten sich die Ländervertreter im IT -Planungsrat fragen sollen, ob der da schon sehr holprige Weg über 115 und FITKO für die Umsetzung dieser Verpflichtung der richtige ist. In der Gesetzesbegründung war 115 nur als eine Möglichkeit erwähnt worden. Und 115 muss nicht unbedingt der von FITKO noch in der Entwicklung befindliche First-Level Support sein.

Die gesetzliche Vorgabe in § 3a ist nicht so zu verstehen, dass Bund und Länder gemeinsam dieselben öffentlichen Stellen verpflichten sollen, sondern jedes Land steht selbst in der Pflicht, ebenso wie der Bund. Daher haben sich schon einige Länder im Rahmen des EfA-Verbundes entschieden, wer den Support für die von ihnen entwickelten Dienste übernehmen soll und die Antwort in Brandenburg, Bremen, Sachsen-Anhalt und Thüringen ist: wir nicht, sondern das mitnutzende Land. Da lag ich mit meinem Hinweis auf die den Dienst betreibenden Stellen nicht falsch.

Vorbild Brandenburg

Soweit erkennbar ist Brandenburg bisher das erste Bundesland, das nicht auf den von FITKO in Aussicht gestellten First-Level Support warten will, sondern der gesetzlichen Verpflichtung mit einem eigenen Projekt bereits ein Stück weit nachgekommen ist und eine Vollbeauskunftung über ein eigenes Angebot über 115 entwickelt hat und nun auch laut einer Pressemeldung vom 26. 5.2026 einen First Level Support für die Wohnsitzanmeldung anbietet. Das ist immerhin ein allererster Schritt, zwei Jahre nach Verabschiedung des OZGÄndG und erst für einen von mehr als 20 priorisierten OZG-Dienst.

Und wie kommt der Bund seiner Verpflichtung nach?

Zuständig für die Umsetzung der Verpflichtung aus § 3a OZGÄndsG auf Bundesebene ist das Bundesministerium für Digitales und Staatsmodernisierung (BMDS). Auf der Website des Ministeriums gibt es keine Treffer für eine Suche nach "§3a OZGÄndG" oder "Support". Für den Suchbegriff "First Level Support findet man eine Seite Bürger-und unternehmenszentrierter Staat mit der Ankündigung eines gebündelten First_Level_Supports für Verwaltungsleistungen des Bundes und einem Foto mit der Unterschrift "Beteiligungsprozess Service der ankommt". Mehr nicht. Chat GPT findet jedoch eine Stelle in der Modernisierungsagenda Bund 2025 vom November 2025. Auf Seite 28 im Abschnitt "Bürger-und Unternehmenszentrierter Service" steht zur Maßnahme "Leicht erreichbarer Zugang zu Beratungs- und Unterstützungsangeboten":

Nicht zu glauben!

Der Entwickler und Betreiber der AusweisApp , die Fa. Governikus, bietet seit 2014 im Auftrag des BSI i eine Hotline unter der Rufnummer 0421 204 95 995 Montag bis Freitag von 9 bis 17 Uhr. Sie unterstützt ausdrücklich bei technischen Problemen sowie bei Einrichtung und Nutzung der AusweisApp; zusätzlich gibt es E-Mail- und Fehlermeldungs-Support. Darauf wird auf der Seite zur AusweisApp hingewiesen. Und jetzt braucht das BMDS noch einmal 18 Monate. Für was genau? Ich bin sprachlos.

Weitere Infos: