Servicestandard-Bericht

Selbstaudit des Teams über die Anwendung des Servicestandards, herausgegeben vom Bundesministerium des Innern und für Heimat

Der Online-Dienst „Grundsteuererklärung für Privateigentum“ erfüllt in 10 von 19 Punkten den Servicestandard. Drei Punkte wurden teilweise erfüllt, während fünf weitere nicht zutreffend waren und nur ein Punkt nicht erfüllt werden konnte.

Status: erfüllt

Zusammenfassung:

• Regelmäßige Usability-Tests und Interviews mit Nutzer:innen
• Nutzung des User-Supports als weitere Quelle für Iterationen

Begründung:
Qualitative Interviews mit Nutzer:innen halfen zu Beginn des Projekts mehr über ihre bisherigen Erfahrungen zu lernen, ihre Bedürfnisse zu verstehen und sich in ihre Herausforderungen einzufühlen. Mithilfe konkreter Fragen, eingewoben in eine offene Gesprächssituation, erhielt das Team einen Einblick in verschiedene Abläufe und Einstellungen gegenüber relevanter Themen. Dazu zählten etwa Steuererklärungen, Eigentumsfragen, Dokumente, die Kommunikation mit Finanzbehörden und die Beschaffung allgemeiner Informationen.

Über den gesamten Verlauf des Projekts wurden in regelmäßigen Abständen Usability-Tests durchgeführt, die dazu dienten, den Prototypen, neue Features oder Bereiche der Website auf Verständnis und Nutzbarkeit zu prüfen. Die Ergebnisse wurden in einer Synthese ausgewertet und anschließend zur Iteration des Dienstes genutzt. Der Grad der Iteration entschied darüber, ob erneut getestet oder Änderungen direkt im Code umgesetzt wurden. Unsere Projektpartner:innen aus dem BMF nahmen an fast jedem Durchlauf teil und hatten eine aktive Rolle inne.

In der 14-monatigen Laufzeit des Projekts wurden insgesamt 25 Usability-Tests durchgeführt.

• Die Tests fanden remote über Google Meet statt.
• Die Rekrutierung erfolgte über Freundes- und Bekanntenkreise, eine Agentur und Veranstaltungen.
• Das dafür notwendige Material bestand aus einem Laptop, Unterlagen, Behördenschreiben sowie einem Klick-Dummy oder einer Testumgebung innerhalb der Website.
• Pro Session nahm eine Person als Nutzer:in teil.
• Zusätzlich gab es ein:e Moderator:in, ein:e Notiznehmer:in und ein:e stille:r Zuhörer:in, die aus dem Entwicklungsteam kamen.
• Die Dauer der Tests betrug zwischen 30 – 60 Minuten.

Status: teilweise erfüllt

Zusammenfassung:

• Mehrere Optionen zum Registrieren und Anmelden anbieten
• Identifikationsoptionen zugänglich machen

Begründung:
Eine Herausforderung bestand darin, die Komplexität von 16 Seiten Papierformular plus 26 Seiten Anleitung zu reduzieren und auf den möglichen Leistungs- und Funktionsumfang des Dienstes herunterzubrechen und anzupassen. Der Fokus lag auf der Übersetzung eines analogen Formulars in eine digitale Version, die dynamisch, in Abhängigkeit der Eingaben der Nutzer:innen, eine vollständige Steuererklärung auswirft. Die Formularseiten beruhten auf logischen Abhängigkeiten der getätigten Eingaben. Nutzende mussten also nicht selbst herausfinden, ob die nächste Angabe relevant für den ermittelten Sachverhalt ist. Zum Beispiel wurde die nachfolgende Kategorie „Gebäude“ gar nicht mehr angezeigt, wenn zuvor das Grundstück als „unbebaut“ angegeben wurde. Oder – je nach Auswahl des Bundeslandes – wurde das entsprechende Geodatenportal zum Grundstück verlinkt. Viele Eingabefelder wurden zudem mit Plausibilitätsprüfungen versehen. So wurde sichergestellt, dass es sich bei der Eingabe beispielsweise nur um eine Steueridentifikationsnummer oder ein Aktenzeichen handeln konnte.

