Be part of the first-ever CS careers research project
Here’s a toxic thought all of us Customer Success Managers need to leave behind:
If an account is at-risk, you are the only person responsible for turning things around.
The pressure that comes from feeling like the single point of failure isn’t something anyone should be subjecting themselves to.
While being the “hero” may sound appealing, when an account is at-risk, it is the perfect opportunity to live out one of our field’s most used phrases: Customer Success is not a department; it’s a company mindset.
An account can be “at-risk” for many reasons, ranging from product gaps to changes in critical stakeholders. An essential part of our role as CSMs is effectively assembling the right team to address the risk. And while it might sound straightforward, sometimes we end up with a case of decision paralysis.
.gif)
Using the workflow below has personally helped me as a CSM, which is why I’m sharing it with you. Here’s what this workflow will show you:
During a monthly session with a customer, they shared information that immediately raised an at-risk flag for me.
I panicked and immediately created a channel with a handful of people from my company (including folks from our executive team). I shared the information the customer shared with me, and that was it.
A few minutes later, I got a DM from my leader with some feedback. They expressed that I could’ve shared additional information in my thread to give my team a complete picture of the situation and what I needed from them.
They were right –– I kind of just dropped that bomb on them and walked away. I was so focused on raising the potential risk ASAP, that I hadn’t considered thinking through a plan of action.
I didn’t want to make the same mistake again, so soon after that happened I put together a note template that included a list of questions for me (and any other CSM) to answer before raising risk internally:
These questions gave me the structure I needed to communicate with my team effectively. The next step I needed to nail down was who to notify about the risk.
As a CSM, who we need to notify within our company varies depending on the nature of the risk. Before we ring the alarm with an @here in a public Slack channel, we need to be clear on who to notify, what we need from them, and what’s the next step.
Creating a quick “who to notify” cheatsheet can save CSMs a LOT of time. To get started, outline the different risk themes that may arise. For example:
Once we outline the themes, the next step is to document all possible risk reasons and assign them to the themes you’ve defined above. Here are some risk reasons and how to pair them with a theme:
With the risk themes and reasons laid out, you don’t need to start your decision-making process from scratch. Having this clarity is also something that your teammates will appreciate – no more pulling them into a thread they didn’t need to be in.
Believe it or not, you’ve just created a process!
You know what to say when you spot risk and who to bring into the conversation. To go the extra mile, make this part of your team's workflow bank – they’ll thank you for it, and you’ll also stand out as a CSM. Here’s how I went about creating an escalation process as a CSM here at Catalyst:
My initial note template was a great foundation, but to take it to the next level, we wanted to automatically update fields and provide more context for anyone reading the note. I shared the idea with my leader, and we updated the note template together, which ended up looking like this:
With the note template in tiptop shape, the next thing to address was how we raised the risk internally. Some CSMs used private DMs or created private channels within Slack, while others emailed.
We didn’t have a solid approach, which led me to set up a Slack workflow that pushed Catalyst's published risk escalation note to a Slack channel called #at-risk. I created a private channel, invited the top representatives from each department, and shared how the channel worked.
Pushing our escalation notes from Catalyst directly to a dedicated Slack channel meant that CSMs only needed to @mention whoever needed to be made aware.
Ultimately, operationalizing this process has helped our Customer Success department:
