Inhaltsverzeichnis
In diesem Artikel teilen wir drei reale Fehler aus unserem Arbeitsalltag – vom falsch verschickten Newsletter über ein verpatztes Live-Deployment bis hin zu stiller Fehlkommunikation mit einem Kunden.
Wir zeigen nicht nur, was schiefgelaufen ist, sondern auch, welche Massnahmen wir danach ergriffen haben.
Unser Ziel: Eine offene Fehlerkultur, in der Learnings transparent und für alle zugänglich sind.
✉️ Falscher Newsletter versendet – und was wir daraus gelernt haben
Am 17. Februar ging ein interner Entwurf unseres Kundennewsletters versehentlich an über 4'000 Empfänger:innen raus - inklusive unfertiger Texte und Platzhalterbildern. Die Ursache? Eine versehentlich aktivierte Automatisierung und fehlende letzte QA-Prüfung.
Ursachenanalyse
- Auslöser war ein automatisierter Versandzeitpunkt im Tool, der trotz fehlender QA aktiviert blieb.
- Die Kampagne war versehentlich als „bereit“ markiert.
Lerneffekte
- Einführung einer Mail-Versand-Checkliste
- Kein automatischer Versand ohne Freigabe durch zwei Teammitglieder
- Wöchentlicher Testversand an internes QA-Team
- Automatisierungen müssen manuell bestätigt werden
| Fehlerart | Vermeidungstipp |
|---|---|
| Kein Betreff | Pflichtfeld-Check und Testmail |
| Platzhalter-Name sichtbar | Fallback definieren („Hallo!“) |
| Falsche Links | QA-Test mit Live-Links vor Versand |
| Bilder werden nicht geladen | Bilder extern einbinden, Alt-Text hinzufügen |
- Mail-Tester.net – Spam-Risiko vor Versand checken
- Litmus – Newsletter-Rendering in verschiedenen Clients
- Miro – Freigabeprozess visuell abbilden
- Notion – Checkliste zur Redaktionsplanung
🚨 Live-Deployment mit Downtime – unser Go-Live-Fail
Bei einem Live-Deployment am Freitagabend führte ein Konfigurationsfehler zu 9 Stunden Ausfallzeit. Rücksicherung war nur mit älterem Stand möglich.
Ablauf & Problem
- Deployment erfolgte ohne vollständige Staging-Tests
- Datenbankmigration war inkompatibel mit Legacy-Modulen
Lessons Learned
- Go-Lives nur noch bis Mittwochmittag
- „Rollback Ready“-Protokoll eingeführt
- Staging muss alle produktionsnahen Daten simulieren
- Staging-Test abgeschlossen
- Backup verifiziert
- Downtime geplant & kommuniziert
- Rollback-Skript getestet
"Ich dachte, das sei klar!" – Fehlkommunikation mit dem Kunden
Ein Projekt wurde mit unerfüllten Erwartungen abgeschlossen – Ursache: eine stille Annahme auf beiden Seiten, dass gewisse Anforderungen impliziert seien.
Was ist passiert?
- Wichtige UX-Elemente waren nicht umgesetzt
- Kunde hatte Anforderungen im Erstgespräch genannt, aber nicht schriftlich bestätigt
Neue Massnahmen
- Verpflichtende Zusammenfassung nach Kundencall per Mail
- Gemeinsames Miro-Board für Anforderungen
- Vertrags-Addendum für nachträgliche Anforderungen
- Confluence Projekt-Templates
- Miro-Board zur Anforderungsaufnahme
- E-Mail-Vorlage „Recap: Das haben wir besprochen“