Zusatzinformationen:
Die aufgrund des Fokusses auf Datensparsamkeit gewählte Zugangsform zum Nutzerkonto – Magic Links – stellte für eine hohe Anzahl der Nutzer:innen eine Hürde dar und führte für das Team zu einem großen Erklärungsaufwand. Die Magic Links wurden per E-Mail versandt, was teilweise mit technischen Zustellproblemen verbunden war. Hinzu kommt, dass die Verwendung von Magic Links insgesamt in der Breite der Nutzerschaft noch keine Anwendung gefunden hatte zuvor. Mehr Details werden in einem Blogartikel beschrieben, den das Team im August 2022 veröffentlichte.

Laut § 82d ist das Team als Auftragnehmer verpflichtet, sich Gewissheit über die Person und ihre Anschrift zu verschaffen, bevor Daten übermittelt werden. Siehe hier den dazugehörigen Gesetzestext. Eine Möglichkeit der Identifikation ist der Freischaltcode. Der inhaltliche Aufbau dieses Briefes wurde jedoch von einigen Nutzer:innen nicht verstanden. Den Brief erhielt auch nur, wer kein Konto bei ELSTER besitzt und eine aktuelle Meldeadresse hinterlegt hatte. Der Zustellungszeitraum des Briefes betrug zwischen drei Tagen und drei Wochen.

Status: teilweise erfüllt

Zusammenfassung:

• Einfache und bürgernahe Sprache als zentrale Motivation
• Nutzung inklusiver Sprache
• Audit für Barrierefreiheit mit externer Agentur
• Kein offizieller Test gemäß BITV 2.0
• Erklärung zur Barrierefreiheit auf der Website
• Kein Angebot der Seite in Leichter Sprache

Begründung:
Da es sich bei „Grundsteuererklärung für Privateigentum“ um einen Dienst im Kontext Steuern handelte, hat das Team große Sorgfalt auf bürgernahe Sprache gelegt. Fachbegriffe wurden übersetzt oder erklärt. Wo dies nicht möglich war, wurden Fachbegriffe in Hintergrundinformationen eingebettet. Ein Beispiel dafür ist:

„Sogenanntes Miteigentum, kann zum Beispiel an einem Garagengrundstück, einem Spielplatz, einem Gemeinschaftsgarten oder einem Privatweg bestehen. Schauen Sie dafür in Ihrem Grundbuchauszug auf der Seite ‚Bestandsverzeichnis‘ oder im Kaufvertrag nach. In der Regel liegt für den Miteigentumsanteil ein eigener Grundbuchauszug vor.“

Das Team war von Anfang an für Barrierefreiheit sensibilisiert. Dies wurde in Layout und Code berücksichtigt. Beispielsweise im Aufbau und der Funktionsweise von Komponenten. Kurz vor dem Launch der Software fand eine Expertenprüfung und -beratung durch die Non-Profit-Organisation „Sozialhelden“ statt. Im Anschluss wurden die beanstandeten Punkte umgesetzt. Dazu gehörten unter anderem die Verbesserung des Tab-Fokus bei der Tastatursteuerung, Kontrasterhöhung bei Menüpunkten und die Korrektur fehlerhafter ARIA-Elemente.

Zusatzinformationen:
Die Verwendung des Doppelpunkts machte die Webseite im Rahmen der geschlechtersensiblen Sprache inklusiver. Das Gendern mit Sonderzeichen bringt jedoch Schwierigkeiten mit sich für Menschen, die auf Einfache oder Leichte Sprache angewiesen sind. Das Team musste lernen, dass es den Königsweg für die Einbindung von barrierefreiem Gendern (noch) nicht gibt. Einen Artikel über die Verwendung des Gender-Doppelpunkts für Blinde möchten wir empfehlen. Ein offizieller Test gemäß BITV 2.0 wurde nicht durchgeführt.

Status: nicht zutreffend

