Using your product engagement data to forecast churn

Using your product engagement data to forecast churn

The Covid-19 pandemic has already changed – maybe permanently—the way we all live, shop, work, learn, socialize…and much more. We are having to rethink and adapt in almost every aspect of our lives. 

And our SaaS operations are no exception. The global shutdown has forced many SaaS operations to shift their focus from generating a constant stream of new business to maintaining their existing revenue base. During times like these, churn—or rather, churn mitigation—is the most potent lever for short-term survival, medium-term recovery, and long-term success. 

As SaaS businesses the world round shift their attention to maintaining their existing customer bases, they are having to think about churn in a way they haven’t before. And because of this, we think that a new skill set – a new competency – will emerge. 

Churn forecasting. 

Like for real. If they are paying attention, many SaaS businesses will come out of this crisis with a much more robust churn forecasting practice. 

Why do we need a churn forecasting framework?

Raise your hand if your company forecasts monthly sales. 

Ha. A bit of a rhetorical one there. 😁

OF COURSE your company forecasts monthly sales. In fact, I bet you spend hours on it each and every month. You likely have forecasting models built into your CRMs, weekly meetings across the sales organization to project the likelihoods of converting current deals, weekly updates at the exec level, real-time model adjustments, and more. You have probably built an entire infrastructure to help you accurately forecast monthly sales.

So, why don’t we apply a similar rigor to monthly churn forecasting? Let’s be honest…up until this point, the way you forecasted churn was to drag a simple, consistent churn rate across your spreadsheet like so:

Pretty standard churn forecast process

Maybe you go one better and have a churn model that applies a different churn rate against account types (small, mid, large) given their different churn profiles. If so…bravo. You’re ahead of most.

But the reality is that not many teams put much more rigor than this in forecasting their monthly churn. And truth-be-told, that might have been fine for a lot of companies up until this point. Under normal circumstances, you may not have had a lot of variability in your churn rate. 

But these ain’t normal times, Toto.

This pandemic and unprecedented global shutdown is will most definitely affect your churn rates. And in ways that are far from normal. It is essential to take a truly hard look at the way you project churn – in a way that can not only help provide some visibility over the next few months, but in a way that can extend beyond this shock and provide much more clarity into your business going forward. 

And the basis for any good churn forecasting model is product engagement. 

Four steps to designing churn forecasting model

A solid churn forecasting model should be designed in the same way you build a sales forecasting model. Traditional sales forecasting models are based on a simple formula:

Deal size (potential $$) X Likelihood to close = FORECASTED REVENUE

Add a close date to this model and you’ve got the building blocks of a forward-looking sales model:

The same model can be applied to churn forecasting:

  • Account size (current MRR) X Likelihood to churn

Easy, right?  😉

Of course, whether you are forecasting sales or churn, the biggest challenge is figuring out a good way to calculate the “Likelihood” factor.

In traditional Sales forecasting, “Likelihood” is typically based on the “stage” of a deal. For example:

Of course there are more complex and nuanced versions of this model, but this is the basic framework (of course it doesn’t work well for product-led businesses – here is an alternative methodology for forecasting sales in a product-led business).

That leaves us with the question – how do you create a “Likelihood” factor for churn? How do you assign a risk factor to each of your existing accounts so that you can accurately forecast a monthly churn number? 

This is the crux of designing a churn forecasting model. The four steps to building this model include: 

  1. Understand churn indicators; 
  2. Track these indicators closely;
  3. Create top “risk” cohorts and assign a churn likelihood factor to each cohort;
  4. Plug likelihood factors into revenue forecasting model.

Step One: Understand churn indicators

When it comes to churn, there is no greater indicator than product engagement (or, more accurately, lack thereof). Some of the most common reasons SaaS accounts churn inc

  • Never got to first value before buying
  • Never was able to figure out how to integrate the product into business process
  • Bad fit – didn’t have a high-value use case
  • Key user left the company
  • Found a competitor that better solved their problem
  • Problem issues (bugs, performance, etc)
  • Budget cuts
  • Went out of business

Maybe with the exception of Budget cuts (which sometimes do come seemingly out-of-the-blue), every one of these reasons will be expressed through a product engagement metric or indicator. 

For example, if the account was never able to get to first value, they will have a low Activation rate. in their first few months with the product.  

