Issue #67: A Maturity Framework for CS Ops

How does CS Ops mature? 

We’ve been doing a lot of thinking about CS Ops (thanks to everyone who has shared their perspective by way of interviews, community discussion, and feedback!), and will be publishing an article on the topic on August 10th. So for this week’s issue, we’re highlighting a summarized section from that article on how CS Ops teams mature over time. 

---

Most CS Ops teams follow a similar path as they mature: the team is born out of a specific CS need, they begin taking on more responsibilities, and then they take action to become proactive. 

Stage 1: There's an acute need from Customer Success

CS Ops is often born out of the need to implement tooling. The first CS hire might be able to bandaid together the software they need, but at a certain point the job requires a greater investment. 

The first CS Ops role is usually focused on data and systems administration. They can’t be strategic if things are breaking; the team must be sure that the right tooling and data infrastructure is in place so CSMs can do their job. 

Some CS Ops teams at this stage will have already started doing some strategic activities, like proactively reporting on customer risk or CSM performance so CS leaders know where to focus their attention. 

Stage 2: CS Ops becomes a reactive "everything department"

Once the “acute need” has subsided, the team will start taking on a growing amount of responsibilities. Whenever someone asks, “Could someone help me with this?” Ops is the go-to. Updating the health score calculation, training CSMs, or configuring in-app notifications for tech-touch programs are all examples of tasks that start overloading the CS Ops team. 

The tendency in this stage is to become reactive; “the everything department.” As CS Ops grows, it’s critical they stay focused on the responsibilities they can and cannot take on, and create a planning process for larger initiatives. 

Editor’s note: We stole “the everything department” name from Rav Dhaliwal (Venture Partner at Crane). Thanks, Rav! 

There are 4 areas of responsibility that CS Ops may take over in stage 2: 

1. Analysis and reporting. There are ongoing and one-off tasks here: ongoing reporting to leadership around portfolio and team performance, and then one-off requests to answer questions from the team (which can be answered in partnership with the data science team if appropriate). 
2. Foundational team processes (aka “running the business”). This includes ongoing operational and tactical work, like team enablement (do CSMs have playbooks?), segmentation, territory/compensation/headcount planning, and implementing policies. 
3. Automating tech-touch programs programs. Teams that serve a large long-tail customer segment will need to instrument campaigns that serve those audiences. CS Ops may help by a.) analyzing data to inform the customer journey, or b.) implementing campaigns to help customers along. Some teams have a content marketing resource on the CS Ops team, which is especially useful if the Marketing organization doesn’t have retention-based goals (i.e., they’re less willing to spend time writing content for customers). In an ideal situation where Marketing does have goals that map to retention, CS Ops can partner with a content marketing or product marketing resource to create the webinars, articles, and other resources that’ll be sent to customers in the scale program. 
4. Team and talent for CS Ops. Since CS Ops is growing to meet these new demands, they’re also now responsible for managing their own team’s hiring, onboarding, and processes.

Many companies are not as well-staffed in CS Ops, so the role tends to be broad and can easily become unfocused. Given the wide array of tasks sent to the team, they need to be smart about planning and creative in how they scale themselves. 

Stage 3: CS Ops becomes a strategic advisor to Customer Success

There are two major changes required to move a CS Ops team from Stage 2 to Stage 3. The team needs to move into a centralized Ops function that reports to the COO, and they must add “strategy” to their responsibilities. 

Moving CS Ops to a centralized Ops team under the COO 

A fully mature CS Ops team serves as a strategic thought partner to the Customer Success leader. At this point they tend to report into a centralized Ops function under the COO for two reasons: 

1. Being part of a centralized team under the COO helps ensure handovers between teams are efficient, and 
2. CS Ops can effectively bring their view of the business to strategize with the CS leader (and push back when appropriate). 

There is one downfall here: pulling CS Ops out of the CS team into a centralized function means that Enablement can no longer live within the Ops team’s scope. Even if the team is “embedded” in CS by way of meetings, they’re no longer the experts in CS and so enablement needs to be passed off. By this time, CS usually invests in a dedicated Enablement team that lives within the Customer Success department. 

