Wundercode Projekt anfragen

Eigene Arbeitsprobe · Fiktive Daten · CRM simuliert

01Das Problem

Was passiert mit einer Anfrage, wenn das CRM nicht antwortet?

Jemand schickt eine Anfrage über eure Website. Die Übergabe ins CRM bleibt ohne Antwort – und ab da wird geraten. Ist der Kontakt angelegt? Darf man noch einmal senden? Hat schon jemand angerufen?

Aus genau dieser Unsicherheit entstehen die beiden Fehler, die kein Team will: Anfragen, die liegen bleiben. Und Menschen, die zweimal kontaktiert werden.

Das hier ist keine Kundengeschichte. Es ist eine eigene Arbeitsprobe, die ich lokal gebaut und getestet habe – mit erfundenen Kontakten und einem simulierten CRM. Sie zeigt, wie ich solche Übergaben angehe.

„Ich habe den Ablauf so gebaut, dass unklare Antworten sichtbar bleiben – und nicht einfach ein zweiter Kontakt entsteht.“

Hasan Badruk, Wundercode
Echtes Bildschirmfoto der lokal laufenden Arbeitsprobe mit fiktiven Testdaten. Links eine Liste von Testanfragen, mehrere mit dem Status „Vom Mock-CRM bestätigt“. Rechts ist „Interessent 006“ geöffnet: Eingang und Zuordnung sind erledigt, das CRM-Ergebnis lautet „Empfang unklar – angehalten“. Darunter der Hinweis „Empfang unklar – nichts wird erneut gesendet“, weil ein blinder zweiter Versuch einen doppelten Vorgang anlegen könnte.

Abb. 1Bildschirm aus der lokalen Arbeitsprobe, 18. Oktober 2026

Gezeigt ist bewusst ein ungeklärter Fall. Das Bild belegt nicht, dass alle Anfragen abgeschlossen wurden. Alle Namen sind erfunden, die Adressen nicht zustellbar. Nummern nachträglich ergänzt.

  1. Andere Testanfragen: vom simulierten CRM bestätigt.
  2. Die geöffnete Anfrage: Empfang unklar, kein erneuter Versuch.
  3. Hinweis fürs Team: was jetzt möglich ist – und was gesperrt bleibt.

Originalbild in voller Größe öffnen Erklärt in Testfall 03

Das eigentliche Risiko ist selten der Ausfall selbst. Es ist die Unsicherheit danach.

Deshalb behandelt die Arbeitsprobe „keine Antwort“ weder als Erfolg noch als Fehler, sondern als eigenen, sichtbaren Zustand. Wie das konkret aussieht, zeigen vier Testfälle.

02Testfälle

Vier Testfälle, rückblickend erklärt

Ich habe den Ablauf an vier typischen Situationen durchgespielt. Pro Fall: was ohne klare Regel passieren kann, wie sich die Arbeitsprobe verhält – und was dabei tatsächlich geprüft wurde.

Rückblick, keine Vorführung. Auf dieser Seite wird nichts ausgeführt. Die Ergebnisse unten sind dokumentiert, nicht live erzeugt.

Testfall 01 · Normalfall

Die Anfrage kommt an, das CRM bestätigt.

Eine neue Anfrage kommt über das Formular. Das simulierte CRM nimmt sie an und meldet den Empfang zurück.

Ohne klare Regel

Meist geht das gut. Aber oft bleibt davon nur ein Eintrag in einem Protokoll, das niemand liest. Ob und wann die Anfrage wirklich angekommen ist, sucht man später mühsam zusammen.

Mit diesem Ablauf

Die Anfrage wird erfasst, einem zuständigen Team zugeordnet und einmal übergeben. Die Bestätigung steht als Status sichtbar an der Anfrage.

Tatsächlich geprüft

  • Es entstand genau ein Datensatz im simulierten CRM.

Von Hand im Browser nachgeprüft.