Begründung:
Es liegen der Finanzverwaltung nicht alle erforderlichen Daten über die Grundstücke und die darauf stehenden Gebäude in elektronisch verarbeitbarer Form vor. Deswegen kann die Finanzverwaltung zum jetzigen Zeitpunkt noch kein vollständig digitalisiertes Verwaltungsverfahren anbieten. Diese Daten müssen daher bei den Eigentümer:innen abgefragt werden.

Zusatzinformationen:
Mit der Hauptfeststellung – der Feststellung neuer Grundsteuerwerte für sämtlichen Grundbesitz – im Jahr 2022 und der damit verbundenen Abgabe der Grundsteuererklärung wurde eine noch bessere Grundlage für ein vollständig digitalisiertes Verfahren geschaffen. Der nächste Zeitpunkt der Hauptfeststellung ist turnusmäßig in sieben Jahren im Jahr 2029. Im Sinne der Eigentümer:innen wäre es empfehlenswert, 2029 auf eine weitere durch die Eigentümer:innen selbst auszufüllende Erklärung zu verzichten. Stattdessen sollte proaktiv vonseiten der Finanzverwaltung eine Erklärung verschickt werden, die korrigiert werden kann, falls sich etwas am Grundbesitz in den vergangenen sieben Jahren geändert hat.

Status: erfüllt

Zusammenfassung:

• Datensparsame Entwicklung hatte oberste Priorität
• Überwiegend: Zwischenspeicherung, keine dauerhafte Speicherung von eingegebenen Daten
• Geringe Speicherzeit für notwendige personenbezogene Daten
• Regelung des Datenschutzes in einem Datenschutzkonzept mit Hilfe eines Datenschutzbeauftragten
• Beratung durch den Datenschutzbeauftragten des BMF

Begründung:
Um allen Anforderungen der Datenschutz-Grundverordnung (DSGVO) und des Bundesdatenschutzgesetzes (BDSG) gerecht zu werden, hat sich das Team explizit dafür entschieden, so datensparsam wie möglich zu arbeiten und besonders umsichtig mit personenbezogenen Daten umzugehen. Als Prämisse galt: „So viel wie nötig, so wenig wie möglich“. Nutzende haben sich im Dienst zwar registriert und identifiziert und damit ihre Steuererklärung absenden können, die Daten wurden jedoch nicht dauerhaft, sondern lediglich temporär gespeichert. Die eingegebenen Formulardaten wurden im Cookie des Browsers für maximal 13 Wochen bis zum Absenden der Steuererklärung zwischengespeichert. Die Daten zur Anmeldung (Steueridentifikationsnummer, Geburtsdatum und Informationen zum Freischaltcode) wurden temporär in einer Datenbank gespeichert und sieben Monate nach der letzten Benutzeraktion (Registrierung, Freischaltcode beantragt, Identifikation, Erklärung abgeschickt) gelöscht. Hat jemand erfolgreich seine Steuererklärung abgeschickt, wurden die übermittelten Daten nach 24 Stunden gelöscht. Notwendige Informationen für die Nachweispflichten nach §87d 2 AO und die Bestätigung der Vereinbarungen wie der Nutzungsbedingungen wurden in einer extra Tabelle der Datenbank für den rechtlich notwendigen Zeitraum gespeichert. Diese Daten wurden nur verschlüsselt gespeichert, sodass nur die datenschutzrechtliche Person Zugang zu diesen Daten hat.

Die Rahmenbedingungen für diesen Umgang mit den Daten der Nutzenden wurden in Zusammenarbeit mit dem Datenschutzbeauftragten des DigitalService in einem Datenschutzkonzept festgehalten. Auch der Datenschutzbeauftragte des BMF wurde zu Rate gezogen.

Zusatzinformationen:
Datensparsamkeit, und damit verbundene Speicherung der Daten im Cookie des Browsers der Nutzerin oder des Nutzers, führte zu Schwierigkeiten in der Usability: Die Erklärung wurde zum Beispiel in einem bevorzugten Browser gestartet, der Magic Link aus der E-Mail öffnete aber die Software automatisch im Standardbrowser. Nutzerinnen und Nutzer fanden das Formular leer und nahmen an, ihre Daten seien verloren gegangen.