Adding “strategy” to the team’s scope of responsibility

While a Stage 2 team asks, “How can we make the CS team ‘run better’?’” the Stage 3 team  asks, “What can we do to move the needle on our goals?” The focus is still on improvement, but it’s more about identifying opportunities and placing bets than just iterating on how the team currently works. 

Stage 3 CS Ops teams enable CS leaders with the data they need to drive decisions across the company. For example, they might: 

• Bring data on the Ideal Customer Profile (ICP) in different cohorts to drive decisions around who Marketing and Sales should be targeting,
• Share win/loss data to drive pricing discussions with Marketing, or 
• Report on the customer requests that Product could build to drive the highest impact on NRR. 

They use data to provide strategic recommendations to the CS leader. And then depending on the project, they may also be the team executing on the recommendation. For example, we’ve heard of teams who incorporate “strategic bets” in their annual planning — these “bets” are the projects that vary most year over year.

---

💡 How LinkedIn’s CS Ops team plans their priorities:

1. Foundations 

These are the things you must get right because nothing else can move forward without them. The two categories that fall into this bucket are:

1. CS Ops Team & Talent: Do you have the right folks on the CS Ops team? Who do you need to hire? What additional training do they need? How do you retain them and keep them engaged and happy? Without a staffed, happy CS Ops team the work won’t move forward. For more mature CS Ops orgs, this category could also mean ensuring you have the right cross functional partners to help you get work done (i.e. do you need partners in Data Science, Systems, Rev Ops etc and do you have clear roles & responsibilities across the teams)
2. Data & Systems: This is where the “garbage in garbage out” saying comes in. If your data foundations are not solid, then any analysis won’t be as useful. Without the right systems & tools, you may end up doing more manual work. For this category, the work may not always sit with CS Ops (i.e. it may sit with data science or a separate systems & tools team) but we still need to make sure it happens and is prioritized to allow us to do our jobs.  

2. Business As Usual Priorities (BAU Priorities) 

This category usually includes ongoing responsibilities that have been and stay with CS Ops, things like annual headcount planning, territory building, QBRs. These are the basic expectations of the team. 

3. Strategic Initiatives

Only when the foundations and BAU are tackled do you get to move on to the fun strategic projects. Here we prioritize by looking at what is the most impactful work and what is our ability to deliver on it. We also add a lens of what is most important for the business right now? Where does this fall on the company’s overall priorities? These projects could be things like rethinking service models, exploring paid services, thinking through scale and partnerships, rethinking accountability and the appropriate metrics for the business. 

Given the maturity of the CS Ops team, you may be able to specialize roles on the Data & Systems side so the rest of the team splits their time between BAU (~60%) and Strategic Work (~40%).

Note: Thank you Zeina Marcotte for sharing how your team thinks about prioritization. 

This week's top posts

PROCESS

Alex Farmer on the Role of the CSM in Successful Onboarding

The “right time” to introduce CS in a sales cycle is a well-covered topic, but in this interview, Alex Farmer (the VP of CS at Cognite) offers tactical advice on the role of CS in pre-sales. He shares tips like “At the 60% sales cycle mark, CS should send the customer a one-pager outlining exactly what the customer will need to do before and for onboarding.”

Read the full post

INDUSTRY

5 Stages of CEO Acceptance of Customer Success

An entertaining post: Nick Mehta describes the evolution some CEOs go through — from the “peak of inflated expectations” through the “slope of enlightenment” —  before they fully accept the Customer Success function. 

Read the full post

MANAGEMENT

How Do You Recognize Your Team for Great Work?

Here’s a nice reminder for managers to give recognition for excellent work (+ creative ideas on “how” to give recognition).

Read the full post

Success Happy Hour is a weekly newsletter for Customer Success leaders. Each week we feature one digestible piece of advice or a framework from a top Success leader, along with the best resources from that week. Subscribe here.