Dispute Defender

Every chargeback dispute at FlightHub came with a reason code, and the evidence needed to answer it lived in several places: booking records, payment and transaction history, dispute records and customer communications. An analyst had to search each system, work out what that reason code required, and assemble a response by hand. The same investigative steps repeated case after case.

That made response quality depend on who picked up the case and how much time they had. Unauthorized-fraud disputes were especially hard. Evidence was spread across systems, requirements varied by reason code, and a busy queue pushed people toward generic or incomplete answers at exactly the point where consistency affected how much revenue was recovered.

The goal was not to remove judgment. It was to give every reviewer a complete, structured starting point, make missing evidence obvious, and make sure each final submission was still a person's decision.

I designed and built Dispute Defender in FlightHub's Solutions Lab. It pulls case, payment and booking evidence from approved systems, using approved fields only and keeping a link to each source. It maps inconsistent fields into one canonical case schema, then applies versioned business rules to decide which evidence each dispute reason requires. An API-connected workflow drafts a structured response package in which every material claim points back to the record it came from.

The case schema has a slot for each piece of evidence a reason needs. If a slot is empty, it stays empty and visible. The system does not invent evidence to make a package look complete, and it cannot include a claim that has no source. Missing evidence blocks the package instead of hiding behind a polished draft. Outcomes flow back into reporting split by reason label, so performance is judged for each segment rather than lost in an overall average.

Three problems shaped that design. The same concept appeared differently across systems, which is why the canonical schema exists. Polished drafts could conceal a missing document, so absence became explicit and blocking. And the overall average hid what was happening inside each segment, so reporting was split by reason. If I built it again, I would define the data contract and the evaluation plan before the first drafting workflow. We learned during implementation which fields were authoritative, where evidence could be absent and how easily polished output could hide uncertainty. Settling those controls first would have saved rework.