Testfall 02 · Doppelt gesendet

Dieselbe Anfrage kommt ein zweites Mal.

Das Formular oder ein vorgeschaltetes System liefert dasselbe Ereignis erneut – zum Beispiel, weil es nach einer Störung automatisch wiederholt.

Ohne klare Regel

Im CRM stehen zwei Kontakte, im Team zwei Aufgaben. Im ungünstigsten Fall melden sich zwei Leute bei derselben Person.

Mit diesem Ablauf

Das wiederholte Ereignis wird als bekannt erkannt, es entsteht kein zweiter Datensatz. Schreibt dieselbe Person später wirklich noch einmal, ist das eine neue Anfrage – und wird auch so geführt.

Tatsächlich geprüft

  • Dasselbe Ereignis erneut eingespielt: kein zweiter Datensatz.
  • Eine neue Anfrage mit derselben Test-Adresse blieb eine eigene, getrennte Anfrage.

Von Hand im Browser nachgeprüft.

Testfall 03 · Bestätigung fehlt

Das CRM antwortet nicht.

Die Anfrage geht an das simulierte CRM, doch die Bestätigung kommt nie zurück. Ob sie angekommen ist, weiß in diesem Moment niemand.

Ohne klare Regel

Entweder wird blind erneut gesendet – und es entsteht womöglich ein doppelter Kontakt. Oder der Fall gilt stillschweigend als erledigt – und die Anfrage geht verloren.

Mit diesem Ablauf

Die Anfrage bekommt den Zustand „Empfang unklar“ und wird angehalten. Erneut senden ist gesperrt; erlaubt ist nur, im CRM nachzulesen. Gibt es den Vorgang dort schon, wird er bestätigt. Ist das Ergebnis nicht eindeutig, bleibt die Anfrage angehalten – und sichtbar.

Tatsächlich geprüft

  • Der Zustand blieb „unklar“ – weder „fehlgeschlagen“ noch „erledigt“.
  • Das Nachlesen fand den bereits angelegten Datensatz im simulierten CRM und bestätigte ihn, ohne erneut zu senden.
  • War das Nachlesen nicht eindeutig, blieb die Anfrage angehalten.

Von Hand im Browser nachgeprüft. Genau diesen Zustand zeigt Abb. 1.

Testfall 04 · Bewusster Neustart

Das CRM hat nachweislich nicht angenommen.

Das simulierte CRM meldet eindeutig, dass es die Anfrage nicht angenommen hat. Jetzt ist belegt: Dort gibt es keinen Vorgang.

Ohne klare Regel

Jemand legt den Kontakt von Hand an oder stößt einen neuen Versuch an – ohne Begründung und ohne Spur. Arbeiten zwei Personen parallel daran, passiert es doppelt.

Mit diesem Ablauf

Erst wenn die Nichtannahme belegt ist, kann eine Person einen neuen Versuch freigeben: einmal, mit Begründung und nur auf dem aktuellen Stand der Anfrage. Wer mit einer veralteten Ansicht arbeitet, kann nichts überschreiben.

Tatsächlich geprüft

  • Nach belegter Nichtannahme war genau ein begründeter neuer Versuch möglich – abgesichert gegen veraltete Stände.
  • Ein veralteter zweiter Browser-Tab wurde abgewiesen (HTTP 409), ohne dass etwas geschrieben wurde.

Von Hand im Browser nachgeprüft.

03Nutzen

Was dein Team von diesem Ansatz hat

