HOST_A: Welcome. Today we're doing something a little different — this is a mock interview prep session for the Wonderful.ai decomposition case study interview. I'm Emma, and I'll be playing the Wonderful interviewer. Ryan is going to be our candidate. Ryan, before we start — are you ready for this?

HOST_B: Ready as I'll ever be. Though I have a feeling you're going to make this genuinely uncomfortable.

HOST_A: That's the point. Let me set the stage first. Wonderful.ai is an enterprise AI agent platform. They deploy AI agents across voice, chat, and email — for customer service, sales, HR, finance, legal, IT workflows. What makes them different isn't that they do AI. It's that they do multilingual, culturally-fluent, locally-deployed AI at scale. They operate in over 30 countries. They've hit an 80% resolve rate on customer interactions. They just closed a 150-million-dollar Series B in March 2026. And they've partnered with McKinsey to combine transformation consulting with their platform and forward-deployed engineers. This is a company moving very fast.

HOST_B: And the interview format reflects that. The decomposition case study isn't a McKinsey market-sizing exercise. It's applied. They give you a real client problem — a bank, a healthcare insurer, a media company — and they watch how you think. Not what you know. How you think.

HOST_A: Exactly. What they're testing for — six things. One: do you clarify before jumping to solutions? Two: can you decompose a messy problem into clean components? Three: do you quantify? Volume, cost, effort, impact. Four: do you identify constraints proactively — regulation, integration complexity, trust? Five: can you prioritise ruthlessly? And six: do you actually understand AI agents specifically — not just "AI in general"?

HOST_B: That last one is important. There's a big difference between someone who says "we should use AI here" and someone who understands the distinction between an informational agent, a transactional agent, and a decisional AI system. Wonderful builds agents that resolve — not just deflect. That distinction matters enormously.

HOST_A: Alright. Before we get into the cases, let's walk through the framework you should have in your head going into any decomposition case. Ryan — take us through it.

HOST_B: Right. I call it the DECOMPOSITION framework, which is a bit contrived but it works. Seven steps. Step one: clarify the situation. What is the actual business problem — not the tech problem? What's the current state? What's the pain metric they care about? Cost? CSAT? Resolve rate? Get this wrong and everything downstream is wrong.

HOST_A: Good. Step two?

HOST_B: Map the workflow space. Before you narrow down, you have to map the full universe. What are ALL the interaction types? Don't jump to the one that's obvious. Draw the whole picture first — then we'll prioritise.

HOST_A: Three?

HOST_B: Segment by automability. For each workflow type, score it on two dimensions: first, volume times handle time — that's the total FTE load. Second, AI-readiness — how structured is the interaction, how high is the regulatory risk, how much judgment is required? The sweet spot is High Volume, Low Complexity. That's where you start. Always.

HOST_A: Four?

HOST_B: Quantify the opportunity. Contacts per month, multiplied by handle time, multiplied by fully-loaded cost — gives you the current cost of that interaction type. Apply your estimated automation rate. That's your potential saving. Do this for each category. Then sum it up and build the business case.

HOST_A: Five?

HOST_B: Identify blockers. Regulation — especially in EU markets. GDPR, PSD2 for banking, SGB V for German healthcare. Integration complexity — what systems does the agent need to talk to, and are those systems modern enough to talk back? Trust and adoption — customers in some markets are more sceptical of AI than others. Data availability — does the client even have the data the agent needs? These blockers don't kill the project but they change the phasing and the cost.

HOST_A: Six?

HOST_B: Propose a phased roadmap. Thirty days: what's the quick win? Ninety days: what's the first measurable impact? Six months: where are we? Eighteen months: what's the end state? Interviewers want to see you think in phases, not just in end states.

HOST_A: And seven?

HOST_B: Risks and mitigations. What could go wrong? What's the regulatory exposure? What happens if automation rate is lower than projected? What if a customer gets bad information and takes financial action on it? Every risk needs a mitigation. Not a dismissal — a mitigation.