If a key user leaves a company, the account’s overall engagement will drop significantly. 
If the users found a competitive product, their engagement will drop over a period of time (when they are assessing the other solution) and they may eventually trigger some key event that would indicate they are ready to leave (like export data, or disconnect integrations, etc).

The first step in creating a churn forecasting model is understanding engagement-based churn indicators. As mentioned above, there are many reasons why accounts cancel their subscription, but they will all be expressed by some engagement metric. These include: 

  • Low Activation: Activation is a measure of how far an account has gone down the path of becoming “Activated.” A paying account with low Activation rates is an indication of an account that hasn’t been properly onboarded and therefore may be missing some key value of the platform – which could lead to early cancellation.
  • Low Engagement: An account with low engagement levels is certainly more likely to churn than an account with higher engagement. But if that low level of engagement is relatively consistent, it may not be a major risk. 
  • Significant drop in Engagement: An account that shows a significant drop in engagement over time is a bigger red flag than consistent levels of low engagement. There can be many reasons why an account’s engagement would drop overtime (including some of the reasons mentioned above) – none of them very good.  
  • Inactivity: Low engagement is one thing. NO engagement is another – and one that carries a much higher churn likelihood. An account that has been inactive for 7 days it not good. An account that hasn’t been active for more than 30 days is a real problem.
  • Triggered farewell event: In some products, there are certain activities that users do when they are preparing to close down the account (like exporting data, or removing a key integration, or deleting templates, etc). We call these “farewell” events.

Step Two: Track these indicators

Admittedly, this might be the hardest step in this exercise. To be honest, it’s precisely why we built Sherlock. If you are a Sherlock user, tracking these metrics will be easy and second nature. If not, then you will need to have an internal system to track and calculate these important metrics for all of your paid accounts. You can learn more about building an engagement scoring system in this post  if this is something you want to build internally to support this effort. If you don’t, you can try to build some kind of proxy for engagement. The important part is to be able to measure both engagement and activation (and they are different) separately. 

Step Three: Create your top “risk” cohorts

With these engagement indicators in mind, the next step is to put together a churn likelihood model that creates different churn threat segments and assigns a respective likelihood factor to each. Generally, we recommend creating these segments with account tenure in mind. Accounts engage with your product differently based on how long they’ve been using the product and therefore should be treated differently in any kind of churn forecast model.  
Your churn likelihood model will look something like this:

Step Four: Combine likelihood factors with MRR for each account

Once you have likelihood estimates in place per segment, you can plug them into your larger forecasting model (shown earlier) – accounting for the MRR of each account:

Et voila! You’ve got a churn forecast model based on account engagement!

Looks awesome – but how do I set this up??

I know, I know. This sounds like a lot. But don’t worry. So long as you have a solid handle on your key engagement metrics for each account, you can absolutely build a solid model without a PhD in machine learning (or any machine learning at all – trust me!). 
Start by looking at the last X number of churned accounts. Let’s call it the last 3 months to start. Some of this historical data will be difficult to get (even with Sherlock), so alternatively you could just commit to tracking churned accounts over the next 1-3 months. These accounts will serve as the basis of your model. 

For each churned account, look at the engagement indicators from your model. You will start to understand which indicators are more consistently correlated with an account cancelling. This is a very iterative process so spend time setting up an initial model – knowing that it will evolve overtime.  Play with it and use it to forecast churn in your third month. See how accurate you are. I think you will surprise yourself. 

What about timeframe? Should I only forecast one month out? 

This is a really good question and it’s really up to you how far out you want to look. Like with any forecasting, it’s often harder to be accurate with a forecast in a very small window – like one month out – and easier if you use a slightly wider one – like 3 months out. Anything beyond that is really planning (versus forecasting). 

We recommend a forecasting model that covers both short-term churn (1 month) and a mid-term window (3 months). Simply append your likelihood model with columns for “likelihood of cancelation in next 1 month, next 3-months” and adjust your “likelihood” rates to each time frame. For example, an account that is inactive for 7 days might not be likely to cancel this month, but might have a 10% likelihood of cancelling the following month. 


This type of model works the same with annual or monthly contracts. If you sell only annual contracts, simply apply the model against those accounts whose contract is scheduled to renew within the next three months. This will give you a very good indication which contracts are at risk. 

With that said, with an annual contract model, it is likely someone from your team will be in touch with account as contract renewal approaches. The direct feedback from the account (ie – “We’re not going to renew this contract”) may override the “likelihood factor” in this kind of engagement model. 


