Rétention dans la fenêtre de 48 heures
Le problème
Les résiliations sont enregistrées, regroupées, puis traitées ultérieurement. Les traitements batch, les processus ETL ou les listes manuelles génèrent de la latence. Les agents reçoivent souvent les dossiers plusieurs heures après l’événement, tandis que la priorisation intervient trop tard ou manuellement. Les fenêtres de traitement critiques sont ainsi réduites ou complètement manquées. La cause réside dans l’architecture des systèmes : de nombreux systèmes historiques sont optimisés pour la cohérence et le stockage des données, et non pour l’exécution en temps réel.
La solution
Le traitement s’effectue en temps réel et de manière orientée événements. Les dossiers sont automatiquement importés, priorisés et routés de façon déterministe vers des files opérationnelles. Les fenêtres de 48 heures sont représentées à l’aide de TTL dans des étapes de campagne définies. Si un dossier atteint cette limite sans être finalisé, une transition basée sur des règles vers l’étape suivante de la campagne est déclenchée, y compris avec des métriques prédéfinies. Le traitement devient ainsi transparent, cohérent et piloté conformément aux SLA.
Interview : La rétention chez un fournisseur d’énergie
Un échange entre un Operations Manager (J) et Dialfire (SA).
J (Fournisseur d’énergie:)
« Notre problème principal était l’incohérence entre l’ERP et le poste de travail des agents. La résiliation était bien présente dans le système, mais toute la logistique de données derrière était lente. Processus ETL, jobs batch, exports manuels. Au moment où un lead apparaissait de manière priorisée dans la file outbound, six à dix heures s’étaient souvent déjà écoulées. En pratique, nous travaillions contre notre propre IT — et contre la fenêtre des 48 heures. »
SA (Dialfire:)
« C’est un problème classique d’architecture. Les systèmes ERP et CRM sont optimisés pour le stockage des données, pas pour une exécution critique en temps réel. Nous positionnons Dialfire comme un hub orchestré entre les deux. Au lieu d’attendre le prochain cycle ETL, l’ERP déclenche un événement. Le dossier est transféré directement vers le moteur de taskflow via webhook. La réponse API est immédiate, sans persistance intermédiaire dans des listes ou des fichiers. »
J (Fournisseur d’énergie:)
« En interne, cela a suscité beaucoup de débats. L’IT était sceptique à l’idée d’ajouter encore un système entre l’ERP et les agents ou les équipes. La crainte portait sur une complexité supplémentaire et davantage de sources d’erreurs potentielles. »
SA (Dialfire:)
« Nous connaissons bien cette discussion. Techniquement, nous réduisons la complexité parce que nous éliminons la logique batch et les transferts manuels. Dialfire est stateless dans le routing, et chaque dossier est traité exactement une fois. En parallèle, des métriques telles que le statut, les détails de statut, les TTL et les règles de transition peuvent être librement définies dans le taskflow. Cela rend le flux de données transparent, flexible et traçable, au lieu d’être fragile. »
J (Fournisseur d’énergie:)
« Un véritable goulet d’étranglement pour nous était la priorisation. Avant, tout était traité chronologiquement. Un client en résiliation avec une forte valeur contractuelle se retrouvait dans la même file qu’un simple dossier administratif. L’agent devait décider lui-même de ce qui était important — sous pression et avec de gros volumes. Cela ne fonctionnait tout simplement pas. »
SA (Dialfire:)
« La priorisation doit appartenir au système, pas à la tête de l’agent. Dans le taskflow, nous attribuons une priorisation dynamique des appels, par exemple via $call_order. Celle-ci dépend du SLA, du motif de résiliation, de la valeur contractuelle ou de l’historique. Les leads nouveaux et critiques remontent en tête de file. En parallèle, nous définissons un TTL (Time-to-Live) de 48 heures. Après 48 heures sans finalisation, le dossier n’est pas automatiquement clôturé. Les 48 heures définissent simplement la durée d’une étape de campagne.
Par exemple : une résiliation est reçue, le client est identifié comme récupérable et transféré à Dialfire via une interface. Là, il démarre dans l’étape d’importation (TTL de 48h), puis passe dans l’étape d’appel pour être traité par les équipes inbound ou des agents individuels. En l’absence de finalisation, le dossier passe de manière déterministe à la tâche suivante, par exemple un webhook de retour vers le système. »
J (Fournisseur d’énergie:)
« Cela a eu un effet mesurable. Notre time-to-first-call a nettement diminué, et pour la première fois nous voyons clairement quels leads sont encore dans le SLA. Avant, les agents perdaient du temps sur des dossiers qui n’avaient déjà plus aucune valeur. »
SA (Dialfire:)
« C’est précisément l’objectif : concentrer le temps de travail net sur les contacts convertibles. Ce qui se passe dans le taskflow est entièrement configurable et suit la logique métier correspondante. Les étapes de campagne peuvent être adaptées dynamiquement : priorités, transitions et règles de traitement ne sont pas statiques, mais pilotables. Ainsi, aucun lead ne reste dans un état indéfini. »
J (Fournisseur d’énergie:)
« Un autre point critique concernait les week-ends. Les résiliations du vendredi soir étaient encore dans le système le lundi, mais déjà hors de toute fenêtre exploitable. Personne n’avait une vue claire de ce qui restait encore utilisable. »
SA (Dialfire:)
« C’est la conséquence de processus rigides. Dans le taskflow, en revanche, des métriques comme le statut et le détail de statut peuvent être définies et liées à des règles de délai précises. Pour chaque étape de campagne, il est possible de définir après quel délai la transition vers l’étape suivante doit avoir lieu — par exemple après 4 heures, 48 heures ou 365 jours. Lors de cette transition, le dossier reçoit exactement le statut ou le détail de statut défini dans la logique. Le processus reste ainsi basé sur des règles et transparent — indépendamment du jour de la semaine ou du moment du traitement. »
J (Fournisseur d’énergie):
« La scalabilité était également critique pour nous. En cas de fort volume, nous avions auparavant des engorgements, des traitements batch retardés et, dans le pire des cas, des appels en double provenant de différentes équipes. Cela coûtait cher et provoquait des discussions internes. »
SA (Dialfire:)
« Le routing est basé sur des événements et évolue horizontalement. Nous traitons plusieurs milliers d’événements par minute. Chaque dossier est routé de manière unique et entièrement journalisé. Les doublons de traitement sont impossibles au niveau du système, quel que soit le volume. »
J (Fournisseur d’énergie:)
« Plus tard, nous avons même étendu ce concept au-delà de la rétention classique des résiliations. Le mot-clé ici, ce sont les signaux d’intention provenant du frontend. »
SA (Dialfire:)
« Par exemple le suivi IP en B2B : lorsque Leadinfo identifie un client existant sur la page tarifaire, c’est un signal clair de forte intention. Ce trigger est transmis directement à Dialfire via webhook et intégré immédiatement dans le taskflow sans délai. Là, le statut actuel détermine quelle tâche sera exécutée ensuite, et le lead est dirigé de manière ciblée vers des agents ou équipes disponibles — avec le contexte associé. D’un point de vue opérationnel, cela ressemble davantage à une gestion proactive de l’inbound qu’à de l’outbound classique. »
J (Fournisseur d’énergie):
« Le plus grand avantage opérationnel pour nous a été que nous n’avons pas eu besoin de reconstruire nos systèmes centraux. L’ERP reste lourd, mais stable. Dialfire agit comme une couche de traitement flexible presque en temps réel : chaque dossier possède un statut qui détermine ce qui se passe ensuite. Il est ensuite transmis à la tâche suivante, qui décide à son tour de la suite selon le statut et la logique. L’architecture peut traiter des volumes extrêmement importants de données, les imports sont très rapides, et les logiques de tâches, mises à jour de statut et transitions pilotées par TTL sont entièrement configurables. »
SA (Dialfire:)
« C’est exactement l’approche. Nous ne remplaçons pas les systèmes existants. Nous contournons leur latence. L’efficacité naît là où les données sont transformées en action sans délai batch — de manière traçable, mesurable et sans étapes manuelles intermédiaires. »