HOST_A: Good. That's the framework. Now let's stress-test it. Case one. Banking. Full walkthrough. Ryan — I'm the Wonderful interviewer. You're the candidate. Here we go.

HOST_A: Our client is a tier-two European bank. Three million retail customers. Their contact centre handles 45,000 contacts per day — across voice calls and chat. Average handle time is 9 minutes. First contact resolution is 67%. They're spending 42 million euros per year on contact centre operations. Customer satisfaction is 61 out of 100 — below industry average. They want to deploy AI agents. Where do you start?

HOST_B: Before I structure this — I want to ask a few clarifying questions. First: what are the top contact reasons today? Do they have intent data or are we working from agent notes? Second: what markets and languages are they operating in? Third: what's the regulatory context — EU consumer banking has strict requirements around authentication and data. Fourth: what does their current tech stack look like — particularly for core banking integrations? And fifth: what's their definition of success? Pure cost reduction, or are they also trying to move the needle on that 61 CSAT score?

HOST_A: Good questions. They have basic intent tagging — not great, but workable. They operate in three countries: Germany, the Netherlands, and Poland. Core banking is on a legacy platform, details to follow. And their CFO cares about cost, their COO cares about CSAT. Both.

HOST_B: Perfect. That sets me up well. Let me map the contact universe. In retail banking, you typically see roughly: 25% balance and transaction inquiries, 15% card issues — that's blocking, unblocking, disputes, 12% loan and mortgage status, 10% payment issues, 8% digital channel support, 8% account changes, 7% fraud-related, and 15% complex or other. That's our universe. That's roughly 45,000 contacts a day mapped across those categories.

HOST_A: Alright. Now tell me what you'd actually automate and in what order.

HOST_B: I'd score each category on two dimensions. Volume times handle time gives me the FTE load — that's the prize if I automate it. AI-readiness gives me the feasibility and risk. Balance and transaction inquiries: high volume, 25% of contacts, low complexity — it's a pure information retrieval interaction. HIGHLY automatable. Card blocking: high volume, moderate complexity — identity verification is the key step here, but it's structured. Automatable with a good authentication flow. Loan and mortgage status: high volume, relatively low complexity — informational, automatable. Fraud: I would NOT automate the resolution here — human judgment is essential. But I could automate the intake and triage. Complex account changes require authentication and documentation — partial automation at best. So my Phase 1 universe is balance inquiries, card status, and loan status — roughly 50% of all contacts.

HOST_A: You mentioned 80% automation rate a moment ago. Where does that number come from? Are you benchmarking or are you making it up?

HOST_B: Fair challenge. That number is grounded in published industry data on AI agent resolve rates — including Wonderful's own headline metric of 80% resolve rate across their deployed agents. For balance inquiries specifically — where the interaction is almost entirely information retrieval with no decision-making — I'd actually expect the automation rate to be higher than 80%. I'd validate this against the client's actual intent distribution. If their balance inquiry contacts include a lot of account discrepancy complaints rather than pure balance checks, the rate comes down. That's why I'd want to segment within the category, not just at the category level.

HOST_A: Okay. Quantify the banking case for me. Numbers.

HOST_B: Let me work through balance inquiries first since it's the biggest bucket. 25% of 45,000 contacts is 11,250 contacts per day. At 9 minutes average handle time, that's 1,687 agent-hours per day just for balance checks. At 20 euros per hour fully loaded cost — which is conservative for a European contact centre — that's 33,750 euros per day, or roughly 12.3 million euros per year on balance inquiries alone. An 80% automation rate gives us 9.8 million euros of potential saving from that one category. And that's before we touch card issues or loan status.

HOST_A: The CFO wants payback in 18 months. Does your plan actually work?

