I recently had a conversation with a top CS leader who was struggling to build and get their “Playbooks” to work.

I heard her struggles and they felt very familiar. My suggestion to her was — forget the playbooks. I knew she wasn’t going to get them to work because they just don’t fit the way a SaaS business works. They don’t fit the desired journey of a modern SaaS customer. She was obviously surprised at my take on this because the “Playbook” has been a pretty standard part of the Customer Success function for a long time. And I understand why.

Playbooks — when used in the context of a Sales or CS team — represent lists of “plays” (or actions) that a rep is required to apply against any new lead or customer. They are borne from the belief (hope?) that there is some consistent, linear set of steps that can be designed and followed to ensure success for every one your accounts.

I know this dream. I’ve held it. I’ve designed plenty of playbooks (on both the Sales and CS side) — all of them some flavor of this:

We use this type of playbook with the stated goals of:

• Ensuring success for our customers (follow these steps and success is yours! follow them not and…well); and

• Making things easier for our reps (just follow the playbook for each account and you’ll never have to think about anything!).

But let’s be honest — these playbooks are really just management hacks. We mostly use them to hold our reps accountable for working their accounts. This account is only on step two of the playbook — what’s the deal??

And while this kind of approach made sense in a traditional software sale (or even more so in a service-type offering) — it falls apart really quickly in a modern SaaS business…especially in a product-led operation.

Why is that?

Well…because SaaS — especially product-led SaaS — is different than a traditional software offering. It is a different business model. It’s a model that is built on the premise of reduced human intervention. In fact:

The goal of the “product-led” model is, in many ways, to drive sales (and engagement) with NO human intervention.

These are products — and business models — designed to support a self-serve customer journey.

Of course, this isn’t the reality. Even though some companies don’t like to admit it, we know that most of the companies in this space have strong Sales and CS teams. These teams are still important/essential parts of the customer experience. The reality is that very few companies can drive strong growth without these teams in place and operating at a high-level.

But that doesn’t change the fact that the product-led model was built to work without them. This is important to remember. Users of these software products don’t care about following some linear adoption process. With a try-before-you-buy offering (free-trial and especially freemium), users expect to sign-up and get started without talking to anyone. And they expect to upgrade without talking to anyone. And they expect to use the product without intervention. In short,

Customers don’t care about your playbook.

This means that the effectiveness of these playbooks collapse shortly after you build them.

The playbook failure

In most cases, playbooks require reps to follow some rigid, linear process that, as I just mentioned, is not in-line with how customers experience (or want to experience) your product. These playbooks basically force a rigid process onto a fluid experience. Square peg, round hole.

The typical playbook is designed to create a bunch of tasks for reps at different points of the customer journey - which is defined simply by the age of the account.

Day one - do this. Two days later - do that. Five days after that - do this. Etc.

And these tasks are generally created without respect to a previous task being completed. Inevitably, after a few weeks with this new process, your reps will wake up to an insurmountable mountain of overdue tasks in their CRM.

This leads to stress and frustration for everyone involved. Reps start to feel overwhelmed, management starts to question the work ethic of the reps, and customers start receiving a bunch of desperate emails — not because they need or want help, but because reps are dying to check off a few of the steps in their playbook.

Whispers of “screw these playbooks” will be start appearing in water cooler conversations (ie — private Slack channels). The seeds of resentment will be planted.

Wide-scale mutiny is not far off.

‍

But we need to do everything possible to ensure our accounts are successful!

I appreciate that instinct, but you have to remember: the product-led model is not designed for manual intervention. It’s designed to open your software up to larger audiences and drive larger numbers of accounts. This means you simply can’t touch every customer — as much as you may want to. And, not for nothing, many of your customers don’t want that either.

This means that the playbook is the wrong framework for a product-led CS (or Sales operation). What you need instead is a proper signaling system. A system that highlights which accounts on which you should (and can afford to) be spending time. These signals can generate/trigger specific actions (like task creation, or emails, for example), but they will be targeted to specific accounts that deserve/require your attention.

And this is mainly a question of smart segmentation — based on more than the age of the account.

Creating a Signaling system to replace playbooks

A system of relevant and signals is much more in line with how a product-led model should operate. It replaces the rigid, linear nature of the playbook with a framework that “bubbles” up the right accounts and truly makes your team more efficient (and, dare I say, more proactive).

To build a good signaling system, you need to (1) define your signals; and (2) create a plan for actions against those signals.

Defining Signals

When creating signals, you should focus on two major vectors:

• Account Tenure; and

• Account Engagement/Activation

TENURE

There are 3 stages of Tenure we’ll consider in this discussion (you can define more if it makes sense for your business):

• Brand New: accounts less than 30 days old

• Young: accounts between 1 and 3 months old

• Mature: accounts 4+ months old

ENGAGEMENT/ACTIVATION

When we talk about Engagement/Activation, we talk about them in the context of metrics created and tracked in Sherlock (but again, you can have your own versions of these metrics if you want to build them):

• Engagement: An over-time measurement of how much a user or account is using your product.

• Activation: A static measurement of how far along a user or account is in their journey toward “first value” or the “aha” moment where they realize how great your product is.

Of course, every product/business is different, but this is an example of a signaling framework you could create for you SaaS product based on Tenure and Engagement/Activation:

For some businesses, it might make sense to add a third vector — account size (or potential account size). You may want to create signals for accounts of a certain size or you would plan different actions for accounts of different sizes. That might look something like this:

Defining Signal actions

Once you have your signals established and you are tracking them well, you should build a set of suggested actions for each. The actions that you design need to be unique and tailored for your business and operation. But as an example, your program could look something like this:

As you can see, by assigning specific actions to your signals, your signals will start to act as triggers. While at first glance this may resemble “a playbook”, there are a couple of big differences between the playbook and this signaling approach.

First of all, Playbooks are traditionally applied in a more global fashion — we must apply this playbook to every account (or the majority). Signals, on the other hand, are designed under the assumption your team simply can’t deliver high-touch attention to every account (or even most of them) and need to be able to focus their work on those with the highest priority. They don’t need a system to ensure every account is getting attention — they need a system to help them focus on the right accounts.

Secondly, playbooks are generally designed as linear processes — they call for several steps that the rep and user need to pass through to complete the playbook. Whereas signals assume a non-linear engagement pattern for accounts. They trigger single actions when certain engagement conditions are met.

For these two reasons, a good signal program is much more in-line with the needs and flow of a product-led business — and the journey that these customers take.

Other non-behavioral, scheduled signals

After reading a draft of this post, another friend in the CS space reminded me of a few “signals” (he referred to them as “touchpoints”) that he considered “scheduled.” These included things like QBRs (when relevant), NPS surveys, and renewal conversations that happen at specific times and are independent of any behavioral criteria.

These made a lot of sense and if applicable, should be added to your program appropriately.

In conclusion

While much of this discussion will seem obvious to many in the space, my hope is that it will help break others from an approach that was borne at a different time. A different era of the software business. By moving your approach to a better framework — one more in-line with how modern software is sold and serviced — you can liberate you and your teams from the oppressive weight of the traditional playbook!