Status: erfüllt

Zusammenfassung:

• Nutzer:innen konnten sich durch Eingrenzung der Sachverhalte klar zuordnen
• Die Abgabe der Hauptfeststellungserklärung (Grundsteuererklärung) wurde von Anfang an als digitaler Service gedacht
• Abhängigkeiten in die Formularstruktur eingebaut
• Steuerliche Fachbegriffe bürgernah formuliert
• Aufbau eines Support-Teams für Rückfragen und bei Problemen
• Positive mediale Berichterstattung und Vorstellung des Dienstes bei Infoveranstaltungen

Begründung:
Der Online-Dienst „Grundsteuererklärung für Privateigentum“ war ausschließlich für Eigentümer:innen mit einfachen Sachverhalten vorgesehen. Es konnten Einfamilienhäuser, Zweifamilienhäuser, Eigentumswohnungen und unbebaute Grundstücke erklärt werden. Ob dies auf das jeweilige Grundstück zutraf, haben Nutzerinnen über einen Vorab-Check geprüft. Der Online-Dienst wurde stets als eine vereinfachte Alternative zu anderen Angeboten beworben und war über Verlinkungen auf einigen Portalen der Landesfinanzverwaltungen, der Website des BMF sowie in zahlreichen Medienartikeln zu finden.

Die Formularseiten basierten auf dem „One-Thing-Per-Page“ Prinzip. Bedeutet, Inhalte (Eingabefelder) wurden kontextuell gebündelt und gegebenenfalls auf wenige Felder heruntergebrochen. Als Referenz nutzte das Team die Erkenntnisse des britischen Government Digital Service (GDS) über die Neustrukturierung von Formularen. Die Formularseiten standen in logischer Abhängigkeit zueinander. Das bedeutet: Auf Basis ihrer Eingaben, bekamen Nutzerinnen und Nutzer die nächst logische Formularseite angezeigt; für den Sachverhalt irrelevantes, wurde gar nicht mehr angeboten.

Hilfe fanden Nutzerinnen und Nutzer in ausklappbaren Komponenten direkt an den Eingabefeldern. Darin fanden sich zum Beispiel schematische Abbildungen von Grundbuchauszügen, in denen die gesuchten Informationen für den Übertrag markiert wurden.

Außerdem setzte das Team eine ständig erweiterte, umfangreiche Artikelsammlung „Hilfebereich“ auf, um Fragen und Sachverhalte sowie die Nutzung der Software tiefer behandeln zu können.

Status: nicht zutreffend

Begründung:
Die Anforderung „Rechtliche Änderungsbedarfe“ war im Fall von „Grundsteuererklärung für Privateigentum“ nicht zutreffend, da bereits eine Self-Service-Schnittstelle vorhanden und im Gesetz verankert war (und nach wie vor ist). Auch abseits davon gab es keine rechtlichen Hindernisse.

Zusatzinformationen:
Künftig würde ein Gesetz zur Reform des Grundsteuer- und Bewertungsrechts vermutlich im Rahmen des Digitalcheck vorab auf Digitaltauglichkeit geprüft werden.

Status: erfüllt

Zusammenfassung:

• Anwendung und Adaption agiler Methoden, zum Beispiel Scrum-Framework, Kanban, Dual Track und iterative Produktentwicklung
• Anwendung von Design-Thinking-Methoden
• Interdisziplinäres Team, das in Projekt- und Produktentscheidungen einbezogen wurde
• Einbindung der Projektpartner:innen aus dem BMF: Domain-Deep-Dive und Scrum-Treffen
• Roll-outs mit Fixes und Verbesserungen basierend auf Nutzerfeedback teils wöchentlich