HOST_B: Let me stress-test that. Phase 1 scope: informational agents covering balance inquiries, card status, loan status — roughly 35% of all contacts. That's 15,750 contacts per day. Apply a 75% automation rate — I'm being conservative relative to the 80% benchmark to account for integration gaps. That's 11,800 automated contacts per day. At 9 minutes each and 20 euros per hour fully loaded: approximately 6.5 million euros annual saving. Phase 1 implementation cost for a deployment of this scale — I'd estimate 400 to 600 thousand euros including integration, testing, and the forward-deployed engineering time. Payback: well under one year on Phase 1 alone. That's a strong CFO argument. And that's before Phase 2 adds transactional capabilities.

HOST_A: What if I told you their core banking system hasn't been updated since 2003 and has no APIs?

HOST_B: That changes things — but it doesn't kill the project. It changes Phase 1. We have two paths. Option A: build a middleware integration layer that extracts data from the legacy system and exposes it through a modern API surface. That adds cost and timeline — probably 60 to 90 days of integration work before agents can go live. Option B: start with channels that already have modern API access. If the bank has a mobile app, that backend likely has a proper API. We start there and prove the model before tackling the legacy integration. Either way, I'd scope the integration cost explicitly in the business case — it's not a surprise, it's a line item. And I'd ask: does the bank have any digital transformation budget separate from the contact centre budget, because this integration benefits multiple initiatives?

HOST_A: Let me push on one more thing before we get to regulation. You said Phase 1 includes card status. What does "card status" actually mean as an agent interaction — walk me through it.

HOST_B: Sure. A customer calls in because their card was declined, or they want to check whether their card block is still active, or they want to know the status of a replacement card they requested. In each case, the agent authenticates the customer — name, date of birth, last four digits, or a one-time passcode — retrieves the card status from the core banking system, and communicates it clearly. If the card needs to be unblocked, that's a transactional action and it requires a higher authentication standard — that moves to Phase 2. But pure status inquiry? Fully automatable in Phase 1. It's the same information retrieval architecture as balance inquiry — just a different data field.

HOST_A: Good. What are the regulatory constraints here? Tell me what you're watching for.

HOST_B: Three main ones. PSD2 — the EU Payment Services Directive. Any agent that surfaces account data or initiates payment actions needs to comply with Strong Customer Authentication requirements. That's two-factor verification minimum. GDPR — any agent that processes personal data, which is all of them, needs explicit data handling policies, retention limits, and the ability to process deletion requests. And then there's the language angle — operating in Germany, Netherlands, and Poland means three separate language models and three separate cultural calibrations. Wonderful's multilingual platform is actually a major differentiator here. A custom build for three languages would cost significantly more and take much longer. And critically — Polish consumers have different communication expectations than German consumers. That cultural nuance has to be baked into the agent behaviour, not just the language model.

HOST_A: Last banking question. What's the top risk that could derail this project?

HOST_B: Customer trust. In financial services, customers are acutely sensitive to who — or what — is handling their financial information. If the agent feels robotic, evasive, or makes a mistake, customers escalate immediately and the business case collapses. Two mitigations. One: transparent handoff — the agent should never pretend to be human, and should offer a clear, smooth transfer to a human agent the moment the interaction goes outside its scope. Two: liability guardrails — any agent that surfaces account information must have accuracy checks, must never speculate, and must have an escalation path built in for any interaction where incorrect information could lead to financial harm. That's a non-negotiable.

HOST_A: Solid work on banking. Let's move to Case 2. Healthcare. This one is about constraints. Healthcare insurer. 8 million members. They handle 120,000 contacts per month. Top intents: benefits eligibility inquiries at 30%, claim status at 25%, pre-authorization requests at 20%, provider search at 12%, billing and payment at 8%, complaints at 5%. They operate in Germany and Austria. Go.

HOST_B: First clarification: Germany and Austria means we're operating under the statutory health insurance framework — in Germany that's SGB V, the Social Code Book Five. That regulatory context is the most important constraint in this case and I want to establish it upfront before I touch the decomposition.

HOST_A: Go on.

