Retention innerhalb des 48-Stunden-Fensters
Das Problem
Kündigungen werden erfasst, gesammelt und erst später weiterverarbeitet. Batch-Läufe, ETL-Prozesse oder manuelle Listen erzeugen Latenz. Agenten erhalten Datensätze oft erst Stunden nach dem Ereignis, Priorisierung erfolgt verspätet oder manuell. Zeitkritische Bearbeitungsfenster werden so verkürzt oder verpasst. Die Ursache liegt in der Systemarchitektur: Viele Bestandssysteme sind auf Konsistenz und Datenhaltung optimiert, nicht auf Echtzeit-Ausführung.
Die Lösung
Die Verarbeitung erfolgt ereignisbasiert in Echtzeit. Datensätze werden automatisch übernommen, priorisiert und deterministisch in operative Queues geroutet. Die 48-Stunden-Fenster werden über TTLs innerhalb definierter Kampagnenstufen abgebildet. Erreicht ein Datensatz diese Grenze ohne Abschluss, erfolgt ein regelbasierter Übergang in die nächste Kampagnenstufe – inklusive definierter Metriken. Bearbeitung wird so nachvollziehbar, konsistent und SLA-konform gesteuert.
Interview: Retention bei einem Energieversorger
Ein Austausch zwischen einem Operations Manager (J) und Dialfire (SA).
J (Energieversorger):
„Unser Kernproblem war die Inkonsistenz zwischen ERP und Agenten-Desktop. Die Kündigung war im System, aber die Datenlogistik dahinter war träge. ETL-Prozesse, Batch-Jobs, manuelle Exporte. Bis ein Lead priorisiert in der Outbound-Queue auftauchte, waren oft sechs bis zehn Stunden weg. Effektiv haben wir gegen unsere eigene IT gearbeitet – und gegen das 48-Stunden-Fenster.“
SA (Dialfire):
„Das ist ein klassisches Architekturproblem. ERP- und CRM-Systeme sind auf Datenhaltung optimiert, nicht auf zeitkritische Ausführung. Wir setzen Dialfire als orchestrierten Hub dazwischen. Statt auf den nächsten ETL-Lauf zu warten, triggert das ERP ein Event. Der Datensatz wird per Webhook direkt an die Taskflow-Engine übergeben. Die API-Response ist sofort da, ohne Zwischenpersistenz in Listen oder Dateien.“
J (Energieversorger):
„Intern war das durchaus umstritten. Die IT war skeptisch, noch ein System zwischen ERP und Agenten oder Teams zu setzen. Die Sorge war: zusätzliche Komplexität, mehr Fehlerquellen.“
SA (Dialfire):
„Die Diskussion kennen wir. Technisch gesehen reduzieren wir Komplexität, weil Batch-Logik und manuelle Übergaben eliminiert werden. Dialfire ist zustandslos im Routing, jeder Datensatz wird genau einmal verarbeitet. Gleichzeitig können Metriken, wie Status, Status-Details, TTLs und Übergangsregeln, im Taskflow frei definiert werden. Das macht den Datenfluss transparent, flexibel und nachvollziehbar, statt fragil.“
J (Energieversorger):
„Ein echter Engpass war die Priorisierung. Früher lief alles chronologisch. Ein Kündiger mit hohem Vertragswert lag in derselben Queue wie ein formaler Vorgang. Der Agent sollte entscheiden, was wichtig ist – unter Zeitdruck und bei Volumen. Das hat nicht funktioniert.“
SA (Dialfire):
„Priorisierung gehört ins System, nicht in den Kopf des Agenten. Im Taskflow vergeben wir eine dynamische Call-Priorisierung, zum Beispiel über $call_order. Die richtet sich nach SLA, Kündigungsgrund, Vertragswert oder Historie. Neue, kritische Leads rücken an den Anfang der Queue. Parallel dazu setzen wir eine TTL (Time-to-Live) von 48 Stunden. Nach 48 Stunden ohne Abschluss wird der Datensatz nicht automatisch geschlossen. Die 48 Stunden definieren lediglich die Laufzeit innerhalb einer Kampagnenstufe.
Ein Beispiel: Kündigung geht ein, der Kunde wird als rückgewinnbar erkannt und per Schnittstelle an Dialfire übergeben. Dort startet er in der Importstufe (48h-TTL), wechselt anschließend in die Call-Stufe zur Bearbeitung durch Inbound-Teams oder einzelne Agenten. Erfolgt kein Abschluss, läuft der Datensatz deterministisch in den nächsten Task, z. B. einen Webhook zurück ins System.”
J (Energieversorger):
„Das hatte einen messbaren Effekt. Unsere Time-to-First-Call ist deutlich gesunken, und wir sehen erstmals sauber, welche Leads überhaupt noch innerhalb der SLA liegen. Früher haben Agenten Zeit auf Datensätze verwendet, die faktisch schon wertlos waren.“
SA (Dialfire):
„Genau darum geht es: Netto-Arbeitszeit auf konvertierbare Kontakte zu konzentrieren. Was im Taskflow passiert, ist vollständig frei definierbar und folgt der jeweiligen Prozesslogik. Kampagnenstufen lassen sich dynamisch anpassen – Prioritäten, Übergänge und Bearbeitungsregeln sind nicht statisch, sondern steuerbar. So bleibt kein Lead in einem undefinierten Zustand.“
J (Energieversorger):
„Ein weiterer Pain Point waren Wochenenden. Kündigungen am Freitagabend waren montags zwar noch im System, aber außerhalb jedes sinnvollen Zeitfensters. Niemand hatte einen klaren Überblick, was noch verwertbar ist.“
SA (Dialfire):
„Das ist die Folge starrer Prozesse. Im Taskflow lassen sich dagegen die Metriken Status- und Status-Detail definieren und mit klaren Regeln für die Verzögerung verknüpfen. Für jede Kampagnenstufe kann festgelegt werden, nach welcher Verzögerung sie in die nächste Stufe übergeht – etwa nach 4 Stunden, 48 Stunden oder 365 Tagen. Beim Übergang erhält der Datensatz exakt den Status bzw. das Status-Detail, das in der Logik definiert ist. Der Ablauf bleibt damit regelbasiert und transparent – unabhängig vom Wochentag oder Bearbeitungszeitpunkt.“
J (Energieversorger):
„Skalierung war für uns ebenfalls kritisch. Bei hohem Volumen hatten wir früher Stau, verzögerte Batch-Läufe und im schlimmsten Fall doppelte Anrufe durch verschiedene Teams. Das war teuer und hat intern für Diskussionen gesorgt.“
SA (Dialfire):
„Das Routing ist eventbasiert und skaliert horizontal. Wir verarbeiten mehrere Tausend Events pro Minute. Jeder Datensatz wird eindeutig geroutet und vollständig protokolliert. Doppelbearbeitung ist systemseitig ausgeschlossen, egal wie hoch das Volumen ist.“
J (Energieversorger):
„Wir haben das Konzept später sogar über die klassische Kündiger-Retention hinaus genutzt. Stichwort Intent-Signale aus dem Frontend.“
SA (Dialfire):
„Zum Beispiel IP-Tracking im B2B: Wenn Leadinfo einen Bestandskunden auf der Tarifseite erkennt, ist das ein klares High-Intent-Signal. Dieser Trigger geht per Webhook direkt in Dialfire und wird ohne Verzögerung in den Taskflow übernommen. Dort entscheidet der aktuelle Status, welcher Task als Nächstes ausgeführt wird, und der Lead wird zielgerichtet an verfügbare Agenten oder Teams weitergeleitet – inklusive Kontext. Operativ ist das eher proaktives Inbound-Management als klassisches Outbound.“
J (Energieversorger):
„Der größte operative Vorteil für uns war, dass wir unsere Kernsysteme nicht umbauen mussten. Das ERP bleibt schwerfällig, aber stabil. Dialfire fungiert als flexible Verarbeitungsschicht und nahezu in Echtzeit: Jeder Datensatz hat einen Status, über den entschieden wird, was als Nächstes mit ihm passiert. Anschließend wird er in den nächsten Task übergeben, der wiederum auf Basis von Status und Logik den weiteren Verlauf bestimmt. Die Architektur kann extrem viele Daten verarbeiten, Imports erfolgen sehr schnell, und Task-Logiken, Status-Updates und TTL-gesteuerte Übergänge sind frei definierbar.“
SA (Dialfire):
„Genau das ist der Ansatz. Wir ersetzen keine Bestandssysteme. Wir umgehen ihre Latenz. Effizienz entsteht dort, wo Daten ohne Batch-Verzögerung in Handlung übersetzt werden – nachvollziehbar, messbar und ohne manuelle Zwischenschritte.“