Begründung:
Das Team arbeitete iterativ. Das heißt: Das Projekt war nicht von Anfang bis Ende durchgeplant und unterlag keinem vordefinierten Anforderungskatalog. Aufgaben wurden auf Basis der Bedürfnisse von Nutzer:innen priorisiert und, wenn nötig, im Umfang heruntergebrochen. Für die Entwicklung und Implementierung nutzte das Team Sprints von zwei Wochen Länge, denen die Problemanalyse, Lösungsfindung, Vertestung und gegebenenfalls Iteration asynchron vorausgegangen waren. Dabei waren Zusammenarbeit und freier Austausch wichtiger als starre Prozesse. Das gesamte Team wurde eingebunden, um Ideen aus verschiedenen Blickwinkeln zu entwickeln. Durch das inkrementelle Vorgehen konnte das Team flexibel auf neue Anforderungen eingehen. Im Verlauf des Projekts hatte das Team von „Grundsteuererklärung für Privateigentum“ interne Prozesse überarbeitet, um alle Disziplinen, bestehend aus UX/UI- Design, Software-Entwicklung und Produktmanagement in eine Continuos Discovery einzubeziehen. Dies hatte den Vorteil, dass ein Problem aus verschiedenen Fachperspektiven analysiert wurde und das Produktverständnis bei allen Beteiligten gleich hoch blieb. Das Team fand gemeinsam heraus, welche Lösung die praktikabelste ist und kam schneller voran. Das interdisziplinäre Team bestand am Ende aus 18 Personen: vier Software-Entwickler:innen, zwei Designer:innen, zwei Produktmanager:innen und zwei Expert:innen aus dem BMF für Finanzen; weitere acht Personen bildeten das Support-Team.

Status: nicht erfüllt

Begründung:
Die vorherigen Erfahrungen beim „Steuerlotse für Rente und Pension“ hatten gezeigt, dass insbesondere bei schnellen und zeitlich begrenzten Entwicklungszyklen eine Integration in einen Portalverbund nur schwer bis gar nicht möglich ist. Mit sieben Monaten bis zum Launch eines MVP (Minimum Viable Product = eine minimal funktionsfähige Produktversion) und ursprünglich weiteren vier Monaten für die Weiterentwicklung sowie der von Beginn an begrenzten Nutzungsdauer der Software, erfolgte deshalb aus Zeit- und Kapazitätsgründen keine Integration in einen Portalverbund.

Wir empfehlen eine Überprüfung des aktuell zugrunde liegenden Prozesses, um eine leichtere Integration in einen Portalverbund zu ermöglichen.

Status: erfüllt

Zusammenfassung:

• Das Team vom DigitalService arbeitete interdisziplinär
• Einbeziehung von Fach-/Steuerexpertise, wenn notwendig
• Regelmäßige und transparente Abstimmungen mit Projektpartner:innen
• Regelmäßige Teilnahme an Treffen der Unterarbeitsgruppe der Länder

Begründung:
Seitens des BMF standen uns mit unseren Projektpartner:innen gleichzeitig auch zwei fachliche Ansprechpersonen zur Verfügung. In wöchentlichen Jour fixes und fast wöchentlichen Arbeitsmeetings kamen die Teams des DigitalService und des BMF zusammen, um Anforderungen fachlich zu erfassen. Alle Teammitglieder waren gleichberechtigt am Prozess beteiligt, um eine einheitliche Perspektive auf Problembereiche, vorgeschlagene Lösungen und Einigkeit bei Entscheidungen zu schaffen.

Einige Teammitglieder nahmen an den Sitzungen der Unterarbeitsgruppe Grundvermögen der Facharbeitsgruppe Grundsteuerreform teil. Diese Unterarbeitsgruppe setzt sich aus Fachexpert:innen zusammen: Referent:innen und Sachbearbeiter:innen der Landesfinanzministerien (aus Referaten, die für Grundsteuer zuständig sind) sowie des BMF. Die Sitzungen der Unterarbeitsgruppen fanden einmal im Monat statt. Zusätzlich wurden sogenannte „Länder-Runden“ initiiert – kurze einstündige Treffen, die zweimal im Monat stattfanden. Dort ging es um aktuelle und akute Ereignisse im Zusammenhang mit der Durchführung der Grundsteuerreform. Hier teilte das Team Daten zum Fortschritt vor- und nach dem Livegang des Dienstes und hatte die Gelegenheit auch inhaltliche Verständnisfragen zu stellen.