HOST_B: Under German health insurance law, any automated system that touches clinical decisions — including communicating pre-authorization outcomes — must have human oversight. An AI agent cannot make or communicate a pre-authorization decision autonomously. That immediately creates a hard line in my decomposition: INFORMATIONAL interactions on one side, DECISIONAL interactions on the other. The agents can operate autonomously on the informational side. On the decisional side, we are in AI-assisted territory, not AI-autonomous territory. That's not a bug — it's the architecture of the whole engagement.

HOST_A: So walk me through the decomposition with that framing.

HOST_B: Informational side: benefits eligibility at 30%, claim status at 25%, provider search at 12% — that's 67% of all contacts. 67% of 120,000 is 80,000 contacts per month. These are pure information retrieval interactions. No clinical judgment. Fully automatable. In German and Austrian German — which have distinct dialect patterns and formality registers. Wonderful's platform handles this natively. That's 80,000 contacts per month we can automate in Phase 1. The decisional side: pre-authorization at 20%, that's 24,000 contacts per month. Billing disputes could be partially informational. Complaints at 5% should stay with humans — complaints require empathy that agents can support but not replace.

HOST_A: Pre-authorization is 20% of their volume and probably their biggest operational pain point. You just said AI can't do it. Is that a dead end?

HOST_B: No — and this is the most important distinction in the whole case. AI-assisted is not the same as AI-autonomous. Here's the opportunity: pre-authorization today probably involves a human agent gathering information from the member, then a clinical reviewer spending 45 minutes reading through an unstructured case file. What an AI agent can do is transform that intake. The agent contacts the member, asks structured questions, collects all required clinical information in a standardised format, pre-screens the case against eligibility rules, flags missing documentation, and routes the case to the right reviewer with a complete, structured dossier. The human reviewer goes from 45 minutes of chaotic case review to 10 minutes of structured decision-making. That's a 75% reduction in human review time on 24,000 contacts per month. That's enormous — even with zero autonomous decisions.

HOST_A: How important is it that the German-language agent sounds like a native German speaker versus a competent German speaker?

HOST_B: It depends on the interaction type and the customer profile. For eligibility and claim status — relatively transactional — competent is sufficient. But for pre-authorization, which often involves a member explaining a medical situation — sometimes a serious one — the cultural and linguistic calibration matters a lot. German communication in healthcare contexts is formal, precise, and patients expect structured interaction. An agent that sounds generically "German" but uses wrong formality registers, misses regional phrasing, or doesn't follow German medical communication norms will erode trust in exactly the interactions where trust matters most. That's Wonderful's actual differentiator — not just language translation, but cultural calibration. An agent trained on generic German data is not the same as an agent calibrated for German statutory health insurance member communication.

HOST_A: What's your 90-day win in the healthcare case?

HOST_B: Benefits eligibility inquiry automation. It's the highest volume single intent at 30%, it has zero regulatory complexity — it's pure information retrieval — and it's immediately measurable. In 90 days, you can have an agent handling eligibility inquiries in German and Austrian German, show a deflection rate, show a handle time reduction, show a CSAT comparison. That's the proof point that funds the rest of the roadmap.

HOST_A: Good. Case 3. Media. Shorter. I want to see your prioritisation logic here. Major broadcaster. Seven European countries. 180,000 subscriber contacts per month. Interactions include: subscription management — cancellations, upgrades — technical support for streaming, billing disputes, content inquiries. Countries: Italy, France, Spain, Portugal, Poland, Czech Republic, Romania. Go.

HOST_B: This case is specifically about multilingual prioritisation and I want to be explicit about that lens upfront. The question isn't just which interaction types to automate — it's which interaction types, in which markets, in which order. Those are two dimensions and I need to hold both simultaneously.

HOST_A: Show me the framework.

