20,000 Customers, Wrong Product

"On that call, I do three things. I acknowledge their concern genuinely — 'I hear you, this is serious and I'm taking it seriously.' I commit to a specific timeline — 'Give me 90 minutes, I'll come back to you with what I know by 7pm.' And I don't speculate or defend — I don't say 'that doesn't sound right' or 'it might be the SI's fault.' I just commit to finding out.

I'd also ask the Domain Owner to hold off escalating to their own leadership until I come back at 7pm. There's no point in them triggering a panic up their chain based on something we haven't validated yet. That protects them from looking reactive to their own bosses, and it protects us from fighting a political fire alongside the technical one.

Then I investigate. Because a panicked domain owner calling on a Thursday afternoon, pointing the finger at us — that's a claim, not a confirmed incident. Before I mobilise Kraken, I need to know: is this actually real? Is it 20,000 or is it 200? Have any of these customers been billed on the wrong tariff — which in a regulated energy market isn't just a commercial problem, it's potentially an Ofgem compliance issue.

I'm not dismissing the client. But I have a responsibility to Kraken not to trigger an expensive fire drill based on unvalidated information."

"Within 90 minutes, I'd run these four checks. AI accelerates the mechanical work — I'd feed it the legacy-to-Kraken product mapping table to generate the comparison matrix, have it flag anomalies across 20,000 accounts in seconds rather than hours, and build this dashboard from the query results. But I make the judgment calls.

Let me show you what that looks like —

[Click the 'View Live Dashboard' button to open the dashboard in a new browser tab. Scroll through summary stats and sample data.]

You can see the 20,000 flagged versus 12,847 actually affected. The pattern is systematic — one mapping rule. And in the sample data, the contrast between correctly mapped and incorrectly mapped accounts tells the story.

[Switch back to the presentation.]

'Wrong product' in a migration often just means 'differently named in the new system.' I need to see actual rates. Are customers on a tariff that charges them differently from what they agreed to? Overpaying is direct financial harm. Underpaying is revenue exposure for United Energy. The shape of the problem determines the response.

And I'm checking our side too — was the product configured correctly in Kraken? Should the API have caught this? The brief says Kraken validates format but not commercial logic — that could be a gap we need to own. I need to know the answer before the client conversation, not find out during it.

If my investigation confirms it's real and significant — that's the rest of this presentation. If it's overstated, I share my evidence transparently and invite the client to verify. Protect the relationship while protecting Kraken."

"My investigation confirmed the issue is real — 12,847 accounts, not 20,000. Now I need to find where it went wrong. There are five points in the data flow where this could have broken.

Starting at the source: was the legacy data itself incorrect? If customers were on the wrong product in the old system, the Systems Integrator faithfully extracted bad data. We check this by sampling legacy records.

Second: the Systems Integrator's mapping table. This translates legacy product codes into Kraken product IDs. If this table is wrong, every customer in the cohort gets the wrong product. We verify by requesting the mapping table and cross-referencing with United Energy's product catalogue.

Third: even if the mapping table is correct, there could be a bug in the Systems Integrator's transformation logic that applied it incorrectly. We check by comparing actual API payloads against what the mapping table says they should contain.

Fourth: the products themselves in Kraken. Were they configured correctly? If Product A and Product B were set up with swapped details, the mapping could be right but the target is wrong. United Energy's Commercials team needs to audit the product catalogue.

Fifth — and least likely — an API processing anomaly at Kraken's end. We check by comparing our API request logs against what's on the customer accounts now.

My investigation plan works through each of these systematically. I'm not here to assign blame — I'm here to find the failure point with data, so we can fix it with confidence."

"This isn't just a Commercials problem — it radiates across the programme. My investigation confirmed 12,847 affected accounts, not the 20,000 initially reported. Critically, 3,214 of those have already been billed — that means we're dealing with real financial harm to customers. That splits into overpayments — direct customer harm — and underpayments — revenue exposure for United Energy. I've briefed the Billing and Comms Client Delivery Leads and they're on standby. No one is going to be blindsided."

"My plan has three phases. First, contain — we've already paused migrations and I've confirmed the billing impact: 3,214 customers billed incorrectly with £847K exposure. Second, correct — once we have the right mapping confirmed by United Energy and validated by the Systems Integrator, we use Kraken's bulk correction capability. Crucially, United Energy's Commercials team confirms what 'correct' looks like for each mapping — this is their domain, their first real test of the ownership model. I'd coach them through it rather than doing it for them. We validate before running — we don't fix 12,847 accounts wrong a second time. Then batch corrections starting small — 500, validate, scale up. For the 3,214 already billed, we reverse and re-issue. Third, prevent — I'm proposing a validation gate so this can never happen again. No migration batch goes to billing without a product reconciliation sign-off."

"Same facts, five audiences, five tones. Click through each one to see how I'd tailor the communication. The Domain Owner gets empathy and reassurance. The Transformation Director gets a structured briefing with numbers and a plan. The Systems Integrator gets a collaborative investigation request — no blame, just data. Customers get a plain-English apology. And Kraken leadership gets a concise Slack update — contained, plan in place, relationship managed.

Every one of these started as an AI draft. I refined the tone, checked the facts, added the human judgment. That's the workflow: AI gets me to 80%, I close the last 20%."

"I don't talk about AI. I just use it. And you've already seen that throughout this presentation — the dashboard I showed you was built with AI in 20 minutes. The client email started as an AI draft that I refined. The investigation was AI-accelerated. Even this presentation. You didn't notice because it just looked like competent delivery. That's the point.

My system: I maintain four context files — incident log, stakeholder profiles, comms history, decision log. AI drafts arrive informed, not cold. That's why the outputs are good enough to refine rather than rewrite.

Beyond this scenario: scenario modelling for financial exposure before leadership calls, and a living risk register that evolves as the situation does. AI is how I work — not something I talk about."