Kundenbericht für KI-Automatisierungen: Wöchentlich zeigen, was läuft und was es bringt

Orientierung, keine Beratung. Der Text verspricht keinen Retainer und keinen Umsatz. Er zeigt, wie du einem Kunden nachvollziehbar zeigst, was deine Automatisierung getan hat und wo sie Probleme machte.

Kurz gesagt

Ein guter Kundenbericht passt auf eine Seite und beantwortet vier Fragen: Was lief? Was ist schiefgegangen? Was heißt das für den Kunden? Was passiert als Nächstes? Zahlen bekommen eine Quelle und eine Methode, Fehler stehen offen im Text. Eine Quelle aus dem Agenturbereich rät, den Bericht aus der vereinbarten Scorecard zu bauen und nicht aus allen verfügbaren Zahlen [4]. Wer das regelmäßig tut, begründet Betreuung mit Belegen statt mit Behauptungen. Ob der Kunde deshalb verlängert, ist nicht belegt.

Was in den Bericht gehört

Das ist eine Arbeitsregel, keine Quellenaussage. Vier Blöcke, jeder mit wenigen Zeilen.

1. Messwerte mit Quelle. Jede Zahl bekommt drei Angaben: woher sie stammt (zum Beispiel die Ausführungsliste deines Automatisierungstools), welcher Zeitraum gilt und wie gezählt wurde. Schreib "142 Ausführungen, davon 9 mit Fehler (Ausführungsliste, 13. bis 19.10., gezählt nach Status)" statt "läuft stabil". Welche Zahlen du zeigst, legt ihr vorher fest. Die Scorecard-Idee stammt aus [4].

2. Vorfälle. Was ist ausgefallen, wann, wie lange, was war die Wirkung für den Kunden, was hast du getan? Ein Fachbuchkapitel zu Postmortems nennt als Bestandteile Auswirkungen, Gegenmaßnahmen, Ursachen und Folgemaßnahmen [1]. Du brauchst keinen langen Bericht, aber diese vier Punkte.

3. Fehler offen benennen. Dasselbe Kapitel betont Systeme statt Schuld: Wo Schuld zählt, melden Leute Probleme laut Quelle nicht [1]. Übertragen auf dich: Ein Fehler, den du selbst meldest, ist eine Betreuungsleistung. Ein Fehler, den der Kunde zuerst findet, ist ein Vertrauensproblem. Das ist eine Schlussfolgerung, keine Quellenaussage.

4. Nächste Schritte. Maximal drei, jeweils mit Verantwortlichem und Termin. Offene Entscheidungen des Kunden stehen als eigene Zeile.

Trenne im Text Fakten, mögliche Ursachen und offene Fragen. Das empfiehlt [4]. "Die Ausführung brach um 03:12 ab" ist ein Fakt, "vermutlich Zeitlimit des Dienstes" eine Vermutung, "Wer ändert das Postfach?" eine Frage.

Vom Log zum Bericht

1. 1Rohdaten sammeln. Ausführungsliste und Fehlermeldungen des Tools. Bei n8n gibt es eine Liste je Workflow und eine über alle [3]. Ein Fehler-Workflow mit Error Trigger erhält Fehlermeldung, letzten Knoten, Workflow-Name und ID [2]. Damit lässt sich eine Fehlerliste automatisch füllen.
2. 2Personenbezug entfernen. Postmortems sollen keine Informationen enthalten, die Endnutzer identifizieren [1]. n8n kann Ein- und Ausgabedaten schwärzen und behält Status, Zeit und Knotennamen [3]. Ob das für deinen Fall datenschutzrechtlich genügt, ist keine Frage, die dieser Text beantwortet.
3. 3Zählen, nicht schätzen. Anzahl Ausführungen, Anzahl Fehler, Dauer der Ausfälle. Rechne selbst nach oder lass ein Skript zählen. Ein Sprachmodell soll formulieren, nicht rechnen.
4. 4Formulieren lassen, prüfen. Das Modell schreibt den Entwurf, du prüfst jede Zahl gegen die Rohdaten.

Fiktives Beispiel

Alle Angaben erfunden, nur zur Veranschaulichung.

Du betreust für eine fiktive Steuerkanzlei eine Automatisierung, die Mandantenanfragen sortiert und Antwortentwürfe vorbereitet. Dein Wochenbericht: "Zeitraum 13. bis 19.10. (fiktiv). Die Ausführungsliste zeigt 120 Läufe, 6 mit Fehler. Ursache bei 5: Der Mail-Dienst hat Anhänge abgelehnt, Beleg: Fehlermeldung in der Liste, Montag bis Mittwoch. Vermutung: neues Größenlimit, noch nicht bestätigt. Bei 1: unklar, offen. Wirkung: Fünf Anfragen kamen verspätet in die Sortierung, die Kanzlei hat sie am Donnerstag von Hand nachgezogen. Nächste Schritte: Ich prüfe das Limit bis Freitag, ihr entscheidet, ob Anhänge vorab verkleinert werden." Der Bericht erfindet keinen Erfolg und verschweigt keinen Fehler. Ob die Kanzlei damit eine Betreuung weiterbucht, zeigt erst ihre Entscheidung.

