Retention Within the 48-Hour Window
The Problem
Cancellations are recorded, collected, and only processed later. Batch runs, ETL processes, or manual lists create latency. Agents often receive records hours after the event, while prioritization happens too late or manually. As a result, time-critical processing windows are shortened or missed entirely. The root cause lies in the system architecture: Many legacy systems are optimized for consistency and data storage, not for real-time execution.
The Solution
Processing takes place in real time on an event-driven basis. Records are automatically imported, prioritized, and deterministically routed into operational queues. The 48-hour windows are mapped through TTLs within defined campaign stages. If a record reaches this limit without completion, a rule-based transition into the next campaign stage is triggered — including predefined metrics. This ensures that processing is transparent, consistent, and managed in compliance with SLAs.
Interview: Retention at an Energy Supplier
A conversation between an Operations Manager (J) and Dialfire (SA).
J (Energy Supplier:)
“Our core problem was the inconsistency between the ERP system and the agent desktop. The cancellation existed in the system, but the data logistics behind it were sluggish. ETL processes, batch jobs, manual exports. By the time a lead appeared in the outbound queue with proper prioritization, six to ten hours had often already passed. In practice, we were working against our own IT — and against the 48-hour window.”
SA (Dialfire:)
“This is a classic architecture problem. ERP and CRM systems are optimized for data storage, not for time-critical execution. We position Dialfire as an orchestrated hub in between. Instead of waiting for the next ETL cycle, the ERP triggers an event. The record is transferred directly into the taskflow engine via webhook. The API response is immediate, without intermediate persistence in lists or files.”
J (Energy Supplier:)
“Internally, this was quite controversial. IT was skeptical about placing yet another system between the ERP and agents or teams. The concern was additional complexity and more potential sources of error.”
SA (Dialfire:)
“We know that discussion well. Technically speaking, we reduce complexity because batch logic and manual handovers are eliminated. Dialfire is stateless in routing, and every record is processed exactly once. At the same time, metrics such as status, status details, TTLs, and transition rules can be freely defined within the taskflow. This makes the data flow transparent, flexible, and traceable instead of fragile.”
J (Energy Supplier:)
“A real bottleneck for us was prioritization. Previously, everything ran chronologically. A cancellation with high contract value ended up in the same queue as a purely formal process. The agent was expected to decide what mattered most — under time pressure and high volume. That simply did not work.”
SA (Dialfire:)
“Prioritization belongs in the system, not in the agent’s head. In the taskflow, we assign dynamic call prioritization, for example via $call_order. This is based on SLA, cancellation reason, contract value, or history. New and critical leads move to the front of the queue. In parallel, we set a TTL (Time-to-Live) of 48 hours. After 48 hours without completion, the record is not automatically closed. The 48 hours merely define the runtime within a campaign stage.
For example: A cancellation is received, the customer is identified as recoverable, and transferred to Dialfire via interface. There, it starts in the import stage (48h TTL), then moves into the call stage for processing by inbound teams or individual agents. If no completion occurs, the record deterministically moves into the next task, e.g. a webhook back into the system.”
J (Energy Supplier:)
“That had a measurable impact. Our time-to-first-call dropped significantly, and for the first time we can clearly see which leads are still within SLA. Previously, agents spent time on records that were effectively already worthless.”
SA (Dialfire:)
“That is exactly the point: concentrating net working time on convertible contacts. What happens inside the taskflow is completely configurable and follows the respective process logic. Campaign stages can be adjusted dynamically — priorities, transitions, and processing rules are not static, but controllable. This ensures that no lead remains in an undefined state.”
J (Energy Supplier:)
“Another pain point was weekends. Cancellations submitted on Friday evening were still in the system on Monday, but already outside any meaningful time window. Nobody had a clear overview of what was still usable.”
SA (Dialfire:)
“That is the consequence of rigid processes. In the taskflow, however, metrics such as status and status detail can be defined and linked with clear delay rules. For each campaign stage, it can be specified after which delay the transition into the next stage occurs — for example after 4 hours, 48 hours, or 365 days. During the transition, the record receives exactly the status or status detail defined in the logic. This keeps the workflow rule-based and transparent — regardless of the weekday or processing time.”
J (Energy Supplier):
“Scalability was also critical for us. Under high volume, we previously experienced bottlenecks, delayed batch runs, and in the worst case duplicate calls from different teams. That was expensive and caused internal discussions.”
SA (Dialfire:)
“The routing is event-based and scales horizontally. We process several thousand events per minute. Every record is uniquely routed and fully logged. Duplicate processing is systematically impossible, regardless of the volume.”
J (Energy Supplier:)
“We later even expanded the concept beyond classic cancellation retention. The keyword here is intent signals from the frontend.”
SA (Dialfire:)
“For example, IP tracking in B2B: When Leadinfo recognizes an existing customer on the pricing page, that is a clear high-intent signal. This trigger is sent directly into Dialfire via webhook and immediately transferred into the taskflow without delay. There, the current status determines which task is executed next, and the lead is routed purposefully to available agents or teams — including context. Operationally, this is more proactive inbound management than classic outbound.”
J (Energy Supplier):
“The biggest operational advantage for us was that we did not have to rebuild our core systems. The ERP remains cumbersome, but stable. Dialfire acts as a flexible processing layer operating almost in real time: Every record has a status that determines what happens next. It is then handed over to the next task, which in turn determines the further flow based on status and logic. The architecture can process extremely large amounts of data, imports are very fast, and task logics, status updates, and TTL-controlled transitions are freely configurable.”
SA (Dialfire:)
“That is exactly the approach. We do not replace legacy systems. We bypass their latency. Efficiency emerges where data is translated into action without batch delays — traceable, measurable, and without manual intermediate steps.”