The strategy execution gap

A CS leader can build a rigorous OKR framework, design a well-sequenced roadmap, and have a clear view of what the function needs to achieve and how. None of it matters if the organisation does not support it — if the budget is not approved, if product does not prioritise the fixes CS has been requesting, if engineering does not resource the tooling integration, or if leadership does not understand why CS is asking for what it is asking for.

The gap between a good strategy and a strategy that gets executed is almost always a stakeholder and influence gap rather than an analytical one. The CS leader who cannot communicate their strategy compellingly, build the cross-functional relationships that make things happen, and influence decisions made by people who do not report to them will be perpetually under-resourced, under-supported, and under-valued — regardless of the quality of their operational thinking.

Stakeholder management, business case construction, and influencing up are not soft skills peripheral to CS leadership. They are the capabilities that determine whether the strategy the CS leader has built actually gets implemented or remains a planning document that nobody outside the function has ever read.

Understanding your stakeholder landscape

Effective stakeholder management begins with a clear understanding of who the relevant stakeholders are, what they care about, and what their relationship to the CS function is. Treating all stakeholders as a uniform audience — communicating the same message in the same format to everyone — is one of the most consistent failures in CS leadership communication.

A CS Director in a mid-to-large organisation typically has four categories of stakeholder to manage.

Upward stakeholders are the people CS leadership reports to — the VP of Customer Experience, the COO, the CEO. They care about outcomes at the business level: revenue retention, customer lifetime value, cost efficiency, and the reputation of the organisation with its customers. They do not need — and in most cases do not want — operational detail. They need confidence that the CS function is well-led, that it is advancing toward the right outcomes, and that its leader knows how to identify and address problems before they become crises.

Cross-functional peers are the leaders of adjacent functions — Product, Engineering, Sales, Customer Success, Finance, Legal, Compliance. Each has their own priorities, pressures, and success metrics. Their relationship with CS ranges from close partnership to polite indifference to active tension. Effective cross-functional stakeholder management requires understanding what each peer cares about, how CS performance affects their function, and what CS needs from them — and designing engagement that serves both parties rather than just making requests.

Internal customers are the teams within the organisation who depend on CS performance — the sales team that uses CS quality as a selling point, the customer success team that relies on CS to protect account health, the finance team that needs accurate cost reporting. Internal customers need different things from CS stakeholders — primarily reliability, transparency, and early warning when something that affects them is changing.

External stakeholders — in some CS operations — include customers themselves, particularly strategic enterprise accounts where the CS Director may have direct relationship visibility, as well as regulators or industry bodies in compliance-sensitive environments.

Stakeholder mapping

A stakeholder map is a simple analytical tool that organises stakeholders by two dimensions: their level of influence over CS decisions and their current level of alignment with CS priorities. Plotting stakeholders on a two-by-two — high influence/high alignment, high influence/low alignment, low influence/high alignment, low influence/low alignment — reveals where to invest relationship and communication effort.

High influence, low alignment stakeholders are the priority. These are the people whose support is most consequential and least secure — the product VP who deprioritises CS-driven product fixes, the finance director who cuts the CS budget, the COO who sees CS as a cost to be minimised rather than a function to be invested in. Understanding what drives their current position and what would shift it is the strategic question that stakeholder management is designed to answer.

High influence, high alignment stakeholders are assets to be maintained and leveraged — people who already understand CS's value and whose support can be drawn on when navigating resistance from less aligned stakeholders.

Low influence stakeholders require less intensive engagement but should not be neglected — today's low-influence stakeholder may be tomorrow's decision-maker, and building relationships before they are needed is always more effective than trying to build them under pressure.

Communicating with senior leadership

Senior leadership communication is the area where CS leaders most consistently underperform — not because they lack the information or the operational insight but because they have not learned to translate operational reality into the language that senior stakeholders respond to.

Three principles distinguish CS leaders who communicate effectively with senior leadership from those who don't.

Lead with outcomes, not activities

Senior leaders are not interested in what the CS team did last month. They are interested in what changed — for customers, for the business, for the organisation's strategic position. A report that opens with "we handled 47,000 contacts last month, achieved 94% SLA attainment, and completed the Q2 training programme" is an activity report. One that opens with "we retained three accounts at risk of churn by resolving a systemic escalation pattern, reduced service credit exposure by €42,000 through SLA improvement, and identified a product friction point that engineering has now prioritised for next sprint" is an outcomes report.