Drei kopierbare Prompt-Vorlagen

Ersetze Platzhalter in eckigen Klammern. Gib keine Daten realer Personen in ein KI-Tool ein, ohne dass du dazu berechtigt bist. Prüfe jede Antwort selbst. Die Prompts folgen den Techniken aus [5]: Unsicherheit erlauben, nur aus gegebenem Material arbeiten, Aussagen mit Zitat belegen.

1. Fehlerliste zusammenfassen

Hier ist eine anonymisierte Fehlerliste aus [Tool] für [Zeitraum]: [Liste].
Gruppiere gleiche Fehler. Gib je Gruppe an: Fehlermeldung wörtlich, erste und letzte Zeit, Anzahl laut Liste.
Zähle nur, was in der Liste steht. Rate keine Ursachen. Wenn etwas unklar ist, schreibe "unklar".

2. Bericht aus Fakten entwerfen

Schreibe einen Kundenbericht (max. eine Seite, sachlich) nur aus diesen geprüften Angaben: [Fakten mit Quelle].
Gliederung: Was lief, Vorfälle, Fehler, nächste Schritte.
Trenne Fakt, Vermutung und offene Frage sichtbar. Erfinde keine Zahlen und keine Erfolge.
Wenn eine Angabe fehlt, schreibe "Angabe fehlt" statt zu ergänzen. Nenne zu jeder Zahl die Quelle aus meinen Angaben.

3. Bericht gegenprüfen

Hier sind Rohdaten: [Rohdaten] und mein Berichtsentwurf: [Entwurf].
Suche zu jeder Zahl und jeder Behauptung im Entwurf die passende Stelle in den Rohdaten und zitiere sie wörtlich.
Finde Behauptungen ohne Beleg und Formulierungen, die einen Erfolg größer darstellen als die Daten.
Liste sie auf, ändere den Entwurf nicht.

Typische Fehler

• Zahlen ohne Methode. "98 % laufen durch" sagt nichts ohne Zeitraum, Zählweise und Quelle. Der Kunde kann nichts nachprüfen.
• Erfolge übertreiben. Eine Zahl, die sich bewegt, ist noch keine Erkenntnis [4]. Wenn weniger Anfragen kamen, sind weniger Läufe kein Fehler. Schreibe, was die Daten tragen.
• Fehler verschweigen oder weichzeichnen. Offenheit ist der Kern von Postmortem-Kulturen [1]. "Kleine Unregelmäßigkeit" ist keine Angabe.
• Das Modell rechnen lassen. Sprachmodelle können Falsches erzeugen, kritische Angaben prüfst du selbst [5].
• Alle Zahlen zeigen. Die Quelle rät zur vereinbarten Scorecard statt zu allen verfügbaren Kennzahlen [4]. Die Obergrenze "höchstens fünf Messwerte" ist eine Arbeitsregel, keine Quellenaussage.
• Personendaten im Bericht. Siehe [1] und Datenschutz. Das ist keine Rechtsberatung.
• Bericht ohne Anschluss. Kein Bericht ohne nächsten Schritt. Wie du Betreuung als Angebot fasst, steht unter Angebot klar formulieren, Preisrahmen unter KI-Automatisierung Preise.

Nächster Schritt

Nimm eine laufende Automatisierung und schreibe den Bericht für die vergangene Woche nach den vier Blöcken, mit Quelle an jeder Zahl. Danach zeigst du ihn einem Kunden zur Probe. Wie du Betreuung sauber anbietest, zeigt Angebot klar formulieren. Wie du den Anfang gestaltest, steht unter Erster Kunde, deine Arbeitsweise prüfst du mit Methode, eine Einschätzung bekommst du im Score.

Quellen

Abrufdatum für alle Quellen: 20.10.2026. HTTP-Status per curl -L: jeweils 200.

1. 1Google, "Site Reliability Engineering", Kapitel "Postmortem Culture: Learning from Failure": https://sre.google/sre-book/postmortem-culture/
2. 2n8n Docs, "Error handling": https://docs.n8n.io/flow-logic/error-handling/
3. 3n8n Docs, "Executions": https://docs.n8n.io/workflows/executions/
4. 4Enterprise DNA (Sam McKay), "AI Client Reporting for Agencies" (Anbieter-Blog): https://enterprisedna.co/resources/insights/agencies-ai-client-reporting-agency
5. 5Anthropic, "Reduce hallucinations": https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/reduce-hallucinations