HOST_B: I'd build a matrix. Rows are countries ordered by volume — Spain and Italy are likely the two largest markets, then France, then Portugal, then Poland, Czech Republic, Romania. Columns are interaction types ordered by complexity — content inquiries at the low end, then billing disputes, then subscription management, then technical support at the high end. Each cell gets a colour: green is automate now, amber is automate in Phase 2, red is human-required. The starting point is the top-left cells — highest volume markets, lowest complexity interactions. That's where the ROI is densest.

HOST_A: But there are seven languages here. Where do you actually start?

HOST_B: Spain first. If Wonderful already has Spanish deployed — which is likely given their Latin American and European footprint — Italy is the second deployment because Spanish and Italian have significant structural similarity. The training data and workflow patterns carry over substantially. France is the third — Romance language family, but more distinct. Poland and Czech Republic are Slavic languages — they require separate training data, separate dialect work, and separate cultural calibration. They're not an afterthought, but they are a separate track. Romania is interesting — Romanian is Romance but with heavy Slavic influence — it sits between the two tracks.

HOST_A: Poland and Romania together are about 15% of their contacts. Is it worth building agents for those languages?

HOST_B: Yes — and here's why this is actually a Wonderful-specific answer. On a custom build, 15% of contacts across two complex languages might not justify the investment. But Wonderful's architecture is designed for exactly this. The orchestration layer, the business context layer, the management layer — those are built once and shared. The incremental cost of adding Polish or Romanian is language tuning and localisation, not platform rebuild. So the marginal cost of adding those languages on Wonderful is a fraction of what it would be on a custom solution. And 27,000 contacts per month in Poland alone — that's still significant enough to show clear ROI. You don't abandon markets because the language is complex. That's the whole point of Wonderful's model.

HOST_A: Tell me about cancellations. Why are they high value in this case?

HOST_B: Cancellations are the highest-value interaction in a subscription business — not because they're the most common, but because the outcome of the interaction has direct revenue impact. A human agent handling a cancellation request is working from a script and limited context. An AI agent handling a cancellation can access the subscriber's full history, segment them by churn risk, present personalised retention offers in real time, and escalate to a specialist only for high-value subscribers where human engagement has proven ROI. That's not deflection — that's revenue generation. Wonderful's agents resolve. In this case, "resolve" means either completing a cancellation cleanly — which actually improves CSAT even on lost customers — or saving the subscription with a contextually appropriate offer. Both outcomes are better than what a rushed human agent does with a script.

HOST_A: Alright. Let's step out of the case format for a few minutes. Common mistakes. Ryan — what kills candidates in these interviews?

HOST_B: Seven things. First: jumping to solution before mapping the problem. Saying "we should deploy AI here" before you've listed the contact types. The interviewer will stop you immediately and it signals you don't have a structured process.

HOST_A: This one is the most common.

HOST_B: Completely. Second: no numbers. Vague claims get destroyed. If you say "there's a big opportunity in balance inquiries" without quantifying it, the interviewer will ask "how big?" and if you don't have a framework for answering, you've lost the thread. Third: ignoring regulation. Especially in EU banking and healthcare. If you get to the healthcare case and you don't raise SGB V, that's a red flag. Wonderful operates in heavily regulated markets. They expect candidates to know that regulation is a first-class constraint, not an afterthought.

HOST_A: We have turned down candidates who gave technically brilliant decompositions with zero regulatory awareness. It signals you haven't thought about deployment reality.

HOST_B: Fourth: treating all AI the same. Not distinguishing between informational agents, transactional agents, and decisional AI systems. These require completely different architectures, different integration requirements, different regulatory treatment. Saying "we'll use AI for pre-authorization" without understanding that you mean AI-assisted, not AI-autonomous, is a category error. Fifth: forgetting the human. Every AI agent system needs a human escalation path. If you propose a fully autonomous agent for any interaction type without addressing how it hands off to a human when it reaches the edge of its competency — that's a red flag. Sixth: not asking about integration complexity. A beautifully designed agent that can't connect to the core banking system, or can't access the insurer's claims data, or can't pull subscriber history from the broadcaster's CRM — is worthless. Integration is not a technical detail. It's a business constraint that affects timeline, cost, and what you can actually put in Phase 1.