No forecasting is an exact science. Churn forecasting is no exception. But when you have the proper, detailed visibility into how your accounts are engaging (or not engaging) with the product, you can build a model that is incredibly accurate and gives you essential transparency into this key metric. 

Don’t consider this post an exact formula for how you should be using product engagement to forecast your churn. Our goal is to encourage you to start thinking about churn forecasting more seriously – and to put product engagement data at the heart of it. The specifics of how you do it aren’t as important as the process here. Give it a shot. I promise you won’t be disappointed. In fact, you’ll wonder why you didn’t do it a long time ago.

Track and communicate your Product data schema with this Notion template

Track and communicate your Product data schema with this Notion template

Good product data is an essential part of any modern software company’s operation. It ain’t just for product analytics anymore. Marketing needs it to effectively target prospects and users. Sales needs it to understand which trial accounts are worthy of attention. Customer success needs it to help them identify issues and opportunities. Operations needs it to help support forecasting. This data is the lifeblood of software business.

But one of the biggest challenges with regard to this data (beyond getting the product/engineering team actually track the data) is communicating what is being tracked — and what it is all called — to the teams that need it.

“What’s the event for X?”

“Do we track when someone saves a Y?”

“How do we know the name when a user creates a Z?”

“What do we call our subscription plans again?”

These are questions that haunt product teams on a regular basis. And the last thing they want to do is search through Github or an engineering ticketing system (Jira, etc) to find these answers.

What’s worse, however, is when the team DOESN’T ask these questions. When they don’t know what is tracked — what’s available for them to use. And this happens a lot. You can spend a lot of time tracking this product data, but it goes to waste because the people who need it don’t understand it.

It’s really important to have a “public” product schema so that everyone on the team can be on the same page with your product data.

Moving our schema to Notion

Over the last several months, we have moved our knowledge base to Notion. One of the last pieces we brought over was our product data schema (we used to track it in Github, then we moved it to a Dropbox Paper doc). This has been super helpful for us, so we decided to create a template that anyone can use. You can grab it here 👇

Purpose of this schema doc

We built this doc to serve two purposes:

  1. To give the team a single reference point for all of our tracked product data; and
  2. To help us manage the implementation of requests for additional data.

I know it’s not easy to combine these two goals in a single doc, but it is working well for us. Obviously, this doc doesn’t replace an engineering system, but when we need to implement new data, we simply reference this doc in the engineering ticket. It has worked really well for us.

How to read the schema doc

This template has a bunch of columns (which Notion calls “properties”) that serve as the basis of the information we need to know about each piece of data. Here is a quick explanation of each one:

  • STATUS: Like I mentioned, we use this doc to track the implementation of new events/data. So we have 4 different statuses for each — Requested, In process, Live, and Depreciated.
  • TYPE OF CALL: This is used to differentiate between events and trait calls.
  • EVENT NAME: This is our main name column. For events, this is the actual name of the event that is triggered (with the proper formatting). We leave it blank if it’s a trait call so it isn’t confusing.
  • RELATED FEATURE: This is an important “tag” which makes this a good reference doc. Many times when trying find tracked data, the feature it is related to is a typical mental taxonomy. So every data point is tagged with a specific feature (we do have a General category for those not tied to a specific feature).
  • PROPERTIES: These list out any properties that are tied to a specific event.
  • USER TRAITS: These are the user traits that to be updated.
  • ACCOUNT TRAITS: These are account traits that will be updated.
  • FRONT OR BACKEND: This is for the engineering team to track whether or not this is something that is tracked via the front or backend.
  • GITHUB PR: For the engineering team to enter the PR where this data point was implemented — for easy, future reference.
  • GO-LIVE DATE: Engineering should post the date this data point is implemented for easy, future reference.

Obviously, you can add/subtract anything else that makes sense for your team.

Things I like/love about this template

In general I’ve become a fan of Notion. It took me a while, but our relationship has definitely grown stronger over time the past 3–5 months. Little-by-little, we have moved most of our knowledge base here (and more). I find the Notion docs to be very versatile for all of our needs — I really like having docs that allow us to use text and embedded tables/boards (core Notion offering). This alone makes it possible to build a document that can serve multiple purposes and keeping people on the same page. It is not easy to find something that can serve as a meeting place for engineering and go-to-market teams alike.

