Vom WhatsApp-Video zum bewiesenen Fix

„Die App spinnt" ist keine Fehlermeldung. Es ist ein Gefühl. Und Gefühle kann kein Entwickler beheben — weil niemand weiß, was genau passiert ist, unter welchen Bedingungen, und ob es sich wiederholt oder von selbst verschwunden ist. Das Problem im Direktvertrieb: Dein Team steht abends nach acht Stunden im Feld nicht vor einem Rechner, sondern schickt eine WhatsApp. Was du aus dieser WhatsApp machst, entscheidet darüber, ob der Bug morgen noch da ist oder nicht.

Diese SOP zeigt, wie du aus einer Abend-Meldung einen bewiesenen Fix machst — kein Raten, kein „wir beobachten das mal".

Schritt 1: Das Video-Protokoll — was die Meldung zeigen muss

Ein kurzes Video reicht. WhatsApp ist gut genug. Aber das Video muss drei Dinge zeigen:

Erstens: Der Bildschirm im Moment des Fehlers. Nicht danach, nicht davor. Idealerweise mit dem Finger sichtbar — so sieht man, was getippt wurde und was die App daraufhin gemacht hat.

Zweitens: Den Ablauf unmittelbar davor. Ein kurzes Stück reicht. Was hat der Vertriebler gerade getan? Welches Formular, welchen Schritt? Das Vorher ist oft wichtiger als das Fehler-Moment selbst.

Drittens: Was sichtbar auf dem Bildschirm passiert — nicht, was der Vertriebler erwartet hatte. „Es hat sich was geändert" hilft nicht. „Der Knopf war weg" oder „die App ist zurückgesprungen" hilft.

Dazu fünf schriftliche Angaben — die Vorlage steht am Ende dieses Leitfadens.

Warum das so strikt? Weil ein Fehler, der sich nicht reproduzieren lässt, nicht behoben werden kann. Und weil „am nächsten Tag weg" nicht heißt, dass er behoben ist — er taucht beim nächsten Einsatz unter denselben Bedingungen wieder auf.

Schritt 2: Reproduktion und Einzelbild-Analyse: das Video Bild für Bild

Wenn das Video da ist, beginnt die echte Arbeit: Reproduzieren.

Ein konkreter Fall aus unserem Echtbetrieb, anonymisiert: Ein Vertriebler meldete abends, dass die App einen Kontakt als „Interessiert" markiert habe, obwohl er nur den Bildschirm weggewischt habe. Kein Doppel-Tap, kein versehentliches Tippen auf einen Button — so die Einschätzung.

Die Einzelbild-Analyse des Videos hat gezeigt: Der Tap auf „Wegwischen" fand genau in dem Moment statt, in dem sich eine Zwischenfläche öffnete. Der Finger traf nicht das, was er treffen sollte — sondern das, was sich in diesem Sekundenbruchteil darunter aufbaute. Der Fehler war kein Anzeige-Fehler im klassischen Sinne, sondern ein Timing-Problem: Eine aufschiebende Fläche verschob das Ziel des Taps, ohne dass der Vertriebler es sehen konnte (17.07.2026).

Diese Art von Fehler findest du nicht durch Ausprobieren auf dem Schreibtisch. Du findest ihn, indem du das Video Bild für Bild durchgehst — und dir genau anschaust, in welchem Einzelbild der Finger landet und was in diesem Moment auf dem Bildschirm passiert.

Das ist der Unterschied zwischen „wir haben es nochmal getestet und nichts gesehen" und einem reproduzierten, verstandenen Bug.

Schritt 3: Fix und Beweis statt Behauptung

Eine Meldung „behoben" ist keine Behauptung wert, solange sie unbewiesen bleibt. „Wir haben das behoben" reicht nicht — weder für dich als GF, noch für dein Team im Feld, das dem System wieder vertrauen soll.

Der Beweis läuft über Telemetrie: Auf den Fehlerfall wird ein Zähler gesetzt. Jedes Mal, wenn das fehlerhafte Verhalten auftritt, zählt er hoch. Die Behebung gilt als bewiesen, wenn dieser Zähler 48 Stunden auf null steht — unter echten Feldbedingungen, nicht im Labor (17.07.2026).

Im konkreten Fall oben: Video abends gemeldet, Einzelbild-Analyse über Nacht, Fehler am Folgetag behoben und live gebracht (17.07.2026). Der Zähler blieb auf null. Das ist eine bewiesene Behebung.

Dieser Ablauf hat einen weiteren Vorteil: Du als GF hast keinen Interpretationsspielraum mehr. Du fragst nicht „läuft es jetzt?", du schaust auf eine Zahl. Die Zahl ist null — oder nicht.

Die Vorlage: fünf Angaben für jede Feld-Bug-Meldung

Wenn dein Team abends meldet, braucht ihr genau das — nicht mehr, nicht weniger:

1. Was sollte passieren? — Ein Satz, was der Vertriebler tun wollte.
2. Was ist stattdessen passiert? — Ein Satz, was die App gemacht hat.
3. Wann genau? — Uhrzeit und Schritt im Ablauf (z. B. „nach dem dritten Formularfeld, vor dem Absenden").
4. Auf welchem Gerät? — Modell und Betriebssystem-Version, wenn bekannt.
5. Video — Bildschirm, Finger, der Moment des Fehlers, der Ablauf unmittelbar davor.

Fünf Angaben. Das reicht für eine Reproduktion. Ohne diese fünf Angaben ist eine Fehlermeldung kein Arbeitsauftrag — sie ist ein Gefühl.

Der Selbst-Check

Bevor du entscheidest, ob du dieses System brauchst, vier ehrliche Fragen:

1. Wenn heute Abend ein Vertriebler einen Fehler meldet — wie lange bis zur Behebung, und wie weißt du, dass er wirklich behoben ist?
2. Hast du je einen Bug als „verschwunden" abgehakt, der drei Wochen später unter denselben Bedingungen wieder da war?
3. Kann dein Team in einer WhatsApp-Nachricht die fünf Angaben oben liefern — oder schreibt es „die App spinnt"?
4. Hast du einen Mechanismus, der dir zeigt, wann ein Fehler aufgehört hat aufzutreten — oder verlässt du dich auf Rückmeldungen aus dem Feld?

Wenn du bei zwei oder mehr Fragen zögerst, läuft gerade ein Bug in deinem System, den du nicht siehst — weil niemand ihn dir beweisen kann.

Basis: eigene Betriebszahlen aus dem Echtbetrieb (Stand 07/2026), anonymisiert — keine Kundendaten, keine Anbieter-Interna.