Status: nicht zutreffend

Begründung:
Zwar wurde „Grundsteuererklärung für Privateigentum“ für die elf Bundesländer, die bei der Grundsteuer das sogenannte „Bundesmodell“ anwendeten, bereitgestellt und es erfolgte ein enger Austausch mit diesen, eine Entwicklungsgemeinschaft im klassischen Sinne, war jedoch in der Projektplanung nie vorgesehen.

Status: erfüllt

Zusammenfassung:

• Entscheidungen und Erkenntnisse sowie Arbeitsergebnisse wurden standardmäßig offen und transparent geteilt
• Anwendungsentwicklung mit Web-Standards, interne Kommunikation über offene Protokolle
• Kommunikation mit Finanzverwaltung über ERiC Schnittstelle

Begründung:
Das Team hat von Beginn an auf Offenheit gesetzt und immer das Credo verfolgt, entsprechend der verfügbaren Ressourcen möglichst offen zu arbeiten – in jeglicher Hinsicht. Die Teammitglieder haben immer bewusste Entscheidungen zugunsten offener Standards getroffen, nicht zuletzt, um möglichst effizient Software entwickeln zu können.

In der Anwendungsentwicklung wurde mit Web-Standards (HTML, CSS, JavaScript) gearbeitet, die interne Kommunikation zwischen Diensten fand ausschließlich über offene Protokolle und Datenformate wie REST, HTTP(s), JSON oder SQL statt. Für die Kommunikation mit der Finanzverwaltung wurde auf ERiC gesetzt. Proprietäre Formate kamen nicht zum Einsatz.

Im Betrieb wurde mit einer Infrastruktur gearbeitet, die auf offenen Standards wie Kubernetes und OpenStack basiert und die, soweit möglich, über den de facto Standard Terraform (HCL) konfiguriert wurde.

Status: erfüllt

Zusammenfassung:

• Veröffentlichung und Open-Source-Lizenzierung aller Eigenentwicklungen
• Quellcode verfügbar unter https://github.com/digitalservicebund/grundsteuer
• Veröffentlicht unter freizügiger Open-Source-Lizenz „MIT“
• Geeignete Dokumentation mit gut lesbarem Code und umfangreiche Test-Suite

Begründung:
Von Beginn an fand alle Entwicklung komplett „in the open“ unter einem Trunk-basierten Modell statt.

Die vom Team selbst entwickelten Komponenten von „Grundsteuererklärung für Privateigentum“ werden unter der Open-Source-Lizenz „MIT“ verwaltet. Das bedeutet, dass diese Komponenten für jede und jeden kostenlos und ohne Einschränkungen nutzbar und modifizierbar sind.

Das Projekt stützt sich zudem stark auf von der Community entwickelte Open-Source-Bibliotheken wie zum Beispiel Remix oder React, die alle quelloffen verfügbar sind. Lediglich die bereits bestehende, von der Finanzverwaltung bereitgestellte Software ERiC ist nicht quelloffen verfügbar.

Der Code wurde den im Node.js-Ökosystem üblichen Paradigmen entsprechend entwickelt und gründlich mit Unit-, Integrations- und Akzeptanztests abgedeckt.

Die Dokumentation wurde auf drei Ebenen umgesetzt:

• sprechende Namen im Sinne der „Clean Code“-Methode,
• stellenweise Methoden-, Klassen- und Codekommentare, falls sie zum Verständnis der Abläufe notwendig sind
• und eine umfangreiche Test-Suite, aus der das erwartete Verhalten hervorgeht.

Status: erfüllt

Zusammenfassung:

• Nachnutzung Erica aus dem Steuerlotsen Projekt: github.com/digitalservicebund/erica

Begründung:
Die Wiederverwendbarkeit und Nachnutzbarkeit vorhandener Lösungen wurden geprüft. Für die Datenübergabe an ELSTER konnte eine bereits intern für ein vorheriges Produkt entwickelte Software-Komponente wiederverwendet werden. Die vorhandene Lösung wurde dabei um zusätzliche Funktionalität ergänzt.

