Case study — 01
AI-native customer service agent
A large consumer business had a chatbot that customers had learned to skip. I led the product that replaced it — from concept to a full working prototype — and the work began with twenty conversations rather than a roadmap.
Self-service resolution
User interviews
Projected users
01 The problem
The client already had a chatbot. It was not an AI product in any meaningful sense: it matched a question against a set of known intents and, when nothing matched closely enough, told the customer it couldn't help. That last sentence was the product's most common output. Customers would try once, get it, and call the contact centre anyway — which meant the chatbot was adding a step to the journey rather than removing one.
So the interesting question was not "how do we make the bot smarter." It was: what are people actually asking, and what does it take to answer them? I ran more than twenty interviews with customers and with the service agents who picked up the calls the bot had given up on. The pattern that came out of those conversations is what the rest of the build was organized around.
[The line from one of the interviews that changed how you thought about the problem.]
[Who said it — role, not name]
02 What I built
An agent that reads the question, retrieves against the client's own material, and routes to a specialist sub-agent when the question belongs to one. I owned the product end to end for a team of more than ten engineers and designers: the problem framing, the scope, the sequencing, and the calls about what shipped in the prototype and what waited.
Recreated illustration — not the shipped product; anonymized for confidentiality.
03 Key decisions
Decision 01
Specialist sub-agents over one general agent
A router that hands each question to a sub-agent scoped to one domain.
[The alternative you actually weighed — one general agent with a larger context, or something else?]
[What the interviews or the evaluation showed — and what this cost you in latency, complexity or build time.]
Decision 02
Fixing retrieval before adding capability
Spending the early sprints on retrieval quality against real customer questions.
[What the client or the team wanted to build first instead.]
[How you made the case — the evidence, and how you got a sceptical stakeholder to agree.]
Decision 03
[The trade-off you'd most want to be asked about in an interview]
[What you did]
[What you gave up]
[Why, and whether you'd make the same call again]
04 Outcome
Self-service resolution improved by ten percent against the existing chatbot — meaning one in ten more customers got what they came for without reaching a person. The prototype was built for a product projected to serve more than a million users. [Add how the improvement was measured: the evaluation set, the baseline, and over what period.]
[What you'd do differently, or what the next release was scoped to do. One honest paragraph here does more for a hiring manager than another metric.]
Confidentiality note
This project was built within McKinsey & Company. Specific client names, proprietary architectures, and internal tooling details are confidential. What's shared here reflects the publicly describable scope of the work; product screens shown are generic, illustrative recreations, not the shipped product.