Customer Success Is Not the Department That Does Everything
When leaders confuse ownership of the customer with ownership of every internal failure, the team becomes a punchbag. Customers notice. Good people leave.
Customer Success has a strange superpower: whenever nobody knows who owns a problem, the problem somehow lands with Customer Success. At first, it looks like flexibility. A CSM chases a support ticket, coordinates a shipment, translates a product defect, repairs a poor handover and keeps the customer calm. Sometimes that is exactly what good teamwork looks like. The problem starts when the exception becomes the operating model.
A Customer Success team should own the customer relationship, adoption, value realisation, risk visibility and renewal protection. It should coordinate the right people and keep the customer informed. It should not become the permanent owner of every bug, every logistics issue, every undocumented product gap, every commercial promise, every escalation, every internal campaign and every new administrative task the business invents. That is not accountability. It is the absence of accountability, hidden behind the words “you own the customer”.
I have seen what happens next. The workload grows, headcount stays flat or shrinks, other functions learn that they can redirect difficult work to CS, leaders add activity metrics to make the function more visible, and the team spends more time proving it is busy than helping customers move forward. Morale drops. Quality drops. Good people leave. The answer is not to make Customer Success less accountable. It is to make accountability real.
Owning the customer does not mean doing every job
The phrase “CEO of the account” can be useful, but it can also be dangerous. A real CEO has authority, budget and specialist teams. A CSM is often told to own the outcome while having none of those things.
Customer Success should orchestrate. Support should investigate and resolve technical issues. Product should own defects, prioritisation and roadmap decisions. Operations and logistics should own shipments and equipment. Sales should own commercial promises, pricing and terms. CS should bring the business context, coordinate communication, show the impact, identify risk and make sure commitments do not quietly disappear.
When a domain team refuses direct customer contact, closes a case before the underlying problem is resolved, or creates an informal process that leaves CS managing the issue forever, the burden has not vanished. It has simply been moved to the person with the least power to solve it.
What leaders should do: publish a clear RACI for recurring customer scenarios; separate customer communication from technical execution; appoint a named escalation owner; and keep the relevant domain team accountable until resolution.
What leaders should not do: use “CS owns the customer” as permission to transfer every unwanted task to CS.
Capacity is a leadership decision, not a personality test
A major organisational transition rarely replaces the old work. It adds to it. New systems, new portals, new products, new reporting, new governance, new EBR expectations, more risk administration, data hygiene, customer-review campaigns, internal business reviews and technical upgrades all arrive while normal customer problems continue. Then leaders wonder why the team is tired.
You cannot ask a team to absorb a transformation, manage a growing book of business, take on operational work, cover weekends, reduce headcount and then describe the resulting strain as a lack of discipline. That is not performance management. It is arithmetic.
Capacity must reflect the number of accounts, their strategic importance, lifecycle stage, product maturity, geography, partner model, support intensity, risk and renewal timing. Six complex strategic accounts can be heavier than thirty stable accounts, or the reverse. Flat quotas ignore reality.
What leaders should do: protect time for onboarding and change; build a capacity model based on the real portfolio; make trade-offs explicit; remove lower-value work before adding new work; and create a credible coverage plan before reducing people.
What leaders should not do: announce aggressive growth expectations and workforce reductions without explaining how the work will be covered.
Metrics are useful until people start working for the metric
Customer Success needs measurement. Much of the work is difficult to see, and leaders need visibility into engagement, adoption, value, risk and renewal readiness. The trouble starts when the metric stops being a signal and becomes the goal.
Give people a fixed target for meeting hours and some meetings that need thirty minutes will become an hour. Demand a certain number of executive reviews in a quiet month and customers will be pressed into dates that suit the dashboard rather than them. Count every interaction and one useful conversation will become two separate calendar entries. The dashboard improves. The customer does not. Movement is not progress. Quantity is not quality.
An EBR is valuable when it proves value, surfaces risk and aligns the next decisions. It becomes theatre when it exists only because a monthly quota says it must. Better measures include value milestones progressed, time to value, adoption, risk reduction, sponsor coverage, decision quality, renewal confidence and customer-validated outcomes. Activity can be a leading indicator, but it should never be treated as final proof of success.
What leaders should do: use segment and lifecycle context; inspect the quality behind the numbers; and focus on exceptions and outcomes rather than uniform activity.
What leaders should not do: apply the same quota to radically different portfolios or celebrate activity that has no connection to customer progress.
The way you talk about Customer Success becomes the way the company treats it
The internal status of a function is heavily influenced by the way its own leader speaks about it. When leaders repeatedly signal that Customer Success is not good enough, other departments take the cue. A product defect becomes an adoption problem. Slow support becomes a relationship problem. An oversold deal becomes a renewal problem. A failed handover becomes a CSM problem. Customer Success becomes the organisational punchbag.
Holding a team accountable is not the same as undermining it. Good leaders challenge their team internally, defend fair boundaries publicly and distinguish system failures from individual performance.
Restoring a broken product to basic usability is not value realisation. It is defect resolution. CS can coordinate the recovery, explain the business impact and keep the customer informed, but it should not be blamed for the defect or expected to replace engineering and support.
What leaders should do: give credit accurately; correct false narratives; ask which process or owner failed; coach privately; and use cross-functional reviews to establish facts.
What leaders should not do: humiliate the team, invite other functions to blame it, or publicly question whether CS brings value while it is cleaning up failures elsewhere.
Risk management must include the people who create and resolve risk
Customer risk is not limited to support tickets and product defects. It can start with a commercial promise, a budget cut, a partner relationship, a missing executive sponsor, a procurement delay, a weak implementation, a product limitation or a mismatch between what was sold and what the customer actually needs.
A risk forum made up only of Customer Success, Support and Product will miss risks created or owned by Sales, Partners, Professional Services, Finance and leadership. CS can raise the red flag, but it cannot resolve every issue without the people who have the authority to act.
A mature risk process needs one source of truth and a simple standard: what is the risk, why does it matter now, what is the customer and business impact, who owns the plan, what happens next, by when, what decision is required and what will be communicated to the customer.
What leaders should do: include the functions that create and resolve each type of risk; define clear escalation routes; require owners, actions and dates; and make leadership decisions visible.
What leaders should not do: make CS the sole owner of every risk and then criticise the team when other departments do not act.
Performance management must start with the role, not with the names
I have no problem with difficult performance decisions. Leaders owe the business and its customers a capable team. But performance management becomes politics when the future role has not been defined, a percentage of people to remove is chosen first, or managers are pressured to nominate names regardless of the evidence. You cannot fairly judge whether someone fits a role that nobody has properly described.
The evidence should include customer outcomes, retention, customer feedback, commercial impact, technical and business skills, communication, collaboration, coachability and the difficulty of the portfolio. Personal likeability or senior preference cannot replace that evidence.
What leaders should do: define the future role first; publish the criteria; calibrate decisions across managers; document coaching and progress; consider context; and plan how customers will be covered before removing people.
What leaders should not do: work backwards from a target number of exits, use vague ideas of fit, or punish managers for defending people whose results do not support the proposed decision.
Trust is not a soft benefit
Trust is the operating system of an experienced team. A leader can destroy months of trust in a five-minute message that assumes bad intent. Questioning approved leave as though it were unauthorised, applying unwritten rules retrospectively, ignoring work completed outside normal hours, or treating a minor calendar mismatch as misconduct tells people that they need to protect themselves.
Once people feel watched rather than led, their behaviour changes. They document every interaction, avoid initiative, stop offering honest feedback and eventually leave. You do not hire experienced individual contributors so that you can micromanage them.
What leaders should do: set expectations clearly and in advance; manage outcomes rather than presence; assume positive intent; protect time off; acknowledge extra effort; and use one-to-ones to coach and remove blockers.
What leaders should not do: try to catch people out, use oversight as surveillance, or reward repeated heroics while questioning commitment.
Burnout is data
When several people burn out, work nights and weekends, or say they cannot keep up, the first question should not be, “How do we make them more resilient?” It should be, “What has our operating model made impossible?”
A tired team can still look productive for months. It attends meetings, updates systems, handles escalations and saves renewals. Then quality degrades or people resign, and leadership describes the outcome as sudden. It was not sudden. It was ignored.
What leaders should do: review the workload honestly; remove work; rotate escalation duty; protect weekends and leave; provide genuine time in lieu; recognise wins; and make it safe to say that capacity has been exceeded.
What leaders should not do: answer burnout with another tracker, more mandatory meetings or a motivational speech.
A practical reset for Customer Success leaders
A leader does not need a six-month transformation programme to begin fixing this. I would start with nine actions:
- Write a one-page CS charter. State what Customer Success owns, coordinates, supports and does not own.
- Map the most common customer problems. For each one, identify the domain owner, the customer-communication owner and who remains accountable through closure.
- Build a real capacity model. Use portfolio size, complexity, lifecycle, product maturity, risk and renewal timing – not a flat account count.
- Replace raw activity quotas with outcome measures. Track progress, adoption, value, risk reduction and renewal confidence. Use activity only as supporting evidence.
- Create a cross-functional risk forum. Include the people with authority to resolve commercial, partner, product, support and delivery risks.
- Give Support a real escalation-management capability. CS should not be left managing an unresolved technical issue indefinitely after the case process has moved on.
- Move operational and logistics work to the right teams. Well-paid CSMs should not be the default project coordinators for tasks that do not require Customer Success expertise.
- Define roles before making talent decisions. Set the skills, behaviours and outcomes first, then assess people fairly and plan customer continuity.
- Remove low-value administration and restore recognition. Stop asking people to prove work that creates no customer value, and make space to celebrate the outcomes the team delivers.
The point
Customer Success should be expected to know its customers, lead the outcome plan, surface risk early, create a credible executive narrative and protect the renewal. Those are demanding responsibilities. But accountability without authority, capacity, enablement or cross-functional ownership is not accountability. It is blame with a nicer name. When a team spends more time demonstrating activity than creating value, do not add another dashboard. Redesign the system.
A healthy Customer Success organisation is not the department that does everything. It is the function that makes customer outcomes visible, coordinates the right people and ensures commitments are kept. That works only when the rest of the company is accountable too.
Movement is not progress. Quantity is not quality. Ownership without authority is just blame with a nicer name.
Originally published on Medium