The former describes what the team was busy doing. The latter describes the value the team created. Senior leaders respond to the latter because it speaks to the outcomes they are accountable for — revenue, cost, and customer relationships.

Quantify wherever possible

Qualitative statements — "CSAT is improving," "escalations are being handled better," "agents are more capable" — require the listener to trust the speaker's assessment. Quantitative statements — "CSAT increased from 4.1 to 4.4 over the quarter, with the largest improvement in APAC where we implemented the targeted coaching programme," "S1 breach rate dropped from 4.2% to 1.8%, reducing service credit exposure by €31,000 per month" — create their own credibility. They are specific, verifiable, and expressed in terms that connect to business outcomes.

The discipline of quantification is not just about using numbers. It is about choosing the numbers that matter to the audience — financial impact, customer retention, revenue protection — rather than the numbers that matter to the CS team — SLA attainment percentages, QA scores, adherence rates. Both sets of numbers describe the same operational reality. One speaks the language of business; the other speaks the language of CS operations.

Match the format to the context

A monthly written update to the VP of CX should be different in format from a quarterly business review presentation to the COO, which should be different from a weekly Slack message to the direct manager, which should be different from an annual strategy presentation to the leadership team.

A monthly written update: one page maximum, structured as headline performance, key developments, risks requiring attention, and priorities for the coming month. Designed to be read in five minutes without asking questions.

A quarterly business review: ten to fifteen slides maximum, structured as performance against OKRs, key wins and misses with explanation, outlook for next quarter, and investment requests if any. Designed to support a thirty-minute conversation, not to be read as a document.

An annual strategy presentation: the function's direction for the coming year — where it is going, why, what it will take, and what the organisation can expect in return. Designed to build confidence and earn commitment rather than to report on the past.

The common failure is using the same format for all contexts — typically a dense metrics report that works for operational review and fails for everything else. Calibrating format to context is a form of respect for the audience's time and attention.

Building business cases that get approved

A business case is a structured argument for an investment or decision. Its purpose is not to demonstrate that the CS leader has done their analysis — it is to make the decision easy for the person who has the authority to approve it. A business case that requires the approver to do their own analysis, fill in unstated assumptions, or take the CS leader's word for the projected return will fail more often than one that removes all friction from the approval decision.

The anatomy of a compelling business case

A business case that consistently earns approval has six components.

The problem statement. A precise description of the current situation that justifies the investment — not a general complaint but a specific, quantified account of what is not working and what it is costing. "Our current escalation management process is generating €48,000 per month in service credits and has been identified as a contributing factor in three account losses in Q2 representing €340,000 in lost ARR" is a problem statement. "Our escalation management needs improvement" is not.

The proposed solution. What specifically is being proposed — not at an implementation level of detail but at a level that makes the nature and scope of the investment clear. "A dedicated escalation management programme including a new T2 specialist hire, a redesigned escalation protocol, and a post-escalation follow-up process, implemented over Q3" is specific enough to be evaluated. "Better escalation management" is not.

The expected outcomes. What will be different if the investment is made — in specific, quantified terms where possible. The outcomes should connect directly to the problem statement: if the problem is service credit exposure of €48,000 per month, the expected outcome should quantify how much of that exposure the proposed solution will eliminate and over what timeframe.

The financial model. The cost of the investment and the financial return, expressed as ROI and payback period. This does not need to be precise to the last euro — it needs to be credible, transparent about its assumptions, and expressed in the financial terms the approver uses. The financial model from the unit economics article — cost-per-contact analysis, deflection value, repeat contact cost — provides the inputs for most CS business case financial models.

The risk of inaction. What happens if the investment is not made? This component is the most frequently omitted and the most persuasive. A business case that only argues for the return of the investment leaves the approver thinking about the cost of saying yes. A business case that also quantifies the cost of saying no forces a comparison between two options — invest and get the return, or don't invest and bear the ongoing cost — that is much more likely to produce approval.

The ask. A precise statement of what is being requested — the budget amount, the headcount approval, the cross-functional commitment — and what the approval process is. A business case that ends with a vague "we would welcome your support" has not made the ask. One that ends with "we are requesting approval of €180,000 in incremental budget for Q3, to be confirmed by June 15 to allow recruitment to begin in time for a Q3 implementation" has made the ask in a form that can be acted on.