Status: erfüllt

Zusammenfassung:

• Berücksichtigung einschlägiger Sicherheitsempfehlungen (u. a. OWASP) bei Design und Entwicklung der Software-Komponenten
• Kontinuierliche, automatische Prüfung verwendeter Software-Pakete auf bekannte Sicherheitslücken
• Verschiedene Dokumente erstellt, u. a. Sicherheitskonzept inkl. Betrieb, Hosting, Software-Architektur
• Durchführung von Lasttests vor Livegang und während des Betriebes zur Überprüfung der Zuverlässigkeit
• Sicherstellung einer hohen Verfügbarkeit und schneller Wiederherstellung bei Störungen und Ausfällen durch einen ständigen technischen Bereitschaftsdienst (On-Call-Rotation)
• Kontinuierliche automatische Überwachung von Systemeigenschaften und -verhalten mit sofortiger Benachrichtigung des technischen Bereitschaftsdienstes bei Störungen und Ausfällen
• Vertragliche Regelungen mit technischem Dienstleister, u. a. bzgl. Sicherheitsvorfällen
• Nach einem Ausfall: gründliche Analyse gemeinsam mit IT-Dienstleister, um zukünftige Vorfälle zu vermeiden
• Kein BSI-Grundschutzcheck, dafür externer Penetrationstest

Begründung:
Nutzer:innen wandten sich bereits kurz vor dem Launch der Software mit Fragen an das Team von „Grundsteuererklärung für Privateigentum“. Kurz nach dem Launch wurde ein Ticketsystem eingeführt, um eingehende Anfragen strukturiert abarbeiten zu können. Dafür wurde ein Team aus 8 Support-Mitarbeiter:innen aufgebaut. Es sind über 23.000 E-Mails von Nutzer:innen eingegangen, das waren durchschnittlich 110/Tag.

Status: nicht zutreffend

Begründung:
Es wurden keine Schnittstellen angeboten oder neue Standards eingeführt.

Status: nicht zutreffend

Begründung:
Durch die speziellen Umstände wurde die Weiterentwicklung schon einige Monate nach Go-live eingestellt. Daher kamen wir gar nicht in die Verlegenheit, eine jährliche Evaluation durchzuführen.

Status: teilweise erfüllt

Zusammenfassung:

• Implementierung von Tracking, mit dessen Hilfe Basisdaten ermittelt wurden, die Rückschlüsse auf Nutzerfreundlichkeit und -zufriedenheit zuließen
• Analyse von Support-Anfragen
• Erhobene Daten sind größtenteils nur intern zugänglich

Begründung:
Wir haben anonyme Daten zur Nutzungsintensität erhoben. Durch die Analyse von Support-Anfragen haben wir indirekt Daten zur Nutzerzufriedenheit erhalten. Die Ergebnisse wurden nicht veröffentlicht.

Status: erfüllt

Zusammenfassung:

• Weiterentwicklung des Dienstes auf Basis von Tracking-Daten, Usability-Tests, Feedback aus Support-Anfragen und Erkenntnissen aus direktem Kontakt zur Zielgruppe (zum Beispiel über Veranstaltungen)
• Laufende Einbeziehung von Nutzerbedürfnissen in Produktentscheidungen
• Erkenntnisse sind teilweise intern, teilweise öffentlich zugänglich

Begründung:
Unser digitales Hilfsangebot hat sich als praktisches Werkzeug zur Überprüfung der Qualität unseres Dienstes erwiesen. Wenn Nutzer:innen Fragen zu bestimmten Sachverhalten oder technischen und inhaltlichen Einschränkungen hatten, konnten wir daraus wichtige Erkenntnisse gewinnen, an welchen Stellen gehäuft Probleme auftraten. Diese Informationen wurden dann in unsere Liste an notwendigen Verbesserungen aufgenommen und in Abhängigkeit von ihrer Priorität nach und nach umgesetzt.