Problem-solving for Customer Success Managers
Most of us have been confronted with small children, our own and other peoples repeatedly asking ‘Why’.
It can be frustrating, but it can also make us question our own assumptions.
“Why are those people standing in a line?’
‘It’s a queue’.
‘Why are they doing that?’
If you answer, ‘It’s what we do in this country’, it does sound a little feeble.
You know it’s the fairest way to wait for something, but when you hear yourself explaining it to a small child, you may begin to question your own norms.
That’s the strength of this technique; in 5 steps, you can look a little deeper into a situation, think about what you have always taken for granted, then hopefully reach the root cause of a problem or issue.
This example from Wikipedia illustrates the technique:
Your car will not start.
- Why? – The battery is dead. (First why)
- Why? – The alternator is not functioning. (Second why)
- Why? – The alternator belt has broken. (Third why)
- Why? – The alternator belt was well beyond its useful service life and not replaced. (Fourth why)
- Why? – The vehicle was not maintained according to the recommended service schedule. (Fifth why, a root cause)
With a little adaptation, this iterative approach can be usefully employed as a problem-defining and problem-solving solution.
Let’s look again at Wikipedia’s problem and how we can adapt it to our needs.
Step 1 Define the problem – The battery is dead. (1st Why)
Step 2 Define the process – The alternator isn’t working. (2nd Why)
Step 3 Identify possible causes – The alternator belt has broken. (3rd Why)
Step 4 Identify/Implement Solution – It was over its working life, so replace it. (4th Why – the Root Cause)
Step 5 Test for resolution – does the engine start (5th Why)
I’m sure you get the idea.
Root cause analysis is covered in more detail in the Practical CSM Academy program, but let’s look at each step more closely.
The first step is defining the problem; focus on the facts, not opinions or emotions. At this stage, investing some time in describing the problem in detail can be worthwhile and not jumping to ‘solution mode’ immediately.
But none of us lives in an ideal world where customers will put their plans and schedules on hold while the CSM analyses things, so think about offering a short-term solution or ‘work-around’.
It could be arranging temporary hosting for a mission-critical software application or sourcing additional production facilities.
So, we understand the problem, moving to step 2, engaging with the customer to gather more information.
This can take various forms, for example, visiting a production facility and speaking to people on the ground or working with IT engineers to understand their issues.
But remember, business capacity has three elements: people, processes, and tools. People often get the blame when the process or the underlying training is the real issue.
This can also be an excellent time to sit down with the customer and create some form of process mapping.
Step 3 is looking for possible causes. Sit down with the customer and rank them from most to least likely.
It can be helpful to do this in a group setting, getting input from a more diverse group, and reaching a consensus.
You may want to employ a ’cause and effect’ diagram (sometimes called a fishbone or Ishikawa). This is a visual technique that helps you to identify all of the likely causes of the problem(s) you’re facing.
In step 4, you start thinking about countermeasures or solutions.
As in step 3, if you find more than one option, you can rank them from most likely to succeed to least likely.
You must take a holistic approach here, remembering to include the cost of the intervention in your calculations, the need for, and impact on, resources and the time it will take to implement it.
Be flexible in your approach, and as we mentioned earlier, consider including temporary solutions in your thinking. It’s not ideal (we don’t live in a perfect world), but it can give you and your customer more time to design a better long-term fix.
Once you have agreed on your plan, assigning roles, responsibilities, and deadlines is a good idea. This will give everyone a clear sense of what needs to be done, when and how it fits into the bigger picture.
Now is also a good time to agree on what success looks like; whatever measures you decide on, it could be setting agreed KPIs or success gates, make them concrete, simple, and easy to identify.
Now we arrive at step 5,
This is where you test the solution; in the Wikipedia example, it was, does the engine start?
If it works well, great!
If it fails, we’ll move to the next solution on your list.
This is when the time you spent thinking about cost and resources can come in useful, as there may be some overlap (the same resources needed) for different solutions.
It works – excellent, problem solved.
Built into your plan should be a contingency period; it could be a day or a week.
Use it to check for unintended consequences. From time to time, what looks like a perfect solution causes some disruption in another workflow or process – this is where creating a broad discussion group in step 3 can pay dividends.
It may turn out that the group only identified some of the issues, but by being involved earlier in the process, when you bring them back together, they will be aware of the initial problem and how the flawed solution arrived.
This should help in resolving the issue.
One last thing – document everything.
Not only will this help with future problem-solving, but it will also be helpful to refer to, if a dispute occurs.
Is this how your company deals with problem-solving?