Some more specifics on my love affair with this doc:

  • Permission management: Obviously, this is a basic feature of any shared docs, but I do think Notion’s sharing is very easy and intuitive. For us, the Product team owns this doc and is the only team that can edit the doc (add new requests, edit status, make changes, etc). Everyone else is given comment access in case someone needs to ask a question or make a note for future viewers.
  • Table view plus individual cards for each element: This is where Notion tables leapfrog your typical spreadsheets/tables. Any element (row) can open up to a more detailed view (in our case, it’s the event name in each row). This allows you to enter more details about each event/trait — whether that be engineering specs or more explanation for those using the data. It’s really the magic feature here. We add a lot of information here (more than you are seeing in this template).
  • Filtering/sorting: This is super important. Being able to filter/sort each row allows the user to easily find any specific group of items for which they search. For example, if they want to see all the events tracked against a specific feature, they can filter the RELATED FEATURE COLUMN and find everything they need.
  • Search: Notion search on a table is pretty badass. Another thing that makes this doc a reality for us.
  • Multiple Views: Another key feature of Notion is the ability to create multiple views for each set of data. For this doc, we have the main table as well as a Board (ie — a kanban board) to track the requests for new data. We also created a table that is filtered to show only new data requests — making it a bit easier for engineering team to find these requests.

What I don’t love

Obviously, this isn’t a perfect solution. Spreadsheets/tables are generally a bit clunky and cumbersome for users. Notion tables are far more friendly than other options, but they still can be clunky. For example, I don’t love how the table hangs off the edge of the page and requires a bunch of awkward scrolling. But that’s being picky.

This doc also doesn’t do a good job of listing out each individual trait or property that we track. We may create a supplemental document or table for this. Need to figure this one out. As of now, our teams can search for a property/trait and get the information they need — it’s just not idea.

Finally, this is also a document that is manually created and updated. It is not an application that can update automatically based on changes in the code (or Segment) or carry any real time data from the product. That would be nice 🙂

Would love your feedback

The template is free for you to use in your instance of Notion. We’d love to hear how it is working for you and what adaptations you make to it to make it even more valuable. Happy tracking!

Why Customer Success Playbooks fail in a product-led model and what to do about it

Why Customer Success Playbooks fail in a product-led model and what to do about it

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, generally, will be defined by the age of the account).

Do this on day one; then two days later, do that; then five days later, do that; 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 their work ethic, and customers start receiving a bunch of desperate emails — not because they need help, but because reps are trying to check off the steps in their playbook.

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

Wide-scale mutiny is not far off.

Is there a better way? What is the solution?

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 good signaling system 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:


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


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!

Here’s How Audiense is Making the Transition from Sales-Led to Product-Led

Juan Fernandez of Audiense

For every company that’s trying to figure out how to layer Sales onto an existing product-led model, there are several trying to do the opposite — introduce a Product-Led Growth (PLG) model onto an existing sales-led model. 

And this is NOT an easy transition. For those who think this is a simple as slapping free trial sign-up on the website and adding some pretty new onboarding flows in the product is in for a rude awakening. In fact, the product challenges involved with this kind of move – while far from trivial – are many times, the easy part. 

One company that is in the throes of this transition right now is Audiense – a European audience intelligence startup helping marketers and consumer researchers understand how to be relevant to the audiences that really matter to brands. 

Although they started off as a self-service tool for community managers and small agencies, Audiense transitioned to a B2B sales-led model years ago. Their core product has been a sophisticated solution with a higher price point and every customer had to go through a sales process to buy the product.

Recently they decided to move to a product-led model. 

Juan Fernández is Audiense’s Head of Product and is leading the company’s transition to PLG. We sat down with Juan last week to talk about how he plans to make the transition.

SHERLOCK: The first thing I’d love to understand is why Audiense decided to move to a Product-Led model? What was the reason for this move? 

JUAN: We decided to move in this direction because we thought we were limiting our business by requiring customers to go through a sales process. We thought if we could allow new accounts to sign-up and try the product without talking to sales, we’d attract a much wider base of prospects. We also wanted to reduce the cost of acquiring new leads and disrupt our market by letting everyone experience our product first hand. 

SHERLOCK: And has that proven to be true?

JUAN: Definitely! We’ve seen a steady growth in leads month after month since we went to this model. And the best part is that these leads already have a deep understanding of what we do and what we offer. That makes the commercial conversation much easier.