Die Technik ist nur Mittel. Entscheidend ist, dass zu jeder Anfrage jederzeit vier Dinge klar sind – ohne dass jemand nachfragen muss.

  1. Wer zuständig ist

    Jede Anfrage hat ein verantwortliches Team oder eine Person. Fehlt eine Angabe – in der Arbeitsprobe etwa das betroffene Objekt –, wird die Zuordnung nicht geraten, sondern mit Begründung nachgeholt.

  2. Wo die Anfrage steht

    Eingegangen, zugeordnet, bestätigt oder unklar: Der Stand ist auf einen Blick sichtbar. Ist die Verbindung weg, wird das angezeigt – und alles, was etwas verändern würde, ist gesperrt.

  3. Was bisher passiert ist

    Wer hat wann was entschieden – und warum? Zuordnungen und neue Versuche verlangen eine Begründung, damit der Verlauf später lesbar bleibt. In der Arbeitsprobe überstand der Stand auch einen Neustart des Programms.

  4. Was jetzt zu tun ist

    Statt einer kryptischen Fehlermeldung steht da ein klarer nächster Schritt für einen Menschen – etwa „Status im CRM nachlesen“ – und was in diesem Zustand bewusst nicht erlaubt ist.

Warum „keine Bestätigung“ nicht automatisch „fehlgeschlagen“ heißt

Bleibt die Antwort des CRM aus, gibt es zwei Möglichkeiten: Die Anfrage ist nie angekommen. Oder sie ist angekommen – und nur die Bestätigung ging auf dem Rückweg verloren. Von außen sehen beide Fälle gleich aus.

Wer dann automatisch „Fehler“ annimmt und neu sendet, riskiert einen doppelten Kontakt. Wer „wird schon geklappt haben“ annimmt, riskiert eine verlorene Anfrage. Deshalb gibt es einen dritten Zustand: unklar. Die Anfrage bleibt angehalten, bis im CRM nachgelesen wurde, was wirklich passiert ist.

Ausschnitt aus demselben Bildschirmfoto der Arbeitsprobe mit fiktiven Daten: Kasten „Aktueller Stand und nächster Schritt“ mit der Überschrift „Empfang unklar – nichts wird erneut gesendet“. Erklärt wird, dass das simulierte CRM nicht geantwortet hat und ein blinder zweiter Versuch einen doppelten Vorgang anlegen könnte. Eine Wiederaufnahme ist gesperrt; möglich ist nur, den Status im simulierten CRM nachzulesen.
Ausschnitt aus Abb. 1: Diesen Hinweis sieht das Team im Zustand „unklar“.

Drei Zustände statt zwei

Bestätigt
Das CRM hat den Vorgang. Nichts weiter zu tun.
Unklar
Keine Antwort. Anhalten, im CRM nachlesen – nicht neu senden.
Nachweislich nicht angenommen
Belegt, dass dort nichts angelegt wurde. Ein begründeter neuer Versuch ist erlaubt – einmal.

04Belege & Grenzen

Was belegt ist – und was nicht

Eine Arbeitsprobe ist kein Kundenprojekt. Deshalb hier ohne Aufrunden: was geprüft wurde, und wo die Aussagekraft endet.

Belegt

18 gezielte automatisierte Tests der Ablauf-Logik – alle bestanden.

Zusätzlich von Hand im Browser durchgespielt: die vier Testfälle und diese Ausnahmen.

  • Normalfall: genau ein Datensatz.
  • Dasselbe Ereignis erneut: kein zweiter Datensatz.
  • Fehlende Bestätigung: Zustand „unklar“; Nachlesen bestätigt den vorhandenen Datensatz ohne erneuten Versand.
  • Nachlesen nicht eindeutig: Anfrage bleibt angehalten.
  • Belegte Nichtannahme: genau ein begründeter, versionsgesicherter neuer Versuch.
  • Neue Anfrage mit derselben Test-Adresse: eigene Anfrage.
  • Fehlendes Objekt: Zuordnung nur mit Begründung.
  • Veralteter zweiter Tab: abgewiesen (HTTP 409), nichts geschrieben.
  • Ohne Verbindung: Zustand gekennzeichnet, ändernde Aktionen gesperrt.
  • Neustart des Programms: lokaler Stand exakt erhalten.

