Key Takeaways
- What is customer operations is simultaneously used to mean CS operations, cross-functional post-sale infrastructure, and strategic GTM operations—most companies confuse these and design the wrong team
- 54% of companies had a dedicated CS operations role in 2024, down from 61% in 2023—an 11% decline that signals smaller companies are cutting ops headcount exactly when they need it most
- The operational backbone (systems, data, playbooks) is invisible until it's missing—it's the difference between "our CS team can't scale" and "our CS team doubled their book without new headcount"
- A single customer operations manager can support a team of six CSMs when the function is scoped correctly
- Customer operations lives or dies on integrations, not features—a CS platform that doesn't sync cleanly with your CRM and support system creates more work than it saves
You're hiring for customer operations. You post the req. Three different people forward you three different job descriptions. One looks like a data analyst embedded in customer success. Another reads like a support operations manager who also owns onboarding. The third is a strategic role reporting to the Chief Revenue Officer with a mandate to "own the post-sale customer journey."
All three are called Customer Operations Manager. All three exist at real companies. None of them do the same work.
If you search what is customer operations, the reason it's hard to define is that it isn't one job—it's three overlapping functions that companies confuse, collapse into one title, and then wonder why the hire doesn't work. The first model treats customer operations as an enablement layer inside customer success. The second treats it as the operational backbone spanning support, success, and onboarding. The third treats it as a strategic peer to sales operations and marketing operations, owning systems and process across the entire post-sale motion.
You don't have a customer operations problem. You have a definitional problem. And until you name which model you're building, you'll keep hiring the wrong person into the wrong org chart with the wrong success metrics.
What is customer operations—and why does everyone define it differently?
Search "what is customer operations" and you'll find six authoritative definitions that contradict each other. Salesforce says it's "everything a company does to assist customers." Front says it's "strategic management of behind-the-scenes systems." Zendesk narrows it to "the crew helping customer success managers excel." Helpdesk.com widens it to "all activities from first contact to farewell."
They're all describing different jobs using the same title.
The confusion exists because customer operations emerged organically across B2B SaaS companies over the last decade—not as a designed function with a clear charter, but as a response to the same pain showing up in three different places. Some companies felt it in customer success when CSMs couldn't scale. Others felt it in support when ticket volume exploded. Others felt it cross-functionally when handoffs between sales, onboarding, success, and support kept breaking.
Same pain. Different organizational responses. Different definitions.
The three meanings of "customer operations" used in practice today
Here's what "customer operations" actually means when companies use the term:
Definition 1: Customer Success Operations (CS Ops). A role embedded inside the customer success organization that owns the systems, data, and playbooks CSMs use. Typical deliverables: health score models, QBR templates, Gainsight configuration, Salesforce hygiene rules, CSM onboarding plans. Reports to VP Customer Success or Chief Customer Officer. Exists to make CSMs more efficient.
Definition 2: Customer Operations (cross-functional infrastructure). A team that owns operational systems and processes across all post-sale functions—support operations, CS operations, onboarding operations, sometimes knowledge operations. Typical deliverables: unified customer data model, cross-team routing rules, escalation SLAs, shared reporting dashboards, post-sale tool stack rationalization. Reports to Chief Customer Officer, VP Operations, or sometimes directly to CEO. Exists to eliminate silos between support, success, and implementation.
Definition 3: Customer Operations (strategic GTM peer). A strategic function at the same organizational level as sales operations and marketing operations, owning the entire post-sale revenue motion as a system. Typical deliverables: retention and expansion playbooks, post-sale forecasting models, cross-GTM process design, customer lifecycle analytics, tool stack strategy across the full customer journey. Reports to Chief Revenue Officer or COO. Exists to treat post-sale as a repeatable revenue engine, not a cost center.
The first model is the most common. The second is the one that actually solves the operational pain most Directors of Support and VPs of Customer Experience feel. The third emerges only at companies that have decided post-sale revenue is a first-class GTM motion.
How the definition you choose determines your org chart (and your budget)
The model you pick isn't cosmetic. It determines who reports where, what gets funded, and whether customer operations has the authority to fix the problems it's hired to solve.
ModelReporting LineHeadcount TriggerWhat It Doesn't OwnCS Ops (Definition 1)VP Customer Success15–25 CSMsSupport ops, onboarding ops, knowledge management, cross-GTM processUnified Customer Ops (Definition 2)Chief Customer Officer or VP OpsSupport + CS + Onboarding combined headcount reaches 40–60Sales process, marketing automation, product opsStrategic Customer Ops (Definition 3)Chief Revenue Officer or COOPost-sale ARR material or company treats retention/expansion as peer to new salesProduct roadmap, engineering delivery
Here's what changes based on which model you choose:
If you build CS Ops (Definition 1), you get efficiency gains inside customer success, but support and onboarding continue running their own conflicting systems. Your CS platform doesn't sync with your support platform. Customer data lives in three places. Handoffs still break.
If you build Unified Customer Operations (Definition 2), you eliminate the silos—one customer data model, one routing engine, one set of escalation rules across support, success, and onboarding. But you don't get strategic influence over the revenue motion. You're still improving the back office while sales and marketing make the promises customer operations has to keep.
If you build Strategic Customer Operations (Definition 3), you get a seat at the revenue table. Post-sale becomes a forecasted, refined, repeatable motion. But you need executive sponsorship, real budget authority, and a company mature enough to treat retention and expansion as peer priorities to new business.
Most companies default to Definition 1 because "customer success operations" is a known job title with a Radford compensation band. But Definition 2 is the structure that solves the real problem—fragmented post-sale operations across multiple teams.
What customer operations teams actually do (when they're set up correctly)
The value of customer operations is invisible until it's missing. When it's working, customer-facing teams operate smoothly. Data flows between systems. Playbooks exist and get used. New hires ramp in weeks instead of months. Health scores update automatically. Escalations route to the right person with full context.
When it's not working, your Director of Support is manually exporting ticket data into spreadsheets every Monday morning. Your CSMs are guessing which accounts are at risk because the health score model broke six months ago and nobody fixed it. Your onboarding team is reinventing the implementation plan for every new customer because nothing is templated.
Customer operations is the difference between "our CS team can't scale" and "our CS team just doubled their book of business without new headcount."
The operational backbone: systems, data, and process that keep customer-facing teams from drowning
Customer operations owns the how. Frontline teams own the who and the what.
Here's the dividing line: a CSM decides which accounts get a QBR this quarter (the what) and conducts the QBR with the customer (the who). Customer operations builds the QBR template, ensures the data feeding the QBR is current, configures the calendar automation that schedules it, and tracks completion rates across the team (the how).
A support manager decides escalation priority for a VIP ticket (the what) and personally handles the customer conversation (the who). Customer operations owns the routing rule that flagged the ticket as VIP in the first place, the SLA that governs response time, and the dashboard showing whether SLAs are being met (the how).
An implementation specialist runs a customer onboarding project (the who and what). Customer operations owns the milestone template, the health check that triggers if a milestone is overdue, and the handoff protocol that moves the customer from onboarding to ongoing success (the how).
The operational backbone is systems, data, and process. Systems: the tools customer-facing teams use—CRM, CS platform, support platform, communication tools, analytics. Data: customer records, usage data, health scores, interaction history, escalation logs. Process: playbooks, workflows, routing rules, escalation paths, reporting cadences.
When customer operations is absent or underpowered, every frontline team builds its own version of these. Support has its own customer data in Zendesk. Success has its own customer data in Gainsight. Onboarding has its own customer data in a project management tool. None of them match. Every handoff requires manual reconciliation.
What customer operations owns vs. what customer success/support/onboarding teams own
The ownership line gets fuzzy in practice because the work overlaps. A well-run customer operations function owns:
- CRM data quality rules and hygiene protocols (who updates what fields, when, and how conflicts get resolved)
- Health score model design and maintenance (what inputs feed the score, how they're weighted, when the model needs recalibration)
- Tool stack integration and administration (connecting Salesforce to Gainsight to Zendesk, managing user permissions, troubleshooting sync failures)
- Playbook templates and workflows (QBR decks, renewal motion sequences, escalation paths, onboarding milestone plans)
- Reporting dashboards and analytics (what metrics matter, how they're calculated, who sees which reports)
- Routing and assignment logic (which tickets go to which agents, which accounts go to which CSMs, how workload gets balanced)
- Process documentation and team enablement (how to use the tools, how to execute the playbooks, where institutional knowledge lives)
- Forecasting models for post-sale revenue (renewal risk scoring, expansion pipeline tracking, churn prediction)
Customer success, support, and onboarding teams own the actual customer interactions, the judgment calls that require context and relationship, and the outcomes those interactions produce. Customer operations owns the infrastructure that makes those interactions repeatable, measurable, and scalable.
The work no one sees: playbook design, CRM hygiene, health score architecture, and routing rules
Here's what a customer operations manager actually does in a given week:
Monday morning: Salesforce audit reveals customer records missing renewal dates. Runs a data quality report, identifies the gap pattern (records created before a certain date when the field wasn't mandatory), writes a bulk update script, validates with finance that the dates match contract records, executes the fix, adds the field to required-field validation rules so it doesn't happen again.
Tuesday afternoon: CS team reports health scores aren't updating. Investigates. Discovers the Gainsight sync broke when IT updated the Salesforce API version last week. Reopens the integration, re-authenticates, tests on a sample account, confirms scores are flowing again, documents the fix in the runbook for next time.
Wednesday: Onboarding team escalates that three customers are stuck at the same milestone with no clear owner. Reviews the milestone definitions, realizes the handoff trigger from onboarding to success isn't defined. Schedules a 30-minute working session with the onboarding lead and the CS lead, writes a draft handoff protocol (completion criteria, notification rules, who does what), gets sign-off, configures the automation in the project tool, ships it.
Thursday: Builds a new QBR template because the old one is out of date and CSMs are customizing it inconsistently. Pulls the five best recent QBRs, identifies the common structure, standardizes the format, adds dynamic fields that auto-populate customer data from Gainsight, adds a slide on product usage trends, shares draft with three senior CSMs for feedback, incorporates feedback, publishes to the team playbook library, runs a demo on the Friday team call.
Friday: Runs a support efficiency analysis to see where the support team is tracking. Discovers chat volume is up quarter-over-quarter but chat headcount is flat—agents are underwater. Pulls the top chat topics by volume, identifies three topics that could be handled through better help center content, flags them for the knowledge team, estimates potential savings if successful, writes it up in a one-pager for the Director of Support.
None of this work is visible to customers. None of it shows up in a QBR deck. But without it, the CSMs can't run QBRs, the support team drowns in chat volume, and onboarding customers get stuck at handoffs.
Related: how customer lifecycle management is actually run in 200-800-person B2B SaaS companies — the org chart behind the function, and why the wrong definition ranks.
The three customer operations models—and how to choose yours
Most companies don't choose a model deliberately. They inherit one based on where the pain showed up first and who got budget to solve it.
If your VP of Customer Success hired the first ops person, you built CS Ops (Model 1). If your Chief Customer Officer hired someone to "fix the mess across support and success," you built Unified Customer Operations (Model 2). If your Chief Revenue Officer decided post-sale needed the same operational rigor as sales, you built Strategic Customer Operations (Model 3).
Here's when each model works—and when it doesn't.
Model 1: Customer Success Operations (the most common starting point)
Customer Success Operations is what most B2B SaaS companies mean when they say "customer operations." It's a function embedded inside customer success that owns the systems, data, and playbooks CSMs use to do their jobs.
Typical org structure: 1 CS Ops Manager or Specialist reporting to VP Customer Success. At scale, expands to a small team—CS Ops Manager, CS Ops Analysts, sometimes a CS Systems Admin.
What it solves: CSM efficiency, data consistency within the CS org, playbook standardization, health score accuracy, forecasting for renewals and expansions managed by the CS team.
What it doesn't solve: Support operations, onboarding operations, cross-functional handoffs, customer data fragmentation across teams, tool sprawl.
A single customer operations manager can support a team of six CSMs when the scope is purely CS enablement. The ratio breaks when the CS team grows past a certain size or when complexity increases (multiple products, multiple segments, geographic expansion). At that point, you need a second hire.
When Model 1 works: You have a customer success team, and the primary operational pain is inside that team—inconsistent CSM execution, unreliable health scores, no standardized playbooks, poor renewal forecasting. Support and onboarding are separate functions with their own ops (or no ops), and that's acceptable for now.
When Model 1 fails: Support, onboarding, and success all report to the same Chief Customer Officer, but they run on conflicting systems with duplicate customer data. Handoffs between teams break constantly. You hired a CS Ops person, but the real problem is cross-functional—and CS Ops has no authority to fix it.
Model 2: Unified Customer Operations (support + success + onboarding ops under one leader)
Unified Customer Operations treats the entire post-sale organization—support, success, onboarding, education—as one operational system with one shared backbone. It's the model that eliminates silos.
Typical org structure: Director or VP of Customer Operations reporting to Chief Customer Officer, VP of Operations, or CEO. Owns operations across support, CS, and onboarding. Team size scales with combined headcount—starts small when combined post-sale team reaches a manageable size, grows at enterprise scale.
What it solves: Customer data fragmentation, tool sprawl, handoff failures between support/onboarding/CS, inconsistent routing and escalation logic, inability to report on the full post-sale customer journey, operational inefficiency caused by each team running its own systems.
What it builds: One customer data model (typically in the CRM, synchronized to specialized tools). One routing engine (tickets, onboarding projects, CSM assignments all follow consistent logic). One set of escalation rules across all teams. Shared operational dashboards. Unified tool stack strategy (one support platform, one CS platform, one knowledge base—all integrated).
When Model 2 works: You have people across support, success, and onboarding combined. These teams currently operate independently with separate tools, separate data, and constant handoff friction. The Chief Customer Officer (or equivalent) has the authority and budget to consolidate operations under one leader. The company is mature enough to treat post-sale as a unified function, not three separate cost centers.
When Model 2 fails: The teams resist consolidation because they protect their autonomy. Or the company hasn't committed to unified tooling—support wants to keep Zendesk, CS wants to keep Gainsight, onboarding wants to keep Monday, and nobody has the authority to force convergence. Model 2 requires executive sponsorship and real decision-making power. Without it, Customer Operations becomes a coordinator with no influence.
Model 3: Customer Operations as a revenue operations peer (strategic, cross-GTM)
Model 3 treats Customer Operations as a peer to Sales Operations and Marketing Operations—a strategic function that owns the post-sale revenue motion as a repeatable, forecasted, refined system.
Typical org structure: VP Customer Operations reporting to Chief Revenue Officer or COO. Owns strategy, systems, and process across the full post-sale lifecycle—onboarding, adoption, renewal, expansion, advocacy. Collaborates with Sales Ops and Marketing Ops on cross-GTM process (handoff protocols, account planning, revenue forecasting). Team size varies depending on ARR scale.
What it solves: Post-sale treated as a cost center instead of a revenue engine. No visibility into renewal or expansion pipeline until shortly before contract end. Retention and expansion playbooks that exist on paper but aren't systematized. Misalignment between what Sales sells and what post-sale teams can actually deliver. Inability to forecast post-sale revenue with the same rigor as new business.
What it builds: Retention and expansion revenue forecasting models. Cross-functional playbooks (how Sales, CS, and Support collaborate on at-risk renewals or expansion opportunities). Customer lifecycle analytics that connect product usage, support interactions, and revenue outcomes. Tool stack strategy across the entire GTM motion, not just post-sale. Operational frameworks that treat customer operations as a strategic capability, not back-office support.
When Model 3 works: Post-sale ARR exceeds a meaningful threshold or represents a significant percentage of total revenue growth. The company has decided retention and expansion are strategic priorities at the same level as new customer acquisition. Leadership treats Customer Operations as a revenue function, not a cost function. The CRO or COO sponsors the investment.
When Model 3 fails: The company talks about retention and expansion but doesn't fund it accordingly. Customer Operations gets the strategic title but not the budget, headcount, or authority to execute. Or the function gets built before the company is ready—post-sale revenue is too small to justify the investment, and the VP Customer Operations ends up doing CS Ops work with an inflated title.
Real team structures: roles, ratios, and when to hire
The founding hire: Customer Operations Manager or Specialist (and what they build in year one)
The first customer operations hire is almost always made too late. It happens after repeated escalations from a CS manager about data quality issues, or after the support lead manually reroutes tickets because the assignment rules broke, or after the CFO asks about forecast accuracy again.
The trigger signals are measurable. CRM data quality below acceptable thresholds (missing fields, duplicate records, stale information). CS team managing too many accounts per CSM without segmentation by tier, ARR, or health score. Support ticket routing breaking at high volumes because nobody owns the logic. Onboarding taking too long with no consistent milestone tracking. Product usage data living in one tool, support history in another, CS notes in a third—and nobody can answer "is this customer healthy?" without pulling three reports and reconciling them manually.
When those signals appear, the founding hire is either a Customer Operations Manager (if the company needs someone who can design systems from scratch) or a Customer Operations Specialist (if budget is tighter and the focus is execution—average $26.99/hour per ZipRecruiter).
What they build in year one: A clean customer data model in the CRM with mandatory fields enforced. Health score logic (product usage + support ticket volume + contract size + CSM sentiment = red/yellow/green) that updates automatically. Playbook templates for the most common CS motions (onboarding, QBR, renewal). Support ticket routing rules that don't require manual intervention. A dashboard showing renewal pipeline by quarter with enough lead time to act. Integration between the CRM and whatever CS platform or support tool the company uses, so data flows without export-import cycles.
The work is unglamorous. It's Salesforce field mapping. It's writing routing logic in Zendesk. It's documenting the onboarding workflow so it's repeatable instead of reinvented per customer. But when it's done right, CS managers stop spending significant time on CRM cleanup, support leads stop manually assigning tickets, and renewal forecast accuracy improves substantially.
When to add your second and third ops hire (and what changes)
The second ops hire happens when the first hire is underwater. Typically months after the founding hire, or when combined post-sale headcount crosses a threshold. The trigger: backlog of operational requests (new playbooks, new integrations, new reporting) that can't be cleared in the current week, or the first hire is spending too much time on firefighting (broken integrations, data cleanup, ad-hoc analysis for leadership) instead of building systems.
The second hire is usually a specialist in the area causing the most pain. If CRM data quality is still the constraint, hire a Salesforce Administrator or Data Operations Specialist. If CS playbooks exist but aren't being followed, hire a CS Enablement Manager. If support ticket routing and knowledge base management are consuming too much time, hire a Support Operations Specialist.
The third hire (usually later, or when post-sale headcount exceeds a larger threshold) splits the function into specialization. One person owns data and systems. One person owns playbooks and enablement. One person owns reporting and analytics. At this point the founding hire typically becomes Director of Customer Operations or Head of Customer Operations, managing the team instead of doing all the execution.
What changes with a multi-person ops team: The function shifts from reactive (fixing what's broken) to proactive (designing what's next). Strategic projects that were perpetually backlogged—like building a multi-touch attribution model for renewals, or creating segment-specific onboarding tracks, or implementing AI-assisted ticket routing—actually ship. Cross-functional projects (aligning Sales Ops and Customer Ops on handoff protocols, or building shared dashboards for the executive team) become feasible because someone has the bandwidth to lead them.
Typical reporting structures—and why "where CustOps reports" signals its real scope
Where Customer Operations reports tells you what the company thinks the function does.
Reports to VP Customer Success: The function is scoped as CS Operations. It exists to enable the CS team—playbooks, health scores, renewal dashboards, CSM onboarding. It does not own support operations or onboarding operations. This is Model 1. Works when CS is the dominant post-sale function and support/onboarding are smaller or outsourced.
Reports to Chief Customer Officer or VP Customer Experience: The function is scoped as unified Customer Operations (Model 2). It owns systems and process across CS, support, and onboarding. The CCO or VP CX has authority over all three teams, so ops can drive consolidation. Works when the company has committed to treating post-sale as one function.
Reports to Chief Revenue Officer or COO: The function is scoped as a strategic peer to Sales Ops and Marketing Ops (Model 3). It owns retention and expansion as revenue motions, not just service delivery. Works when post-sale revenue is material and leadership treats Customer Operations as a revenue function.
Reports to VP Operations or Chief of Staff: The function is probably under-resourced or misunderstood. It's been slotted into "general operations" because the company doesn't know where else to put it. This structure works only if the VP Ops or CoS has deep customer operations expertise and real authority over post-sale teams. Otherwise, Customer Operations becomes a coordinator with no influence—asked to solve cross-functional problems without the authority to change how teams operate.
The ChurnZero 2024 study found 54% of companies had a dedicated CS operations role, down from 61% in 2023—an 11% decline in one year. That drop is concentrated in smaller companies cutting headcount. Larger companies are increasing investment in Customer Operations while smaller companies are cutting it. The decline is a mistake being made in real-time. Companies are eliminating ops roles exactly when they need them most—during the transition from founder-led customer management to repeatable process. They will pay for it in churn and missed renewals months later.
Benchmarks that matter: how to know if your customer operations function is working
Efficiency metrics: what ops work enables for frontline teams
Most Customer Operations teams are measured on lagging indicators they don't control. Net Revenue Retention. CSAT. Renewal rate. Customer Lifetime Value. These are outcomes produced by the frontline teams (CS, support, onboarding)—not by the ops function that enables them.
The operational metrics Customer Operations actually controls:
CRM data completeness: Percentage of customer records with all required fields populated (industry, segment, ARR, health score, assigned CSM, contract end date, product usage tier). High targets are achievable. If it's below acceptable levels, the ops function doesn't have data governance under control, and every downstream system (health scores, forecasting, segmentation) is built on bad inputs.
Time to onboard a new CSM or support agent: Days from hire date to first productive customer interaction. Reasonable targets exist for both CSMs and support agents. If it's longer, playbooks and training materials don't exist or aren't accessible. Ops owns this—not the hiring manager.
Playbook adherence rate: Percentage of customer interactions (onboarding kickoffs, QBRs, renewal discussions, support escalations) that follow documented playbooks instead of being improvised. High adherence is achievable. Measured by spot-checking activity logs in the CRM or CS platform. If adherence is low, the playbooks are either too complex, not embedded in workflow, or disconnected from how the work actually happens.
Average time to resolve a ticket routing conflict: When a support ticket gets assigned to the wrong team or person, how long does it take to fix? Quick resolution is achievable. If it's longer, routing rules are broken and nobody owns them. This is pure operational waste—customer waits, agent waits, manager intervenes manually. Ops owns the routing logic and should know when it breaks.
Integration uptime and sync latency: How often do integrations between CRM, CS platform, support platform, and product analytics break? When data syncs, how long does it take? High uptime and low latency are achievable. If customer data updated in Salesforce takes hours to appear in Gainsight, the CSM is working from stale information. Ops owns the integration layer.
Forecast accuracy for renewals: At a certain time before contract end, how accurate is the renewal forecast (will renew / at risk / will churn)? High accuracy is achievable. If accuracy is low, the health score model is broken or the data feeding it is incomplete. Ops owns the health score logic.
If your Customer Operations team can't produce these numbers on demand, it's not doing ops work—it's doing project management or firefighting. The function exists to make these metrics visible and improve them quarter over quarter.
Data health and system adoption (the leading indicators everyone ignores)
Data health predicts operational performance months out. If CRM data quality drops in Q1, renewal forecast accuracy falls in Q2. If playbook adherence drops in March, CSAT drops in May. These are leading indicators—measurable now, predictive of outcomes later—but most companies don't track them until the lagging indicators (churn, NRR, CSAT) are already declining.
CRM field coverage by customer segment: Enterprise customers should have the highest field coverage (all required fields populated). Mid-market should be high. SMB should be good. If SMB data quality is low, you're not managing that segment—you're guessing. Ops should run this report monthly and flag deterioration before it impacts forecast accuracy.
CS platform login frequency: How many CSMs log into the CS platform (Gainsight, ChurnZero, Planhat) daily? High daily usage is achievable. If it's low, the platform isn't embedded in their workflow—they're managing customers in email and spreadsheets. Ops owns system adoption. Low login rates mean the tools aren't delivering value or aren't integrated properly.
Support content effectiveness by article: Which support articles are actually helping customers (customer finds the answer, closes the page, doesn't contact support)? Which articles get viewed but don't help (customer reads it, still submits a ticket)? Good success rates on high-traffic articles are achievable. If articles are being viewed but not helping, the content is incomplete or unclear. Ops should flag underperforming articles to the support team for rewrite.
Average touches required to complete onboarding: How many meetings, emails, or support tickets does it take to get a customer from contract signature to first value milestone? Track by segment and product. If enterprise onboarding requires fewer touches than SMB, the SMB motion is broken—it should be more automated, not more manual. Ops owns this metric and should be driving it down quarter over quarter.
Support contact benchmarks for 2026
Customer Operations doesn't set headcount budgets or compensation—but it owns the process and tooling that determine efficiency. Every support interaction, every CS touch, every onboarding milestone has a cost. If ops improves routing, knowledge access, and automation, costs drop. If ops fails, costs scale linearly with volume.
Support teams in 2026 see meaningful variation by channel. Voice support remains the most expensive channel. Live chat and messaging fall in the middle range. Email and ticketing systems carry moderate costs. Self-service through knowledge bases and chatbots delivers the lowest contact costs.
What this means for Customer Operations: If your support team handles tickets per month and most are via email, monthly support cost is calculable. If ops can shift a portion of those tickets to self-service, monthly cost drops significantly. The ops team didn't reduce headcount. It improved routing, built better knowledge base articles, and deployed an AI assistant that handles tier-1 questions before they reach an agent.
First Contact Resolution (FCR) benchmark: 70% average, 85% for top-performing teams. FCR is the percentage of support cases resolved in the first interaction—no follow-up required. Low FCR means agents lack the information, tools, or authority to resolve issues without escalation. Ops owns this. If knowledge base coverage is incomplete, if routing sends tickets to the wrong team, if agents can't see full customer history in one screen—FCR stays low and costs climb.
Customer Operations doesn't get credit for cost reduction in most companies. Finance sees lower support costs or higher CS account loads and attributes it to "the team working harder." Ops should own these metrics, track them monthly, and report them to leadership as operational performance—not hidden efficiency gains.
The tools and platform architecture (and why "best-in-class" usually means "doesn't talk to anything")
The core stack: CRM, CS platform, support platform, and the integration layer between them
Customer Operations lives or dies on integrations, not features. A CS platform with powerful health scoring, beautiful dashboards, and strong playbook automation is worthless if it can't sync cleanly with Salesforce and pull support ticket history from Zendesk. A "best-in-class" support platform that requires manual export-import to feed data into the CS platform creates more work than it saves.
The core stack has four layers:
Layer 1: CRM (system of record for customer data). Salesforce dominates at enterprise scale. HubSpot dominates at SMB and early-stage. The CRM holds account records, contact records, contract data, opportunity history, and product usage data (either natively or synced from product analytics). Everything else integrates with the CRM—it's the single source of truth.
Layer 2: Customer Success platform. Gainsight (enterprise, premium pricing), ChurnZero (mid-market, variable annual pricing depending on scale), Planhat (growth-stage SaaS, flexible pricing), Totango (mid-market, usage-based pricing). The CS platform sits on top of the CRM and adds health scoring, playbook automation, renewal forecasting, CSM activity tracking, and customer journey orchestration. It pulls data from the CRM, product analytics, and support platform, combines it into a unified customer view, and surfaces insights the CRM can't.
Layer 3: Support platform. Zendesk (most common at scale), Freshdesk (mid-market alternative), Intercom (product-led companies), Front (email-centric support). The support platform manages ticket lifecycle, agent assignment, SLA tracking, and knowledge base. It integrates with the CRM so customer data flows in and ticket history flows back out. Support teams work in this tool; CS teams pull ticket data from it.
Layer 4: Integration and workflow layer. Zapier, Make (formerly Integromat), Workato, native platform APIs. This is where most ops work happens—building the connections between CRM, CS platform, support platform, product analytics, billing system, and any other tools in the stack. A customer record updates in Salesforce → triggers a health score recalculation in Gainsight → creates a task for the CSM if health score drops below threshold → logs a note in Zendesk if there's an open support ticket.
The integration layer is invisible to frontline teams, but it's what makes the stack function as one system instead of five disconnected tools. Customer Operations owns this layer. When integrations break, data stops flowing, and every team reverts to manual workarounds. When integrations are well-designed, teams don't think about them—data is just there when they need it.
What Gainsight, ChurnZero, Totango, and Planhat actually do (and when each fits)
Gainsight: Enterprise-grade CS platform. Deep Salesforce integration. Wide feature set (health scoring, success plans, playbooks, timeline view, customer journey analytics, forecasting, reporting). Premium pricing—often large annual commitment for mid-sized teams. Takes time to implement (several months to full adoption). When it fits: significant post-sale ARR, sizable CS team, enterprise customers with complex onboarding and multi-year contracts, company committed to treating Customer Success as a strategic revenue function. Positioned as a Leader in Forrester Wave for Customer Success Platforms, Q4 2025.
ChurnZero: Mid-market CS platform. Easier to implement than Gainsight. Lower cost. Good for SaaS companies with product usage data to track. Real-time alerts when customer behavior changes. In-app engagement (NPS surveys, feature announcements, onboarding checklists delivered inside the product). When it fits: mid-range ARR, mid-sized CS team, product-led or hybrid motion, need to act on usage signals quickly.
Planhat: Flexible CS platform popular with European SaaS companies. Modern UI, fast implementation, usage-based pricing (pay for active customers, not seats). Strong product analytics integration. Good API for custom workflows. When it fits: growth-stage SaaS, technical CS team comfortable building custom integrations, want a lighter-weight alternative to Gainsight without sacrificing power.
Totango: Mid-market CS platform, modular pricing (pay for the features you use). Pre-built integrations with common SaaS tools. SuccessBLOCs (packaged playbooks for common CS motions). When it fits: SMB and mid-market SaaS, team wants a structured out-of-the-box experience instead of building everything custom, budget-conscious but need more than spreadsheets.
The platform choice depends on company stage, budget, and how much customization the ops team can handle. Gainsight is powerful but requires dedicated admin headcount to manage. ChurnZero and Planhat are faster to value but less deep. Totango is modular but feature depth varies. The wrong choice isn't "bad platform"—it's "platform that doesn't match company maturity." Buying Gainsight too early is overkill and will sit underused. Trying to scale ChurnZero to support a very large team managing substantial ARR hits limits.
The build vs. buy decision for smaller teams
Early-stage companies should not buy an enterprise CS platform. The cost doesn't justify the value, and the team doesn't have the operational maturity to use it. Instead, build lightweight Customer Operations in the tools you already own.
The lightweight stack for early-stage:
- HubSpot CRM (free tier or affordable paid tier)
- Intercom or Zendesk for support (both have accessible pricing tiers)
- Airtable or Google Sheets for manual health scoring and renewal tracking
- Zapier for basic integrations
- Slack for internal communication and alerts
What you can build with this stack: A customer record in HubSpot syncs to an Airtable base. Every week, a Zapier workflow pulls product usage data (from your product analytics tool), support ticket count (from Intercom or Zendesk), and contract data (from HubSpot), calculates a simple health score (green if usage is above threshold and tickets below threshold, red otherwise), and posts a Slack alert if any customer drops to red. CSMs manage renewals in HubSpot deals. The ops person (probably the first CS hire wearing two hats) maintains the Airtable base and Zapier workflows.
This is not scalable past a certain customer count or CSM count. But it's affordable in tools instead of much higher annual cost for a CS platform the team won't fully use. Spend the first months proving the CS motion works—strong retention rate, growing expansion ARR, CSMs following repeatable playbooks. Then buy the real platform when the manual process breaks.
The mistake early-stage companies make: buying Gainsight at Series A because a board member or advisor says "you need a CS platform." The platform gets implemented, nobody uses it because the workflows don't match how the team actually works, and later it's a sunk cost with low login rate. Build first. Prove the motion. Buy the platform when manual process can't scale—not before.
Start with the system of record: best CRM software, graded for SaaS.
What's changing in 2025–2026 (and what it means for how you staff this function)
CS Ops headcount is declining at smaller companies—but growing at mature ones
The ChurnZero 2024 Customer Success Leadership Study shows 54% of companies had a dedicated CS operations role in 2024, down from 61% in 2023—an 11% year-over-year decline. The drop is concentrated in companies under 500 employees. Larger companies (500+ employees) are increasing CS ops investment while smaller companies are cutting it.
What's happening: Smaller companies faced budget pressure and cut "non-revenue" roles. Customer Operations was categorized as overhead, not strategic investment. The cuts happened during the exact period when these companies needed ops most—transitioning from founder-led customer management to repeatable, scalable process.
The consequence will show up months later. Without ops, CRM data quality deteriorates. Playbooks don't get documented. Health scores don't get built. Renewal forecasting stays manual and inaccurate. CS teams can't scale because the operational foundation was never built. Churn climbs. NRR drops. Leadership asks "why is CS underperforming?" The answer: you eliminated the function that would have prevented this.
Meanwhile, mature companies (those that survived the downturn) are doubling down on Customer Operations. They've learned that retention is cheaper than acquisition, that expansion is an efficient growth lever, and that neither scales without operational rigor. They're hiring Director and VP-level Customer Operations leaders, building ops teams, and treating the function as strategic infrastructure.
What this means for how you staff: If you're under 500 employees and don't have a dedicated Customer Operations person, you're making the same mistake many companies are making. Hire earlier than the benchmark suggests. The founding ops hire should happen when combined post-sale headcount reaches a manageable size, not when it's already overwhelming. At that point, one ops person can build the foundation (clean data model, health score, playbooks, integrations) before the team outgrows manual process. At larger sizes without ops, you're already in crisis mode—backfilling what should have been built earlier.
AI is shifting tier-1 support work, and ops teams are the ones rewriting the workflows
AI isn't replacing customer-facing teams yet—but it's shifting what they spend time on. Tier-1 support questions (password resets, billing inquiries, product FAQs, simple troubleshooting) are being handled by AI chatbots and knowledge base search. Tier-2
.svg)
.svg)
.svg)
