Dispute Defender

Chaque contestation de paiement chez FlightHub arrivait avec un code de motif, et les preuves nécessaires pour y répondre se trouvaient à plusieurs endroits : dossiers de réservation, historique des paiements et des transactions, dossiers de litige et communications avec les clients. Un analyste devait fouiller chaque système, déterminer ce que ce code exigeait et monter une réponse à la main. Les mêmes étapes d’enquête se répétaient d’un cas à l’autre.

La qualité de la réponse dépendait donc de la personne qui prenait le dossier et du temps dont elle disposait. Les litiges pour fraude non autorisée étaient particulièrement difficiles. Les preuves étaient dispersées, les exigences variaient selon le code de motif, et une file chargée poussait vers des réponses génériques ou incomplètes, précisément là où la constance influait sur les revenus récupérés.

L’objectif n’était pas d’éliminer le jugement. Il s’agissait de donner à chaque réviseur un point de départ complet et structuré, de rendre les preuves manquantes évidentes et de garantir que chaque soumission finale demeure la décision d’une personne.

J’ai conçu et construit Dispute Defender au Solutions Lab de FlightHub. Le système récupère les preuves liées au dossier, au paiement et à la réservation dans des systèmes approuvés, en utilisant uniquement des champs autorisés et en conservant un lien vers chaque source. Il ramène les champs incohérents dans un schéma de dossier canonique, puis applique des règles d’affaires versionnées pour déterminer les preuves exigées par chaque motif de litige. Un processus relié par API rédige ensuite un dossier de réponse structuré dans lequel chaque affirmation importante renvoie au dossier d’où elle provient.

Le schéma prévoit un emplacement pour chaque preuve qu’un motif exige. Si un emplacement est vide, il reste vide et visible. Le système n’invente aucune preuve pour qu’un dossier paraisse complet et ne peut inclure aucune affirmation sans source. Une preuve manquante bloque le dossier au lieu de se cacher derrière un brouillon soigné. Les résultats reviennent dans les rapports, ventilés par motif, pour que la performance soit évaluée segment par segment plutôt que noyée dans une moyenne globale.

Trois problèmes ont façonné cette conception. Un même concept apparaissait différemment d’un système à l’autre, d’où le schéma canonique. Un brouillon soigné pouvait masquer un document manquant; l’absence est donc devenue explicite et bloquante. Et la moyenne globale cachait ce qui se passait dans chaque segment; les rapports ont donc été ventilés par motif. Si je le refaisais, je définirais le contrat de données et le plan d’évaluation avant le premier processus de rédaction. Nous avons appris en cours de route quels champs faisaient autorité, où une preuve pouvait manquer et à quel point un résultat soigné pouvait masquer l’incertitude. Fixer ces contrôles d’abord aurait évité du travail à refaire.