Why green CX dashboards can hide failing customer experiences

A green customer experience dashboard can hide failure

A green customer experience dashboard can give leaders a seemingly sound reason to leave a failing service unchanged. Its numbers may accurately describe infrastructure or overall performance while a particular group of customers struggles to complete a task. When those numbers determine where engineering effort goes, the gap between reported performance and customer experience becomes a resource-allocation problem.

This is the “watermelon effect”: reported performance looks healthy while using the service is difficult. The term emerged in site reliability engineering (SRE), the discipline of keeping services dependable, and IT service management, the work of delivering and supporting IT services. Monthly reviews showed healthy key performance indicators (KPIs) and compliance with service-level agreements (SLAs), which set commitments for service performance. Yet end users described difficulties those measures missed.

The gap develops when a team measures a property correctly and treats its healthy status as evidence of a satisfactory customer experience. Problems outside the measurement’s location, timing, population, or meaning then receive too little attention. For customer experience (CX) leaders, closing that gap requires better observation and an operating rule: customer-defined local failures must be able to change engineering priorities.

Measurement choices determine whose failures disappear

The gap between infrastructure health and usable service appears in an unnamed workplace account of quarterly business reviews. Infrastructure availability stood at 99.98%, patch compliance was in the mid-nineties, and endpoint agents were reporting successfully. On the same day, a finance employee told their manager that their laptop took 11 minutes each morning to become usable. A sales employee was apologizing to a customer after Zoom dropped during a demonstration.

All those reports could be accurate because they described different things. An endpoint agent reporting successfully shows that the reporting mechanism works, while the employee’s complaint concerns how soon work can begin. Infrastructure availability likewise leaves room for an interrupted customer demonstration. The mistake is letting healthy operational measurements settle a question about work they do not directly observe.

A similar gap can arise between executive confidence and customer judgment. Capgemini found that more than 80% of executives believed customers would recommend them, while fewer than half of customers were willing to do so; the figures were 84% and 45%, respectively. Capgemini sells customer-experience consulting and services, so demand for work addressing that gap serves its commercial interests. Its finding gives leaders a practical question to test with customers: does the headline measure describe their experience?

Answering that question requires examining three measurement choices: sensor placement, aggregation, and proxy metrics. Sensor placement determines where an experience is observed and when feedback becomes available; aggregation combines different experiences into an overall result. A proxy metric uses an indirect signal to infer something about the customer. Each choice can produce accurate data while leaving an important failure out of view.

Timing creates that problem in an illustrative fast-food queue. A customer becomes frustrated while waiting, but the invitation to give feedback appears on a receipt available only after purchase. Customers still waiting to complete the transaction cannot use that mechanism at the moment of friction. Each extra step between the difficulty and the chance to describe it creates another opportunity for the experience to go unrecorded.

Moving feedback earlier also means choosing a channel customers will use. If a customer trusts a human more than an artificial intelligence (AI) chatbot, will the chatbot elicit useful feedback about the frustration? Teams need to investigate that question when deciding how to collect responses. The collection method must account for both the moment of difficulty and the customer’s willingness to describe it through that channel.

Physical location can create the same gap, as a household measurement anecdote illustrates. A few weeks before recounting it, the observer’s family had struggled with oppressive upstairs heat, and the dogs had moved to cool tiles. The downstairs thermostat showed 70 degrees because it measured a small, shaded section of hallway away from glass. Upstairs had extensive windows, while rising heat added to the difference between floors.

Because the display conflicted with the family’s experience, the observer took a wireless grill thermometer upstairs, pointed it at the door, and obtained a reading of 84 degrees. A second thermostat was then installed at the top of the stairs, and the upstairs became a separate zone. Establishing that the original reading failed to represent the occupants’ experience was difficult; making the physical adjustment was relatively easy. The original sensor worked, but its location limited the decisions it could support.

Even well-placed observations can lose their meaning when combined into an average. Consider an illustrative airline with 90% of flights operating on time: the remaining 10% can still include passengers missing board meetings and birthdays. Delays may cluster by origin, destination, customer status, or persona. Passengers waiting in Terminal B experience the delays affecting their own journeys, whatever the airline-wide result.

To find those concentrations, teams need to examine results by meaningful groups: location and route, status and persona, or branch, team, and journey. In the airline scenario, some affected customers might remain silent and eventually leave, making complaints an incomplete guide to the problem. The percentages show how an aggregate can hide a concentrated failure. Examining groups separately helps locate that failure so the team can investigate the affected journeys directly.

Indirect signals create another problem even before results are aggregated. Falling support-ticket volume could mean that customers need less help because their experience has improved, but it could also mean that they expect little useful assistance or abandon attempts to obtain it. A customer who completes a task easily and one who gives up on support can both generate no ticket. Teams therefore need direct evidence of customer experience to interpret the count before using its decline to justify a favorable decision.

Define customer success before choosing measurements

Interpreting those signals requires a clear statement of what customers should be able to accomplish. SRE addressed this measurement problem over a decade ago by defining service outcomes from the perspective of the person consuming the service. IBM describes SRE’s reliability-related purpose in terms of “resiliency, redundancy and reliability.” IBM sells technology and services used to improve reliability, so wider investment in that work serves its commercial interests.

