Alexander Dade

All programs

Program 1 of 2

Scaling an AI payment check from 2 products to 22

Case study · Meta, Global Scaled Operations · 2025 to 2026

At a glance

Role
Senior Technical Program Manager, contract
Scope
22 products · 15+ markets · 14,000+ agents · 3 engineering teams
Result
Average handling time from 19 minutes to 9
My part
The case for it, the pass criteria, the gates, the data it ran on, and the defect loop. Engineering built the tool.

The problem

Support agents verified payments for people buying Meta products and advertising. Every case meant working the same checks by hand, from account standing and card ownership to the rules of each jurisdiction, and matching invoice numbers and licenses with the payments and risk teams. A case took 19 minutes on average.

I saw an automation opportunity in those checks and pitched an AI feature built into the agents’ case software. It ran in the background during normal case handling, and agents acted on its output.

Sequence

  1. Opportunityspotted and pitched
  2. Business caseand a feasibility test
  3. Pass criteriaset in advance
  4. Pilot2 products
  5. Scalea gate per product, to 22

Fig. 1The rollout sequence. Each product moved forward only after it cleared its own gate.

How it ran

AI payment check, 2 products to 22: the program, in order

  1. Make the business case before every build.

    Server capacity, resource allocation, and usage cost went into the business justification before each build started. Nothing was built without one, and after launch the results were reported against it.

  2. Start with a pilot.

    I ran a feasibility experiment first, then took the tool live as a pilot on two products.

  3. Set the pass bar before the build.

    I ran a workshop where the product owner and knowledge owners set the OKRs and thresholds in advance. The pass criteria were adoption and a measured cut in handling time.

  4. Gate every product.

    Each product after the pilot had to clear its own phase gate, with kill criteria written down before it started.

  5. Govern what the tool reads.

    The tool read from a separate, machine-only knowledge base. I governed what went into it, with named owners, restricted write access, and a RACI.

  6. Run the defect loop.

    In testing I flagged suspect fields. The engineer confirmed or corrected the location and committed a fix time, and I cut the ticket and assigned it.

  7. Fix cost and speed.

    When it ran slow and heavy on tokens, I ran the review that found why, and it was restructured to use fewer tokens and respond faster.

  8. Scale it.

    The rollout reached 22 products and 15+ markets across three engineering teams and 14,000+ agents.

Failure modes and controls

Failure modes and the controls built for them
Failure modeControl
The tool fails on a case.It detected its own failures. The agent fell back to the manual process they already knew, so agents needed no retraining.
The same failure keeps coming back.Engineering was notified of every failure. We collected them to spot trends and worked the trends in a weekly workshop.
An agent disagrees with the output.Scope limits were written into the protocol. On risk, impersonation, and bad actor cases, agents followed the output and could flag the case for review.
Bad data goes in.The machine-only knowledge base had named owners and restricted write access.
A product misses its numbers.Its kill criteria applied at its gate, and it stopped there.
The tool fails on a case.
Control
It detected its own failures. The agent fell back to the manual process they already knew, so agents needed no retraining.
The same failure keeps coming back.
Control
Engineering was notified of every failure. We collected them to spot trends and worked the trends in a weekly workshop.
An agent disagrees with the output.
Control
Scope limits were written into the protocol. On risk, impersonation, and bad actor cases, agents followed the output and could flag the case for review.
Bad data goes in.
Control
The machine-only knowledge base had named owners and restricted write access.
A product misses its numbers.
Control
Its kill criteria applied at its gate, and it stopped there.

Results

  • 19 → 9minutes, average handling time
  • 22products, from a pilot of 2
  • 15+markets
  • 14,000+agents using it

What colleagues said

  • …he owned the knowledge foundation behind it, driving a large-scale KB feedback audit and delivering the knowledge-base overhaul that made the Co-Pilot recommendations trustworthy and deployable as the program scaled from experiments to production.

    Sharmilla AbhilashGlobal Operations Senior Program Manager, Meta · Worked with Alexander on a different team · July 2026
    Read the full recommendation

    I had the pleasure of working closely with Alexander in Ads, Co-pilot & MPS programs, and he's one of the dependable partners I've collaborated with. Alexander played a key role in Co-Pilot program launch (improving human agent resolution capabilities by providing proactive guidance and resolution using AI) where he owned the knowledge foundation behind it, driving a large-scale KB feedback audit and delivering the knowledge-base overhaul that made the Co-Pilot recommendations trustworthy and deployable as the program scaled from experiments to production. Co-pilot was launched in Advertiser program and it helped improve CSAT by 3 - 5% in some of the crucial workflows.

    He also partnered directly with product, engineering, and program leadership on knowledge readiness for AI launches -- flagging draft gaps before go-live, aligning on where content should live, and ensuring quality requirements were built in correctly rather than bolted on afterward. He did all of it with positivity and a calm, solutions-first mindset that made every collaboration better. In his knowledge management role, Alexander was the person who consistently turned complex requirements into clear, usable guidance for frontline support teams. Any team building or scaling AI programs would be lucky to have Alexander. I recommend him without hesitation.