The planning gap in CS operations
Most CS operations are good at managing the present. They track metrics, respond to incidents, adjust staffing, and handle escalations. Fewer are good at planning the future — at deciding deliberately where the operation needs to be in twelve months, what it will take to get there, and how to sequence the work of getting there against the ongoing demands of running the operation today.
The planning gap shows up in a recognisable pattern. The team is perpetually reactive — working through an informal list of priorities that shifts with every leadership conversation, every product change, and every operational crisis. Improvement initiatives start and stall. The same problems recur because they are addressed symptomatically rather than structurally. When leadership asks what the CS strategy is, the answer is a list of things the team is currently working on rather than a coherent direction with a logic behind it.
OKRs and roadmapping are the tools that close this gap. OKRs provide the goal-setting framework that connects day-to-day operational work to strategic direction. Roadmapping provides the sequencing and communication framework that turns a collection of initiatives into a plan that the team, the function, and the organisation can orient around.
Neither tool is complicated in concept. Both require discipline in execution — the discipline of being specific about what you are trying to achieve, honest about what you are not going to do, and consistent in reviewing progress and adjusting course. That discipline is what distinguishes CS operations that improve systematically from those that are always busy but rarely advancing.
What OKRs are — and what they are not
OKRs — Objectives and Key Results — is a goal-setting framework developed at Intel in the 1970s and widely adopted across technology and service organisations since. The framework has two components that work together.
An Objective is a qualitative statement of what you are trying to achieve — the direction, the ambition, the change you want to create. It answers the question: where are we going? Objectives should be inspiring enough to create motivation, specific enough to create direction, and time-bound enough to create urgency. They describe outcomes, not activities.
Key Results are quantitative measures of progress toward the Objective. They answer the question: how will we know we are getting there? Key Results are specific, measurable, and achievable within the OKR period — typically a quarter. They are the evidence that the Objective is being achieved, not a list of tasks or initiatives.
The distinction between Objectives and Key Results is important and frequently collapsed in practice. An Objective that says "improve our SLA attainment" is not an Objective — it is a direction without destination. An Objective that says "become the most reliable payroll support operation in the EOR market" is an Objective — it describes a meaningful change in the operation's position. The Key Results then define what evidence would demonstrate that the Objective is being achieved: S1 breach rate below 1% for three consecutive quarters, CSAT above 4.6 across all payroll customers, zero repeat S1 incidents on the same root cause within a rolling 90-day window.
OKRs versus KPIs
The most common confusion in goal-setting is conflating OKRs with KPIs. They serve different purposes and should be used alongside each other rather than as substitutes.
KPIs are ongoing performance metrics that measure the health of operations that should always be running. CSAT, SLA attainment, AHT, FCR — these are KPIs. They should always be above threshold. They do not have an end date. They do not describe a change from current state.
OKRs describe the specific improvements and strategic changes the operation is working toward in a defined period. An OKR exists because something needs to change — the current state is not good enough and a specific improvement is being committed to. Once the OKR is achieved and the new performance level is sustained, it becomes a KPI floor — the new baseline rather than an active goal.
A CS operation running both KPIs and OKRs is measuring two different things simultaneously: whether the operation is healthy today (KPIs) and whether it is advancing toward its strategic goals (OKRs). Both matter. Optimising only for KPIs produces an operation that maintains current performance without improving. Setting only OKRs without KPI monitoring produces an operation chasing new goals while current performance degrades.
Writing good OKRs
The quality of OKRs determines whether they drive behaviour or sit in a planning document and are forgotten. A set of principles consistently separates OKRs that work from those that don't.
Objectives should describe change, not continuation
An Objective that describes doing the same thing better — "maintain strong SLA performance" — is not an Objective. It is a description of current expectations. An Objective that describes a meaningful change from current state — "transform our escalation management from reactive resolution to proactive trust protection" — creates direction and energy because it describes something genuinely different from today.
Good Objectives pass a simple test: if the team achieved this Objective fully, would something meaningfully different be true about the operation? If the answer is yes, it is an Objective. If the answer is "we would be doing what we are already doing, just more reliably," it is a KPI floor dressed up as an Objective.
Key Results should be outcomes, not outputs
The most common failure in Key Result writing is making them outputs — things the team will do — rather than outcomes — changes in the world that result from what the team does.
Output Key Result: "Complete DSAT scrubbing process for all S1 tickets by end of quarter." Outcome Key Result: "Reduce S1 DSAT rate from 18% to below 10% by end of quarter."
The output version describes an activity. The outcome version describes the change in performance that the activity is designed to produce. Outcome Key Results are harder to write because they commit to a result rather than a process — but they are more valuable precisely because they focus attention on whether the work is actually changing anything.
Three to five Key Results per Objective
Fewer than three Key Results leaves too much ambiguity about what achieving the Objective actually looks like. More than five creates a measurement burden that dilutes focus. Three to five well-chosen Key Results that collectively describe what evidence would demonstrate the Objective is being achieved is the right range for most CS OKRs.
Ambitious but achievable
OKRs should be set at a level where achieving them requires real effort and focus — not a level where they are guaranteed to be achieved regardless of what the team does, and not a level where they are so ambitious that the team has no realistic path to achieving them and disengages.
A useful calibration principle from the original OKR literature: if a team is consistently achieving 100% of its Key Results, the targets are probably too easy. The right ambition level produces consistent achievement in the 70–80% range — most Key Results met, occasionally a Key Result that wasn't fully achieved despite genuine effort. This calibration only works in an organisational culture where missing a stretch target is treated as informative rather than punitive — an environment where setting ambitious targets and falling slightly short is preferred to setting easy targets and hitting them comfortably.
Cascading OKRs: from function to team to individual
OKRs deliver their full value when they are cascaded — when function-level Objectives decompose into team-level OKRs which decompose into individual-level goals. The cascade creates vertical alignment: every agent's development goals, every team lead's performance priorities, and every manager's operational focus connects upward to the function's strategic direction.
A practical cascade for a CS function OKR:
Function-level Objective: Build an escalation management system that protects customer trust across all severity tiers.
Function-level Key Results:
- Reduce time from S1 receipt to T2 first contact from 4 hours to 1 hour
- Achieve post-escalation CSAT of 4.3 or above on 85% of resolved escalations
- Implement proactive escalation communication protocol with 95% compliance rate
Team-level OKR (EMEA escalation team):
- Objective: Become the fastest and most consistently communicating escalation team in the function
- KR1: Average time from S1 receipt to T2 acknowledgement below 45 minutes
- KR2: 100% of escalated contacts receive proactive update within 2 hours of escalation
- KR3: EMEA post-escalation CSAT above 4.4
Individual-level goal (T2 specialist):
- Complete escalation communication certification
- Reduce personal average T2 first contact time from 90 to 45 minutes
- Achieve post-escalation CSAT of 4.5 on personally handled escalations
The cascade ensures that the individual specialist's daily behaviour — how quickly they acknowledge, how they communicate, how they handle escalation interactions — is directly connected to the function's strategic goal of building a trust-protecting escalation system. The connection is visible and explicit, not assumed.
OKR cadence: setting, reviewing, and closing
OKRs require a defined cadence to function — set once and never reviewed, they lose relevance; reviewed obsessively without letting them breathe, they become a source of anxiety rather than direction.
Setting — at the start of each quarter. Function-level OKRs should be set in the final two weeks of the preceding quarter — after enough is known about the coming quarter's context to set relevant goals but early enough that teams have time to cascade and set their own OKRs before the quarter begins. OKR setting should involve the team — not as a top-down announcement but as a collaborative process where team leads and managers contribute to defining what the function's goals should be.
Mid-quarter review — week six of the quarter. A structured check-in at the midpoint of the quarter that assesses progress against each Key Result, identifies what is on track and what is not, and determines whether any course correction is needed. The mid-quarter review is not a performance evaluation — it is a course correction mechanism. If a Key Result is behind target, the question is what needs to change, not who is to blame.
Closing — at the end of each quarter. A structured review of final progress against each Key Result, an honest assessment of what was achieved and what wasn't, and an analysis of what drove the outcomes. The closing review feeds directly into the setting of next quarter's OKRs — learnings from this quarter inform the ambition, focus, and framing of next quarter's goals.
Annual OKRs alongside quarterly. Some strategic goals — building a new QA programme, launching a new tier structure, establishing a WFM function — cannot be meaningfully measured in a single quarter. An annual OKR layer, reviewed quarterly for progress but measured annually for achievement, is appropriate for these longer-horizon initiatives. The annual OKRs provide the strategic direction. The quarterly OKRs define the specific progress milestones for each three-month period.
What a CS roadmap is
A roadmap is the sequenced, communicated plan of what the CS operation is going to build, change, and improve over a defined time horizon — typically 12 months, sometimes 18. It is not a task list or a project plan. It is a strategic communication tool that makes the operation's direction visible to three audiences simultaneously: the CS team, the CS leadership, and the broader organisation.
For the CS team, the roadmap answers the question: where are we going and what will we be working on? It provides the context that makes individual tasks meaningful — an agent or team lead who knows that the roadmap includes a KB overhaul in Q2, a new escalation protocol in Q3, and a WFM platform implementation in Q4 understands how their day-to-day work connects to a larger direction.
For CS leadership, the roadmap provides the sequencing framework that prevents over-commitment — the discipline of deciding not just what will be done but in what order, and acknowledging explicitly that some things will not be done this year.
For the broader organisation, the roadmap communicates what the CS function is investing in and why — providing the transparency that earns credibility and the specificity that makes cross-functional dependencies visible and manageable.
Building a CS roadmap
A roadmap is built in four steps.
Step 1: Identify the initiative pool
Start by gathering all the potential initiatives the CS operation could pursue in the coming year — improvements, investments, projects, and structural changes that have been identified through operational analysis, OKR setting, customer feedback, team input, and leadership direction. At this stage the goal is completeness — capturing everything that could be on the roadmap before filtering begins.
Sources for the initiative pool: the gap analysis from the current state OKR review, pain points identified in DSAT scrubbing and journey mapping, technology needs surfaced by the team, regulatory changes requiring process updates, product changes requiring CS capability development, and cross-functional commitments made to other teams.
Step 2: Prioritise
Not everything in the initiative pool can be on the roadmap. Prioritisation is the discipline of deciding what to do and — equally importantly — what not to do. A roadmap that includes everything the operation could theoretically work on is not a roadmap — it is a wish list.
Prioritisation criteria for CS initiatives:
Impact — what is the expected improvement in customer outcomes, operational performance, or financial efficiency if this initiative is successfully delivered? High-impact initiatives deliver improvements in CSAT, SLA attainment, cost-per-contact, or agent capability that materially advance the function's OKRs.
Effort — what is the operational and financial cost of delivering this initiative? Large, complex initiatives that consume significant management attention and investment should be weighted against their impact relative to smaller initiatives that deliver meaningful improvement at lower cost.
Dependency — does this initiative depend on something else being in place first? A QA-driven coaching programme depends on a QA framework being implemented. A self-serve knowledge base depends on contact driver analysis identifying what content is needed. Dependency sequencing — ensuring prerequisites are delivered before the initiatives that depend on them — is one of the primary functions of roadmap planning.
Urgency — is there a time-bound driver that makes this initiative more pressing than its impact and effort alone would suggest? A regulatory change with a compliance deadline, a product launch that will generate new contact types the team is not prepared for, a contractual SLA commitment that takes effect next quarter.
A simple prioritisation matrix — scoring each initiative on impact and effort, plotting them in a two-by-two, and treating high-impact-low-effort initiatives as first priority — provides a defensible starting point that can be adjusted for dependency and urgency considerations.
Step 3: Sequence
With priorities established, sequence the initiatives across the four quarters of the roadmap horizon. Sequencing requires balancing three constraints simultaneously.
Capacity constraint — the management and operational bandwidth available to deliver initiatives alongside running the operation. A common planning error is treating initiative delivery and operational management as separate capacity pools. They are not — the same managers who need to deliver the QA framework redesign also need to run 1:1s, handle escalations, and manage daily operations. Honest capacity modelling prevents over-commitment that results in initiatives starting and stalling.
Dependency constraint — ensuring prerequisites land before the initiatives that depend on them. If the contact driver analysis that will inform the KB overhaul is planned for Q1, the KB overhaul itself should be no earlier than Q2. If the WFM platform implementation requires IT procurement and setup, the operational rollout should be planned for at least one quarter after the procurement decision.
Organisational constraint — aligning the CS roadmap with other organisational rhythms. A major product launch planned for Q3 will generate a volume spike and new contact types that CS needs to prepare for. A planned headcount freeze in Q2 constrains the hiring that some initiatives may depend on. A fiscal year-end in Q4 creates competing demands on leadership attention. The CS roadmap should be built with awareness of these organisational rhythms rather than in isolation from them.
Step 4: Communicate
A roadmap that exists only in a planning spreadsheet has not yet delivered its value. Communication is what activates the roadmap as a management tool.
The roadmap should be communicated in formats appropriate to each audience:
For the CS team: a visual representation of the year's initiatives by quarter — typically a horizontal timeline with initiative names and brief descriptions, presented in the monthly team session and referenced in weekly meetings as context for current work. The goal is not to overwhelm agents with detail but to give them the direction that makes their day-to-day work feel connected to something larger.
For CS leadership: a more detailed version that includes initiative owners, dependencies, success metrics, and the OKRs each initiative supports. This is the working document that the leadership team reviews in monthly planning sessions.
For the broader organisation: a summary version shared with key cross-functional stakeholders — product, engineering, finance, customer success — that communicates what CS is working on, what it needs from other functions, and what the expected outcomes are. This version is the basis for cross-functional alignment conversations and the mechanism through which CS makes its strategic direction visible at the organisational level.
Roadmap discipline: what to do when everything is a priority
The most common failure mode in roadmap planning is not poor initiative selection or sequencing — it is the inability to hold the plan stable when new requests arrive. Every organisation generates a constant stream of new initiatives, priorities, and urgent requests. Without roadmap discipline the plan becomes whatever was most recently asked for, and the deliberate sequencing and prioritisation that makes a roadmap valuable is lost.
Roadmap discipline requires a defined process for handling new requests — not a rigid refusal to change course, but a structured evaluation of whether a new request is important enough to displace something currently on the roadmap, and if so, what it displaces.
The questions that structure that evaluation: does this new initiative advance the function's OKRs more than the initiative it would replace? What is the cost of displacing the existing initiative — does it break a dependency, disappoint a cross-functional commitment, delay something with an urgency driver? Is this new request genuinely urgent or does it feel urgent because it was recently raised?
A roadmap that never changes is probably not responding to reality. A roadmap that changes every time someone raises a new priority is not a roadmap — it is a reactive task list with a Gantt chart on top. The discipline is in the middle: a stable plan that is deliberately updated when genuinely important new information arrives, not reactively updated whenever the urgency of the moment overrides the deliberateness of the plan.