Common business case mistakes

Building the case around the solution rather than the problem. A business case that starts with "we want to implement MaestroQA" and then argues for why MaestroQA is good is a solution looking for a problem. A business case that starts with "our current QA process is producing inconsistent calibration and agent gaming that is distorting our quality data" and then presents MaestroQA as the solution to that specific problem is a problem looking for the right solution. The second structure is more persuasive because it makes the need self-evident before the solution is introduced.

Projecting returns without stating assumptions. A financial model that projects €500,000 in annual savings without stating the assumptions behind that projection — the volume affected, the cost-per-contact used, the deflection rate assumed — invites the approver to question the numbers. A model that states its assumptions explicitly — "based on 8,000 monthly contacts at a cost-per-contact of €17.80 and an assumed deflection rate of 30%, consistent with published benchmarks for comparable implementations" — is far more credible because it can be evaluated.

Presenting a single option. A business case that presents one solution and asks for approval creates a binary — yes or no — that gives the approver no middle ground. Presenting three options — a full investment, a phased investment, and a minimal investment — with different cost and return profiles gives the approver genuine choice and signals analytical rigour. Often the approval that emerges from a three-option presentation is the phased investment rather than the full one — which is still progress and often the right starting point.

Underselling the strategic context. A business case for a QA tooling investment that argues only for the direct operational benefits — better calibration, more consistent scoring — is a weaker case than one that connects the investment to the function's OKR of becoming the most reliable payroll support operation in the EOR market. Strategic context elevates a tactical request into a strategic investment and invites approval at the level of the strategic goal rather than the operational detail.

Influencing without authority

The most complex stakeholder challenge for CS leaders is influencing decisions made by people who do not report to them and who have their own priorities, pressures, and incentive structures. Product decisions that affect CS. Engineering prioritisation that determines whether CS-driven fixes get scheduled. Finance decisions that determine whether the CS budget reflects operational reality. These decisions are made by peers and superiors, not by the CS function — and yet their outcomes directly determine whether the CS operation can deliver on its commitments.

Influencing without authority is not manipulation and it is not political manoeuvring. It is the disciplined practice of understanding what other stakeholders care about, presenting CS priorities in terms that connect to their goals, and building the relationships that make collaboration the path of least resistance.

The currency of influence

Influence in organisational settings is built on three currencies that accumulate over time and can be drawn on when they are needed.

Credibility is the most fundamental currency. Stakeholders who have found that the CS leader's analysis is accurate, their projections are realistic, and their commitments are delivered will give their proposals significantly more benefit of the doubt than those whose credibility is unestablished or damaged. Credibility is built through small, consistent acts of accuracy and follow-through — delivering on commitments, being honest about uncertainty rather than overstating confidence, and being right more often than wrong in assessments and predictions. It is lost quickly through overpromising, underdelivering, or presenting analysis that does not hold up to scrutiny.

Reciprocity is the currency of mutual support. Stakeholders who have received support, information, or advocacy from the CS leader in the past are more likely to reciprocate when CS needs something. A CS Director who proactively shares customer insight with the product team — surfacing friction patterns that help product prioritise — is building reciprocity with the product VP that will be drawn on when CS needs a product fix prioritised. A CS Director who advocates for the customer success team's perspective in a leadership meeting builds reciprocity with the customer success leader. Reciprocity is built through genuine generosity — giving before asking — and is undermined by transactionalism that is transparently self-serving.

Relationships are the infrastructure that makes the other two currencies usable. A well-calibrated argument from someone the stakeholder does not know will always be less persuasive than an equally well-calibrated argument from someone they trust and respect. Relationship investment — the regular touchpoints, the genuine curiosity about what stakeholders are working on, the shared context that comes from repeated interaction — is what makes influence possible at moments of genuine disagreement or competing priorities.

The technique of reframing

The most practical influence technique for CS leaders is reframing — presenting CS priorities in terms of what they mean for the other stakeholder's goals rather than in terms of what they mean for CS.