SHERLOCK: What product changes, if any, did you have to make (or are you planning to make) to support this new model?

JUAN: Lots! The first set of changes we attacked was a frictionless sign up journey, a clear pricing model and a very simple online checkout process. Now, our focus is on constantly improving the whole customer journey, phase by phase. We’re starting with Activation rate, followed by feature adoption, conversion and finally product virality. It’s an ongoing process. Measure, identify friction, fix and measure again. Rinse and repeat! 🙂

SHERLOCK: How did your sales team respond to this move?

JUAN: To be honest, this was one of our biggest concerns. We wanted to make sure that opening up the product to self-serve signups wouldn’t hurt our sales pipeline. We wanted more leads, but not if it meant hurting our Salespeople. 

SHERLOCK: How did you avoid that?

JUAN: Well, first of all, a lot of our new business comes through channel partners, so our sales team isn’t dependent on free trial leads. But we still had to approach this product-led offering in a way that wouldn’t threaten them. Our product-led offering increases the number of hot leads (PQLs) for each salesperson, so they’re actually pretty happy about it. 

SHERLOCK: Interesting. So you are starting by removing some (but not all) of the friction for potential buyers. Are they ok with that?

JUAN: So far, it appears so. What we see is that customers considering the cheapest plans are happy to purchase without talking to a salesperson and those considering an Enterprise plan prefer to go the sales-led way. For us, it’s all about deciding which route to take for whoever is engaging with the product. 

SHERLOCK: And has this move changed how you are managing leads through your “funnel”?

JUAN: Definitely. I had to set up a process for qualifying these new leads based on how they are using the product and their firmographics (such as company size and location). We have Product Qualified Leads that we put in automated nurture campaigns and PQLs that I send to the sales team every week. It’s all pretty manual for now. I run a report for new accounts that have reached a certain Activation rate during their trial and send it to the sales team as a list of qualified leads. 

We also launched email sequences to accounts that haven’t reached a certain Activation rate yet. We want to encourage them to become more Activated or to raise their hand for a quick chat with someone from our team.

SHERLOCK: And what type of engagement emails have you seen the best results from so far?

JUAN: We are still testing a lot of this, so I can’t really say empirically at this point. But emails that come directly from someone at the company and offer help/support with the product, or better yet, specific features receive more responses. These sorts of emails have the added benefit of promoting actual conversations, which helps us move these accounts toward conversion.

SHERLOCK: Is your sales team happy with the transition so far?

JUAN: Yes! They actually prefer talking to leads who have at least tried the product and understand its value. Plus they don’t have to waste their time on customers who don’t really understand the offering. These leads have traditionally taken up a lot of their time, as I’m sure you can imagine. 

SHERLOCK: What’s next for the transition?

JUAN: A couple of things. First of all, we need to become more systemized about the process. Both on the automation side and on the ideation side. 

We want to reduce the amount of manual work by automating engagement sequences that we know are working. We also want to refine the way we ideate and prioritize improvements. I want my team and I to focus on developing a well-defined weekly ideation protocol, where we’re looking at our KPIs, deciding which metrics we’ll focus on, listing ideas, ranking them by cost and impact, and executing on the best ones.

SHERLOCK: Sounds like a lot! Why are you, as Head of Product, leading this effort versus someone in Marketing or even Sales?

JUAN: I think a move to “product-led growth” puts the product at the center of the operation, so the product team really needs to own the process. But this affects all departments so we created a cross-functional PLG team. It’s like The Avengers: a group of very different people, each one with a different superpower, and I am extremely proud to be working with them.

Apart from me as a team lead, this team is comprised by a marketer who is in charge of driving traffic to our top of the funnel: generating visits with our blog, newsletter, social media and advertising; then a product manager in charge of the on-boarding experience and the email sequences. We also have a customer success manager in charge of the knowledge base and the technical support and someone from the ops team in charge of account settings, legal and accounting. And finally, a UX designer who supports all of us by designing delightful experiences and beautiful graphic material. 

SHERLOCK: Awesome. Any advice you would give to others trying to make the transition from a traditional sales-led approach to a product-led approach?

JUAN: I’m still learning myself, so I wouldn’t dare. I read a lot and ask a lot of questions of people who have had success with product-led models. One thing I would say is that you have to think about it as an evolution and a constant learning and experimentation path instead of some immediate switch you can turn on.

SHERLOCK: This is great advice, Juan. Thanks so much for taking the time to tell us about your process!

