Subscription Software and the Churn Challenge Blog Series
In the previous blog post, I described the churn challenge at subscription-based B2B software companies and provided guidelines for churn reduction based on my experiences. In this blog post, I’ll dive deeper into the first two recommendations:
Organize customer-facing personnel into cross-functional, customer-centric teams. This means that pre-sales and post-sales roles work closely and collaborate to drive customer adoption.
Establish a common set of success metrics for all cross-functional customer-centric team members.
The idea behind these recommendations is to reduce silos as much as possible, give customers a consistent, unified customer experience, and ensure all customer-facing personnel have a shared understanding of customer needs and learnings about technical product details and challenges.
What customer-facing roles and responsibilities are important?
A word of caution: titles vary dramatically at different companies for each of the roles defined below. I’m going to do my best to use generic, descriptive titles and clearly define the roles and responsibilities of each:
Sales engineer - focuses on the pre-sales motion, assisting prospective customers with tool evaluations, responding to RFPs, and helping salespeople appropriately position the value of the tool to prospective and existing customers.
Support engineer - focuses on interfacing with existing customers to troubleshoot product issues, provide workarounds for known issues, and answer specific feature usage questions that a customer has.
Post-sales engineer - provides implementation, configuration, and product usage guidance specific to a customer’s defined use cases.
Account manager - focuses on account oversight to ensure customer adoption and successful renewal
When I first started defining the various roles, I had separated “billable” vs “non-billable” roles, i.e. roles that work with customers who have paid a fee for additional support and/or services on top of the standard license fee versus those who work with customers who have not paid for services. But then I realized that segmentation is a big part of the problem that needs to be solved. With more roles comes more silos, additional handoffs, a lack of clarity about role expectations, and a lot of customer confusion about who they should be working with to support their needs. For these reasons, I’ve reduced the number of roles to the four above.
Are paid support and service offerings important? In many cases, YES. Customers are willing to pay for expert guidance to help them adopt a new tool successfully. It’s important to remember though that the goal of a subscription-based software company is to maximize predictable recurring revenue. In traditional companies, Professional Services (PS) groups have been treated as consulting firms - separate profit centers where the focus is on billable utilization and ensuring that each consultant delivers enough to cover the cost of their own salary and the overhead of the consulting business. But if the goal of a tech company is to maximize predictable recurring revenue, this approach is short-sighted for several reasons.
First, the people in your organization who deliver paid consulting and engineering services are a gold mine of information - they get in-depth, hands-on experience with complex customer use cases, allowing them to continually refine implementation and onboarding practices while also learning where product limitations exist and where customer expectations are misaligned with the tool capabilities. They should be using these learnings to conduct important non-billable activities that help the rest of the organization:
Documenting specific customer use cases and tool configurations to support them
Creating customer success stories, whether internally available to help team members or externally available as customer case studies
Capturing product issues with appropriate technical detail
Capturing enhancement requests aligned to customer use cases
Mentoring and supporting both billable and non-billable customer-facing personnel
Second, the scope and price of services in this model often become prohibitive to a large part of the customer base. PS groups define large service packages at high price points and with a sales and delivery model that focuses on the largest customers with the biggest budgets. This leaves smaller customers, who often have the potential for license expansion and growth, struggling with product adoption and churning instead of expanding.
Why cross-functional teams?
John P. Kotter, in his book Accelerate: Building Strategic Agility for a Faster-Moving World, describes a tech start-up as a fast-moving adaptive ‘entrepreneurial network’ that acts collaboratively to address customer needs. However, as companies grow, it’s difficult to maintain this structure. Instead, the company becomes increasingly hierarchical, which causes conflict with the adaptive network, until the network is eventually crushed.
This is a fair assessment of what I’ve experienced in my tech start-up experiences. Even though product and engineering follow agile methodologies, agility gets lost in the other parts of the organization with customer-facing responsibilities as the tech startup grows. It becomes almost impossible to foster fast feedback loops.
It is crucial to instantiate fast feedback loops to ensure product features meet customer needs. Fast feedback loops require optimizing flow, and flow requires minimizing wait times between hand-offs. This is true whether you are thinking about getting a new feature to market or appropriately enabling customer adoption. In the first case, we consider the development value stream; in the second, we focus on the operational value stream. What’s interesting here is that the constructs applied to lean and agile software development for the development stream can and do apply equally well to customer success in the operational value stream.
By building high-performing collaborative, cross-functional teams, handoffs can be reduced and the customer can have a more consistent, uniform experience and accelerate product adoption. But what does this look like in reality? Some tech companies have adopted “pods” that support a set of customers. Each pod contains a mixture of pre and post-sales roles that handle account management, technical adoption, and support. So this might look like 6 sales reps working with 2 sales engineers, a renewals manager, a billable post-sales engineer, a non-billable post-sales engineer (or 2 post-sales engineers who share billable and non-billable engagements in some cases), and a support engineer. I’m intrigued by this approach as it closely models the cross-functional aspect of agile software teams. Where the standard development model used to be designers handing off to developers, who then hand off to QA, each being separate departments, the implementation of agile practices introduced the concept of persistent cross-functional teams that are now the norm. This increased the shared understanding of the application features being developed, increased collaboration, and allowed teams to focus on reduced wait times between steps, reducing overall cycle time. Cross-functional customer-facing teams will experience similar benefits.
There’s another benefit here too - unifying the focus across roles - to make the customer successful. Teams align on success metrics which naturally arise to emphasize customer satisfaction. And processes evolve that better support flow, in something I like to call “global vs. local optimization” or what’s commonly known as the lean software development practice of optimize the whole. What does local optimization look like? For example, consider a support organization that implements a new support ticket escalation policy requiring an account manager to complete a detailed form and get approval from their director and a support manager. The policy was implemented to protect the support team that was recently inundated with “emergency” escalations, some of which were initiated by anxious account managers for non-business-critical situations. While the new policy produced the intended impact of protecting the support team and reducing the number of escalations, it also had the negative impact of increasing the wait time for legitimate issues to be escalated, decreasing customer satisfaction.
Or consider the case of a Customer Success Engineering team with the primary responsibility of providing product usage guidance to customers who request it. Each engineer was measured primarily based on the number of customer calls they supported each quarter. Requests would come into a queue via email and the engineers would pull work as they had the capacity to support the request and then schedule a call with the customer. The focus on the quantity of requests drove a fast response time, as engineers were motivated to take on more work fast. However, it also drove uncollaborative team member behaviors as well as low quality. Since team members were motivated to quickly handle calls and move on to the next one, they tended to:
Skip doing an appropriate pre-call investigation to understand customer background and use cases
Utilize pre-canned responses they collected from other customers without tailoring them to the specific customer’s needs
Regularly refer customers back to support or the account team for questions deemed “out of scope”
Avoid proactively volunteering to help other team members and not ask for help from other team members with expertise in the requested product area
Skip follow-up activities such as adding detailed use cases to enhancement requests or writing FAQ articles that would help product management understand product gaps as well as help other team members who might encounter similar customer situations in the future
The result was frustrated customers and account teams.
Metrics need to be customer-focused: time to first value, customer satisfaction (CSAT) scores, product adoption and health metrics, and net promoter scores (NPS) can provide a realistic view of how successful customer-facing teams are being supporting their customers. And customer-facing team members should be measured based on these metrics. There is a lot that goes into how to define metrics to use for time to first value, product adoption, and health to provide a clear view of the customer’s state. The product also needs to have built-in instrumentation to get the right data to drive real visibility of a customer’s usage patterns. I hope to cover these topics in more detail in a future blog post.
How to improve collaboration and flow
Cross-functional customer-facing teams are one solution to increase customer adoption and reduce churn, but not every company is going to be willing to reorganize completely to improve the way it supports customers. What other options exist?
If you’re in an organization that already has siloed departments, the most important thing is to look for where there is an opportunity to drive more collaboration, more flow, and a global focus on customer success. Evaluate processes - where is there a lot of friction where customers and/or internal team members are frequently frustrated? How can those processes be improved? Some common areas are:
Licensing - post-customer purchase, the customer does not receive a license or cannot figure out how to apply it, and internally at the tech company, it’s unclear whose responsibility it is to follow up on this and make sure the customer has found and successfully applied their license.
Support processes such as auto-closing tickets after a certain amount of time, escalation processes, and ruling customer tickets as out of scope without providing additional options for help to the customer tend to cause a lot of internal friction and customer pain.
Pre to post-sales handoffs - they need to happen and everyone who is interacting with the customer needs to have the same information in terms of their use cases, success criteria, and roadmap for adoption. It’s shocking how broken this handoff process is in many organizations.
Professional services purchasing and delivery - because of the predominant model of paid services teams being their own organization and operating as a profit center, there are many processes here that inherently conflict with the license sales process. Offering sku’ed services that can be quoted with licenses on an order form, selling packages of licenses and services together, and selling annual subscription-based services all help move the needle here. Additionally, paid services should not be an afterthought! A common scenario I’ve seen is account teams selling licenses first. Only when the customer says “We need help adopting” does the account team start discussing paid services, and then there is usually a lengthy legal review and approval of SOWs, only for the final closed services opportunity to sit in a queue for 1-2 months before the commencement of the delivery of those services. In many cases, there is zero communication between the PS team and the customer during that wait time. The result: a customer has had product licenses for 3+ months and has either done nothing during this time to realize value from the product…or worse, they tried to do things on their own and chose poor configurations that will now take extra time and effort to rework into something valuable.
Customer tracking tools in use - has anyone else ever experienced a situation where salesforce is the hub (and has a bloated configuration, is slow to load, and difficult to use), account teams use Clari for forecasting, the PS sales team doesn’t have access to Clari and uses custom views in salesforce, customer success uses Gainsight, salespeople get some data from Gainsight into salesforce but don’t have Gainsight licenses and can’t see everything they need to see, support uses Zendesk and has limited salesforce access and no Gainsight access, the product team uses an issue tracker for enhancements and has some Zendesk read-only access but no salesforce access, pre-sales engineers primarily use google docs to capture information learned and have limited access to salesforce, read-only access to Zendesk, no access to Gainsight or Clari, post-sales engineers have virtually no access to any of the tools listed above and use their own google docs and Kantata for project tracking…and I could go on and on! Viewing the current state of any prospect or customer gets more and more complex as different teams choose different tools for their needs. And there is no cross-functional agreed-upon set of data that is used to identify a customer’s current state and roadmap. I have seen this pattern emerge at multiple tech companies. In these cases, clean up of data and consolidation of the toolset used will greatly improve cross-functional collaboration and the chance of increased customer success.
Compensation models - you will get the behavior that you reward. Here it’s really important to evaluate the roles involved in the operational value stream, in which steps each role contributes the most, and how to compensate appropriately to drive the right behaviors. I’m sure many people have had experiences of the sales rep who sells a large deal and then “throws it over the wall” to the customer success team, washing their hands of it completely. In those cases, the reps are typically only comped on new business, or their commission structure is skewed heavily towards new business. They need to move on to the next opportunity, and based on the reward system, it is clearly not their responsibility to ensure the customer is successful once the initial license deal is closed. There are equally loathsome examples from support and customer success teams as well, as I touched on earlier around department processes and metrics.
In this blog post, I’ve covered customer-facing roles, the importance of cross-functional teams, why customer-centric processes and metrics are crucial, and how to improve collaboration and flow. Interestingly, I did not touch on the role of product management here. Since one of the biggest goals of any tech start-up is fast feedback loops to product teams so that they can determine which features to prioritize next to provide the highest value to customers, product management is a key piece of the puzzle. And that will be covered in part 3 of this blog series.