A request to the product team framed as "we need you to fix the onboarding data bug because it is generating a high volume of support contacts" is a CS problem asking for product's help. The same request framed as "the onboarding data bug is generating 800 support contacts per month at a cost of €14,240, and our analysis shows it is contributing to a 12% lower NPS among customers who experience it in their first 30 days — which your team's churn model shows is predictive of reduced expansion revenue" is a shared business problem that the product team has a direct incentive to address.

The reframe does not change what is being asked for. It changes the terms in which the request is understood — from a CS operational concern to a shared business outcome that the product team's own success metrics depend on.

Handling pushback constructively

Pushback — disagreement, skepticism, competing priorities — is an inevitable part of stakeholder engagement. How a CS leader responds to pushback determines whether it becomes a relationship-damaging conflict or a productive conversation that ultimately produces better outcomes.

Three responses to pushback consistently produce better results than the alternatives.

Acknowledge before arguing. When a stakeholder pushes back on a CS proposal — questions the financial projections, argues that the priority is lower than CS believes, suggests that the resources are not available — the instinctive response is to defend the original position. The more effective response is to acknowledge what is legitimate in the pushback before defending the position. "You're right that the deflection assumptions are aggressive — they are based on published benchmarks rather than our specific contact mix, and I can refine them with our actual data if that would make the model more credible" signals confidence rather than defensiveness and opens a collaborative rather than adversarial dynamic.

Separate positions from interests. A stakeholder who says "we can't prioritise this fix in Q3" is stating a position. The interest behind that position — what they are actually trying to protect — might be engineering capacity, a competing product priority, a budget constraint, or a risk aversion about the implementation. Understanding the interest rather than debating the position often reveals paths that satisfy both parties — a phased implementation that fits within capacity constraints, a shared-resource model that spreads the cost, or a later quarter that works for both.

Know when to escalate. Some disagreements cannot be resolved at the peer level because they reflect genuinely competing priorities that require a senior decision-maker to adjudicate. Knowing when a disagreement has reached that point — and escalating it cleanly rather than allowing it to fester — is a sign of organisational maturity rather than a failure of influence. The discipline is to escalate the decision rather than the conflict: "product and CS have a genuine priority disagreement about the resource allocation for Q3 — we'd like to bring it to the VP level for a decision" rather than "product is blocking CS and we need support."

Positioning CS as a strategic function

The most significant long-term stakeholder management challenge for a CS leader is shifting how the function is perceived — from a necessary cost centre that handles customer problems to a strategic function that protects revenue, generates customer insight, and contributes to competitive differentiation.

This positioning shift does not happen through a single compelling presentation. It happens through a consistent pattern of behaviour over time — a pattern in which CS is always showing up with data, connecting its work to business outcomes, surfacing insights that other functions find valuable, and demonstrating that it anticipates and addresses problems rather than just reacting to them.

The specific behaviours that build the strategic positioning over time:

Bringing customer intelligence to leadership, not just performance reports. A monthly CS report that includes analysis of the top customer friction points, with quantified impact and recommended cross-functional action, positions CS as a customer intelligence function rather than a ticket-handling operation. Leaders who find that the CS monthly report contains insights they cannot get elsewhere will read it differently from those who see it as a metrics summary.

Connecting CS performance to commercial outcomes explicitly. Every leadership communication from CS should include at least one connection between operational performance and a business outcome that leadership cares about. SLA improvement connected to service credit reduction. CSAT improvement connected to renewal rate. Escalation reduction connected to account expansion. These connections, made consistently over time, build the mental model that CS performance and business performance are the same thing expressed in different metrics.

Proactively flagging risks before they become crises. A CS leader who brings a risk to leadership — "our volume analysis suggests we will be 15% understaffed in Q4 if we don't begin recruiting now, which at current SLA failure rates would generate approximately €60,000 in additional service credits" — three months before it becomes a crisis is a different kind of leader from one who reports the crisis after it has occurred. Proactive risk management builds the trust that comes from being reliably ahead of problems rather than behind them.

Making cross-functional contributions visible. When CS analysis drives a product change, when a CS-surfaced customer insight informs a sales strategy, when a CS-identified compliance risk is addressed before it becomes a regulatory issue — these contributions should be explicitly communicated to leadership rather than absorbed silently. CS leaders who make their cross-functional contributions visible build the organisational understanding that CS creates value beyond its direct service delivery function.