Learn more about getting started with PQLs here >>

Sherlock + Zapier for a Winning Sales Operation

You already loved Sherlock’s Slack Alerts for your PQL process. Now we’re taking that a step further with Sherlock Actions. All you need to do is set up an Action in Sherlock, forget about it and we’ll take care of the rest. 

There’s Actions for apps like Hubspot, Intercom and Slack, sure. But if you really want to change the way you work, there’s our Zapier Action (courtesy of Webhooks). If you’ve never used Webhooks, start with this help doc.

Ready to to put your product qualified lead process on steroids? Here are 5 of our favorite Sherlock + Zapier Actions:


Let’s start simple. Todoist lets you create tasks. In some sense, maybe everything you do is a task. But following up on PQLs? That’s definitely a task.

Set up an Action flow in Sherlock so a new task is automatically created every time someone becomes product-qualified and you’ll never miss an opportunity to connect with a lead that will actually convert.

Bonus points if you set up a task for leads that are close to becoming PQLs but haven’t quite gotten there yet. You’ll want to (gently) prod them into finishing those last few steps to first value.


Sometimes a full out task management system is too much to manage. Maybe you like to keep it simple. Maybe you’re the sort of person that just wants an email when someone finally hits that Activated status. From there, you can filter them to another box, send them an email or reach out however you choose.

With Sherlock + Zapier + Gmail, you can have all that happen automatically. Well, you’ll have to reach out and do the demo, but all that process stuff will happen automatically. That leaves you more time to do what you do best — close deals.

While we don’t recommend sending emails directly to your leads through this setup, it is something you could do if you’re feeling brave. Want a better product engagement-based email outreach flow? Sherlock’s got you covered.


You already know we have a direct Action for Hubspot (or you do now), but Hubspot isn’t the only CRM on the block. With Sherlock + Zapier, you can connect to any CRM on Zapier’s platform. Create leads, mark them as Activated and manage them however you see fit — and do it all where your team already lives.


Still using Airtable to manage leads? With Sherlock + Zapier + Airtable, you can add Activated trials (or not) to a spreadsheet, categorize them as Activated and know exactly where everyone stands at a glance.

Then, when you’re looking for trials to reach out to, all you have to do is scan the list, find the ones that are Activated and 💥— you’ve got a list of trials that are already in love with your product.


Wondering if a new account is fully Activated? One of your key accounts adding new users? Worried you’ll miss a score change? You need a Zapier + Slack integration.

Just kidding. Whatever product engagement alert you need, we’ve already got. Use Actions to set up realtime, customizable product engagement alerts directly from Sherlock. 

With Sherlock Slack Alerts, you never miss an Activated trial

Now that’s Sherlock smart.

Building a Product Qualified Lead process for your Complex product

This is part 4 of a 4-part series on PQLs: What they are, how to find them and how to build a winning Product Qualified Lead process

Want to know everything you didn’t know about Product Qualified Leads (PQLs)? Get our e-book.

activation slack alerts for Product Qualified Lead process

In case you haven’t heard, PQLs are leads that are more likely to convert because they have found value in your product. If you’re a modern SaaS business, you want to find these leads. So the only question left — how? It’s elementary: you need a Product Qualified Lead process.

So you’re convinced: you want to find PQLs and make a Product Qualified Lead process for your business. But where to start?

To build a proper Product Qualified Lead process, you will need to:

  1. Properly define what the criteria by which your leads will become product qualified (otherwise known as an Activation checklist)
  2. Have a set of guidelines for turning these leads into paying customers.

Let’s get started!

defining a pql is important for a winning Product Qualified Lead process

First off, how complex is your product?

When our customers ask how they should be designing their Product Qualified Lead process, the first question we ask them is: 

How complex is your product? 

More simply, how hard is it for a new user (or small group of users) to self-serve their way to first value? Don’t forget: self-serve means without any manual support of intervention from your team. 

The answer to this question is the starting point for your PQL definition. It’s answer tells you how Activated a new account should be before your team gets involved. 

This post covers a Product Qualified Lead process for complex products. Not sure if that’s you?

Ask yourself how many of your last 10 signups self-served their way to first value. If the answer is less than 4, read on!

A new user is almost always going to require manual support to get to the promised land. Complex products often require technical implementation, access to data or tools from other departments, or some deeper domain knowledge for a user to get value. 

