When to use the pooled model for customer success

There’s always been a perception of the customer success manager (CSM) role as something of a “SaaS concierge.”

This person is your go-to contact for anything related to your software subscription. They check in with you, find out how you’re doing, recommend tips and tricks, field your roadmap questions. They route your bug reports and feature requests, lead ROI analysis, help you prep your executive summaries. They serve you insights from other customers. They’re your erstwhile therapist; they’re almost a part of your business. They send you a bottle of champagne for your anniversary—er, renewal date.

Your customer experience is their job.

You already know the biggest problem with this model: it doesn’t scale. That kind of CSM can only really act as a concierge for a relative handful of customers. Try running a CSM team with an average portfolio size of 10 or 20 accounts. Only the highest-ACV (average contract value) businesses would go for that. 

But there’s another sneaky problem with this mentality: customer experience isn’t really a CSM’s job. It’s customer success. And trying to be a one-stop shop for everything a customer needs isn’t the best way to deliver success in most customer relationships.

That’s why companies (including us) are increasingly turning to pooled CSM models, at least in part.

What is a pooled customer success model?

In practice, CSMs are a lot more like doctors than hotel concierges. (You can tell that to your parents next time they ask what you do. 😅 ) They have specialties and areas of focus. Sure, there are general practitioners, but there are just as often CSMs with deep knowledge in specific parts of the product and shallower knowledge in others. Oftentimes some are better teachers, some are better problem-solvers, some are better sellers.

And even if everyone is a generalist or the product isn’t complex, any given CSM will have seen and solved certain problems more than others. Pooled models are designed to get the right person in touch with the customer at the right time.

Intuitively, we get this. That’s why companies at any stage beyond startup have support teams, success teams, account managers, and onboarding teams to specialize in different parts of the customer journey. And even within those teams there are teams, like different tiers of support, different segments of accounts, and so on.

This type of strategy gets a bad rap. People tend to think it’s just another support system, or a phone tree at your cell service provider. But like I said, it’s supposed to work more like Kaiser than Verizon.

Pooled models have the potential to be much more nimble than concierge CSMs. They scale a lot easier, and they drive better outcomes for the bulk of customers for most companies.

But they aren’t right for every company or every customer relationship.

Two types of pooled models

First off, there are really two types of pooled CSM models. And lots of companies (including Front) are neither 100% pooled nor 100% dedicated. Pooled models are all about maximum flexibility, so don’t let yourself get boxed into going all or nothing either way.

Model 1: High-volume, low-touch

The first model is for companies with very high volumes of “long tail” or low-touch accounts.

For these CSMs, having in-depth knowledge of each customer’s business and use case isn’t a priority or a possibility. Deployments will more likely be pretty homogenous rather than bespoke. These CSMs can focus on having really deep knowledge of the product and how to get value out of it versus knowing any one customer.

If your company has a larger book of lower-revenue customers, you probably don’t want to assign them a full-time CSM. In that case, both proactive outreach and inbound messages can be assigned round-robin style to your pool of CSMs to both manage workloads and deliver fast service. In this model, you can be highly focused on goals — driving product adoption and identifying and tracking markers for risk and for growth.

Fair warning: the line between support and success can sometimes be blurry from the client side in this system. If you’re not careful, it can be blurry internally too! Setting clear expectations for what the customer can anticipate from each team should be a key part of your strategy.

Model 2: Complex or horizontal products

The second model makes the most sense for companies where CSMs need particularly deep knowledge across a broad range of use cases. In fact, Front uses this exact model for some segments of our business.

It can take a lot of time for any individual CSM to acquire a deep understanding when your product is complex or you sell to a wide variety of customers with disparate use cases and success criteria. That’s time you don’t have when your customer base (and your team) is constantly growing.

In this model, CSMs can specialize by use case so they ramp faster and deliver value quicker. They’re often more technical and more specialized in deep product knowledge. They know exactly how your product works with others — all the integrations, APIs, and the general software ecosystem.

It works almost like a dispatch system. The Account Manager “owns” the customer and can tap in a CSM on a much more flexible basis. Sometimes the CSM can be loosely tied to an account, but isn’t directly introduced to the customer unless the AM pulls them in. Alternatively, AMs could pull in the CSM with the most relevant subject matter expertise at any given stage in the life cycle.

In either of these two models, you could have a stable of CSMs dedicated to round robin response or ad hoc response or you could budget a percentage of all CSMs time — maybe 80% of a CSMs time is working with their dedicated accounts and 20% is spent on pooled customers or actions.

Bonus model: The one-to-many CSM

I don’t want to spend too much time on this one, but there’s (surprise!) a third model that isn’t strictly “pooled” but it isn’t tied to a book of business either. It’s a one-to-many CSM.

This person spends their time doing newsletter outreach, webinars, video or written content, training sessions, and maybe some direct interactions. This could also be a percentage of any CSM’s time as well, but the point is that it can create a lot of value for your broadest base of customers. 

How to sort customers to pooled CSMs

Setting up a pooled model requires careful operational thinking. If that’s got you thinking about hiring a CS Ops leader, you’re on the right track. At the bare minimum, you need a methodology for sorting customers to the right CSM at the right moment in their life cycle. And there are several ways to do it. Let’s look at four. These can also be used in any combination:

1. Subject matter expertise: Based on textual clues within the inbound message, it gets tagged and assigned to a CSM with deep knowledge in those keywords. 

2. Round robin: At the most basic level, messages get routed in sequential order to the next CSM. With more sophisticated software (like Front), you can also add in load balancing to make sure nobody gets overwhelmed.

3. Shifts: If you’re allocating a percentage of a CSM’s time to pooled work, it makes sense to assign them to shifts. Maybe one week a month or one day a week.

4. Proactive: CSMs can also scan a shared inbox for cases, names, accounts, or issues they recognize and handle or assign them to someone they know is best for the situation.

It’s almost cheating to be using Front for this work. It’s simple enough that you can do it without a CS Ops person, but if I was a CS Ops person, I wouldn’t want to do it without Front.

When a pooled model doesn’t make sense

A pooled model has a ton of advantages, which we’ve talked about. But it doesn’t work for every business model or every situation.

If there’s a baseline level of information a CSM needs about the customer’s individual implementation in order to even begin a conversation, it doesn’t make sense not to have them tied to the customer. The amount of time it would take to prep wouldn’t make sense. Similarly, if CSMs are especially proactive or part of the sales process, it’s harder to justify pooled models.

Lastly, if you’re not operationally capable of solving these two problems, think again about pooled CSM:

1. Maintaining consistent messaging with every interaction. Nothing hurts the customer experience in a pooled model more than two CSMs sending conflicting messages. If you don’t have a way to enable all CSMs to speak with one voice, you can’t risk having multiple reps talk to the same customer.

2. Internal information sharing. One of the things you lose when you fragment your responses across a team is the bigger picture of the customer’s health. Each CSM might have a puzzle piece. If you have internal transparency and information sharing is easy, you can put those together and get a picture of customer sentiment and outlook. If not, your pooled model will block you from that value.

Of course, Front was built to solve both those problems, which makes it a game-changer for pooled CSM. If you’re not using Front for CSM, I’d encourage you to sign up for a demo! Mention you read this blog and our team will put together a personalized presentation focused on these workflows.