The scope decision on this page, chat channel only, two languages, one contact type gated behind a clean balance check, is the least exciting-looking part of the whole engagement, and it is the part I care about most when I'm reviewing someone else's pilot brief. I have seen more AI-CX pilots fail from scope creep in the first three weeks than from the technology underperforming, and the failure mode is always the same: a pilot that started as one contact type quietly starts answering adjacent questions because the team can see the model handling them fine in testing, and by week four nobody can say cleanly what the pilot actually proved.

The negative-balance-flag exclusion is a detail I would have insisted on myself, and I'd tell this room why. A customer with a negative-balance flag calling about a failed transfer is very often not asking the question they appear to be asking; they're anxious about money that isn't where they expect it, and that anxiety changes what a good answer looks like even when the technical facts are identical to a clean-account customer. A model tuned on the technical facts alone will answer the clean case and the anxious case the same way, and that is precisely the gap between a technically correct answer and a trusted one. Keeping that carve-out is not caution for its own sake; it's the difference between a pilot that holds CSAT and one that quietly erodes it in a way the weekly numbers won't show for a month.

The escalation-leakage metric, capped at four percent and checked weekly rather than only at the pilot's end, is the discipline I'd point to as the difference between a support-led pilot and a vendor-led one. A vendor's own dashboard will show you deflection rate happily, because deflection rate is the number that makes the tool look good. It will not proactively surface how many of those deflected contacts quietly came back within two days, because that number makes the tool look worse. Ferra Pay built the harder metric into the brief itself rather than waiting to discover it in a quarterly review three months in, and that is exactly the sequencing I'd want brought back to my own team.

The one place I'd add a line the brief doesn't have yet: name, explicitly, who has the authority to pause the pilot mid-cycle if the leakage number spikes in week three, not just who reviews it. A metric with no named authority to act on it is a KPI, not a guardrail.

Sockalingam Muthiah · VP, Technical Customer Services & AI-Driven Transformation Leader

Six hundred and forty thousand dollars against a vendor's own estimate of $1.1 million is not a number I'd apologize for in front of a CFO; it's the number I'd lead with, because the gap between those two figures tells the more credible story. I have sat on both sides of that conversation, the one presenting the case and the one signing off on the budget, and a CFO who has seen enough vendor decks develops an instinct for a number that was sized to the total queue rather than to what the pilot is actually scoped to touch. Ferra Pay's case doing that discounting itself, publicly, on the same page as the vendor's bigger number, is what actually earns the room's trust in the smaller figure.

The decision to fund the $640K entirely through redeploying two freed agents onto the nine-day-overdue card-dispute backlog, rather than through a headcount reduction, is the sharper move on this page, and it's the one I'd spend the most time defending in the room. A savings case built on headcount reduction reads, to the team doing the work, as a signal that AI's real purpose is to make them replaceable, and a team that reads that signal correctly stops giving a rollout their honest cooperation, which is the one input no business case can put a number on. Redeploying those two agents against a backlog the team already knows is under-resourced does two things a straight cost-reduction line never does: it produces a second, visible win the team can point to, and it tells the team, correctly, what this pilot is actually for.

Where I'd push harder than this page currently does: the payback period of 5.4 months assumes the redeployed agents clear the card-dispute backlog at their current productivity rate, and backlog work is rarely as clean as steady-state queue work. I would want a second, more conservative payback scenario run against a 20% productivity discount on that redeployed time before this goes to the CFO's office, not because I think the case is wrong, but because the first question a sharp CFO asks about any redeployment-funded case is what happens if the redeployed time doesn't convert as cleanly as assumed. Having that answer ready, rather than discovering the question live in the room, is the entire difference between a business case that survives scrutiny and one that only looks like it does until someone asks the second question.

Sockalingam Muthiah · VP, Technical Customer Services & AI-Driven Transformation Leader

The ordering of this plan, build first, then run with weekly review, then decide whether to scale, mirrors how I've sequenced every AI-driven change I've made that actually stuck, and the phase I'd flag as most likely to get compressed under pressure is the first one. Thirty days to confirm the CSAT floor and the redeployment plan with the CFO's office before a single live contact is answered looks, to anyone watching a launch date slip, like thirty days of nothing shipping. It is nothing of the sort. Every disagreement about what counts as success that doesn't get resolved in that window resurfaces in week six as a disagreement about the results instead, and a disagreement about results is a much worse place to discover you and the CFO's office never actually agreed on the bar.

The weekly cadence in days thirty-one to sixty, human-review sample and leakage check every Friday rather than one end-of-pilot report, is the part of this plan I'd hold Ferra Pay to most strictly, because it's the part a busy pilot lead is most likely to let slip to biweekly once the early numbers look fine. I have watched exactly that slippage happen, and the number that always moves first when review cadence loosens is the leakage rate, quietly, because a reopened contact from ten days ago doesn't show up cleanly in a review that only looks back seven.

What I'd add explicit weight to, because this plan already gestures at it but doesn't say it plainly enough: the instruction in days sixty-one to ninety to name any guardrail that was quietly loosened during the live weeks, before scaling, not after. That single sentence is the difference between a rollout plan a team trusts and one it tolerates. A team watches what a leader does when a guardrail becomes inconvenient far more closely than it listens to what a leader says about guardrails in the kickoff meeting. If Ferra Pay's pilot lead can stand in front of the frontline team in week thirteen and say plainly which limits held and which ones bent under pressure, that honesty is worth more to the next contact type's rollout than a clean set of final numbers with no such accounting behind them. That is the entire argument I built this course around: the technology decides whether a pilot works in the first ninety days, but whether the team hands you the next ninety days willingly is decided by how honestly you account for the first.

Sockalingam Muthiah · VP, Technical Customer Services & AI-Driven Transformation Leader