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 

(edited)

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.