HOST_A: And seven?

HOST_B: Confusing "can be automated" with "should be automated." Some interactions are technically automatable but shouldn't be. A distressed customer calling about a denied insurance claim — technically, an agent could handle the information delivery. But the right answer is that the information should come from a human, and the agent should support the human with a complete dossier, not replace them. If you can't articulate that distinction, you're not thinking about the customer, you're thinking about the technology.

HOST_A: One more thing on mistakes — what about candidates who over-engineer the framework? Who come in with a beautiful 12-step process and then can't adapt when the case goes sideways?

HOST_B: That's a real failure mode. The framework is a scaffold, not a script. If Emma hits you with a curveball — "the core banking system has no APIs" — and you freeze because that wasn't in your framework, you've lost the thread. The framework is there to help you not miss things. But the ability to adapt, recalibrate, and keep the thread of the business logic is what separates a consultant from a slide deck. At Wonderful, the forward-deployed engineer model means you're going to be on-site with clients who will throw curveballs constantly. They need to see that you can hold structure AND flex simultaneously.

HOST_A: Completely agree. And related to that — candidates who can't say "I don't know." If you're asked about a specific regulation and you're not certain, say "I'm not certain of the exact regulatory text here, but my instinct is X and I would validate with legal before committing to this architecture." That's a mature answer. Pretending to know is transparent and it damages credibility on everything else you said that was accurate.

HOST_A: Let's close with synthesis. What does "great" actually look like in a Wonderful interview specifically?

HOST_B: There are five things that separate a good candidate from a great one in a Wonderful interview. First: you understand their actual product. Not "AI chatbots." Not "virtual assistants." Agents that resolve. Wonderful's 80% resolve rate is their headline metric — not deflection rate, not containment rate. Resolve rate. If you talk about deflection, you're using the wrong frame.

HOST_A: We built the whole platform around resolution, not deflection. These are architecturally different products.

HOST_B: Second: you treat multilingual deployment as a core capability, not an afterthought. Every case they give you has a language and country dimension. The candidate who raises it proactively — who says "wait, they're in Germany and Austria, that's a specific dialect and formality register" — signals they've done the work. Third: you think about the forward-deployed engineer model. Wonderful doesn't just license software. Their teams go on-site with clients to build and deploy. That means implementation complexity is part of your business case — it's a cost line, a timeline, a team structure. Fourth: you have a concrete 90-day win with numbers. Not a vision statement. A specific scope, an estimated automation rate, a cost saving, and a payback period. If you can hand the CFO a one-page business case after a 20-minute interview question, that's the signal they're looking for. And fifth: you proactively raise regulatory constraints before the interviewer does. Don't wait to be asked about GDPR. Don't wait to be told about SGB V. Raise it yourself, frame it correctly, show you know how it shapes the solution. That's the difference between a candidate who understands deployment reality and one who's done research but not thinking.

HOST_A: One final thing I'd add from the interviewer side. We are looking for intellectual honesty. If you don't know an assumption — say so and flag how you'd validate it. If your number is a benchmark, not a measurement — say so and explain your source. The worst thing you can do is present an assumption as a fact and then get caught when we push on it. The best thing you can do is show you know what you know, know what you don't know, and have a plan for closing the gap. That's the mindset we hire at Wonderful.

HOST_B: That's the whole thing, really. These interviews aren't knowledge tests. They're structured thinking tests run in real time, under pressure, on problems that matter. Prepare your framework, know the regulatory context for banking and healthcare in EU, understand Wonderful's multilingual differentiator, and quantify everything. Do those four things and you'll be in a strong position.

HOST_A: Good luck. This stuff is genuinely hard — but it's also genuinely learnable. Practise the framework until it's automatic, then practise applying it under interruption. That's the real test. Thanks for being our candidate today, Ryan.

HOST_B: Thanks for making it uncomfortable. That's exactly what it should feel like.