For CX teams applying this approach, the first task is to define a service-level objective: a target for the outcome a service should deliver. Consider the illustrative objective, “Look up my account balances in under 10 seconds for 95 percent of sessions”. It identifies the customer’s task, the time allowed, and the share of sessions that should meet the target. These values show how to make an objective understandable to customers; teams must choose targets appropriate to their own service.

A component-level statement answers a narrower question. “Authentication service available” describes the condition of one component, while a customer may still encounter a slow or unsuccessful balance lookup. Authentication health therefore cannot establish whether the full task succeeded. A balance-checking objective requires measurements of completed customer sessions, including the time needed to reach the result.

Once the outcome is defined, the team can choose telemetry, automatically collected operational measurements, that confirms or disproves whether it occurred. Reversing that order lets existing visibility determine what counts as success. The objective should instead guide which measurements to collect and where to collect them. This keeps engineering work tied to the task the customer needs to complete.

The task also determines where observation is useful. A remote data center three network hops, or connections between network devices, away may report healthy operation while the customer-facing device presents a different experience. A kiosk, point-of-sale (POS) system, or mobile app can offer a closer view of whether the interaction succeeds. Teams should collect device-level telemetry where feasible and judge its usefulness against the customer’s objective.

Closer observation makes failures easier to identify, but detection leaves a management decision open. A team may see that one location or journey repeatedly misses the objective while the company-wide result remains healthy. It then needs an agreed rule connecting that local evidence to engineering priorities. Without that connection, better measurement can leave the allocation of effort unchanged.

Give local failures authority to redirect engineering effort

An error budget can connect customer outcomes to resource decisions. It defines the permitted amount of failure against a service objective; to “spend” the allowance means that failures have occurred and used up part of it. As the allowance runs down, the team gains a defined reason to intervene. For CX work, the failures counted must match the customer experience the objective describes.

An account-balance objective, for example, needs a budget based on failures to complete the lookup within the specified time. A budget tied only to component availability would retain the earlier gap between infrastructure health and task completion. The connection must run from the customer’s outcome, through observed failures, to an engineering decision. Otherwise, the organization gives authority to the same narrow measures under a different name.

Where the budget is tracked determines which customers can prompt action. In an illustrative scenario, a company meets its overall objective while a particular branch or team exhausts its allowance by the eighth of the month. Under the proposed approach, engineering effort shifts toward that branch or team even while the aggregate remains acceptable. Tracking a branch, team, or journey separately gives its failures consequences when priorities are set.

Early depletion also changes when the organization should respond. Waiting for company-wide performance to deteriorate allows stronger results elsewhere to delay attention to the affected customers. Tracking the allowance as it is used creates an earlier opportunity to redirect work. The household example offers a simple parallel: the additional sensor exposed the difference between locations, and the separate upstairs zone enabled a local adjustment.

Engineering teams still face competing demands, and an error budget creates no additional capacity. Its role is to make the cost of leaving a customer-defined failure unresolved visible when leaders allocate the capacity they have. The operating rule must give local depletion enough authority to change planned work, while leaving room to weigh other demands. A more detailed dashboard alone cannot make that decision.

Error budgets are useful where persistent failure needs an explicit connection to resource allocation. Other measurement problems may first require better-placed feedback, a clearer objective, or investigation of an ambiguous proxy. Teams should choose the response that addresses the failure they have found. Where healthy company-wide reporting repeatedly delays action on a local problem, a locally tracked allowance provides a concrete trigger for reconsidering priorities.

Test one weekly metric with customers

A practical first step is to choose one metric the team already reports every week and ask a dozen customers whether it describes their experience. Twelve conversations can reveal mismatches and guide investigation, but the exercise is diagnostic. The responses describe the experiences of the people consulted. Agreement helps explain those experiences, while disagreement identifies questions the existing metric may leave unanswered.

Use that disagreement to decide what to inspect next. Customers may describe friction before feedback becomes available, a journey hidden within an aggregate, or an experience that conflicts with a favorable interpretation of an indirect signal. Investigate the relevant point of collection, customer group, or proxy before proposing a wholesale measurement overhaul. The immediate decision is which part of the measurement process needs closer examination.

If the investigation leads to a local error budget, define how its depletion will affect engineering priorities before relying on it to prompt action. Then evaluate changes in retention, revenue, or satisfaction separately from compliance with the service objective. Meeting the objective measures delivery of the chosen customer task; those business outcomes require their own assessment. This lets the team judge both whether the operating rule changes engineering decisions and whether the resulting work improves customers’ experience.

Key highlights

• Check where measurement hides failures: CX teams need to examine feedback timing, customer groups, and indirect signals such as support-ticket volume. Company-wide averages and falling ticket counts can conceal persistent problems in specific journeys or locations.
• Define success around customer tasks: Service owners need measurable objectives for completed tasks, such as checking an account balance within 10 seconds. Those objectives determine which operational data to collect and where to observe the experience.
• Give local failures authority over priorities: Engineering and CX leaders need an agreed rule for redirecting work when a branch, team, or journey exhausts its error budget. Tracking these failure allowances locally gives affected customers influence over resource decisions while overall performance remains healthy.
• Test one weekly metric with customers: Ask a dozen customers whether a regularly reported metric describes their experience, then investigate the mismatches. Treat the conversations as diagnostic evidence and assess retention, revenue, and satisfaction separately from service-objective compliance.