Customer satisfaction

Hi!

First of all: please do NOT use a framework at all! Frameworks are for those who don't know how to solve problems in a rigorous and repeatable way. Instead, learn the principles of rigorous problem solving :)

One of these principles is: you can not structure a problem before having defined and operationalized (!) the objective. Here, the objective is “customer satisfaction”. So it is imperative that, before even starting to think about a structure, you first align with the interviewer on how the client is measuring customer satisfaction! Is there a definition they use? Or should we (as consultants) suggest something. 

This kind of alignment is expected of you as a candidate - and if you do not do this, it doesn'T even matter how your structure looks like, because it is already a very weak performance from a methodical view point. (candidates who don't align, and instead try to impress their MBB interviewers with “knowledge” are usually instantly filtered out - since they would be a risk on a real team).

Once the objective is operationalized and and the corresponding KPI is aligned with the interviewer (e.g., Net Prooter Score (NPS) could be such a KPI to measure Customer Satisfaction), then you can disaggregate this KPI into its elements/drivers, and then brainstorm the influencing factors with affect each driver. And then you can start developing ideas on how to influence each driver into the desired direction.

This might still sound a bit abstract - but this is how you solve problems. And this is superior to any framework you could ever memorize.

I hope this helps.

Cheers, Sidi

___________________

Dr. Sidi S. Koné

Former Senior Engagement Manager & Interviewer at McKinsey | Former Senior Consultant at BCG | Co-Founder of The MBB Offer Machine™

I'm going to take a step back and answer the question you're really asking: How do I use frameworks in a case?

If there's anything to remember in this process, is that cases don't exist just because. They have come about because of a real need to simulate the world you will be in when you are hopefully hired. As such, remember that they are a simplified version of what we do, and they test you in those areas.

As such, remember that a framework is a guide, not a mandate. In the real-world, we do not go into a client and say "right, we have a framework that says we need to look at x, y, and z and that's exactly what we're going to do". Rather, we come in with a view, a hypothesis, a plan of attack. The moment this view is created, it's wrong! Same with your framework. The point is that it gives us and you a starting point. We can say "right, part 1 of framework is around this. Let's dig around and see if it helps us get to the answer". If it does, great, we go further (but specific elements of it will certainly be wrong). If it doesn't, we move on.

So, in summary, learn your frameworks, use the ones you like, add/remove to them if the specific case calls for it, and always be prepared to be wrong. Focus rather on having a view, refering back to the initial view to see what is still there and where you need to dive into next to solve the problem.

Hope this helps :)

Hi there,

let me say upfront that there is not only one good way of structuring this. What works quite well in such a case is an approach in 3 steps (for some surprisingly) similar to profit decline type of problems.. 

1. Isolate the problem: In this case, an elegant way to do that is to break down the metric in terms of process (→ structure for step 1), i.e. a typical customer journey to see where the pain points are
2. Identify the root cause: Once you know where you have to look, understand why it's happening → brainstorm hypotheses and test them until you find the WHY
3. Develop solution:  based on 1 and 2 you can finally conduct a structured brainstorming to derive options on how to address the problem.

Note that for each step you'll have a structure that helps you complete the step. 
 

Hope this helps. Feel free to reach out if you have further questions.

Regards, Andi 

Hi there,

I'm sure you've heard this by now, but I'd really stay away from any sort of typical frameworks. These really turn of interviewers. 

They want to see you thinking on your feet, showing creativity and an attempt to genuinely connect with the client's topic.

In terms of your practical suggestions, I'd go for the customer journey structure. Here you have a MECE structure that is intuitive and which is also often used in real consulting engagements. 

The next step would be to identify the core pointpoints under each step of the customer journey and from there to work on how to improve them. 

Sharing with you a guide on structuring techniques which you might find useful:

• Free Guide: Mastering Structuring & Brainstorming

Best,
Cristian

Hi,

Sidi already has a great answer. I just want to add one more point on MECE - MECE is not a ‘step’ to be used at certain points in time. It is a principle that is fundamental to a structured way of solving problems.

So it is always better to be MECE than to not be MECE, because it helps us make sure we are tackling a problem in a MECE way. E.g. assuming the question/objective was about finding painpoints, then you need to approach this in a MECE way

Hello,

You definitely should not be using generic frameworks for cases. Frameworks are a useful tool to have in the back of your mind when solving cases, but you need to adapt them to the context of each case and determine what is relevant. 

So, regarding your specific prompt, figuring out how to quantify the customer satisfaction rate and then figuring out the pain points along the customer journey sounds pretty clear and methodical to me. I would go with that instead of trying to force some arbitrary framework onto the case.