A complex product might have a free trial period, but is more likely to only sell to customers who go through a sales demo with a more hands-on approach. 

Think Salesforce.

Looking for a different product type? Download our e-book.

Next, how big is the opportunity?

Now that you’ve decided you have a complex product, you should think of the other main factor that will determine how quickly your Sales team gets involved. Namely, the size of a Sales opportunity. As with simple products, if a new trial holds the potential for more revenue, you’ll want to get your Sales team involved earlier. 

At the very least, you should be able to categorize your new trial signups into Small, Mid-Size and Large revenue opportunities. 

Oftentimes, companies will use the company size of a new trial as a proxy for opportunity size. This is certainly one way to go about it, but you define opportunity size based on whatever criteria makes sense for your business. 

Putting it together with Activation Rate

The more complex a product, the earlier your Sales team should intervene. Similarly, the bigger the size of the opportunity, the sooner you want your Sales team on it. Sounds simple, right? (That’s good, because it is). 

If you have a complex product, you’ll need to get involved sooner regardless of the deal size. That being said, you’ll probably still want to wait for accounts to hit a certain level of Activation and keep your Sales and CS team focused on bigger deals.

Here are good rule-of-thumb Activation rate guidelines for a complex product:

Deal SizeReach out when:
Small 50% – 75% Activated
Mid-Size25% – 50% Activated
Large0% – 25% Activated

As you go through the next section, keep in mind the goal of a Product Qualified Lead process for complex products is to balance the time of your Sales team. That way, they are focusing on larger opportunities but aren’t abandoning smaller opportunities with a high likelihood to close.

Product Qualified Lead process for the Small Opportunity

Product Qualified Lead process for the small opportunity intermediately complex product
Product Qualified Lead process for small opportunities — Wait until they’re ready to convert

These pose quite the conundrum for Complex products. You know your product needs manual support for most users to get value, but how much time can you afford to give such a small opportunity? 

In these cases, the complexity of your product may just work in your favor. Wait, what?! 

That’s right. Small accounts that are really interested in your value proposition — in the promise of your product — will make the effort to get set up and experience some of the value. 

When their Activation is high, you’ll know they’re committed and it’ll be worth it for your Sales team to give them some attention. How high is high enough? We recommend waiting till they’re at least 50% Activated

How to engage these Product Qualified Leads

Because it is harder for users to recognize the eventual value of a Complex product on their own, trial leads on this product will likely need some kind of demo of the product from your Sales team. They will need to see the finished cake (complete with frosting) if they are going to move forward and convert. 

In these cases, it’s important for your Sales team to engage these users and invite them for an in-person demo of the platform, perhaps with an email. 

Want to know how to win over small deals? Download our e-book and get considerations and sample emails.

Product Qualified Lead process for the Mid-Size Opportunity 

Product Qualified Lead process for the mid-size opportunity intermediately complex product
Product Qualified Lead process for mid-size opportunities — more users, lower Activation

These mid-sized opportunities are exactly what they sound like. Bigger accounts than a small opportunity, but smaller than a large one. The bigger the account, the more users involved, the more coordination necessary and the more complex the path to conversion. 

So let’s be honest: Not many opportunities will self-serve their way to conversion with a Complex product, regardless of the size. But because these are bigger than small opportunities, you’ll want to get your Sales team involved soonish, probably at around a 25-50% Activation level

How to engage these Product Qualified Leads

The challenge here is still the complexity of the product. It’s hard for users to identify the full value of the platform on their own. 

Focus your manual intervention on booking a time to talk to your Sales team instead of pushing the account toward deeper Activation


Not sure what to say? Download our e-book and get sample emails to win these mid-size deals.

Product Qualified Lead process for the Large Opportunity

Product Qualified Lead process for the large opportunity intermediately complex product
Product Qualified Lead process for the large opportunities — It’s ok to jump in a bit earlier

When you get large opportunities to sign-up for you Complex product, you don’t need a great deal of product usage to justify, at least, an initial touch point from your team. In fact, you should feel comfortable reaching out to these accounts soon after they sign-up or when they reach just about 25% Activation.

From there, it’ll be somewhat similar to a traditional Sales process. Or at least as you’re going to get with a modern SaaS product. Start by identifying the key decision makers and make sure that they see the complete, fully-baked value of your product, which can be hard to do during a trial so get them on a demo ASAP.

Ready to take that large opportunity from trial to forever? Download our e-book.