Customer Communication Positioning - Moving from Assigned CSM to Pooled CS Model

Scott Hair

A portion of our business is moving from an assigned CSM to a pooled CS model.  I'm curious to hear from others that have gone through the process and what the communication was to customers regarding the move.  If you have examples of messaging that worked and ones that didn't, I would appreciate the help.  

Brian O'Keeffe

I have been through it. We used an approach that made it super simple: if the CSM had a relationship they communicated it to the customer. You now have this team available: Mary, John etc... and here is how to get in in touch. If there was no relationship, or it was very minimal, we communicated it from the new team via email or during a hand-off process internally. Example sales or support needed CSM then the new team would take it and communicate with the customer who they were and how to get in touch. The key is having that pooled team on fire: respond, follow through and track every issue until resolved and show that the pooled model works. 

Most of the doubt was internal, not from customers. Sales: now they have dial up CSM?! Or other tier CSMs managers presenting it as a downgrade. Of course they wanted to position their team as the top! It really ticked me off. Customers had no problem with it and got it pretty quickly.

I strongly encourage a really flexible approach and let team members own escalation, and even specific customers for periods of time when it makes sense. Shifting customers from pooled, to one to one, based on need is a great way to keep it scaled. Example: customer A is very low touch but very high ARR and customer is in a good place. Move to scale team. Customer A is adding a module or going through a re-org, move back to one to one. 

Clay Telfer

I've been through it a few times, very similar to what Brian said. If there was an existing relationship, the CSM let the client know they were moving to a new role and the customer would have a team of people to help them going forward. If there wasn't an existing relationship, we didn't say anything at all, just had the new team start handling everything. Like Brian, we had lots of internal anxiety, but everything went great! We actually improved SLAs, churn, and expansion in this tier. (Our higher-tier customers still got individual CSMs.)

Here's what everyone forgets: your customers aren't loyal to you, they're loyal to the quality you provide. If you've had a customer for 5 years and he loves his CSM, and that CSM suddenly starts taking a week to respond, he's not going to stay loyal to them. Similarly, if you change him to a new CSM, he might have some trepidation at first... but if he sees that the quality of service is the same, that'll go away fast.

Last time I did this, we made sure that the pooled team had good people, with plenty of training and automated systems, and budgeted a ton of time after the switch for them to work with management/tech/etc on whatever they might need as we ramped up. Then we started making the switch in buckets - I think we took the customers who'd be moving over and did 25% of them, waited a couple weeks to make sure nothing exploded, then did 25% each week for another three weeks. Worked like a charm!

You know how sometimes, when you're cleaning or reorganizing, you have to make an even bigger mess first? This approach can save you a ton of time and resources and headcount, but the first couple months, it's gonna require way more of those things as everyone adjusts and finds the gaps that need filling. Plan for that, and you'll be in great shape.

The thing is, done right, this isn't a downgrade. These folks didn't need much support, but when they did, they were the last priority for their CSM and got support near the max SLA because each CSM had to prioritize larger clients. With the pool model, now they're getting support from people who don't have to shift them to the back of the line.

Brian O'Keeffe

In the end the scale CSM team became the top performer in many metrics. #1, by far, in identifying and enrolling advocates. Turn around time was very impressive and very public since all initial interactions took place via the community. 

The scale team continued to be viewed as less than by the entire organization. That was/is the biggest problem. Despite being every bit as strong in every metric (renewal, NPS) and exceeding other sectors in many it can be viewed as not requiring the advanced skill set of the consultancy approach of one to one and somehow proving a lesser experience. I call BS. It requires a consultancy and digital skill set. These will be your top performers. 

Scaling, using digital engagement, is key to an affective, efficient CS program

Scott Hair

@brian - That's an interesting perspective and a good point.  Given the diversity in skillset required to support a 'scaled csm' model, when thinking about the career progression of a CSM, where would you put this role?  

Brian O'Keeffe

An effective CSM for the scale team needs to have the consultancy skills traditionally associated with a CSM in addition to understanding digital engagement. It includes how to drive engagement, internally and externally (internal is always harder and where most of the resistance is) identifying issues quickly and assigning them to the right category and matching them with the right resource. The vast majority of small customers will be simple issues (that without the scale model that allows you to identify them might fester and become dissatisfaction issues that bubble) and more complex issues that require careful handling and taken off-line to a short, or long-term, engagements that look very similar to other sectors (customer loss of leadership of program, aligning software roll out with business goals etc...

The problem I have witnessed is the scale CSM is seen as entry level. Every team member, with a few exceptions, is at the beginning of the career and they sit back and wait/watch for engagement. Often doing nothing in the interim, or tasked with work that has little value. (They seem free. Let's have them do all the data entry name updates.) They need to be looking for engagement, searching it out, socializing in your community (if you have one) and have the savvy to drive the scale adoption model. It might be a day of five obvious support issues with a seamless hand-off to support, socializing the concept of your model in community threads and identifying a half dozen issues that look like risks and either closing them out, or escalating them to the right resource and a two hour business review with a very problematic customer who had a failed deployment (by internal standards but looks fine from the vendor side) followed by an internal partner meeting with product reviewing and driving product enhancements requested by your customers. 

You want a good mix of mid and entry level with a sprinkle of senior level. You need a leader who drives the team and shares the passion for digital engagement that they evangelize and is the template for the team.