E‑Mail‑Validierung, um Support‑Tickets durch fehlerhafte Adressen zu reduzieren

Warum schlechte E‑Mail‑Adressen so viel Supportarbeit verursachen

Ein überraschender Anteil der Support‑Tickets hat dieselbe Ursache: die E‑Mail‑Adresse im Konto ist falsch, nicht erreichbar oder temporär. Für den Nutzer sieht es so aus, als würde Ihr Produkt versagen. Für den Support wird es ein langwieriger Vorgang, den man schwer schließen kann.

Die Symptome sind vorhersehbar. Jemand erhält die Bestätigungs‑E‑Mail nicht, sodass die Onboarding‑Prozedur bei Schritt eins stoppt. Eine andere Person kann sich nicht einloggen, weil die Nachricht zum Zurücksetzen des Passworts nie ankommt. Rechnungsbenachrichtigungen oder Sicherheitswarnungen gehen verloren, und der Kunde wendet sich hektisch an den Support. Selbst wenn Nutzer Zugriff auf die App haben, können fehlende Benachrichtigungen den Eindruck erwecken, Funktionen würden nicht funktionieren.

Schlechte E‑Mail‑Adressen erzeugen auch wiederholte Kontakte. Ein Nutzer eröffnet ein Ticket wegen einer fehlenden Reset‑E‑Mail, meldet sich erneut, nachdem er ein anderes Postfach ausprobiert hat, bittet um Adressänderung und benötigt dann eine erneute Verifikation. Jeder Schritt kann Identitätsprüfungen, manuelle Kontoänderungen und das Warten auf eine weitere E‑Mail erfordern, die vielleicht immer noch nicht ankommt. Ein Tippfehler kann zu einer langen Kommunikation werden.

Die Kernidee ist einfach: Stoppen Sie schlechte Adressen, bevor sie in Ihre Datenbank gelangen. Erkennen Sie Probleme bei der Anmeldung und beim Aktualisieren der E‑Mail, und Sie verhindern einen Großteil der Folgemeldungen: weniger fehlgeschlagene Resets, weniger blockierte Anmeldungen und weniger „Ich habe die E‑Mail nie erhalten“‑Threads.

Validierung ist keine Zauberei. Sie kann Ihnen sagen, ob eine Adresse korrekt formatiert ist, ob die Domain existiert und ob sie nach Wegwerf‑Mustern aussieht. Sie kann nicht garantieren, dass jede Nachricht zugestellt wird. Dafür brauchen Sie weiterhin gute Versandpraxis wie korrekt eingerichtete Sender, klare Vorlagen und sinnvolle Wiederholungsversuche.

Ein konkretes Beispiel: Ein Nutzer tippt „gmial.com“ während der Anmeldung ein. Ohne Validierung legt er ein Konto an, das er nicht verifizieren kann, und der Support muss das Konto finden, die Inhaberschaft bestätigen, die E‑Mail ändern und Nachrichten erneut versenden. Mit Validierung wird dieser Tippfehler in Sekunden erkannt, bevor er zum Ticket wird.

Woher schlechte E‑Mail‑Adressen kommen

Die meisten schlechten Adressen sind nicht böswillig. Es sind kleine Fehler zur falschen Zeit: jemand eilt durch die Anmeldung auf dem Handy, wechselt die App oder versucht, einen Rabattcode zu sichern, bevor er abläuft.

Ein großer Teil sind einfache Tippfehler und Formatprobleme. Leute lassen das @‑Zeichen weg, fügen ein Leerzeichen am Ende ein oder vertippen eine gängige Domain (z. B. gmial.com). Mobile Tastaturen und Autokorrektur verschlimmern das, besonders wenn Nutzer eine Adresse aus Notizen einfügen und unsichtbare Zeichen auftauchen.

Eine andere Quelle sind Domains, die keine E‑Mails empfangen können. Manchmal existiert die Domain nicht. Oft existiert sie zwar, hat aber keine Mail‑Konfiguration (keine MX‑Einträge), sodass Willkommens‑, Bestätigungs‑ und Passwort‑Reset‑E‑Mails nie ankommen. Der Nutzer erlebt das als einen Ausfall Ihres Produkts.

Dann gibt es Wegwerf‑Postfächer. Die Erkennung von Wegwerf‑E‑Mails ist wichtig, weil diese Adressen oft für schnelle Anmeldungen, Testphasen oder bestimmte Arten von Betrug verwendet werden. Sie funktionieren kurzzeitig und verschwinden dann, sodass Sie Konten haben, die Sie später nicht erreichen können.

Schließlich sind manche Adressen gültig, verursachen aber trotzdem Verwirrung, besonders Rollen‑ oder gemeinsame Postfächer wie support@ oder sales@. Mehrere Personen können darauf zugreifen, wodurch die Kontoinhaberschaft unklar wird und Anfragen wie „Bitte ändern Sie die E‑Mail“ oder „Ich habe mich nicht angemeldet“ häufiger werden.

Wenn Ihr Ziel die Verringerung von Tickets ist, liefern die besten frühen Erfolge das Erkennen von:

• Tippfehlern, fehlenden Teilen und unsichtbaren Leerzeichen
• Domains, die nicht existieren oder keine E‑Mails empfangen können
• Bekannten Wegwerf‑Anbietern
• Rollen‑ oder gemeinsamen Postfächern (wenn sie für Ihr Produkt riskant sind)

Wie schlechte E‑Mails zu typischen Tickettypen führen

Schlechte E‑Mail‑Adressen scheitern selten auf eine saubere, offensichtliche Weise. Sie scheitern leise, und Ihr Support‑Team wird zum menschlichen Backup‑System. Es hilft, die Muster zu erkennen, die immer wieder auftauchen.

Passwort‑Resets sind meist die lautesten Fälle. Ein Nutzer vergisst sein Passwort, fordert ein Reset an und nichts kommt an, weil die Adresse falsch geschrieben, blockiert oder wegwerfend ist. Er versucht es erneut und eröffnet dann frustriert ein Ticket, weil er sich nicht selbst helfen kann.

Konto‑Verifikation ist ähnlich, trifft aber früher. Wenn die Bestätigungs‑E‑Mail nicht zugestellt werden kann, bleibt der Nutzer auf dem Bestätigungsbildschirm hängen. Aus seiner Sicht ist Ihr Produkt kaputt. Aus Ihrer Sicht war die E‑Mail nie erreichbar.

Benachrichtigungen erzeugen langsamere, unübersichtlichere Tickets. Nutzer verpassen Hinweise, Status‑Updates oder Sicherheitswarnungen und beschweren sich dann, Ihr Produkt habe nichts geschickt. Der Support muss sich in Logs einarbeiten und erklären, was passiert ist, oft ohne wirklich beweisen zu können, ob die Adresse bei der Anmeldung gültig war.

Rechnungs‑E‑Mails verwandeln kleine Fehler in dringende Anfragen. Wenn Belege und Rechnungen an die falsche Adresse gehen (oder zurückkommen), machen sich Kunden Sorgen um Compliance, Erstattung oder Streitfälle. Diese Tickets werden oft nach vorn gezogen.

Einladungen und Team‑Onboarding sind eine weitere Falle. Ein Tippfehler in einer Einladungsadresse kann einen Kollegen am Beitritt hindern oder Zugang an die falsche Person senden.

Viele scheinbar unterschiedliche Tickets lassen sich auf dieselbe Ursache zurückführen:

• Reset‑E‑Mail kommt nach mehreren Versuchen nie an
• Beim Bestätigungs‑E‑Mail‑Bildschirm hängt alles
• „Ich habe die Benachrichtigung nie bekommen“‑Beschwerden
• Fehlende Belege, Rechnungen oder Zahlungsbestätigungen
• Einladungen, die bouncen oder an falsche Postfächer gehen

Entscheiden, wann Sie validieren sollten (Anmeldung, Änderungen, Importe)

Schlechte E‑Mails lassen sich am besten behandeln, bevor sie in Ihre Datenbank gelangen. Validieren Sie in den Momenten, in denen eine E‑Mail erstellt, geändert oder für etwas Wichtiges verwendet werden soll. So reduzieren Sie Supportaufwand, ohne überall Reibung einzuführen.

Die wirkungsvollsten Zeitpunkte

Beginnen Sie dort, wo ein falsches Zeichen später viel Aufräumarbeit verursacht:

• Anmeldeformulare: Verhindern Sie Tippfehler, ungültige Domains und Wegwerf‑Adressen, bevor ein Konto erstellt wird.
• E‑Mail‑Änderungsseiten: Ein guter Kunde kann durch ein Update unerreichbar werden. Validieren Sie hier, damit Belege, Warnungen und Verlängerungs‑Mails nicht verloren gehen.
• Vor kritischen Sendungen: Direkt vor Passwort‑Resets, Rechnungen oder Sicherheitswarnungen prüfen, um fehlerhafte Datensätze zu entdecken, die über alte Flows hereingeschlüpft sind.
• Massenimporte: Bereinigen Sie Listen, bevor sie in Ihr CRM oder Ihre Marketing‑Tools kommen, um Bounce‑Spitzen und Zustellbarkeits‑Schäden zu vermeiden.

Was zuerst tun (und was warten kann)

Wenn Sie nur an einem Ort anfangen können, dann bei der Anmeldung. Das verhindert die größte Menge späterer Probleme.

Als Nächstes validieren Sie E‑Mail‑Änderungen. Diese Tickets sind besonders schmerzhaft, weil der Nutzer oft nichts mehr bestätigen kann, sobald er den Zugriff verloren hat.

Schließlich fügen Sie Validierung rund um hochrelevante E‑Mails und Importe hinzu. Ein praktisches Muster ist: validieren, wenn die E‑Mail gespeichert wird, und noch einmal, wenn sie für eine sensible Aktion verwendet wird.

Was die E‑Mail‑Validierung prüfen sollte (in einfachen Worten)

Der Zweck der Validierung ist nicht nur, nach einem @‑Zeichen zu suchen. Es geht darum, eine Frage zu beantworten: Kann diese Adresse realistisch E‑Mails empfangen, und ist es sicher, sie zu akzeptieren?

Die Prüfungen, die am wichtigsten sind

Die Essentials, ohne Fachchinesisch:

• Formatprüfung (Syntax): Erkennt offensichtliche Fehler wie fehlendes @, zusätzliche Leerzeichen oder „.con“ statt „.com“.
• Domain existiert: Bestätigt, dass der Teil nach dem @ eine echte Domain ist. Wenn jemand „gmail.cmo“ tippt, sollten Sie das sofort stoppen.
• Domain empfangsbereit (MX‑Einträge): Prüft, ob die Domain so konfiguriert ist, dass sie E‑Mails empfangen kann. Manche Domains existieren zwar, können aber keine Mails annehmen.
• Erkennung von Wegwerf‑Adressen: Kennzeichnet bekannte Anbieter, die oft für schnelle Anmeldungen oder bestimmte Betrugsarten genutzt werden.
• Blocklisten und Risiko‑Signale: Identifiziert Adressen und Domains, die mit Spam‑Fallen oder verdächtigen Mustern assoziiert sind. Das schützt Ihre Zustellbarkeit, sodass echte Nutzer Ihre Nachrichten erhalten.

Geschwindigkeit gehört dazu

Validierung muss schnell genug sein, damit Nutzer sie kaum bemerken. Langsame Prüfungen führen zu Neuladen, erneuten Einsendungen und doppelten Anmeldungen, was wieder zusätzlichen Supportaufwand erzeugt.

Wie man E‑Mail‑Validierung bei der Anmeldung einbaut (Schritt für Schritt)

Die Anmeldung ist der beste Ort, um zu beginnen. Das Ziel ist klar: Fangen Sie offensichtliche Probleme ab, bevor Sie das Konto anlegen und wichtige E‑Mails verschicken, die nie ankommen.

Ein praktischer Anmelde‑Flow

Entscheiden Sie, wo die Prüfungen laufen. Eine schnelle Frontend‑Prüfung verbessert die Nutzererfahrung, aber das Backend muss die verlässliche Quelle sein (jeder kann die Browser‑Prüfung umgehen).

Ein einfacher, effektiver Ablauf sieht so aus:

• Geben Sie im Formular sofortiges Feedback für Basis‑Formatfehler (fehlendes @, abschließende Leerzeichen).
• Validieren Sie auf dem Server nochmals, bevor der Benutzer angelegt wird.
• Prüfen Sie, ob die Domain existiert und E‑Mails empfangen kann (MX‑Einträge).
• Wenden Sie Ihre Richtlinie für Wegwerf‑Adressen an: blockieren, warnen und erlauben oder erlauben mit Einschränkungen (z. B. Verifikation vor wichtigen Funktionen verlangen).

Wenn Sie einen Fehler anzeigen, halten Sie die Meldung klar und spezifisch. „E‑Mail scheint ungültig zu sein“ ist frustrierend. „Diese Domain kann keine E‑Mails empfangen. Überprüfen Sie die Schreibweise hinter dem @“ führt schneller zur Korrektur. Bei wahrscheinlichen Tippfehlern hilft ein sanfter Hinweis wie „Meinten Sie vielleicht gmail.com?“

Ergebnis für den Support sichtbar machen

Validierung hilft auch nachträglich. Wenn ein Nutzer sagt, er habe das Onboarding nicht erhalten, sollte der Support sehen können, was bei der Anmeldung passiert ist.

Protokollieren Sie das Ergebnis und den Grund so, dass der Support danach suchen kann. Schon ein kurzer Code oder ein Label hilft, z. B.: syntax_failed, domain_missing, mx_missing, disposable_flagged, risky.

Prüfen Sie außerdem erneut, wenn ein Nutzer seine E‑Mail ändert, und wenden Sie dieselben Regeln an wie bei der Anmeldung.

Häufige Fehler, die die Tickets am Leben halten

Schlechte E‑Mails erzeugen selten ein einzelnes Problem. Sie verursachen eine Kette kleiner Fehler, die in Ihrer Support‑Schlange landen. Viele Teams validieren etwas, aber einige Fehler machen die Maßnahme wirkungslos (oder nervig für echte Nutzer).

Eine Falle ist zu strikte Ablehnung ohne Erklärung. Wenn Sie einen Nutzer blockieren und nur „ungültige E‑Mail“ anzeigen, versucht er es erneut, eröffnet ein Ticket oder bricht die Anmeldung ab. Wenn Sie etwas blockieren, sagen Sie, was zu korrigieren ist: „Diese Domain kann keine E‑Mails empfangen“ oder „Überprüfen Sie Tippfehler wie gmal.com."

Ein weiterer Fehler ist, bei der Syntax aufzuhören. Eine korrekt aussehende Adresse kann dennoch unzustellbar sein, wenn die Domain nicht existiert oder keine Mail‑Server eingerichtet hat. Domain‑Checks und MX‑Lookups fangen Probleme auf, die ein einfaches „hat ein @“ nicht erkennt.

Timing ist ebenfalls wichtig. Prüfen Sie nicht erst, nachdem das Konto angelegt wurde — dann haben Sie bereits schlechte Daten gespeichert. Passwort‑Resets, Onboarding‑Schritte und Alerts gehen an die falsche Adresse, und der Support muss später aufräumen.

Einige Muster, die das Ticket‑Volumen hochhalten:

• Wegwerf‑Erkennung als endgültiges Urteil behandeln statt als Risiko‑Signal, das nach Anwendungsfall verarbeitet wird
• Echte Nutzer mit aggressiven Regeln abweisen, besonders bei neuen oder ungewöhnlichen Domains
• Vage Fehlermeldungen, die nicht sagen, was zu ändern ist
• Zu späte Validierung, nachdem die schlechte E‑Mail bereits gespeichert wurde
• Support ohne Einsicht lassen, sodass sie nicht sehen, was fehlgeschlagen ist und warum

Wenn Sie möchten, dass Validierung Tickets reduziert, streben Sie an: „Fange das Offensichtliche ab, erkläre die Lösung und gib dem Support Kontext“, nicht „Blockiere alles, was verdächtig aussieht."

Wie Sie die tatsächlich reduzierte Supportarbeit messen

Um zu belegen, dass Ihre Validierung wirkt, beginnen Sie mit einer einfachen Basislinie. Wählen Sie ein 2–4 Wochen Fenster vor der Änderung und vergleichen Sie es mit derselben Dauer nach dem Rollout.

Verfolgen Sie die Tickets, die normalerweise schlechte E‑Mails verbergen

E‑Mail‑Qualitätsprobleme werden unterschiedlich gemeldet, also messen Sie einige leicht wöchentliche Zählwerte:

• Passwort‑Reset‑Fehler und Tickets, die das Nicht‑Erhalten der E‑Mail erwähnen
• Anzahl der Bestätigungs‑E‑Mails, die pro Tag (oder pro 100 Anmeldungen) erneut gesendet werden
• Beschwerden wie „Ihre E‑Mails kommen nie an“ im Zusammenhang mit Benachrichtigungen und Rechnungen
• Abschlussrate im Onboarding neuer Nutzer (z. B. Anmeldung bis erste wichtige Aktion innerhalb von 24 Stunden)
• Bounce‑Rate von Ihrem E‑Mail‑Provider (Hard Bounces sind am wichtigsten)

Nach der Aktivierung der Validierung sollten Passwort‑Reset‑Fehler und erneute Sendungen sinken, während die Onboarding‑Abschlussrate steigt.

Nach Ursachen taggen, nicht nur nach Kanal

Fügen Sie in Ihrem Helpdesk ein Pflichtfeld für E‑Mail‑bezogene Probleme hinzu und halten Sie die Tags einfach:

• Tippfehler (gmial.com, fehlendes Zeichen, falsche TLD)
• Wegwerf‑ oder temporäres Postfach
• Nicht erreichbare Domain (kein gültiger Mailserver)
• Mailbox nicht gefunden (Hard Bounce)
• Unbekannt (braucht Nachverfolgung)

Das verwandelt vage Beschwerden in Muster, auf die Sie reagieren können. Wenn „Tippfehler“ hoch bleibt, verbessern Sie die Anmelde‑UI (Bestätigungsfeld, Adresse nochmals anzeigen). Wenn „Wegwerf“ hoch bleibt, verschärfen Sie Ihre Richtlinie.

Wenn Sie einen Validator nutzen, protokollieren Sie das Validierungsergebnis (pass, risky, blocked) zusammen mit dem Ticket‑Tag. So können Sie mit der Zeit beantworten: Welche Fehler wurden früher Tickets und welche stoppen Sie jetzt schon bei der Anmeldung.

Ein realistisches Beispiel: der Tippfehler, der ein langes Ticket wird

Ein neuer Kunde meldet sich an und tippt [email protected] statt [email protected]. Das Formular akzeptiert es, das Konto wird erstellt und Ihr System sendet eine Willkommens‑E‑Mail und einen Bestätigungscode. Nichts kommt an, weil die Adresse nicht so funktioniert, wie der Nutzer denkt.

Aus Sicht des Kunden fühlt sich Ihr Produkt kaputt an. Er klickt ein paar Mal auf „Bestätigung erneut senden“. Nichts. Dann probiert er „Passwort vergessen“, nur um zu sehen, ob irgendetwas ankommt. Als das ebenfalls scheitert, eröffnet er ein Support‑Ticket.

Was folgt, ist der vertraute Ablauf:

• Support fragt nach der verwendeten E‑Mail sowie Screenshots des Fehlers und des Postfachs.
• Support sendet Verifikations‑ und Reset‑E‑Mails erneut und wartet.
• Der Nutzer prüft Spam, probiert ein anderes Gerät und antwortet Stunden später.
• Support erkennt den Domain‑Tippfehler, kann ihn aber nicht ohne manuelle Schritte ändern.
• Jemand aktualisiert die Kontoe‑Mail, löst die Verifikation erneut aus und bestätigt den Zugriff.

Selbst wenn das Problem gelöst ist, haben Sie Zeit für Nachrichten, manuelle Änderungen und Nachverfolgung investiert. Das Onboarding verzögert sich und der erste Eindruck ist frustrierend.

Mit Validierung endet dieselbe Geschichte im Formular. Wenn der Nutzer [email protected] eingibt, markiert der Anmeldefluss die Adresse als wahrscheinlich ungültig und fordert zur Korrektur auf, bevor es weitergeht. Der Nutzer korrigiert den Tippfehler in Sekunden, erhält die Willkommens‑E‑Mail und braucht nie Hilfe.

Schnelle Checkliste, um E‑Mail‑getriebene Tickets zu verhindern

Die meisten E‑Mail‑bezogenen Tickets entstehen durch ein paar vermeidbare Lücken: Sie validieren einmal, inkonsistent oder das Supportteam sieht nicht, was passiert ist.

Nutzen Sie diese Checkliste beim Bereitstellen von Änderungen:

• Validieren Sie bei der Anmeldung und jedes Mal, wenn ein Nutzer seine E‑Mail ändert. Profil‑Bearbeitungen können stillschweigend schlechte Adressen wieder einführen.
• Entscheiden Sie Ihre Wegwerf‑E‑Mail‑Richtlinie und halten Sie sie produktweit konsistent (Anmeldung, Einladungen, Checkout).
• Speichern Sie das Validierungsergebnis (und einen einfachen Grund), damit der Support schnell Fehler beheben kann.
• Schreiben Sie menschliche Fehlermeldungen mit klaren Schritten zum Wiederholen. Sagen Sie den Leuten, was sie als Nächstes tun sollen, und leeren Sie das Formular nicht.
• Überprüfen Sie ältere E‑Mails vor kritischen Sendungen erneut. Rechnungen, Sicherheitswarnungen und Onboarding‑Meilensteine sind Stellen, an denen schlechte Daten besonders schaden.

Eine einfache Schnapszahl‑Prüfung: Bitten Sie den Support, 10 aktuelle „E‑Mail nicht erhalten“‑Tickets zu ziehen und zu prüfen, ob Ihre Logs beantworten: War die Adresse zum Zeitpunkt der Anmeldung gültig und erreichbar? Wenn nicht, fügen Sie diese Sichtbarkeit zuerst hinzu.

Nächste Schritte: Sicher ausrollen und kontinuierlich verbessern

Starten Sie klein, zeigen Sie den Nutzen und weiten Sie aus. Der einfachste Gewinn ist die Validierung bei der Anmeldung, denn dort gelangen die meisten Tippfehler und Wegwerf‑Adressen in Ihr System.

Sobald die Anmeldung stabil läuft, erweitern Sie dieselben Prüfungen auf E‑Mail‑Änderungsseiten und Massenimporte. Diese beiden Pfade erzeugen stillschweigend unordentliche Daten, die später als fehlende Benachrichtigungen, Rechnungsprobleme und Passwort‑Reset‑Fehler auftreten.

Führen Sie einen kleinen Pilotversuch durch und messen Sie die richtigen Tickets

Wählen Sie 1–2 Tickettypen, die klar mit E‑Mail‑Qualität verbunden sind, und verfolgen Sie sie einen Monat lang vor und nach der Änderung. Halten Sie den Umfang eng, damit die Ergebnisse zuverlässig sind.

Gute Einstiegsmetriken sind Passwort‑Reset‑Fehler, Verifikationsprobleme, fehlgeschlagene Rechnungs‑ oder Einladungs‑E‑Mails und „Bitte ändern Sie meine E‑Mail“‑Anfragen, die durch Anmelde‑Tippfehler verursacht wurden.

Randfälle behandeln, ohne echte Nutzer zu blockieren

Validierung sollte Risiko reduzieren, nicht ein neues Supportproblem schaffen, indem legitime Anmeldungen abgelehnt werden. Planen Sie für Randfälle, in denen Sie das Konto erlauben, aber die Auswirkungen begrenzen.

Ein praktischer Ansatz:

• Wenn eine E‑Mail risikoreich aussieht (Wegwerf‑Adresse oder kann keine Mails empfangen), erlauben Sie die Anmeldung, verlangen Sie aber Verifikation vor wichtigen Aktionen.
• Begrenzen Sie Testzeiträume und Gratisangebote, bis die E‑Mail bestätigt ist.
• Bieten Sie direkt nach der Anmeldung einen einfachen „E‑Mail korrigieren“‑Flow an.
• Protokollieren Sie den Grund, warum die Anmeldung markiert wurde, damit der Support dies klar erklären kann.

Wenn Sie eine API‑basierte Option möchten, ist Verimail (verimail.co) für genau diesen Workflow ausgelegt: RFC‑konforme Syntax‑Prüfung, Domain‑Verifikation, MX‑Lookup und Echtzeit‑Abgleich mit Wegwerf‑Anbietern, alles in einem Aufruf. Oft ist es am einfachsten, zunächst im Monitor‑Modus zu starten (warnen und protokollieren, nicht blockieren) und Regeln zu verschärfen, sobald Sie sehen, was tatsächlich in Tickets auftaucht.

Überprüfen Sie die Ergebnisse monatlich. Aktualisieren Sie Regeln basierend auf dem, was der Support weiterhin meldet, und betrachten Sie Validierung als fortlaufende Qualitätsprüfung, nicht als einmaliges Projekt.