Der Bildschirm in Abb. 1 stammt aus genau dieser lokal geprüften Oberfläche. Original ansehen

Nicht belegt

  • Kein Kundeneinsatz. Es gibt keine Kundenergebnisse, keine gemessenen Einsparungen und keine Referenz aus dem laufenden Betrieb.
  • Kein echtes CRM. Das CRM ist simuliert. Über die Anbindung an ein bestimmtes CRM oder Automatisierungswerkzeug sagt die Probe nichts aus.
  • Keine Betriebszusagen. Keine zugesicherte Verfügbarkeit oder Reaktionszeit (SLA).
  • Keine Garantie für „genau einmal“. Die Probe garantiert nicht, dass ein externes System jede Anfrage exakt einmal erhält. Sie sorgt dafür, dass Unklarheit sichtbar bleibt, statt sie zu überspielen.
  • Keine echten Daten. Keine Kundendaten, kein E-Mail-Versand, kein KI-Modell, keine externe Schnittstelle.
  • Kein Gesamtbild aus einem Bild. Abb. 1 zeigt bewusst einen ungeklärten Fall. Daraus folgt nicht, dass alle Anfragen abgeschlossen wurden.
Technik in Kürzefür alle, die es genau wissen wollen

Eine eigenständige Engine in Python, die Daten lokal und dauerhaft in SQLite speichert. Das CRM dahinter ist eine deterministische Simulation: Je nach Testfall nimmt es an, bleibt stumm oder lehnt ab – jedes Mal reproduzierbar gleich.

Ein erneut eingespieltes Ereignis erzeugt keinen zweiten Datensatz. Ändernde Schritte sind an den aktuellen Stand der Anfrage gebunden: Wer mit einem veralteten Stand schreiben will, bekommt HTTP 409, und es wird nichts geschrieben. Bedient wurde das Ganze über eine lokale Oberfläche im Browser.

Diese Seite selbst ist eine statische Erklärung. Von der Engine läuft hier nichts, und es werden keine Daten gesendet.

05Nächster Schritt

So würden wir deinen Ablauf prüfen

Jeder Ablauf ist anders: andere Quellen, andere Tools, andere Menschen. Deshalb beginne ich nicht mit einer fertigen Lösung, sondern mit eurem tatsächlichen Stand.

  1. Ist-Stand ansehen

    Woher kommen eure Anfragen – Website-Formular, Portal, E-Mail? Welche Tools und welches CRM nutzt ihr? Und wo geht heute etwas verloren oder landet doppelt?

  2. Begrenzten Pilot vereinbaren

    Eine Quelle, ein Ziel, klare Abnahmekriterien – zum Beispiel: „Dieselbe Anfrage erzeugt keinen zweiten Kontakt.“ Umfang und Angebot halten wir schriftlich fest, bevor gebaut wird.

  3. Umsetzen und testen

    Mit dem Zugang, den du dafür freigibst, in eurer Umgebung und zuerst mit Testdaten. Geprüft wird gegen die vereinbarten Kriterien.

  4. Dokumentiert übergeben

    Ihr bekommt eine Übergabe, die zeigt, was läuft, wie unklare Fälle gelöst werden und wer was tut – damit nichts an einer einzelnen Person hängt.

Der sinnvolle nächste Schritt: ein bezahlter, klar begrenzter Pilot.

Wenn bei euch Anfragen zwischen Formular und CRM liegen bleiben oder doppelt landen, schreib mir kurz, woher eure Anfragen kommen und welche Tools ihr nutzt. Kundendaten brauche ich dafür nicht.

Lieber erst sprechen? Ein optionales 20-minütiges Projektgespräch ist möglich – erwähn es einfach in deiner Nachricht.

Ablauf prüfen lassen Mehr über Wundercode

Hasan Badruk, Wundercode – selbstständig seit 2016, Freelancer seit 2019, seit 2022 in Vollzeit im Agenturgeschäft in Dubai.