CSM's Role in Escalation

Scott Hopper

At IBM we had a Customer Relations department what we called Critical Situations or Crit-Sits. Generally one software issue didn't make a crit-sit.  Generally most had 2 or more serious issues requiring escalation that needed to be addressed. 

Initially critical-situations were handled through this team.  As CS developed.  The crit-sit was opened through the system but the CSM ran the crit-sit.  Additionally,, if it hadn't been yet escalated a CS could open a proactive situation which wouldn't receive as much executive attention but would alert development teams to the problems the customer was experiencing so they could ensure that they were working the issue.  

Kevin Mitchell Leonor

Interesting. Does this mean that in the Crit Sit, the customer is already sitting at a 12 out of 10 mad scale when we could have engaged them better back when they were a 7 or an 8? How well did they do with recovering customer sentiment and value?

Gabriel Fallas

There's definitely some similarities to how we handle escalations. 

For context: We're a B2b2C company. My work is focused with the B2b sector. 

Our Call Center team has an escalations team that will handle B2b and B2c calls. If they're unable to resolve the issue it get's escalated to Call Center Supervisors, and if they're encountering difficulties then they come to me. I'm the first CS hire so I understand why the current process was set-up the way it is. 

My pitch for the 2020 roadmap, would be to split up the escalations team in b2b and b2c and have the b2b escalations team live in CS. 

Thankfully, I have a good relationship with the call center team and supervisors and they partake in our VoC program so we communicate frequently. 

 

Scott Hopper

@Kevin Mitchell Leonor well that is a good question, they definitely want different results, they are engaged.  The idea of the crit-sit is it can bring the proper resources to the situation.  Fly people in, or free up an engineer, have executive attention.  I know one early one I did some work on it actually fixed a dramatic hole in the UNIX platform products of having built-in debugger  and spawned additional work to have a comprehensive memory debugging tool.  Good things did happen because of the recognition of the situation.  It also led to a development shakeup where the UNIX Dev was brought under the Iris team and led to unified builds. 

I would also caution that I lived the evolution of enterprise software.  When I started with Notes/Domino support TCP/IP on Windows was just being introduced and it was independent drivers. When clustering was introduced, there wasn't the scaling to make it affordable.  There weren't crash and recovery system when the product died. Nor was the product scalable.  So, a lot evolved.  

The crit-sit process however, pre-dates all of that at IBM.  So, customer's today likely have less patience than they used to and the SaaS Vendor is assuming most of the risk.

As for recovering sentiment and value, that wasn't on my radar in my role.  However, I do equate the crash in 2008/9 of many customers at least in the Domino space leaving for cloud based mail offerings. Which is more a statement of adoption of the more sticky features of the product. It really meant you weren't developing apps and never went passed the first use case.  

 

Matt Myszkowski

This situation or set-up is definitely something I see more with large, enterprise software vendors like SAP (where I am now) and Autodesk (where I worked previously).

If done well, it works very well - if done poorly it creates huge frustration for the customer, they get passed around, they talk to people who are unfamiliar with their solution and set up, and the CSM has to get involved anyway albeit at a very late stage when the customer is demanding senior exec attention.

Scott Hopper

@Matt Myszkowski you might also at SAP have a different process for those customers who are not on Enterprise contracts that are escalating.  

Alex Turkovic

I think this is easier to achieve in small/mid sized companies, but my preference would be to have the CSM (i.e. the owner of the long-term customer relationship) triage the situation and be the primary POC with the customer. That CSM has the ability to engage other teams around the org for assistance (technical, billing, etc.) - but by remaining the face of the situation, that CSM accomplishes the following:

1. By handling the situation, they continue to foster the relationship and build rapport/reputation as a problem solver and trusted advisor
2. The customer doesn't get bounced around from contact to contact unnecessarily, having to explain the situation to a half dozen individuals in difference departments

This especially is where tools like Slack are irreplaceable, as they open up internal lines of communication, making for quick alignment and resolution. This is certainly relevant right now as a lot of teams are working remotely.

I think the Crit Sits team is a fantastic model - one generally designed for larger organizations, but I like the idea of having a team dedicated to being point of escalations. That said, the CSM should still be the primary POC and point of escalation in my view.

Scott Hopper

The only thing that  I saw as part of the process that was difficult for the CSM was having the power to align the resources.  You require escalation to rally the forces and understand the importance. Also, somethings do take time, they drag on, despite throwing everything you have at them. 

Alex Turkovic

Yeah - I can see that. That's where truly cross functional and collaborative leadership needs to be in place. To enable individual team members with established processes for team engagement.