Your customer uploads a proof-of-address document for the second time, maybe their driver’s license, but their application still does not advance. She checks the status page four times, opens chat, and calls the next morning, so a real-time system recognizes the pattern and creates an outreach task for an onboarding specialist.

That decision makes sense when the trigger fires. Ten minutes later, the situation may be different because a service agent has opened a case, a specialist has started reviewing the documents, and the customer has already replied in chat that someone is helping her. The original trigger still describes what happened, but the proposed outreach no longer fits what is happening now.

This is where real-time customer programs can become expensive. Teams often spend months defining what should cause an action while giving far less attention to what should prevent that action from starting, stop it after it begins, or allow it to resume later. Once the trigger fires, too much is left to workflow logic.

Customer status, operating capacity, permissions, and risk keep changing. A payment may post while an outreach task is waiting while another team may take ownership. A customer may respond in a different channel, or a queue may move beyond the point where a timely response is still realistic. An action that made sense at 9:01 can create unnecessary work by 9:11. These are real, ongoing problems that happen every day between brands and the customers that buy from them.

Back in Week 15 of this newsletter, we showed how to decide when a signal deserves attention. Week 18 created a reusable event layer with definitions, boundaries, owners, timing, and proof. This week starts after a qualified event is ready for action and makes the business ask a harder operating question of itself: “Should that action be released now, sent to review, paused, stopped, continued, or resumed?”

Most workflow designs are strong on the first state and vague on everything that follows. The rule may say, “When this event happens, create a case,” or “When the score crosses this threshold, contact the customer.” It usually says much less about what to do when another team already owns the issue, the customer has acknowledged the problem, the source is no longer reliable, the queue is full, or the useful response window has passed.

The business impact goes well beyond an awkward customer message. Duplicate actions consume labor, increase contact volume, create conflicting promises, and make it harder to understand which intervention actually helped. Pausing too often creates a different problem because valid cases wait while the customer issue gets worse. A useful control needs to manage both ends of the risks.

The simplest way to design that control is to define six states.

‘Start’ determines when a qualified event may enter the action path.

‘Continue’ defines what must remain true while work is underway.

‘Review’ identifies situations that need human judgment.

‘Pause’ protects capacity or allows time for information that is likely to arrive soon.

‘Stop’ ends an action because it is no longer useful, permitted, safe, or distinct from work already underway.

‘Resume’ defines what must change before a paused action can restart.

Those states should connect to a measurement chain someone in your organization can inspect. For example, operating data should show whether the source was healthy, the event was current, an owner was available, and the queue had capacity. Experience measures should show whether the action reduced repeat contact, duplicate outreach, resolution delay, or customer effort. Moreover, customer behavior should show whether the person completed the next step, switched channels, abandoned, or kept seeking help. And finally, business outcomes should show the effect on cost, conversion, retention, complaints, or risk. What the team learns should feed directly into the next version of the rule.

Here is a free test I would use with any real-time action proposal: what exact condition causes this action to stop? Then ask who has the authority to stop it, how quickly can that decision reach every channel, and what must be true before the action can resume.

If the answer is “the case closes,” the design is probably too slow. A customer can receive several unnecessary messages before a case reaches that state. If the answer depends on someone noticing an exception in a queue, the control is not operating in real time. If each channel has a different answer, the company has several local workflows rather than one controlled customer action. This, in the end, is a huge problem to solve for.

For paid members, I include the material I would use with a leadership team to work through this problem. Paid subscribers get a Real-Time CX Release Control Workbook, release-control playbook, leadership map, prompt-and-example pack, completed fictional composite, and executive decision brief.

Together, these documents will help a team test one qualified event, decide among the six phases, and run a controlled 30-day pilot without pretending every customer interaction should happen in real time (because let’s face it, it doesn’t need to, and your customers don’t expect that either.)

Read more

A customer uploads the requested identity document. The application state does not advance. The customer visits the status page four times, opens chat, and calls service the next morning. Meanwhile, a generic reminder remains scheduled, and the specialist queue is already close to its operating limit.

The company can record every one of those occurrences. That does not mean it has an event-driven customer system. One customer has created several signals, logs, and alerts, yet the business still has not agreed on the state change that matters, the decision that follows, or the owner who accepts the response timeline.

I think the phrase “event-driven” has become far too technical in customer experience work. Teams start with an event bus, a customer data platform, a workflow tool, or an AI layer that can process activity faster. The technology can move a message from one system to another. It cannot settle what the message means to the business.

That gap shows up quickly. Digital defines an event as a click or abandonment. Service defines an event as a new contact. Risk defines an event as an exception. Marketing defines an event as a campaign response. Operations defines an event as a queue condition. Each definition may be useful inside its function, but the customer situation still has no shared operating meaning.

The result is usually more motion. Several teams create cases, suppressions, outreach, or reviews from partial evidence. A valid alert reaches an owner who has no capacity. A well-scored opportunity creates duplicate work. A late record starts an action after its useful window. Leaders then debate whether the model or threshold is wrong when the deeper issue is that the company never designed the event as a management decision.

A business event should represent a recognized change in customer or operating state. It should be specific enough that two reviewers can identify the same change, bounded enough to keep unrelated activity out, and useful enough to support a named decision. It also needs a version, an owner, a response timeline, restraint, and proof; otherwise, it is raw activity wearing a more impressive label.

This is where Week 18 differs from the earlier work. Week 15 focused on when evidence deserves attention. Week 17 organized approved signals around one customer moment and one coordinated response. This week builds the reusable layer around those decisions: event families, canonical definitions, boundaries, rule versions, operating routines, governance, and test evidence.

That layer matters before real-time execution. Speed magnifies whatever the company has already designed. If definitions conflict, ownership is implicit, or the receiving queue cannot handle the volume, faster processing makes the failure arrive sooner and more consistently.

Use this test with one proposed customer event. Ask the team to finish a single sentence: When this occurs, it means [state changed], [owner] must decide [choice] within [time], the system must not [restraint], and we will close or revise the event when [proof] appears.

If the sentence collapses into several decisions, relies on a broad complaint theme, names a shared queue instead of an accountable owner, or cannot say what should remain quiet, the event is not ready for automation. The team still has design work to do.

The quickest way to find the gap is to compare two records. Put the proposed event definition beside the work instruction used by the receiving team. If the event says a meaningful state changed but the work instruction does not identify the same state, decision, a response timeline, and restraint, the system will create an orphaned alert. If the instruction is clear but the event arrives without trustworthy identity, source health, or timing, the owner cannot use it safely. Both records have to describe the same operating promise before the team should discuss faster execution.

For paid members, I built the working material I would use with a leadership team: the Event-to-Action Rules Workbook, a completed onboarding example, two decision decks, the event catalog and taxonomy, launch and test tools, the operating rhythm, the governance SOP, a prompt-and-review pack, and an executive decision brief. Together they help you approve, revise, defer, or stop one 30-day shadow pilot without pretending the whole company can become event-driven in a month.

Read more

That example is a fictional composite, but the operating pattern is painfully familiar. Digital sees abandonment. Risk sees an exception. Service sees repeat contact. Marketing sees an unopened reminder. The customer sees one company that keeps asking for effort while its own systems disagree.

Most journey maps capture the broad path and highlight moments that matter. They can be useful for creating shared understanding. The trouble starts when leaders assume the map itself will change how the company responds. A red dot on a slide doesn’t name the decision, start a clock, protect the customer from a bad automated message, or tell two functions which one owns the next move.

I think this is one reason journey work loses influence. The map gets treated as the output, while the real operating work sits elsewhere in system rules, queues, policies, staffing, service levels, escalation paths, and decision rights. Those pieces are often owned by different teams, built on different definitions, and reviewed in different meetings.

The result is an odd form of visibility. Everyone can see the customer is stuck, yet each team sees a different version of the problem. More signals make the disagreement easier to observe without making the response any clearer. That raises cost through repeat work, slows recovery, and teaches customers that the safest path is to call again.

Week 16 dealt with whether customer insight is reliable enough for a stated use. That trust layer matters here. Coordinated action should never be built by sweeping every available signal into a rule and hoping the total looks smart. The team needs an approved insight set, visible limits, and a clear statement of what each signal is allowed to influence.

Week 17 moves the work forward by organizing those approved signals around a customer moment. The company has to settle four practical questions: What changed? What decision does that insight support? Who owns the response? How long can the company wait before the response loses value? A fifth question closes the loop: What proof will show that the action helped rather than creating more effort?

Try this with one high-friction moment in your company. Avoid choosing an entire end-to-end path. Pick the smallest moment where a customer’s state changes and the company should notice. Then ask the five questions below with customer, operations, analytics, product, service, and control partners in the room.

If the team cannot answer one of those questions, the problem is not a missing box on the map. The company has not yet designed the response. That distinction matters because it changes the leadership conversation from where friction exists to how the business will act when the moment occurs.

Paid members receive the Customer Moment Action Coordinator, a completed onboarding example, the Journey-Signal leadership deck, the operating playbook, and a human-review prompt pack. Together, the files help a cross-functional team select one moment, define the response rule, assign an owner and service level, run a 75-minute decision meeting, and launch a 30-day shadow pilot.

The argument and five-question test above are complete for free readers. The working method, completed example, tools, meeting sequence, and implementation plan begin below.

Read more

The customer review was already running for 15 minutes when partners and stakeholders in the room and on Zoom stopped trusting the content on the slides. One team had a healthy relationship score, another had a sharp drop in product use, service had three unresolved complaints, and finance had a payment issue. Every source was technically correct. Together, they produced no clear decision because nobody could explain which insight deserved more weight, which sources described the same customer, or whether the data was even approved for the decision being discussed.

I have sat in versions of that meeting more times than I can count. The problem usually gets blamed on fragmented systems, weak dashboards, or incomplete integration. Those issues matter, but they miss the more important point. A company can connect every source and still create a weak customer signal system when the rules governing the evidence are loose.

Week 16 closes the second AI, Not KPI sprint with that problem in mind. Over the past several weeks, we’ve designed the signal architecture, built voice and text pipelines, added behavioral and operational evidence, connected employee signals, unified tags, and designed real-time triggers. That work will expand what the company can see. It also expands the number of ways the company can reach the wrong conclusion with confidence.

The more sources a company adds, the easier it becomes for definitions to drift. One team counts a complaint when a formal case opens. Another counts any negative comment. Digital behavior is current to the minute, survey data reflects a different population, call transcripts cover only recorded interactions, and employee observations arrive without a consistent sampling rule. Put those records on one slide, and they look connected. Pressure test them, and before you know it, the seams show quickly.

This is why signal governance has to focus on the insight itself. An earlier issue covered who owns decisions, how customer issues move into action, and how leaders hold teams accountable. This week, we’re dealing with a different layer: whether the insights used in those decisions had a stable definition, known coverage, acceptable bias, permitted use, accountable owner, and visible change history.

Let’s keep it simple: More customer data does not create better decisions when leaders cannot explain which signals are reliable, what each signal is allowed to influence, and who has the authority to change it. At that point, the system creates output faster than the company can create trust.

That carries a real business cost. Teams spend meetings debating whose number is right. Customer outreach gets triggered from evidence that is stale or poorly matched. Product teams chase loud feedback from a narrow group while missing behavior from the larger population. Risk and privacy teams enter late, after a use case has already gathered momentum. The result is slower decisions, repeat analysis, avoidable customer contact, and a growing reluctance to act on any signal at all.

Consider a composite example based on a pattern I have seen inside large companies. A leadership team builds a client health view using survey sentiment, product use, service cases, payment behavior, call transcripts, and frontline observations. The combined score looks sophisticated, but three weaknesses sit underneath it. Product use is linked at the account level while service cases sit at the individual level, transcript coverage varies by region, and the survey sample overrepresents the most engaged users.

The score flags an account for proactive outreach. Sales sees an opportunity, service sees unresolved friction, and the relationship manager sees a stable client. Without clear rules, the team can defend three different actions from the same record. An integrated score has made the disagreement harder to see, not easier to resolve. This, by the way, is also the problem with most CXM platforms today; signals ingested but disconnected will lead you down the road to failure AND potentially millions of dollars poorer.

The same problem becomes more serious when AI is involved. AI can summarize conflicting evidence, identify patterns, and draft a recommendation in seconds. It cannot decide whether the source population is representative, whether the identity match is strong enough, whether transcript data is allowed for that use, or whether a source definition changed last month without you knowing about it. Those are management decisions; unfortunately, your AI model simply inherits them. This is a huge risk with simply putting raw data into an LLM and expecting it to work ongoing.

Here is the practical test I would use in your next customer review. Choose the evidence behind one material decision and ask five questions:

1. What exact decision is this signal meant to influence?

2. Which source and population sit behind it?

3. What changed in the definition or collection process?

4. Who owns the source and its permitted use?

5. What is the strongest reason the company should hesitate before acting?

If you or internal stakeholders and partners can’t answer those questions without opening three systems and calling four people, the insight is not ready for a high-stakes decision. It may still be useful for exploration, but that is a different level of permission. Naming that boundary is a sign of judgment, not caution for its own sake.

For paid members, I built the working material I would use with a leadership team: the Customer Signal Reliability Scorecard, a completed six-source example, the Signal Governance Playbook, an access and privacy review map, the leadership deck, and a prompt pack with human review guidance.

There’s also a separate Sprint 2 “Start Here” guide connecting Weeks 9 through 16, giving you a 90-day plan from architecture to governed action. Together, the package helps you decide which evidence is ready, which uses need limits, what must be remediated, and who owns the next decision.

Read more

Many CX teams spent years trying to hear more. They added surveys, social listening, speech analytics, product events, operational data, employee signals, and increasingly sophisticated ways to connect those sources. The result is a much richer evidence base and a new management problem: almost any change in a customer’s experience can now become an alert.

When everything can interrupt the work, attention becomes the limiting resource. A second failed login, a negative comment, an abandoned application, a delayed delivery, a repeat contact, and a drop in usage may all matter, but they do not carry the same urgency or the same confidence. Sending every one of them to a person or workflow creates an alert system that looks responsive and quickly becomes easy to ignore.

This is where many real-time CX efforts lose value. The technology moves faster while the operating rules remain vague, so teams push more alerts into queues that already have unclear ownership, limited capacity, and no shared definition of what deserves attention. The system produces activity, but leaders cannot tell whether it identified the right customer situations, whether people trusted the evidence, or whether the signal arrived while a useful decision was still possible.

Week 14 established a unified signal record built around identity, context, meaning, confidence, and ownership. Week 15 uses that record to answer the next question: when is the evidence strong enough to interrupt the work? The trigger sits between evidence and action. It qualifies a customer situation for review now, later, or not at all, while the design of the response and any automation remain separate decisions for later weeks.

Start with the useful response window

“Real-time” should be defined by the useful response window. Some situations lose value in a few minutes, such as a customer repeatedly failing an identity check while trying to open an account. Others remain actionable for several hours, such as a delivery that is likely to miss its promise, while a gradual decline in product use may be more useful in a daily or weekly review.

Processing every situation at the fastest possible cadence raises cost and noise without improving the decision. A team should first ask how quickly the evidence changes, how quickly the opportunity to help decays, how much harm a delay could create, and whether an owner can realistically respond. The answer may be immediate, within an hour, by the end of the day, or at the next operating review.

That timing choice should be explicit. “Real-time” is too imprecise to guide system design because a millisecond event stream and a four-hour service window can both support a useful intervention. The right standard is whether the signal arrives early enough for the named owner to make the named decision.

Give every trigger a Qualification Standard

I use a Trigger Qualification Standard to make that standard concrete. It is a short, versioned agreement describing why a customer situation deserves attention, what evidence must be present, what evidence should stop the interruption, and who owns the review. The contract has seven parts that can be understood by business, data, technology, risk, and frontline teams without translating the work into different languages.

1. Decision use. Name the decision the trigger supports. “Identify unhappy customers” is too broad, while “decide whether an onboarding specialist should review a blocked application within 30 minutes” gives the team something it can design and test.

2. Customer moment. Define the interaction, need, or change in state the evidence describes. The moment should be narrow enough that the signal has a common meaning, such as identity verification during digital onboarding, rather than a broad label such as acquisition or service.

3. Evidence bundle. State the minimum evidence required to qualify the situation. One high-confidence operational event may be enough in a tightly controlled case, while a lower-confidence situation may require agreement across behavior, service, text, or operational sources.

4. Context window. Specify how long related evidence belongs to the same situation. Two failed uploads within 20 minutes may indicate a blocked customer, but two failures separated by six months probably describe different needs.

5. Threshold. Define the level at which the evidence becomes strong enough to release, review, or suppress. This can include identity confidence, signal confidence, repetition, severity, source agreement, recency, or a change from the customer’s own baseline.

6. Restraint. Add exclusions, suppression periods, duplicate handling, capacity limits, active-case checks, and privacy rules. These controls keep the same customer from receiving overlapping attention and prevent teams from acting on evidence that is stale, ambiguous, or inappropriate for use.

7. Ownership. Assign the person who accepts the trigger for use, the team that reviews released cases, the owner who tunes the rule, and the cadence for reviewing performance. A trigger without an owner becomes another message that everyone can see and no one is required to resolve.

Together, these seven parts turn an alert into a management contract. The team can explain why the trigger exists, reconstruct the evidence behind any release, challenge its assumptions, and decide when the rule needs to change.

The practical test is simple: if the team cannot explain why this moment deserves to interrupt someone’s work, the trigger is not ready.

Read more

A customer begins a digital application. The CRM records a new prospect, the identity system flags a document mismatch, the product event stream shows two failed uploads, and the service platform has no open case because the customer has not called.

Four systems now have each captured something true, yet no system has captured the whole situation.

If these signals remain separate, the customer may receive another automated reminder to finish the application. Your onboarding team may see the issue hours later, and a customer service agent may eventually open a case and ask for information the customer has already provided. Finally, a manager looking at the funnel may call the problem abandonment.

All the while, your customer experiences one blocked moment while your company sees four partial records and one misleading outcome.

This is where many AI programs stall or fail altogether. Teams collect more feedback, connect more systems, and create more summaries, yet the signals you have available to you still can’t support a timely decision. The missing layer is a shared way to identify, describe, trust, and own a signal across sources.

This issue of ‘AI, Not KPI’ focuses on that layer: tagging and unifying signals.

How this builds on the prior weeks

The sprint phase has moved from collecting evidence toward making it operational.

In earlier weeks, we mapped the experience architecture, examined customer, employee, operational and behavioral signals, and established stronger handoffs between evidence and decisions. Week 13 made the next requirement clear. A signal can have a source, an owner, and a decision but still fail when teams describe the same customer or issue in different ways.

One platform calls the issue `YC_FAILED`; another uses `Doc invalid`. A service team selects “Verification issue” while a product analyst tracks `upload_error_17`.

Those labels can coexist inside their local systems. Trouble starts when the organization tries to combine them, use them in an AI model, build a real-time trigger, or explain an action later. Local meaning has to survive while shared meaning becomes possible.

We need to create that bridge, and the work has three parts:

1. Define the minimum fields every signal needs.

2. Map local identities and labels into approved shared records.

3. Attach quality rules and owners before the signal is used.

This also prepares you for the final two newsletters in the quarter’s sprint phase. Week 15 will use approved signals to design real-time feedback triggers. Week 16 will establish the governance needed to manage sources, definitions, thresholds, exceptions, and decision rights over time.

A trigger should never be faster than the evidence is trustworthy. Governance should never begin after automation has already scaled the mistake.

The Five-Part Unified Signal Record

I have always used a simple model to make the work practical. Every signal that may inform a decision should carry five parts:

1. Identity: Who or what is affected?

2. Context: Where and when did it happen?

3. Meaning: What happened, and why does it matter?

4. Confidence: How sure are we?

5. Ownership: Who decides, acts and learns?

These five parts form the ‘Unified Signal Record’.

Identity lets teams connect evidence to the correct customer, account, household, employee, product, or interaction. Context locates the signal in a moment, channel, product, and time window. Meaning provides the event, theme, reason, and severity. Confidence makes matching, freshness, and quality visible. Ownership connects the evidence to a decision, an action, an SLA, and a review cycle.

When one of these parts is missing, a signal becomes harder to use safely. A theme without identity cannot be connected to the right case; an identity without context can combine unrelated events, meaning without confidence invites overreaction; and a high-confidence signal without ownership becomes an alert that nobody accepts.

The goal is one versioned record that preserves both the evidence and the uncertainty around it.

Unfortunately, here’s where the free version ends. If you want to know how to implement the five (5) parts in practice, including receiving the artifacts that support the work, you will have to subscribe. The link is below for you, and thank you in advance for being a paid subscriber, as it supports this ongoing work.

Read more

The CX team tracks customer effort, resolution, trust, retention, and complaints, while HR looks at engagement, intent to stay, manager effectiveness, and a handful of questions about tools or workload. Both functions can produce a polished scorecard and explain why a number moved. Yet when those scorecards reach the same executive agenda, they rarely describe the same work, the same customer moment, or even the same period of time.

This is why the familiar claim that happy employees create happy customers has never been especially useful to an operator. It may be directionally true, but it doesn’t tell a leader which part of the employee experience matters, where it shows up for a customer, how it changes employee behavior, or whether fixing it will improve revenue, retention, cost, or risk. Without that level of specificity, there is very little anyone can do differently on Monday morning.

This week, I want to make that connection usable. We are going to look at the conditions under which work gets done, identify the one that may be shaping a customer outcome, and change it. Then we can see whether employee behavior, the customer’s experience, and the business result move together.

Start with the work

Every customer experience is produced through work. A billing correction, a claim, an onboarding task, a delivery exception, or a service recovery depends on someone understanding what a good outcome looks like and having a reasonable chance of delivering it. That person needs the right information, tools, authority, capacity, coaching, and incentives. When one of those conditions breaks down, employees compensate with workarounds, extra approvals, or their own judgment, and customers experience the consequences as effort, delay, uncertainty, repeat contact, or error.

I have found that the cleanest way to connect EX and CX is to begin with a specific customer moment and trace the work required to deliver it. From there, we can identify the employee condition shaping the behavior, connect that behavior to what the customer experiences, and follow the effect through to a business result.

I call this the Work-to-Customer Chain. Work conditions influence how employees behave, those behaviors shape what customers experience, and the experience affects what customers do next. Customer behavior eventually appears in a business result. Incentives and AI sit across that chain because both can reinforce sound judgment and good work while also magnifying poor policies, weak tools, and badly designed processes.

The work from prior weeks gives us the foundation. Week 9 established the horizontal signal architecture, Week 10 added what customers say, Week 11 added what they do, and Week 12 introduced operational proof. Week 13 brings employee conditions into that same evidence system so leaders can better understand why an outcome occurred and what they have the ability to change.

Five questions expose the condition behind the result

When a customer result is below expectations, I work through five questions in order. They cover distinct parts of the work environment, which helps leaders avoid collapsing every problem into training, coaching, or a vague concern about culture.

1. Do people know what good looks like? Role clarity includes the outcome employees are expected to deliver, the customer promise behind it, the tradeoffs they can make, and the next best action when the situation falls outside the standard process.

2. Can they do the work well? Capability and enablement cover skills, information, tools, workflow support, and access to current knowledge at the point where a decision has to be made. A well-trained employee can still fail when the system is slow, the policy is hard to find, or the customer context is scattered across several screens.

3. Are they allowed to make the right decision? Decision authority includes policy limits, escalation rules, approvals, and the confidence to use judgment within clear boundaries. When those boundaries are confusing or punitive, employees learn to escalate even routine decisions because it is safer for them.

4. Do they have enough capacity to deliver the outcome? Workload, demand variability, staffing, interruptions, queue design, and administrative friction all shape the amount of time available for the customer. A capacity problem often presents as an attitude or performance problem long before anyone looks at how the work is distributed.

5. What behavior does the company actually reward? Formal incentives matter, but so do team scorecards, recognition, promotion decisions, coaching attention, and the targets leaders discuss when pressure rises. Employees learn quickly which commitments are real and which ones disappear when the quarter gets difficult.

These questions make the diagnosis more precise. Training is useful when people lack a skill or don’t understand the standard, although it will do very little for a missing permission, a broken tool, an impossible workload, or an incentive that rewards the wrong behavior. Leaders need to identify the condition before deciding on the intervention.

The five questions above give you a practical way to identify where the employee experience may be affecting a customer outcome.

Paid subscribers can continue below for the linkage method, metric chain, incentive audit, BOOSTR baseline, 30-day pilot, and the complete set of working tools.

Read more

A service operation can look healthy right up until the customer gives up. We’ve all been there and know exactly how it feels, so why do we accept it inside our own companies?

Average handle time improves, digital containment rises, Product’s backlog drops, and everyone’s dashboard looks green. Then complaints climb in one product line, renewals get harder in one segment, and frontline teams start explaining the same exception every day. The operational metrics were not wrong; they were just incomplete.

The Week 12 problem to solve is this: companies treat operational data as internal performance evidence, then wonder why customer experience feels soft, anecdotal, or late. The real opportunity is to use operational data as CX proof and not as a replacement for surveys but as the evidence that shows where the business kept or broke its promise. Otherwise, you’ll have watermelon customers — green on the outside and red on the inside.

This is critical because operational data is where customer friction usually leaves fingerprints within and across silos at your company. There are clear examples such as repeat contacts, transfer rates, cycle time, and rework that creates technical debt. You could also identify exception handling, credit issuance, failed digital starts, reopened cases, missed appointments, escalations, and churn-risk triggers. But none of these are just internal productivity measures. In the right context, they are all customer evidence and need to be treated as such in that context.

The mistake is that most companies organize these metrics around the function that produces them, not around the customer problem they reveal. Service owns handle time. Digital owns containment. Product owns the backlog. Finance owns credits. CX owns sentiment. Everyone has a metric, but very few people unfortunately have the full picture.

In my experience, I’ve observed that this behavior creates three problems.

First, leaders optimize the local metric and miss the customer consequence.

Second, CX teams keep asking for proof while proof is already sitting in operational systems and data.

Third, AI, possibly the worst part, gets pointed at the wrong job-to-be-done. It summarizes feedback beautifully, but it cannot help the business act if the operational evidence is still disconnected from ownership, cost, and who can actually make a decision.

You can see this in service recovery. A customer calls because an issue was not resolved the first time. The contact center may see repeat contact. Operations may see a reopened case. Finance may see a credit. Product would see a defect. Digital may see a failed self-service attempt. The customer does not experience those as five separate metrics. They experience one broken promise with an appreciation for how dysfunctional your organizational structure actually is.

That is why operational data should be treated as experiential evidence. A repeat contact rate is not interesting because it gives the service leader something to report. It is interesting because it may show that the company is making customers re-explain, re-wait, re-escalate, and re-trust a process that already failed them once. That is a customer issue, an employee issue, a cost issue, potentially a technology issue, and often a retention issue.

The same is true in digital. A containment rate can look great while customers are quietly choosing the wrong path, abandoning before completion, or contacting an agent later because the digital answer did not solve the real problem. If the only metric is containment, the business may celebrate deflection and miss unresolved effort. If the metric is paired with failed starts, repeat contact, task completion, complaint language, and downstream service demand, the story gets harder to ignore. And don’t get me started on all of the new AI-enabled support solutions whose fees are based on resolution. Please, can someone define for me what “resolved” means? (I digress!)

Operational data becomes powerful when it shows what customers had to do because the company made something harder than it needed to be. It becomes weak when leaders use it only to judge whether a function looks efficient. That distinction is important, because efficiency without proof can make the business faster at producing the wrong outcome. Fast and wrong is still wrong, after all.

A customer-led team asks a different question: which operational metrics are credible evidence of customer friction, trust, effort, recovery, and value? That question changes the work. The goal is no longer to collect more data. The goal is to decide which operational signals deserve to become part of the CX evidence system.

That decision requires more discipline than most dashboard and PPT deck reviews bring. Some metrics are proof metrics. They explain a customer-relevant failure or success. Some are management metrics. They help a team run workload, capacity, quality, or staffing. Others are diagnostic metrics. They help teams investigate a hypothesis. Some are risk metrics. They warn that a process, policy, or system may be creating damage before the survey catches up.

Those categories are not academic. They decide how leaders should use the number. For example:

1. A proof metric belongs in an executive customer review because it can support action.

2. A management metric may belong in a functional operating review because it helps a leader manage throughput.

The problem starts when the company drags every local management measure into the CX story and calls the whole thing customer evidence.

That is how dashboards get bloated. Everything has a label. Everything has a trend. Everything has an owner who wants their metric shown. But the more numbers a leadership team sees, the easier it becomes to avoid the uncomfortable question: what did we learn that should change a decision?

The practical test I have used in the past and would use this week is simple:

Take one recurring customer pain point and list the operational metrics that should move if the pain is real. If customers say billing is confusing, do not stop at sentiment. Look at bill-related contacts, payment delays, credits, disputes, repeat contacts, digital bill views, chatbot failures, and agent notes. If those measures do not line up, you either have a measurement gap or a story that is not ready for leadership.

Then I’d ask a second question: which of those metrics could or would actually change a decision? If credits are rising but nobody knows why they were issued, that metric is your smoke alarm. If repeat contacts are rising but the definition changes across teams, the trend may create more argument than action. If failed digital starts are rising but the data cannot be segmented by task, the digital team may know there is a problem without knowing where to look.

Operational data can make CX more credible, but only if the data is good enough to carry weight. A number does not become decision-grade because it came from a system. It becomes decision-grade when the definition is stable, the owner is clear, the customer moment is identifiable, the business consequence is plausible, and the next action is visible. All of these things have to be in place.

Most companies get this wrong because incentives are still functional. Leaders are rewarded for improving the measures inside their line of sight. The contact center wants shorter calls. Digital wants more containment. Operations wants lower backlog. Finance wants fewer credits. Product wants fewer defects. Each goal may be reasonable, and they are. But the customer problem appears when those measures are not connected to the full experience of the work.

That is why the operating conversation has to move from metric ownership to promise ownership. A function can own a number, but the customer experiences the promise across functions. Billing clarity may depend on product configuration, finance rules, digital content, agent training, and statement design. Service recovery may depend on policy, staffing, case routing, quality review, and frontline authority. When leaders keep the evidence inside functional lanes, they make the customer problem look smaller than it is. When they connect operational data across the promise, they can finally see the real cost of fragmentation.

This is where CX teams have to stop asking for “a seat at the table” and start bringing clear evidence of the problem and the business impact. Yes, a customer comment can create empathy, and a survey score can show direction. But operational data can show the mechanism: where the work broke, where the customer paid the price, where employees absorbed the friction, and where the business spent money twice because it did not fix the issue once. I saw this firsthand when I was meeting weekly with the then-CEO of Chase’s Home Lending business. We listened to the call and reviewed sentiment only for context; we brought operational data to help us see what was breaking the customer experience from the inside out.

That is also where AI can become useful in a very practical way. AI can help classify unstructured data, summarize operational exceptions, connect customer language to issue codes, and flag patterns that deserve investigation. But AI cannot rescue a measurement system that rewards weak metrics, unclear owners, and ambiguous decisions. Faster summarization of disconnected data is still disconnected data.

The leadership habit to break is metric politeness. Teams keep weak metrics in the pack because someone owns them, someone likes the trend, or removing them would create an awkward conversation. But a metric that does not explain customer friction, support a decision, or connect to business consequences is not proof.

Operational data becomes CX proof only when four conditions are met.

1. It has to describe a customer-relevant moment.

2. It has to be trusted enough to act on.

3. It has to connect to an owner who can change the work in some way (e.g., reprioritize efforts or fund new ones).

4. And it has to point to a decision, not just a read-out in a QBR (quarterly business review).

For paid subscribers who have access to the content behind the paywall below, I built the Week 12 operating kit around that test: how to decide which operational data belongs in the CX evidence system, how to explain the pain point in business terms, and how to turn service failure evidence into an action plan.

Not a subscriber? I hope to see you on the other side of the paywall sometime. And it’s a big week for Founding Members, who receive an additional seven (7) documents compared to what paid subscribers received this week.

Read more

There is a moment in almost every digital review when someone points to the funnel and says, “Customers are dropping here, so this must be the problem.”

Could they be right? Maybe they’re right. But…

Maybe the page is slow. Maybe the offer is unclear. Maybe the form asks for too much information too soon. Maybe the button is broken. Maybe the copy creates doubt. Maybe the policy behind the screen is doing more damage than the screen itself.

Or maybe the customer decided to leave three steps earlier, and the chart is only showing the exit door.

That’s the problem with behavioral data. It’s some of the most useful evidence a company has and also some of the easiest evidence to over-interpret. It feels objective because it shows what people did. They clicked. They searched. They scrolled. They abandoned. They returned. They watched. They opened chat. They stopped.

The fact patterns matter. They’re not opinions. They’re not survey memories. They’re not filtered through a customer’s ability to explain their own frustration after the fact.

But you need to understand that behavior still has limits.

Behavior shows movement. It does not automatically explain motive.

A customer can abandon onboarding because they’re confused, annoyed, distracted, price-sensitive, worried about risk, unwilling to provide documents, blocked by a browser issue, waiting for a spouse, comparing providers, or simply out of time. Tons of different reasons for this to happen.

A customer can search the same help article three times because the content is bad. They can also search three times because the policy is complicated, the answer is different by state, the prior agent gave them conflicting guidance, or the company has trained them to distrust the first answer they see to begin with.

A customer can rage-click a disabled button because the design is broken. They can also rage-click because the customer expected to be eligible for something they are not eligible for, and the real issue is the business rule behind the interface. It’s the equivalent of screaming REPRESENTATIVE!! into the phone multiple times. And don’t try to tell me you’ve never done that.

Behavior is evidence. It’s just not the full story, and that’s what we have to be careful about.

This work is important because too many teams treat digital analytics as proof when it is often a pointer. A drop-off rate becomes a product verdict. A heatmap becomes a design mandate. A click pattern becomes a customer story. The dashboard looks clean, the percentages look precise, and the interpretation still has too much guesswork inside it.

This is where customer-led work has to get more disciplined.

If you’ve been following this newsletter from the start, the phase we’re in started with Week 9, which gave us the signal architecture: source, collection, quality gate, classification, ownership, decision use, action, and learning. Week 10 applied that architecture to voice and text signals, where customers give the business language.

Now, in Week 11, we’ll start to apply the same discipline to behavioral signals, where customers give the business movement.

Customer movement is important because customers often act before they explain. They hesitate before they complain. They search before they call. They abandon before they churn. They return to the same page before they tell you the policy is unclear. They click around the account page before they admit they don’t understand the renewal terms. They open a competitor tab before they ever show up in a lost deal reason.

If you’re only listening to what customers say, you’re missing a large part of the truth. But if you only watch what customers do, you can also convince yourself you understand more than you actually do.

So never choose between voice, text, and behavior. But you do have to make behavior part of the customer’s fact pattern strong enough to support a better decision.

All of this requires a different leadership habit. Specifically, instead of asking, “What does the CX dashboard say?” Ask, “What decision can this behavior safely support, and what other information do we need before we act?”

The differences in these questions fundamentally changes the conversation inside your company.

Here are a few examples around what I mean:

A funnel chart can show where customers leave. It cannot tell you whether the answer is a product fix, a policy change, a pricing explanation, a service trigger, a content rewrite, a trust intervention, or a sales follow-up.

A session recording can show the customer struggling with a form field. It cannot tell you whether the customer struggled because the form was unclear, the data required was unreasonable, or the company asked for sensitive information before earning trust.

A feature adoption chart can show that customers are not using a capability. It cannot tell you whether they don’t know it exists, don’t understand the value, don’t have permission to use it, don’t need it yet, or tried it once and decided it was not worth the effort.

A checkout drop-off rate can show that customers are leaving at payment. It cannot tell you whether the issue is price shock, shipping cost, delivery timing, trust, payment options, return policy, promo code failure, or comparison shopping.

The one behavioral signal is the start of the question. It is not the end of the answer.

That sounds obvious until your ELT is under pressure. Revenue is down. Conversion is soft. Activation is behind schedule. Renewal risk is increasing. Digital containment is missing the target. Product adoption is lower than expected. The executive team wants an answer, and the analytics team has a chart. I’m quite sure many readers of this newsletter have probably gotten the phone call or email on the above.

And at that moment, the company can either get more precise or get more confident than the evidence allows. Unfortunately, most companies choose confidence.

So what do they do?

They move the button. They rewrite the page. They change the sequence. They add another tooltip. They launch another nurture email. They tell Service to deflect more contacts. They open a product ticket. They call the issue “friction” because friction is the kind of word that sounds useful even when it means 10 different things to 10 different people.

Sometimes all of that work does help. Sometimes it doesn’t. And I have personally seen too many times when actions didn’t lead to expected results. That’s how you create tech debt, human capital debt, and process debt. Even experience debt.

And even after all of that, the bigger problem is that the company rarely goes back and asks whether the behavioral signal was interpreted correctly in the first place.

That is where behavioral data becomes expensive. You moved quickly, but you’re wrong. And last time I checked, fast and wrong is still wrong. The organization used the data to accelerate the wrong work.

A customer-led organization treats behavior differently. It does not dismiss the signal. It also does not promote the signal into a conclusion too quickly. It asks what happened, where it happened, who it affected, how confident the team is in the tracking, what customer question the pattern raises, and what decision should change if the pattern is real.

Take a simple example: onboarding abandonment.

The weak version says, “Customers are dropping during onboarding. We need to simplify onboarding.” That might be true, but let’s challenge ourselves a bit, as it’s not good enough.

The better version states, “New small-business customers are starting onboarding, reaching the beneficial-owner collection step, leaving without completion, and not returning within 48 hours. The pattern is concentrated among businesses with more than two owners and is higher on mobile than desktop. We need to understand whether the issue is effort, trust, document availability, mobile usability, or confusion about why we need the information.”

That is a much better conversation. It’s also the more actionable one.

Now there are owners. Product can look at the flow. Compliance can explain the requirement. Service can review contact reasons. Content can assess the explanation. Research can talk to customers who abandoned. Analytics can test whether mobile behavior differs because of screen design, document upload, or session timeout. Leadership can then decide whether the right move is simplification, education, proactive outreach, assisted onboarding, or a policy review.

Same signal. Very different value.

Or take repeat search behavior in a support experience.

The weak version says, “Customers keep searching for the same thing. Search is broken.”

Maybe it is. But the search result might be fine and the answer might be unacceptable. Customers are not always searching because they cannot find the answer. Sometimes they are searching because they don’t like the answer they found.

A customer who searches “cancel subscription,” “refund policy,” “early termination fee,” and “talk to agent” is not giving you a search problem alone. They may be giving you a trust problem, a policy problem, a pricing clarity problem, or a retention risk signal.

A customer who searches “setup integration,” watches a help video, returns to documentation, and then opens chat is not simply “engaged.” They may be telling you the implementation experience is too hard for the person your sales team sold to.

A customer who clicks the same disabled button five times is not only showing frustration with the interface. They may be showing that the company has put the customer in a state where the next logical action appears available but is blocked by a rule the customer cannot see.

Behavior gives you the breadcrumb trail. It does not tell you why the customer took that path. So the mistake is turning the breadcrumb trail into a story too quickly.

As companies put AI on top of behavioral data, this becomes even more important. A model can find patterns faster than a human team. It can summarize sessions, cluster click behavior, detect anomalies, identify risk signals, and recommend next actions. That can be very valuable.

But faster pattern recognition does not eliminate the need for judgment. In some cases, it increases the need for judgment because the system can make weak interpretations look stronger than they are. Remember, fast and wrong is still wrong.

If the event definition is sloppy, AI will scale the slop.

If the tracking is inconsistent, AI will find patterns in noise.

If the team confuses behavior with motive, AI will help them do it faster.

That is why behavioral data needs rules before it needs more dashboards like we see today. The issue is rarely that companies have no behavioral data. The issue is that they have too much ungoverned behavioral data, too many loosely defined events, too many disconnected dashboards, and too few standards for deciding what the signal can actually support.

There’s a practical test that is simple and you can put in place right after you’ve finished reading this article. Heck, stop reading after the example, go try it, and then come back here!

Ready? Take one behavior you already track and force it through six questions.

1. What exactly happened?

2. Where did it happen?

3. Who does it affect?

4. How confident are we in the tracking?

5. What customer question does it raise?

6. What decision should change if the pattern is real?

If you and your team can answer those questions, the behavior is leadership-grade stuff. If the team cannot answer those questions, it may still be useful, but it is not ready to deliver a leadership decision.

Now, I need to highlight a very critical point, and this is as good a spot as any to do that. This newsletter is not about slowing the company down. It’s about preventing the company from moving quickly in the wrong direction.

Because when behavior is handled well, it becomes one of the fastest ways to see where customer intent, company design, and business outcomes are misaligned.

You can see where customers try to do something and fail.

You can see where they repeat effort.

You can see where they avoid a path the company expected them to take.

You can see where they ask for help after self-service was supposed to work.

You can see where they hesitate before a decision with financial, personal, or operational risk.

You can see where customers behave differently by segment, product, tenure, channel, device, geography, contract size, or life cycle stage.

That is incredibly useful. It just has to be treated with respect.

The best behavioral data does not make leadership more certain about the first explanation. It makes the team more precise about the next investigation and the next decision.

That is the real standard. Not more charts. Just better decisions.

Wan to see all of the artifacts for this week’s edition and all prior weeks? Would love for you to subscribe. You’ll also receive my 150-page CX Operating Toolkit, where I have organized 25 years of professional expertise into one document you can take and put into practice first thing tomorrow.

Read more

“We need to get closer to what customers are actually saying.”

It’s the right instinct, but the statement itself is incomplete because most companies are already surrounded by what customers are saying. The customer’s words are sitting in call recordings, chat transcripts, survey comments, product reviews, complaint notes, cancellation reasons, app store feedback, support tickets, social posts, customer success notes, sales objections, and escalation logs.

There is plenty of language. There is far less usable evidence.

That distinction matters because companies have spent years treating customer comments as if they become valuable the moment someone collects, summarizes, or themes them. They don’t. A transcript is raw material. A survey comment is raw material. A review is raw material. Even a clean AI-generated summary is raw material until someone understands the source, checks the surrounding context, tests the evidence, and connects the finding to a decision the business needs to make.

This is one of the more important shifts happening in CX right now, and I don’t think enough teams are treating it seriously enough.

AI has made it much easier to process customer language at scale. Teams can analyze more calls, more chats, more survey comments, more reviews, and more customer interactions than they ever could manually. That opens up a real opportunity, especially for teams that have been trapped in small samples, quarterly readouts, and anecdote-heavy reporting.

It also introduces a new risk.

A company can now create a larger volume of analysis that looks polished, reads well, and still doesn’t change how the business operates. The summaries get cleaner. The themes get faster. The decks get easier to create. The organization feels closer to the customer, even when the underlying evidence remains too thin to influence a meaningful decision.

That is where CX teams need to be careful.

The work ahead is to build a better system for turning customer language into evidence the business can trust. That is the focus of Week 10.

The problem with “what customers are saying”

There is a moment I’ve seen play out more times than I can count.

A leader asks what customers are saying about a specific issue. Maybe it’s onboarding. Maybe it’s billing. Maybe it’s a digital flow. Maybe it’s cancellation. Maybe it’s a spike in calls after a policy change.

The CX or insights team pulls comments. Someone reads through a sample. Someone clusters themes. Maybe there is a text analytics tool involved. Now, increasingly, AI creates a summary.

The summary usually sounds pretty good.

Customers are confused by the process. Customers want clearer communication. Customers are frustrated by delays. Customers are calling because they can’t complete the task online. Customers are asking for more proactive updates.

None of that is necessarily wrong. The problem is that it rarely carries enough weight to help the business decide what to do.

The room then starts asking the questions that determine whether the finding has any real value.

Which customers are we talking about? Which source did this come from? How many comments are in the sample? Is this issue showing up in calls only, or in chats and survey comments too? Is it concentrated in one segment, one product, one region, one policy, one handoff, one agent group, or one customer type? Is this a new issue, or has it always been there? Are we seeing the actual customer problem, or are we seeing the way our own systems force customers to describe the problem?

That’s usually when the confidence starts to drop.

The team had comments. The team had themes. The team may even have had AI support. But the evidence wasn’t strong enough to move the business, so the organization does what organizations often do. It nods, asks for more analysis, debates the issue again next month, or lets the decision drift back to instinct, politics, escalation pressure, or whoever owns the loudest operational pain point.

That’s a waste.

It is also one reason so many CX teams struggle to get out of the reporting lane. They’re close to the customer’s words, but the work has to get closer to the decisions those words should influence.

The hidden issue is evidence quality

For years, open-text comments and transcripts were treated as an analytics problem. Too much volume, too many channels, too much mess, too many formats, and too little time to read everything manually.

That was a real constraint, but it never explained the whole problem. The bigger issue is evidence quality.

A customer comment has value, but the strength of that value depends on the source, the surrounding context, the quality of capture, the available metadata, the customer segment, the sampling method, and the review process.

A call recording from a customer who just failed three times in a digital flow tells you something specific. A one-line survey comment that says “bad experience” tells you something too, but it gives you much less to work with. A public review after a service failure may be emotional and still accurate. An agent-written note may be useful, but it may reflect the agent’s interpretation more than the customer’s actual language.

Those differences matter. Most companies blur them together.

Calls, chats, survey comments, reviews, tickets, and notes get placed under the broad label of “customer feedback.” Then AI or a text analytics tool is asked to make sense of it. The output looks organized, but the underlying evidence may still be uneven.

That is how teams end up treating a loud signal as a representative signal, a vivid comment as a common issue, or a clean summary as a business case.

CX has to mature here.

If customer language is going to influence decisions, teams need to understand what kind of evidence they are working with. Is the source direct customer language or interpreted language? Does it include enough metadata to understand who was affected? Can the comment be tied to a product, policy, process, channel, customer type, or outcome? Is the sample strong enough for the decision being discussed? Do we know what the customer was trying to do? Do we know what failed? Do we know whether the issue is friction, confusion, policy, defect, effort, expectation, handoff, or communication? Do we know who should own the next action?

When those answers are weak, the team may still have a useful clue. It probably doesn’t have decision-ready evidence. That is the whole point.

Why AI makes this more urgent

AI made voice and text analysis much more common. The cost of reading, summarizing, tagging, clustering, comparing, and extracting patterns from customer language dropped fast.

That should be good news for CX teams. It gives them a way to move beyond small samples, manual coding, quarterly themes, and selective anecdotes. It also creates a path to compare sources that used to sit in different systems and different departments.

The catch is that AI improves processing speed before it improves evidence quality.

If the source is poor, AI can summarize poor evidence. If the taxonomy is sloppy, AI can classify comments into sloppy categories. If the prompt is vague, AI can produce vague findings. If the sample is biased, AI can find patterns inside the bias. If no one reviews the output, AI can create a version of customer truth that sounds confident while being only half useful.

This is why I’m increasingly careful with the way people talk about AI in CX.

The value comes from using AI to help teams understand customer behavior, customer friction, and business impact with more speed and discipline. Reading every comment is useful only when the work gets to a better decision.

AI can help, but the operating model around it has to be strong enough.

That means source rules. Metadata rules. Sampling rules. Taxonomy rules. Review rules. Confidence rules. Decision rules.

That may sound less exciting than saying AI will analyze all your customer feedback. It is also the part that makes the output worth trusting.

From language to evidence

The move this week is straightforward: Treat customer language as a source of evidence that needs to be managed, tested, and connected to decisions.

That shift changes the questions teams should be asking. Instead of stopping at what customers are saying, the team should ask what the business can responsibly conclude from what customers are saying. Instead of asking only for the top themes, the team should ask which patterns are strong enough to influence a decision. Instead of celebrating the fact that AI can summarize the text, the team should define the review process that makes the output trustworthy enough to use. Instead of asking who wants the report, the team should ask who owns the action if the evidence is strong.

That is where customer language becomes useful.

The purpose of this work is to help the business make better decisions, faster, with more confidence. That requires a practical customer language pipeline, not a giant transformation program, an overbuilt data architecture effort, or another platform discussion that takes six months and dies in procurement.

A practical pipeline should answer a few basic questions.

Where does customer language already exist? Which sources are ready to use? What context is missing? What needs to be excluded or redacted? How should we sample? What taxonomy should we use? Where can AI help? Where does human review matter? How confident are we? What decision does this support? Who owns the next move?

That’s the work.

Read more

An executive asks three teams why customers are leaving.

The survey team points to relationship scores and verbatims. The contact center points to repeat calls. Digital points to failed self-service attempts. Finance points to credits, discounts, and lost margin. Each team is telling part of the truth. The problem is that the company never designed the signal system that explains how those truths fit together.

That is where the next phase of AI, Not KPI starts.

The first eight weeks were about the foundation: why survey-only CX fails, why outcomes need to come before metrics, why listening needs governance, why feedback has to turn into action, and why dashboards only matter if they change decisions.

Week 9 starts with Designing the CX Signal System because your baseline determines what every later decision can safely rely on.

Before a company asks AI to summarize customer feedback, predict churn, recommend actions, personalize service, or automate recovery, leaders need to answer a more basic question: which customer signals do we trust, who owns them, how are they classified, how is quality tested, and where do they change a decision?

Most companies do not have a signal system. They have listening posts.

They have surveys, call transcripts, chat logs, ticket reasons, complaint records, digital behavior, CRM notes, product usage, social reviews, operational metrics, and frontline observations. Plenty of data. Not enough evidence discipline.

The difference matters. Data is what the company has, collects, and hopefully curates. A signal is evidence that helps explain a customer condition, risk, need, friction point, or opportunity. A signal system is the operating architecture that determines what gets collected, how it is classified, how quality is governed, who owns it, and where it gets used.

Without that architecture, leaders confuse volume with intelligence. More signals do not automatically create better judgment. In many companies, more signals create more internal debate.

AI will make that problem more visible.

If the data is duplicated, stale, biased, unowned, or disconnected from decisions, AI can still produce a polished summary. That is the risk. The output may sound confident while the evidence underneath it is weak.

This is why the next phase starts with signal design, not AI use cases. A customer-led company has to know what evidence it will trust before it asks technology to act on that evidence.

Why companies get this wrong

The common mistake is treating customer signals as data exhaust instead of decision infrastructure.

Tool-first thinking is part of it. Leaders buy platforms before they define the evidence model. Survey bias is another part. Companies over-trust structured feedback because it is familiar, easy to trend, and easier to put in front of executives. Ownership gaps make it worse. Every system has an administrator, but no one owns the combined signal system.

Then AI impatience enters the room. Someone asks for summaries, themes, recommendations, or automated actions before the organization has decided what a good signal looks like.

That is how companies end up with AI sitting on top of messy evidence. The better question is not whether AI can summarize the data. The better question is whether the data deserves to influence a decision.

Diagnostic question: If your leadership team asked which three customer signals should shape next month‘s operating decisions, would everyone name the same signals, trust the same evidence, and know who owns the next action?

Read more

Most CX presentations are built to be defensible. Because of the audience, the numbers are checked, the trend line is explained, the customer comments are selected carefully, and the risks are softened just enough to avoid a fight, but not so much that the problem disappears.

Then the meeting happens. Leaders listen and many nod. Someone asks for one more cut of the data. Or someone else wants to know whether the issue is isolated to a region, segment, product, channel, or (clutch pearls) specific leader. The team agrees to come back with more detail. Everybody leaves feeling like the topic was taken seriously.

But nothing material changes. As a CX leader, you leave one more meeting frustrated, but you can cut the data again and take one more bite at the apple. Except schedules are too packed to allow for a follow-up.

That is the trap. The presentation did the wrong job really well. It made the issue understandable, but it did not force a decision.

A CX presentation is not valuable because it is polished. It is valuable when it changes ownership, funding, priority, policy, staffing, product work, service recovery, or operating pace. If none of those things change, the presentation may have created awareness, but it did not create management progress.

This matters because most companies already have enough evidence to act on at least some customer friction. They may not have perfect evidence. They may not have the final root cause. They may not have the cleanest model. But they usually know enough to identify where customers are struggling, where employees are compensating for broken work, and where the business is paying for delay.

The issue is not always the quality of the analysis. It is often the absence of a clear decision or ask of leaders to make one in the room. A strong CX presentation should tell leaders, early and plainly, what decision is required.

That sounds obvious, but it is not how many presentations are built. Many presentations still walk leaders through the story in the order the team discovered it. First the trend. Then the segmentation. Then the comments. Then the operational data. Then the possible causes. Then, if there is time left, the recommendation. Then, then, then…and by that point the room is tired, the debate has drifted to something else more pressing, and the decision becomes optional.

A decision presentation works differently. Slide one says what leaders are being asked to decide. The rest of the material earns the rest of the ask.

That one shift changes everything. First, it forces the presenter to separate evidence from interpretation. Then, it forces the team to show tradeoffs instead of hiding them. Finally, it forces leaders to say whether they have the authority, appetite, and confidence to make the call. It also makes delay very visible, and I don’t know anyone who loves that much daylight all at once.

Consider a recurring billing issue. Customers are calling after a language change. Employees are spending more time explaining the same policy. Credits are rising. Digital abandonment is higher in the same journey. A normal readout might show all of that clearly and still end with more analysis.

A better presentation would open with the decision: should we approve a rewrite of the billing language, issue temporary frontline recovery guidance, and review credit rules within ten business days? Then it would show the evidence, the cost of waiting, the tradeoffs, the decision owner, and how the team will know whether the decision worked.

That is a different meeting. It is not more dramatic. It is more useful.

AI can help prepare this kind of presentation, but it cannot fix a weak operation by itself. AI can summarize comments, detect themes, compare segments, draft a first version of the decision memo, and pressure-test whether the evidence supports the recommendation. That is all very useful and will be needed. But AI can also make a weak readout look more complete than it really is.

The question is not whether AI made the presentation faster; this is an easy answer. The harder question is whether the presentation made the decision clearer.

The standard from here on out is simple: a CX presentation should either secure a decision or name the exact evidence needed to make the next decision.

From here, paid subscribers get the working kit for that standard: 10 reusable assets that help a team turn a CX presentation into a decision ask, meeting agenda, decision tree, evidence check, owner record, latency tracker, leadership deck, and AI-assisted decision summary.

Read more

Closed-loop feedback (CLF) was onthe e of the ideas that helped customer experience become a real management discipline. At its best, it gave companies a simple rule: when customers tell you something important, the company owes them action, not just measurement.

That idea mattered. The old Bain inner-loop and outer-loop model helped companies separate immediate customer recovery from recurring issue management. The inner loop focused on the customer in front of you. The outer loop focused on the pattern behind the issue.

For a long time, that was a useful way to work. It helped teams follow up, create accountability, and move customer feedback out of the land of passive reporting. It gave leaders a way to ask whether the company actually did something after customers spoke.

But the model is about 25 years old now. That is a long time in operating-model years, and it is a lifetime in customer signal years.

The customer signal environment has changed completely. Companies still get surveys, tickets, complaints, and account feedback, but those are now only a fraction of the picture. Customer signals show up in usage patterns, onboarding friction, support transcripts, renewal risk, sales objections, billing disputes, product workarounds, AI bot failures, community comments, digital behavior, financial reviews, and model performance.

The old inner-loop and outer-loop model was not built for that world. It was built around a simpler view of feedback, where the main questions were whether the customer needed follow-up and whether the issue showed up often enough to fix at the root. Those questions still matter, but they do not cover the job anymore.

A customer signal today can point to several different actions. Sometimes the customer needs immediate recovery. Sometimes the company needs to remove a repeated defect. Sometimes sales, marketing, success, service, or product education needs to change the next action. Sometimes the signal needs to be written back into a model, playbook, forecast, or executive review so the business gets smarter.

That is the gap I built this week’s framework to close.

I call it the Four-Loop Customer Signal Operating Model. The four loops are Recovery, Removal, Orchestration, and Learning. Each loop has a different purpose, owner, cadence, and value measure.

The core belief behind the model is simple: a customer signal should become a decision input. When that does not happen, the company may still look busy, but the signal loses its force.

That is where a lot of closed-loop programs lose the plot. A customer says something important, the company logs it, someone follows up, a case gets closed, and a dashboard shows activity. Everyone can point to movement, yet nobody can clearly explain what changed inside the business because the customer signal existed.

That is the moment where closed-loop feedback starts looking older than it feels.

The limits of the inner-loop and outer-loop model

The original model solved a real problem. It gave companies a way to stop treating feedback as a research artifact and start treating it as something that required action. That was a good move for the field, and it deserves credit.

The inner loop gave frontline and account teams a path to respond to the customer. The outer loop gave leaders a way to find repeated issues and move them beyond the team that heard the complaint. In a world dominated by survey comments, relationship programs, call center issues, and service tickets, that structure made sense.

The limitation shows up when modern customer signals do more than describe a service issue or recurring defect. A customer’s usage pattern can reveal confusion before the customer complains. A sales objection can reveal that the company’s value story does not match how buyers make decisions. A renewal conversation can reveal that the customer never received the outcome they thought they were buying.

An AI bot failure can reveal a design issue, a routing issue, a training-data issue, a knowledge-base issue, and a trust issue in the same moment. A billing dispute can reveal unclear language, weak onboarding, poor handoffs, and preventable cost to serve. A high-value account escalation can reveal that the company has no clean path for decisions that cut across product, legal, risk, finance, and customer success.

The old model pushes too much of this work into two broad lanes. That creates a management problem because the company can look responsive while still missing the decision that should change.

In the AI era, signal volume is not the scarce resource. Decision quality is. Most companies already have more customer signals than they can process well. The advantage now goes to the companies that can classify the signal correctly, assign the right owner, make the decision, and write the learning back into how the business operates.

That is the work the four-loop model is built to do.

The Four-Loop Customer Signal Operating Model

The model has four loops: Recovery, Removal, Orchestration, and Learning.

Recovery makes it right for the customer affected now. Removal eliminates the recurring defect so the company stops creating the same pain. Orchestration turns the signal into a better next action across sales, marketing, service, success, or product education. Learning writes the outcome back into models, playbooks, forecasts, and leadership reviews so the business improves.

The loops are connected, but they should not collapse into one another. A signal can belong in more than one loop, and often it will. A customer may need recovery while the company also removes a repeated defect, changes the next action, and updates a model or playbook.

That is why classification matters. The point is not to create a heavier process. The point is to stop forcing different types of customer signals through the same narrow path.

When every signal becomes a ticket, ticket logic wins. When every signal becomes a dashboard item, reporting logic wins. When every signal becomes a product backlog request, product prioritization logic wins. The customer signal loses its original shape, and the company starts managing the record instead of the business decision.

The four-loop model keeps the signal tied to the decision it should influence.

Loop 1: Recovery

Recovery is the loop most leaders already understand, but many teams still execute it poorly. A customer is blocked, confused, frustrated, or losing trust, and someone needs to own the moment with clarity.

Good recovery has a few practical requirements. The customer needs to know who owns the next step, what will happen next, when they will hear back, and what the company can honestly commit to. The customer should not have to repeat information the business already has, reconcile conflicting answers from different teams, or chase the company for progress.

Recovery also requires plain language. Customers do not need vague empathy followed by a foggy process. They need someone to name the issue, reduce the effort, explain the path, and tell the truth about constraints.

This matters even more when AI is involved. If a bot wastes the customer’s time, the company should not treat that as a routine support miss. The customer needs a human path, and the business needs to capture where the automated path failed.

The strongest recovery teams do something else well: they preserve the signal. They capture the root cause clue before it disappears into the closed case. They record the customer impact, the value at risk, the owner needed, and the possible loop assignment beyond Recovery.

Recovery protects value. It protects revenue, trust, time, margin, and relationship health. But recovery alone leaves the company vulnerable to repeated pain if the signal does not move into the right next loop.

Loop 2: Removal

Removal is where companies stop paying the tax of repeated defects. This is the loop for customer pain that keeps showing up across customers, segments, channels, teams, products, or workflows.

Many organizations confuse responsiveness with improvement. They answer the same billing question quickly and call that good service. They reopen the same support issue and call that persistence. They document the same workaround and call that enablement.

That kind of behavior creates a quiet form of waste. The customer spends more effort than they should, employees spend time compensating for preventable friction, and leaders review activity instead of value leakage.

Removal changes the conversation. If a signal repeats, the business needs to decide whether the issue is a fixable defect, who owns it, what prevention measure will be taken, and how the company will prove the issue was reduced.

This is where the customer conversation becomes a business conversation. A repeated support ticket reopening has cost-to-serve implications. Billing confusion has trust and retention implications. Product workaround fatigue has adoption and margin implications. Security documentation delays can create deal risk, legal review drag, and executive escalation.

Removal should have value attached. That does not mean creating fake precision or pretending every customer issue can be reduced to a perfect dollar amount. It means building a credible view of cost, risk, leakage, drag, or opportunity so leaders know why the issue matters.

The best Removal work moves recurring pain into an owned defect path with business evidence. It also avoids the trap of pretending every defect deserves immediate investment. Some issues should be fixed now, some should be sequenced into a planning cycle, and some should be rejected with a clear reason.

The key is that someone with authority makes the call. Without authority, Removal becomes another list.

Loop 3: Orchestration

Orchestration is the loop that turns customer signals into better next actions. This is where the older closed-loop model feels most dated because customer signals often point to growth, retention, adoption, and timing decisions that sit far outside classic service recovery.

A customer who praises an outcome and asks about a broader use case is giving the company a possible expansion signal. A financial buyer who challenges value is giving the company a signal about proof, language, and decision criteria. A product usage drop after onboarding may tell success or marketing to change the next touch, the education path, or the intervention timing.

A renewal objection can come from a weak value review, a missed onboarding promise, low adoption, poor executive alignment, or a product gap that was visible months earlier. Treating that as a late-stage renewal issue wastes the signal.

Orchestration asks what should happen next because of what the customer is showing or saying. The next action may involve a message, offer, timing change, account intervention, education path, sales motion, lifecycle campaign, or success playbook.

This is one of the most practical places for AI, provided the boundaries are clear. AI can spot patterns, suggest next-best actions, draft outreach, summarize account context, and prepare the handoff. That help can save time and reduce blind spots.

The business still needs human judgment. Someone has to decide what evidence is strong enough, who can change the action, which segments require review, what promises are allowed, and how the outcome will be measured.

Orchestration creates value when it changes behavior before the customer problem becomes larger. It gives the company a way to act earlier, with better context, and with a clearer view of what the signal implies.

Loop 4: Learning

Learning is the loop that keeps the work from resetting every month. This is where many customer programs fall apart because the action may happen, but the lesson does not land anywhere durable.

A case gets resolved, a defect gets discussed, a playbook gets tweaked, or a customer message gets improved. Then the company moves on. A few weeks later, the same issue returns, the same executive question gets asked, and the same teams debate the same point because the learning never became part of the operating system.

Learning asks where the outcome should live. If a signal predicted churn, adoption drag, expansion, cost, or conversion, the model should learn from it. If a playbook worked, the next team should not have to rediscover it. If an AI recommendation failed, the instructions, data, or review path should improve. If a customer promise no longer matches operating reality, leadership needs to see that clearly.

Learning belongs in model features, evaluation sets, playbooks, forecasts, dashboards, business reviews, planning discussions, and decision records. A recap alone is too fragile. People change roles, memories fade, meetings move on, and the same issue returns with a different label.

This loop is where customer-led work starts to compound. Recovery handles the moment, Removal reduces recurrence, Orchestration improves the next action, and Learning makes the next decision better.

Without Learning, the company works hard and still gets dumber than it should.

Ownership has to move closer to the decision

One of the reasons CX teams get trapped is that every customer signal gets pulled back into CX. The business says customers matter, yet the customer team ends up owning the follow-up, analysis, escalation, reporting, prioritization, and sometimes even the fix.

That arrangement weakens the work. CX should provide the signal architecture, the customer lens, the value lens, and the review method. The business should own the actions that sit inside its authority.

Service and Customer Success will often own Recovery. Product, Engineering, Operations, or the accountable business function will often own Removal. Sales, Marketing, Success, Service, or product education teams will often own Orchestration. Data, Finance, Enablement, and executive teams will often own Learning.

Legal and Risk need a defined role as well. They set boundaries where customer commitments, policy exceptions, privacy, security, regulatory exposure, or brand risk appear.

AI also needs an explicit role. It can classify, summarize, draft, route, monitor, compare, and prepare. Humans decide tradeoffs, exceptions, commitments, priorities, and boundaries.

That division of labor matters because closed-loop programs often hide weak ownership. A signal moves from one place to another, a field gets updated, an alert gets closed, and the customer dashboard looks cleaner. The actual decision remains unclear.

Escalation should mean controlled movement to the owner, who can change the outcome. A forwarded note or transferred ticket does not meet that standard.

The metric problem

Closed-loop programs tend to love closure because closure is easy to count. Closed cases, closed tickets, closed alerts, closed escalations, and closed follow-ups give leaders numbers they can review.

Those numbers have a place, but they should stay in the hygiene category. A closed record can still leave the customer frustrated. A closed ticket can leave the defect intact. A closed escalation can leave the decision unresolved. A closed feedback item can leave the business with no real learning.

The four-loop model shifts measurement toward value.

Recovery looks at value protected, such as revenue, margin, trust, time, or relationship health preserved through action. Removal looks at value leakage reduced through lower recurrence, less rework, fewer contacts, lower cost to serve, better adoption, or reduced risk. Orchestration looks at value created through better timing, message, offer, conversion, adoption, expansion, retention, or advocacy. Learning looks at value learned through improved models, playbooks, forecasts, reviews, and decisions.

That value lens changes the conversation with senior leaders. Feedback language can sound soft when it is disconnected from business outcomes. Value language gives customer signals a stronger seat in operating discussions.

This is especially important now because AI will make signal volume explode. Companies will summarize more, classify more, and route more. The work will look smarter on the surface, but the business benefit will depend on whether the signal changes a decision.

A practical example

Consider a customer who reopens a support ticket after a bot or agent said the issue was resolved. Many companies would treat that as a service recovery issue, maybe with a root-cause tag if the problem happens often enough.

The four-loop model gives the team a better operating view. In Recovery, the customer needs a clear owner, a useful answer, and a commitment that the case will remain open until the outcome is clear from the customer’s side. In Removal, the team looks for recurring causes such as poor knowledge content, weak routing, product confusion, bad resolution criteria, or agent guidance that pushes the issue closed too early.

In Orchestration, the company asks whether this customer or segment needs a different next action. High-value accounts may need a human path sooner. Certain issue types may require faster handoff. Some customers may need education or proactive guidance instead of another support interaction.

In Learning, the company updates the knowledge base, QA logic, AI instructions, monitoring questions, and review process. The goal is to learn where the automated path failed and what evidence should trigger a different route next time.

The signal becomes more useful because the company stops treating it as one issue. It becomes a recovery moment, a defect clue, an action trigger, and a learning input.

That is how customer signals should work.

Where AI belongs

AI can make this model run faster, but only if the company knows what kind of help it wants. A vague AI strategy around customer signals will create more output before it creates better decisions.

Useful AI work includes transcript summaries, signal classification, pattern detection, customer response drafts, escalation packets, value hypotheses, meeting prep, defect stories, playbook updates, review narratives, and learning briefs. Those tasks can reduce manual effort and help teams work with larger volumes of signals.

The boundaries matter. AI should not make legal, pricing, contractual, product, compensation, security, or high-impact customer commitments on its own. It should not quietly change model behavior for sensitive workflows without review. It should not turn a thin signal into a confident recommendation without naming uncertainty.

A practical rule helps here: AI prepares; humans decide. AI can help the company see, sort, summarize, and suggest. Humans own the commitment, exception, investment, policy, and priority.

That rule keeps AI useful without letting it become a way to avoid ownership.

How to start in 30 days

This model should begin with one signal category, not a company-wide transformation plan. Big transformation language slows the work down and invites too much debate before the team has proof.

Pick one recurring signal category. Good starting points include onboarding delay, billing confusion, repeated support ticket reopening, product workaround fatigue, renewal objection, security documentation delay, or AI bot failure.

Pull 25 to 50 recent examples. Include the source, date, customer segment, current status, value estimate if available, and a few verbatims in the customer’s own language. The customer language matters because sanitized summaries can remove the detail that makes the signal useful.

Bring the right people together for one working session. The room should include an executive sponsor, CX lead, Service or Success owner, Product or Engineering owner, Sales or Marketing owner, Data or Finance owner, and Legal or Risk partner if the signal touches regulated topics, customer commitments, policy, privacy, or security.

The session should produce decisions, not general agreement. The team should classify the signal into primary and secondary loops, name the business owner for each loop, estimate the value at risk, choose one action that can happen within two weeks, and define the evidence that will prove progress.

After the session, run a simple cadence. Weekly intake captures and classifies signals. A bi-weekly value standup resolves ownership and removes blockers. A monthly Finance and Executive review looks at value protected, value removed, value created, and value learned. A quarterly reset cuts dead fields, updates escalation criteria, refreshes AI boundaries, and adjusts ownership where the business has changed.

The operating rule is simple: keep the work that improves decisions and cut the work that only creates activity. If a field, meeting, report, tag, or dashboard does not help the team classify, assign, act, measure, or learn, it should earn its place or disappear.

The new standard for customer-led work

Customer-led companies will need a stronger standard than closed-loop completion. They will need to show how customer signals changed the way the business made decisions.

The question set becomes more concrete. Did the company recover the customer with less effort and clearer ownership? Did it remove the repeated defect or make an explicit decision about why it will not? Did it change the next action across sales, marketing, service, success, or product education? Did it write the learning back into a model, playbook, forecast, dashboard, review, or executive decision record?

This is the future of customer signal work. The companies that get good at it will not simply listen better; they will decide better. That is a meaningful difference.

Closed-loop feedback helped the field mature, and the old inner-loop and outer-loop model deserves credit for that. Now the signal environment is bigger, faster, and more complex than the model was built to handle.

The next stage requires a stronger operating model. Customer signals need owners, value logic, AI boundaries, and a clear path into business decisions.

That is what the Four-Loop Customer Signal Operating Model is designed to provide.

Subscribe now

Read more

That’s where a lot of customer work gets stuck. The company finds a theme, shares the theme, discusses the theme, assigns a broad owner to the theme, and then waits for a vague sense of improvement to show up later. Sometimes a fix happens. Sometimes a workaround gets dressed up as a fix. Sometimes the issue quietly returns in next quarter’s readout with slightly different language and the same root problem.

This is why “insight” has become too easy a finish line.

An insight is not the work. It’s the start of the work. The real test is whether the organization can take a customer signal, identify the behavior that needs to change, connect that behavior to a business outcome, assign a real owner, and review proof that something actually moved. That’s the difference between a customer listening program and a customer-led operating model.

This week’s AI, Not KPI is about that difference. It’s about moving from feedback to action without losing the thread between what customers say, what customers do, what employees absorb, and what the business gets back. Because the next level of customer work is not more reporting. It’s cleaner management.

The customer data pile keeps getting bigger

I’ve seen this pattern in companies of every size. The customer team has more data than ever, but the action system hasn’t matured at the same pace. Dashboards multiply. Metrics multiply. Survey programs expand. Speech analytics gets added. Digital analytics gets added. AI summarization gets added. And then leaders assume that because the company can now see more, it must be better at acting. That assumption is also dangerous.

Seeing more can help, but it can also create new confusion. When every team brings its own metric to the table, leaders end up debating what the issue is instead of deciding what the company should do. The contact center sees repeat calls. Digital sees retry behavior. Product sees adoption gaps. Finance sees credits or concessions. Employees see escalations and manual cleanup. Customers see a company that still hasn’t fixed the problem. None of those teams are wrong, and that’s the problem.

The issue is not a lack of evidence. The issue is that the evidence has not been organized into an action model. Without that model, signals overlap, accountability blurs, and the business starts mistaking motion for progress.

A customer-led company can’t afford that. It has to know which signal is the primary trigger, which behavior needs to change first, which business outcome matters most, and who owns the response. Anything less creates a beautiful reporting system with weak operating discipline.

The first move is separating the signals

The work starts by separating input metrics into distinct families. This sounds basic, but it’s one of the most important moves a team can make. If the signal inventory is messy, every decision that follows gets messy too.

I use five input metric families for this work.

Stated feedback captures what customers explicitly say. That includes complaint themes, survey comments, verbatim severity, trust language, and relationship confidence. This is the familiar territory for most customer teams, and it’s still valuable. But it’s only one part of the picture.

Customer behavior captures what customers actually do. That includes task abandonment, repeat logins, missed activation steps, delayed funding, retry behavior, and other observable signals that show customer friction without requiring the customer to explain it. This is where many companies still underinvest, even though behavior often tells the clearer story.

Operational execution captures where the business creates drag. Repeat contacts, cycle-time spikes, backlog growth, manual workarounds, and handoff failures sit here. These metrics are critical because they show where the company is forcing customers and employees to absorb avoidable friction.

Financial or risk exposure captures where the issue is already costing money or creating avoidable exposure. Credits, fee reversals, fraud exceptions, renewal downgrades, margin erosion, and compliance risk belong here. These metrics matter because they translate customer friction into language executives already understand.

Employee or culture strain captures the internal burden. Escalation frequency, coaching burden, knowledge bypass, cleanup work, and burnout hotspots all tell the company where employees are compensating for weak systems. This matters because customer problems rarely stay outside the company. They show up inside the work.

The discipline is to give each signal one primary home for action design, even when it influences other areas. That’s the part teams often resist. They want to say everything is connected, and they’re right. But connection is not the same as ownership. A signal can have relationships across the business and still need one primary home for action.

Take billing confusion. A complaint about an invoice belongs first in stated feedback. Repeat contacts about the same invoice belong first in operational execution. Multiple portal logins to check the same invoice belong first in customer behavior. Credits and fee reversals belong first in financial or risk exposure. Frontline escalations about the invoice belong first in employee or culture strain.

That separation keeps the team from throwing every metric into one pile and calling it an initiative.

The behavior bridge is where the work gets done

Once the primary signal is clear, the next question is not “what should we do?” That’s where teams often jump too fast. The better question is, “What customer or employee behavior should change if the action works?”

That question changes the conversation immediately.

If repeat contacts are up, the goal is not simply to reduce repeat contacts. The goal may be that customers understand the invoice without calling. If onboarding milestones are slipping, the goal may be that clients complete setup faster with fewer status-check requests. If complaints are reopening, the goal may be that customers don’t have to come back with the same unresolved issue. If advisor escalations are rising, the goal may be that frontline teams can resolve more cases without pushing work to senior employees.

This is the behavior bridge. It connects the input metric to the business outcome by forcing the team to name what must change in the real world.

I think this is where many customer programs lose executive confidence. They can describe the issue. They can show the trend. They can quote the customer. They can even recommend a fix. But they can’t always say, in plain English, what behavior should change and why that behavior matters to the business.

Without a behavior bridge, the company reacts to symptoms. It retrains employees because complaints rose. It rewrites content because customers seem confused. It redesigns a screen because abandonment is high. It adds status updates because cycle time is slow. Some of those moves may be useful, but they’re guesses unless they’re tied to a clear behavior change.

The standard should be higher. Before an action gets approved, the team should be able to finish this sentence: “If this works, customers or employees will do this differently.” This one sentence can save months of wasted activity.

One behavior, one primary outcome

After the behavior is named, the team has to connect it to a primary business outcome. This is another place where customer work gets diluted. Teams try to make every action matter to every outcome. Growth, retention, efficiency, trust, risk, employee engagement, brand strength, and loyalty all get bundled together because the team wants the work to feel important.

A stronger action model forces one primary outcome for each priority issue. The outcome might be growth, efficiency, churn, risk, trust, or culture. Secondary outcomes can still be named, but the primary outcome tells the leadership team why the work matters now.

Billing confusion may be primarily an efficiency issue if it’s creating avoidable contacts and extra handling. Onboarding delays may be primarily a growth issue if clients are slow to fund or activate. Recovery loops may be primarily a risk issue if unresolved complaints lead to concessions, regulatory exposure, or executive escalations. Escalation burden may be primarily a culture issue if managers and frontline teams are absorbing friction the system should have removed.

This is how customer work becomes commercially serious without becoming cold or robotic. The customer still gets a better interaction. Employees still get less friction. The business gets a result it can see.

Customer work doesn’t gain credibility by sounding more emotional in executive rooms. It gains power by making a clear connection between customer behavior and business value.

Ownership has to be real, not ceremonial

There is a version of ownership that looks good on a slide and does almost nothing in practice. It usually sounds like “this is jointly owned by service, product, operations, finance, digital, and communications.” Translation: everyone agrees the issue matters, and nobody has the authority to make the full decision; that’s how customer issues survive.

The problem is not that multiple teams are involved. Most meaningful customer problems are cross-functional by nature. The problem is that cross-functional involvement often gets confused with ownership. A real action model has one accountable owner, one action path, and one proof set.

The owner doesn’t have to do all the work personally. They do have to own the decision path. They have to know which teams are required, what decision is needed, what tradeoff has to be made, and what proof will show whether the action worked.

For example, if the recurring issue is billing confusion after an invoice-format change, the owner may be the Head of Billing Operations. Support teams may include Product, Finance, and Service. The named decision may be to approve an invoice explanation rewrite and support-script change. The behavior proof may be a reduction in invoice-related contact volume. The outcome proof may be lower credits and dispute volume.

That is a very different conversation from “billing confusion is a cross-functional opportunity.”

A customer-led action system has to be honest about decision rights. If nobody can change the policy, rewrite the message, adjust the workflow, alter the product step, or fund the fix, then the issue is not ready for action. It’s ready for escalation.

Proof has to be designed before the fix goes live

Most teams define proof too late. They launch the action, run the campaign, change the workflow, update the script, redesign the page, or brief the field. Then a few weeks later, somebody asks whether it worked. That is backwards!

Proof should be designed before the action starts. The team needs to know which leading metrics should move quickly and which lagging business outcomes should follow later if the behavior change is real.

Leading proof is the fast signal. It tells the team whether the action is starting to change behavior. Lagging proof is the business validation. It tells the team whether the behavior change created the business result the company expected. The distinction matters because customer work runs on different clocks.

If the issue is Not In Good Order (NIGO) documentation in wealth management onboarding, the leading proof may be a lower NIGO rate. The lagging proof may be lower rework cost, faster days-to-funding, and better early asset capture. If the issue is billing confusion, the leading proof may be fewer invoice-related repeat contacts. The lagging proof may be lower credits, fewer disputes, and fewer renewal-risk flags. If the issue is onboarding delay, the leading proof may be shorter milestone slippage. The lagging proof may be faster activation, more funded accounts, or lower early fallout.

If the team only watches lagging outcomes, it waits too long to adjust. If it only watches leading indicators, it declares victory too early. You really need both.

This is especially important in an AI-enabled world. AI can help teams sort signals, draft summaries, build scenario logic, pressure-test assumptions, and generate executive readouts. It can speed up the thinking. It can reduce the blank-page problem. It can make it easier to test the logic before leaders get in the room.

But AI does not remove the need for management judgment. It does not decide which proof matters. It does not own the tradeoff. It does not make the organization act. This is still leadership’s job.

The leadership test

For this week’s model, I keep coming back to four questions. They are simple, but they expose weak customer systems very quickly.

Which distinct input metric says this is real? Not three overlapping metrics. Not a theme people feel strongly about. Not a quote that creates urgency by itself. Which metric is the primary trigger for action?

What customer behavior should change first? Should customers call less, retry less, complete faster, activate earlier, fund sooner, reopen fewer complaints, trust the answer, or stop needing a workaround?

Which business outcome should move if the team is right? Growth, efficiency, churn, risk, trust, or culture should be named clearly. If the team can’t name the outcome, it isn’t ready for executive sponsorship.

Who owns the response and what will prove it worked? This is where the work either becomes real or stays in the land of good intent. One accountable owner, one action path, one behavior proof set, and one outcome proof set.

These questions are not complicated. That’s why they’re useful. They leave very little room for the kind of vague customer work that sounds impressive and changes very little.

What paid subscribers receive this week

Paid subscribers receive the practical Week 6 tools behind the newsletter. That includes every document in the package except the ones marked Founding Member in the title.

The paid package includes the Week 6 Model Guide, the Week 6 Action Workbook, the Week 6 Prompt and Example Pack, and the Week 6 Insight-to-Action Deck. These are built to help teams move from signal to behavior change to business value without starting from a blank page.

Use the Model Guide first. It explains the purpose of each asset and the sequence of the work. It’s designed for CX, service, digital, analytics, operations, and wealth-management leaders who want a working model, not another generic worksheet. The best way to use it is as the agenda for the first working session with your executive sponsor, analytics lead, and action owners.

Use the Action Workbook as the working file. Start with the Input Metric Inventory to list the signals the business already has. Then use the Behavior-to-Outcome Bridge to connect priority metrics to target behavior changes and business outcomes. After that, use the Action Mapping Template to name the decision, owner, support teams, due date, proof metrics, and escalation path. Then use Action Prioritization to decide what moves now versus later, and the 30-Day Planner to run the first month of execution.

Use the Prompt and Example Pack to accelerate the work with AI. The prompts help build the metric library, create the behavior bridge, draft value assumptions, pressure-test the confidence layer, draft the executive readout, and build the operating cadence. My advice is to use the prompts in rounds. First for speed, second for precision, and third for executive clarity.

Use the Insight-to-Action Deck for the leadership conversation. The workbook handles the detail. The deck explains the logic. It helps leaders see the difference between weak systems that react to themes and strong systems that identify distinct input metrics, name behavior changes, tie those behaviors to outcomes, assign accountable action paths, and review proof instead of activity.

The paid package matters because this is where many teams lose momentum. They understand the idea, but they don’t have a clean structure for putting it into practice. These tools give the team a starting point, a working model, and a leadership story.

Read more

Read more

Week 5: The free section makes the case that most listening failures are governance failures. Paid subscribers get the charter, matrix, map, agenda, planner, stakeholder kit, and prompt pack to turn listening into a decision rhythm.

The meeting usually looks competent on the surface. CX brings survey themes, Service brings complaint counts, Digital brings drop-off data, and Product brings backlog items. After it’s all reviewed, someone says the customer pain point to resolve is clear, “So let’s get this fixed!” and everyone leaves with the same problem they walked in with: no single owner, no escalation, and no decision that turns it all into action.

Your governance is the single-most important aspect of your strategy when it comes to delivering on customer experience improvements. The issue is pretty common in my opinion; companies struggle to hear customers because signals live in different teams, different systems, different objectives, and different incentives. The result is a business that keeps collecting signals, even integrating them into a single platform, without becoming materially better at acting on them.

Why does this matter now?

AI raises the stakes. When you add summarization, text analytics, or predictive models to a weak CX program, the business can produce pretty reports without making clear decisions. It doesn’t govern itself. So if the operating model is squishy, AI can only make it look more polished than it really is.

Why companies get this wrong

Most companies still treat listening as a collection exercise owned by one team instead of an operating discipline shared across functions. You may see this at your own company:

1. CX owns surveys.

2. Service owns complaints.

3. Digital owns behavior data.

4. Product owns backlog themes.

5. Analytics owns dashboards.

Since no one owns the chain from signal to decision, governance gets framed as bureaucracy. As a result, leaders keep the process loose and hope collaboration will fill the gap. But does it really?

The deeper problem to solve for is incentive design. Teams are rewarded for managing their own queue (some even covering their own ass), their own score, or their own delivery risk. Very few are rewarded for protecting the customer signal across handoffs. So the signal gets diluted, duplicated, or disputed before it gets translated into action.

Three failures that make companies bad listeners

First, there is no agreed ownership model. The same issue shows up in comments, call logs, digital behavior, and service escalation notes, but the business has not assigned one accountable owner for pulling those pieces together. This falls on the CX team in most companies, but again, who is the owner?

Second, naming someone with clear decision authority around a topic doesn’t happen. Teams can discuss an issue for weeks without clarity on who can change policy, reprioritize work, or escalate funding. They’ll argue that “no single person” owns it, but that’s a copout. At some point in your hierarchy, there is a single owner.

Third, governance forums are built for updates and readouts, not decisions. Leaders get recaps, not threshold-based choices. The room hears the issue, but the business never changes the way work gets done. This always reminds me of the famous John Stumpf quote: “By the time news gets to me, they can make motor oil taste like pizza.”

A free diagnostic worth using this week

Pick one recurring customer problem and trace it across your company. Where does it first appear? Who owns the raw signal? Who decides whether it is material? Who has authority to assign work? How long does it take before the issue lands with someone who can actually change the customer outcome? If you cannot answer those questions in one 30-minute conversation, you have signal debt.

For paid subscribers, I built the working tools for this: a governance charter, data ownership matrix, decision rights map, monthly governance agenda, 30-day application planner, stakeholder language, and prompt pack that help a leadership team turn listening into an operating rhythm.

Read more

This week’s issue is about that mistake and builds on last week’s issue. If Week 3 was 3a, think of this week’s newsletter as 3b before we move on to the next important topic, governance. Customer outcomes have to come before metrics. If they do not, the metric becomes the product. Teams start optimizing response rates, case close times, call handle times, channel containment, and score movement without being clear on the customer result those numbers are supposed to support. The business looks more measured while the customer still has to ask the same question twice, repeat the same information, or guess what happens next.

I have seen this pattern in a lot of different forms. A company wants to improve onboarding, but the conversation quickly turns into adoption rate, complaint volume, and satisfaction movement. Those indicators matter. The problem is that none of them answer the first operating question: What outcome should the customer reliably get from onboarding in the first place? Until the room agrees on that, the metric stack is mostly a collection of proxies fighting for attention.

That matters even more in an AI-forward model. AI can summarize comments, detect patterns, flag risk, and surface anomalies at a speed that old reporting models never could. But faster analysis does not rescue a weak definition of success. If the outcome is fuzzy, AI simply helps you optimize faster around the wrong thing. You get better instrumentation around internal activity instead of better control over customer progress.

The issue is not that companies lack data. Most have too much of it. The issue is that the measurement system often gets built from what is easy to count, what the dashboard already supports, or what a function already owns. The customer outcome shows up later as a narrative layer. That order is backwards.

At BNY, one of the most useful lessons from building client health scores was that signal integration only matters when the business knows what healthy client progress actually looks like. Financial, service, operational, and sentiment signals can tell you a lot, but only if the underlying outcome is defined well enough for leaders to act on it. Otherwise, the score becomes another executive object to inspect rather than a decision tool.

The same thing is true in transformation work. Bill’s resume notes a metrics linkage framework built for a regional health insurer to connect customer and workforce drivers to business outcomes. That is the right direction of travel. The work starts with the outcome, then the behaviors, then the decisions, and only then the metrics. Not the other way around.

Why do companies get this wrong? Usually because the organization is organized around functions before it is organized around customer progress and the journey they’re going through every day with your company. Operations brings efficiency metrics. Digital brings funnel metrics. Service brings speed and resolution metrics. CX brings survey metrics. Finance asks for a proof point. Everybody shows up with something countable, but very few teams stop long enough to write one plain-English outcome statement that the customer would recognize.

There is also a governance problem hiding inside the metric problem. Dashboards are easy to circulate. Outcome debates are slower and more uncomfortable. They force leaders to confront tradeoffs, unclear ownership, and process design flaws. It is much easier to say a metric moved by three points than to admit the business still cannot deliver a predictable onboarding path or a clean billing explanation.

A simple diagnostic question helps. If you removed every metric from the slide, could the team still describe the exact customer result they are trying to produce in one sentence? If the answer is no, the measurement system is leading the operating model instead of supporting it.

That is the line between reporting and management. Reporting tells the room what happened. Management defines the outcome, names the behaviors that create it, and uses metrics as evidence in service of a decision. Customer-led teams know the difference.

For paid subscribers, I built the working kit for this: the outcome canvas, metric map, cleanup checklist, behavior worksheet, two meeting decks, the review agenda, and the prompt pack that helps you turn this into a leadership review or working session this week.

Subscribe now

Read more

That silence is not a data problem. It is a signal problem.

Most companies do not need another listening post. They need the discipline to map the signals they already have, decide which ones matter, and connect those signals to decisions that change work, cost, risk, retention, or trust. Surveys still matter. They just should not be treated like the system of record for your customers’ reality.

This is where too many CX programs get stuck. They say they want a 360-degree view of the customer, but they have never done the basic work of identifying every meaningful customer signal already sitting inside the business. They have survey comments in one tool, complaint codes in another, chat transcripts in a third, digital abandonment data somewhere else, billing exceptions in a finance report, renewal downgrades inside an account file, and employee escalation themes trapped in manager conversations that never make it into a formal system. Then they wonder why their dashboards explain too little, and typically too late.

I think this is one of the most underappreciated operating failures in CX. We talk a lot about AI models, automation, text analytics, and prediction. These are all very important, but if you do not know what evidence exists, how trustworthy it is, who owns it, how often it updates, data definitions, and what decisions the data should influence, you are not building an AI-forward CX capability. Instead, you’re layering software on top of partial evidence and hoping the output sounds smarter than the input.

That is why this week’s issue matters. Before you can automate action, rank risk, or build a credible management rhythm around customer outcomes, you need a real map of the signal landscape. Not the survey landscape. Not the dashboard landscape. The signal landscape.

The distinction matters because signals are not all doing the same job. A complaint tells you that a customer had enough pain to say something out loud. A failed login sequence tells you that friction happened whether the customer reported it or not. A delayed onboarding step tells you a promise is breaking inside the operation. A downgrade at renewal tells you the commercial consequence showed up. An employee escalation tells you the frontline saw the issue before leadership did. These are all customer signals. They just carry different kinds of evidence.

The companies that get better at this stop treating customer evidence as a stack of unrelated reports, and start treating it as a management system. They know which signals are stated feedback, which are behavioral, which are operational, which are employee-raised, which are financial, which are risk signals, and which are recovery signals. I get it, it doesn’t sound glamorous. But this is exactly what turns messy listening into usable judgment.

This is also where a lot of survey-heavy programs lose credibility. The survey is often the cleanest artifact in the room, so it becomes the default language of truth. It has scores, trends, comments, response rates, and nice visuals. The messier signals are harder to standardize, so they get demoted even when they say more. A dropped application, a service retry, a missed implementation milestone, or a wave of fee reversals can tell you more about customer reality than a quarterly average ever will. But those signals usually belong to different teams, sit inside different systems, and come with more accountability attached. That is why they are easier to ignore.

Companies get this wrong for three reasons. First, silos make signal mapping feel like somebody else’s work. CX owns surveys. Digital owns behavior. Operations owns service data. Finance owns commercial outcomes. HR or EX owns employee listening. Nobody owns the full picture. Second, survey programs feel politically safer because they talk about customer sentiment without forcing a hard conversation about process failure, product gaps, channel friction, or leadership tradeoffs. Third, teams confuse available data with usable data. Just because a field exists does not mean it is fresh, trusted, linked, accessible, or good enough to drive action.

One of the clearest examples from my own work came when teams stopped treating survey feedback as the primary story and started placing service, operational, financial, and relationship signals next to it. At BNY, we built client health scores that integrated financial, operational, service, and sentiment inputs because no single signal was strong enough on its own. At JPMorgan, weekly executive forums worked because the conversation was not limited to a single score. The value came from connecting customer evidence to operating choices and then governing action. That is the difference. The signal only matters if it changes what the business does next.

The same lesson shows up in less glamorous situations. Imagine an onboarding team with a stable satisfaction score. Leadership feels calm. Then you look underneath and see activation delays rising, repeat contacts climbing, manual workarounds increasing, and account teams quietly escalating client frustration. The survey is not necessarily wrong. It is just incomplete. It is describing one slice of reality while the operation is shouting through other channels. If you are only listening to the cleanest signal, you are giving the messier truth permission to hide.

That is why silent signals matter so much. Silent signals are the evidence customers leave behind when they do not fill out your survey, write a review, or call to complain. They abandon a task. They retry the same action. They miss an implementation step. They stop using a feature. They downgrade at renewal. They generate repeat contacts around the same issue. They ignore your outreach after a failure. Silent signals are often where the real commercial risk sits because they capture behavior, not just declared sentiment. Think of it all like digital, operational, and financial exhaust.

Now, if you’re a free reader, you do not need a giant framework to act on this. You need to ask, ‘What evidence of customer friction, customer effort, customer value, and customer risk already exists across the business, and which of those signals are actually used to make decisions?’ That question gets you much closer to the truth.

For paid subscribers reading this week’s newsletter, I built the working tools for this: a signal-mapping workbench, a prioritization matrix, a silent signal finder, an executive readiness scorecard, a 30-day sprint plan, and a board-ready summary slide.

Subscribe now

Read more

The framework in one view

The logic below is the anchor for the article: operational metrics connect to customer signals, customer behaviors, and business outcomes. The measurement system must work top-down for executives and bottom-up for teams close to the work.

Figure 1. Measurement chain from operating reality to customer behavior to business impact.

Contents

1. The metric problem sitting in plain sight

2. Why NPS should not be the north star

3. The better question: what customer behavior proves value?

4. The four-layer measurement chain

5. What a north star must do

6. How to choose the right north star

7. What this looks like in the real world

8. The leadership split: top-down value and bottom-up action

9. How companies accidentally break the model

10. The simple 90-day plan

Paid Subcriber Content

11. The CX North Star Operating Kit

12. A closing thought

The metric problem sitting in plain sight

Most companies do not have a customer measurement problem because they lack data. They have a measurement problem because they have too many disconnected measures and not enough discipline around what those measures are supposed to change.

A leadership team can look at NPS, CSAT, complaints, digital completion, call volumes, hold time, retention, churn, product adoption, margin, and cost-to-serve in the same meeting and still leave with no real decision. Everyone saw the data. Nobody saw the chain.

That chain is the whole point. Customer work only earns a durable seat in the operating rhythm of a company when it can connect what customers feel, what customers do, how the company operates, and what the business gains or loses as a result.

This is where most customer programs get stuck. They collect feedback. They publish dashboards. They send reports. They give executives charts with arrows that move up or down. But when a CEO, COO, or CFO asks, ‘What should we actually change?’ the answer gets mushy.

The answer often sounds like this: improve the customer experience, focus on the moments that matter, close the loop, listen harder, act on feedback, build a better culture. None of that is wrong. It is just not enough. It does not tell the business where to put money, what to stop doing, what operational behavior needs to change, or which customer behavior is worth betting on.

The hard truth is that many customer teams have been using metrics as a reporting system when they need a decision system. Reporting explains what happened. A decision system tells leaders what to do next, where to intervene, who owns the work, and how to know if the work is changing customer behavior in a way that matters to the business.

That distinction matters because customer leaders are now operating in a different environment. Money is tighter. CFOs are less patient. CEOs are more suspicious of broad claims. Operating leaders are under pressure to remove friction, reduce cost, improve digital adoption, simplify work, retain customers, and grow without adding unnecessary complexity. A customer metric that cannot live inside that conversation is going to be admired politely and ignored quietly.

That is why the north star conversation needs to change. A north star is not the score the CX team likes most. It is not the metric that looks cleanest on a dashboard. It is not the metric that appears in the board deck because everyone knows the acronym. A real north star is the customer behavior that best predicts whether the company is creating value for customers and value for the business at the same time.

That is a very different standard.

Why NPS should not be the north star

Let me be direct: NPS should not be the north star for customer experience efforts.

That does not mean NPS is useless. It can be a useful listening measure. It can tell you something about sentiment. It can help you see broad movement across segments, products, or relationships. It can create a common language in companies that have no customer language at all. In some organizations, that alone has value.

But a useful signal is not the same thing as a north star.

The problem with NPS as a north star is that it asks the company to organize around a stated intention instead of an observed behavior. It asks customers whether they would recommend the company. That can be informative. But it is still a proxy. It is not the behavior itself. It is not renewal. It is not repeat purchase. It is not product usage. It is not fewer avoidable contacts. It is not faster onboarding. It is not lower effort in a critical moment. It is not an operational change.

NPS also creates a false sense of simplicity. Executives like simple. Teams like simple. Boards like simple. A single score can make the business feel aligned. But if the score cannot tell you what customer behavior is changing, why it is changing, which operating lever caused it, and what financial outcome followed, then the simplicity is mostly cosmetic.

The company gets a number. The company does not get a better way to run.

This is where NPS causes real damage as a north star. It pulls attention toward score movement and away from the operating work underneath. Teams start asking, ‘How do we raise the score?’ instead of, ‘What customer behavior are we trying to improve, and what company behavior is getting in the way?’ Those are not the same question.

One question points to score management. The other points to business management.

When NPS becomes the north star, bad habits follow. Teams over-focus on survey timing. Leaders celebrate tiny score changes without understanding the drivers. Frontline teams feel judged by feedback they cannot fully control. Executives ask for benchmarks instead of asking whether the company is becoming easier to do business with. Dashboards start protecting the score instead of exposing the work. The company looks busy, but the customer still lives through the same friction.

A north star should not be that fragile. It should not depend on survey response mix, question interpretation, customer mood, or a campaign to increase promoters. It should be closer to what customers actually do when the company is working or not working for them.

If customers renew, expand, complete more tasks digitally, buy again, stay longer, consolidate spend, call less for avoidable reasons, activate faster, return less, complain less, or use more of what they already bought, that is behavior. Behavior is harder to fake. It is also easier to connect to money.

That is why the north star should be behavioral before it is attitudinal. Feelings matter. Perception matters. Trust matters. But if the company cannot connect those things to behavior, the customer program will keep fighting for credibility.

The better question: what customer behavior proves value?

The strongest customer north star starts with one question: what customer behavior proves that we are creating value?

Not what score do we want to improve. Not what metric do we already report. Not what benchmark do we want to beat. Those are secondary questions. The first question is behavioral.

For a bank, that behavior might be customers successfully completing important financial tasks without needing avoidable help. For a retailer, it might be repeat purchase after a problem is resolved. For a health insurer, it might be members getting answers correctly the first time and avoiding repeat contacts. For a SaaS company, it might be customers reaching meaningful product usage within the first thirty or sixty days. For an airline, it might be customers recovering from disruption without having to chase the company across channels. For a utility, it might be customers resolving billing or service issues without repeat calls, complaints, or escalations.

Different industries need different north stars because different businesses create value in different ways. The metric should not be copied from another company just because it sounds smart. It should be chosen because it sits close to the economic engine of the business and close to the real life of the customer.

This is the test: if the north star improves, can a CFO understand why the company is healthier? Can a COO understand which operating systems need to change? Can a CEO understand what strategic advantage is being built? Can CX leaders understand what customers are telling us? Can frontline leaders understand what their teams can do differently next week?

If the answer is no, the metric is not a north star. It is a reportable measure.

A real north star must sit in the middle of the system. It must be close enough to customers to reflect their reality and close enough to the business to matter economically. That middle layer is usually customer behavior.

This is why a score alone is too weak. It floats above the work. It tells you something, but it does not naturally pull the business into action. A behavior pulls harder. It forces leaders to ask what caused it. It forces teams to inspect operational drivers. It creates accountability because the company can see where its own choices are helping or hurting the result.

The behavior is the bridge. On one side are business outcomes: growth, retention, margin, cost, loyalty, risk, share of wallet, operating leverage. On the other side are operating choices: staffing, process design, product clarity, policy rules, digital design, training, incentives, handoffs, service standards, data quality, and management routines. In between is the customer doing something that proves whether the business is working for them.

That is the place to look for the north star.

The four-layer measurement chain

The framework I use has four practical layers.

At the top are business outcomes. These are the measures executives already care about: revenue, retention, growth, margin, cost-to-serve, risk, complaints, product adoption, and customer lifetime value. Customer leaders do not need to invent a new language for the top of the business. They need to connect customer work to the language that already runs the business.

Below that are customer behaviors. These are the actions customers take that create or destroy business value. Do they renew? Do they buy again? Do they complete the task? Do they increase spend? Do they use the product? Do they stay? Do they leave? Do they consolidate more of the relationship with you? Do they avoid calling because the digital path worked? Do they complain because the company made the simple thing hard?

Below behavior are customer feedback and perception measures. This is where NPS, CSAT, CES, relationship feedback, comment themes, complaint narratives, and qualitative signals belong. These measures help explain why behavior is changing. They can show friction, emotion, trust, confidence, clarity, and perceived effort. They are diagnostic. That is their proper job.

At the bottom are operational metrics. These are the measures closest to the work: hold time, first contact resolution, cycle time, error rate, digital completion, backlog, wait time, rework, handoff count, defect rate, onboarding time, missing information, policy exceptions, claim status clarity, billing corrections, and escalation volume.

The mistake companies make is treating each layer as a separate reporting world. Finance reports business outcomes. Customer teams report NPS. Operations reports process measures. Digital reports conversion. Product reports usage. Frontline leaders report volumes and service levels. Each group may be telling the truth, but the truths do not connect.

The four-layer chain forces the connection. It asks leaders to show how an operational condition changes a customer perception or friction point, how that friction point changes customer behavior, and how that behavior changes the business outcome. That is how customer work becomes management work.

Here is a simple example. A company wants to reduce cost-to-serve. The lazy version is to push customers to digital channels and celebrate lower call volume. The better version is to ask which customer behaviors reduce cost while also improving the customer relationship. Maybe the behavior is successful digital resolution of billing questions without repeat contact within seven days. Now the business has something more precise. The operational drivers might be billing clarity, page load time, authentication failures, status visibility, explanation quality, and the ability to dispute or correct an issue without starting over. The customer feedback measures might show confusion, lack of trust, or frustration with repeated information. The business outcome is lower avoidable contact and lower servicing cost.

That is a usable chain. It does not just say, ‘Improve CX.’ It says, ‘Reduce avoidable billing contacts by improving customer understanding and digital completion, then track whether repeat contact and servicing cost fall without increasing complaints.’

Now leaders can make decisions.

What a north star must do

A strong north star metric must pass five tests.

First, it must be tied to a meaningful business outcome. If the metric improves and the business does not get stronger, the metric is probably not important enough. The connection does not have to be perfect on day one, but there should be a credible theory and a path to validation.

Second, it must reflect a customer behavior, not just an internal activity. Internal activity can support the north star, but it should not be the north star. ‘We closed 95 percent of cases within SLA’ sounds useful until customers still feel like nothing was resolved. ‘Customers resolved their issue without repeat contact within seven days’ is closer to real value.

Third, the company must be able to influence it. Some metrics are interesting but too far away from action. A good north star puts pressure on the operating system. It should make leaders ask better questions about process, digital design, staffing, policy, training, handoffs, product clarity, and accountability.

Fourth, it must be measurable with enough consistency to run the business. You do not need perfect data to start. Perfect data is often the excuse companies use to avoid hard choices. But the metric needs a clear definition, a reliable source, and enough trust that leaders do not spend every meeting debating the denominator.

Fifth, it must avoid obvious gaming. Every metric teaches the company what to optimize. If the metric can be improved by doing something dumb, narrow, or customer-hostile, it needs better design. A north star should create the right behavior inside the company, not just the right number in the dashboard.

This is where many companies get exposed. They choose a metric because it is easy to report, already available, or familiar. Then they act surprised when it does not change the business. The better move is to choose a metric that forces the right operating conversation.

For example, if the goal is retention in a subscription business, the north star might be percentage of customers reaching value within the first thirty days, not NPS after onboarding. If the goal is profitable growth in retail, the north star might be repeat purchase rate after a service failure, not satisfaction with the contact center. If the goal is cost reduction in insurance, the north star might be claim resolved with no avoidable repeat contact, not average handle time. If the goal is adoption in banking, the north star might be successful completion of high-value digital tasks, not overall app satisfaction.

Notice what changes. The metric now tells the company what customer behavior matters. It gives operations something to fix. It gives finance a reason to care. It gives customer teams a way to explain the why behind the number. It gives leaders a practical way to separate noise from value.

That is what a north star is supposed to do.

How to choose the right north star

Choosing the right north star is not a branding exercise. It is a business design choice.

Start with the business outcome. Pick one outcome that matters enough to senior leaders that they will keep paying attention after the kickoff meeting. Retention. Expansion. Repeat purchase. Lower avoidable cost. Faster activation. Lower complaint risk. Higher product adoption. Improved share of wallet. Reduced churn. Be specific.

Then ask which customer behavior most directly contributes to that outcome. This is the part that requires discipline. Do not jump to a survey metric. Do not jump to the dashboard you already have. Ask what customers do when they are getting value from the company.

If you are a SaaS company, the behavior might be meaningful usage by day thirty. If you are a bank, it might be successful completion of a critical money movement, servicing, or account task. If you are a retailer, it might be buying again after a return, delivery issue, or service recovery. If you are a healthcare company, it might be getting the right answer, care access, or administrative resolution without rework. If you are a B2B services company, it might be customers adopting recommendations, expanding the relationship, or renewing without last-minute rescue work.

Once you have candidate behaviors, test them against the business outcome. You are looking for evidence that customers who do the behavior are more valuable, less costly, more loyal, or less risky than customers who do not. The evidence might come from data analysis. It might come from a structured pilot. It might come from known operating patterns that you validate over time. But the goal is the same: prove that this behavior deserves leadership attention.

Then identify the feedback measures that explain why the behavior is happening. This is where NPS, CSAT, CES, comments, complaints, and sentiment become useful. They are not the north star. They are clues. They help explain what customers are feeling or perceiving as they move toward or away from the behavior you want.

Finally, identify the operational drivers that the company can change. This is where the work gets real. The drivers might be handoff count, wait time, product complexity, communication clarity, avoidable contacts, error rates, form completion, missing data, failed authentication, training gaps, policy friction, approval delays, or poor status visibility. These are the places where leaders can assign ownership and create action.

The best north star comes from this sequence: business outcome, customer behavior, customer signal, operational driver, team action. Most companies do it backward. They start with the score they already have and then try to convince the business it matters. That is why the work often feels like persuasion instead of management.

When the chain is built correctly, the argument gets easier. The customer team is no longer saying, ‘Please care about customer experience.’ It is saying, ‘This specific customer behavior predicts this business outcome. These operating drivers influence that behavior. Here is where we are underperforming. Here is what we recommend changing.’

That is a very different conversation with a CFO. It is also a very different conversation with an operating leader.

What this looks like in the real world

The framework works across industries because it is not built around a single metric. It is built around a pattern.

In banking, a leadership team might care about deposit growth, digital adoption, and lower servicing cost. NPS will not tell them what to do. A better north star might be successful completion of priority account tasks without assisted support or repeat contact. That behavior connects to digital adoption, lower cost, and customer confidence. The diagnostic measures might include effort, confidence, and clarity. The operational drivers might include authentication failures, unclear instructions, branch-to-digital handoffs, status visibility, and exceptions that force customers into manual channels.

In SaaS, the business outcome might be renewal and expansion. NPS can be a useful sentiment check, but it is too late and too vague to run the business. A stronger north star might be percentage of new customers reaching defined value within the first thirty or sixty days. The diagnostic measures might include onboarding confidence, product clarity, and support friction. The operational drivers might include implementation time, training completion, admin setup, data integration, feature adoption, and unresolved support cases. That metric gives customer success, product, onboarding, support, and finance something concrete to manage together.

In retail, the business outcome might be repeat purchase and basket growth. A broad satisfaction score can hide too much. A stronger north star might be repeat purchase rate after a problem, return, delivery issue, or service recovery. That behavior tells the company whether it repaired trust or simply closed a ticket. The operational drivers might include refund speed, associate empowerment, inventory visibility, communication clarity, and whether the customer had to repeat the story more than once.

In healthcare, the business outcome might be retention, adherence, lower avoidable contacts, or reduced complaint risk. A useful north star might be issue resolved correctly on first contact without rework, or appointment access completed within a clinically appropriate window. The diagnostic measures might include confidence, clarity, and perceived effort. The operational drivers might include scheduling availability, referral rules, prior authorization friction, agent knowledge, system handoffs, and communication gaps.

In insurance, the business outcome might be retention, cost control, complaint reduction, and trust after a claim. A strong north star might be claiming clarity and resolution without avoidable repeat contact. The diagnostic measures might include understanding of status, confidence in next steps, and perceived fairness. The operational drivers might include documentation quality, adjuster responsiveness, status notifications, payment timing, and handoff discipline.

In each case, the north star is not a generic customer score. It is a behavior that shows whether the company is creating value in a way that matters to both the customer and the business.

That is the reason this approach works. It respects the differences between industries without letting every company hide behind its own complexity.

The leadership split: top-down value and bottom-up action

A customer metric system must serve two audiences at the same time.

The first audience is senior leadership. CEOs, CFOs, COOs, business unit presidents, and boards need to know whether customer work is creating business value. They need the top-down story. What outcome are we improving? How much value is at stake? Which customer behavior moves that outcome? Where should we invest? What should we stop doing? What risk are we reducing?

The second audience is the people closest to the work. Frontline leaders, product teams, digital teams, operations, service teams, analytics, and customer teams need to know what to do differently. They need the bottom-up path. Which drivers are hurting the result? Which teams own those drivers? What action will change the metric? What will we test? What will we fix? What will we learn by next month?

Most measurement systems over-serve one audience and under-serve the other.

Some systems are executive-friendly but useless to teams. They show high-level scores and business outcomes, but nobody knows what to change on Monday. Other systems are operationally detailed but strategically weak. They show handle time, backlog, defects, and task completion, but senior leaders do not see why the work matters economically.

The right framework must connect both. Top-down value gets executives to pay attention. Bottom-up action gets the company to change.

That is where the four-layer chain becomes powerful. Executives see the outcome and the customer behavior. Operating teams see the drivers and actions. Customer teams explain the why. Analytics teams validate the connection. Finance helps size the value. The metric becomes shared property instead of a CX-owned report.

That shared ownership is not a soft culture point. It is a practical requirement. If the CX team owns the north star alone, it will fail. The CX team can define it, explain it, and help govern it, but the operating system must own the work that moves it.

A north star without operating ownership is a poster. A north star with operating ownership becomes a management tool.

How companies break the model

Even a well-designed north star can fail if the company manages it badly.

The first failure mode is choosing a metric that sounds good but sits too far from action. This often happens when leaders want something elegant. They choose a broad metric that works in a board slide but does not tell a team what to fix. The metric gets visibility, but it does not create movement.

The second failure mode is confusing correlation with control. A metric can be associated with business outcomes without being something the company can influence in a practical way. If leaders cannot identify the operating levers, the metric will frustrate teams and lose trust.

The third failure mode is letting every function keep its own version of truth. Finance calculates value one way. CX defines customers another way. Operations reports performance at a different level. Digital measures success with a different denominator. Product uses a different time frame. Suddenly the north star becomes a reconciliation exercise instead of a decision tool.

The fourth failure mode is turning the north star into a compensation weapon too quickly. Incentives can matter but putting a new metric into pay before the company understands the drivers invites gaming. Teams will do what the metric rewards, even if that behavior misses the point. Start with learning and management discipline before you hardwire compensation.

The fifth failure mode is overbuilding the dashboard and underbuilding the routine. Companies love dashboards because they feel tangible. But a dashboard without a meeting rhythm is just a better-looking report. The hard work is deciding who reviews the metric, how often, what decisions are required, how actions are tracked, and what happens when teams do not act.

The sixth failure mode is treating the metric as permanent. The right north star for one phase of a company may not be right forever. A business trying to reduce churn may later shift toward expansion. A company trying to drive digital adoption may later shift toward deeper product usage. A company trying to fix a broken service moment may later shift toward growth. Governance matters because the metric needs to stay connected to strategy.

The final failure mode is the most common: the company talks about customers but still manages itself around internal convenience. That shows up in budget fights, policy design, handoffs, product decisions, channel rules, and leadership scorecards. The north star exposes the gap. That is why some companies resist it. A good metric does not just measure customer value. It reveals clear operating choices to stakeholders, shareholders, partners, and employees.

The 90-day plan

If I were standing this up inside a company, I would not start with a massive transformation plan. That is how good ideas get buried under process. I would start with a focused ninety-day build.

The first thirty days are about choosing the right business outcome and customer behavior. This is where leaders must be honest. What outcome matters enough to manage? What customer behavior is likely to move it? What segments or moments matter most? What evidence do we already have? What data do we trust? What do we need to validate?

The second thirty days are about building the chain. This is where the team maps feedback measures and operating drivers to the chosen behavior. The goal is not to explain every possible driver. The goal is to identify the few that matter most and can be changed. This is also where analytics and finance should pressure-test the logic. If the behavior improves, what value should the business expect? If the drivers improve, how quickly should the customer behavior move?

The final thirty days are about putting the metric into the management rhythm. That means a simple dashboard, clear owners, a decision meeting, an action tracker, and a governance routine. The company should know who owns the metric definition, who owns the drivers, who validates the data, who approves changes, and who is accountable for action.

That is the basic version. It is enough to get started, but it is not enough to scale.

The scaling work requires more detail: the metric tree, the data definitions, the dashboard requirements, the operating cadence, the governance model, the executive memo, the team-level action planning, and the industry-specific examples that help leaders see how the model changes by business type.

That is where the paid artifacts come in. For paid subscribers, keep reading…

Subscribe now

Read more

Subscribe now

There is a very specific moment when a customer experience program starts to lose the room. Sometimes it’s when the score dips. It’s not even when the executive team asks, again, why the number moved three points.

It is the moment everyone realizes that the program is better at describing yesterday than changing tomorrow.

That is the trap of survey-only CX. It gives leaders a tidy way to talk about customers. It does not, by itself, give the business a reliable way to understand customers, prioritize fixes, help employees act, or prove that experience work is changing outcomes that matter.

Surveys are not the villain. Let’s get that out of the way right now. A well-designed survey is useful. It can ask a clean question. It can capture emotion. It can put language around moments that operational data can and often times miss. It can give customers a way to say, in plain words, what the business made easy or painful.

The problem starts when the survey becomes the program. When the quarterly scorecard becomes the strategy. When the number becomes more important than the customer behavior behind it. When the team spends three weeks explaining a score and three minutes fixing the thing that caused it. The score becomes the shield people hide behind versus understanding the context and sentiment behind it, and using it like a mirror.

That is where CX gets stuck. And too many companies have been stuck there for a long time.

This series starts here because this is the foundation. If we do not name the failure of survey-only CX, we will keep layering new tools on old habits. We will add AI to dashboards. We will automate reports nobody acts on. We will ask employees to care about another metric that does not help them do the work in front of them.

That is not transformation. That is super nice and expensive wallpaper in a room in your house that few people ever walk into.

The next era of CX cannot be about replacing human judgment with AI. It is about using AI, automation, and connected data to finally make customer understanding usable at the speed of the business. That means moving from feedback collection to signal detection. From reporting to action. From KPI worship to better decisions.

AI, not KPI, is not a cute line. It is a warning shot. A KPI can tell you whether the business is winning or losing. It cannot tell you, on its own, what to do next. It cannot read through thousands of customer comments, connect them to churn risk, spot the operational pattern, identify the employee friction point, and put the right issue in front of the right owner before it becomes a bigger problem. That is where AI-forward CX starts to earn its keep.

So let’s be blunt. Survey-only CX fails for five reasons.

First, surveys are slllloooooowwww. Most customer pain does not wait politely for the next survey cycle. A delivery issue happens today. A billing surprise happens today. A call center transfer maze happens today. By the time the survey result is collected, cleaned, coded, trended, and discussed in a monthly meeting, the customer has already formed an opinion. In some cases, they already left, complained publicly, reduced spend, or told someone else not to bother.

This delay matters because customer experience is not a museum exhibit to be viewed with heads nodding around a conference room table. It is a living system. The business makes promises. Operations either keep or break those promises. Employees absorb the consequences. Customers respond with behavior. The faster you can detect that chain, the more useful your CX program becomes.

Second, surveys are partial. The people who respond are not always the people you most need to understand. Some customers are delighted. Some are angry. Some have time. Some want to be heard. Many quietly adjust their behavior without ever filling out your form. They call less. They buy less. They renew with hesitation. They open a competitor tab. They stop recommending you. They do not always announce the moment you lost them.

This is why survey data can feel precise and still be misleading. A decimal point can create false confidence. A score can look stable while important segments are quietly getting worse. A regional average can hide a failing journey. A glowing comment can distract from an operational defect that is hitting thousands of customers who never answered the survey.

Third, surveys are often separated from the work. This is the big one. Customer feedback is collected in one system, operational data lives in another, employee feedback sits somewhere else, and the people responsible for fixing the issue are handed a PowerPoint summary three weeks later. By then, the story has been sanded down into themes. Helpful for discussion, maybe. Weak for action, absolutely. It reminds me of the old John Stumpf (former Wells Fargo CEO) line, “By the time news gets to me, motor oil tastes like pizza.”

A customer says, ‘Your onboarding process was confusing.’ Fine. What does that mean? Which step? Which channel? Which customer type? Which product? Which policy? Which team owns it? Did it create repeat contacts? Did it delay activation? Did employees already flag the same issue? Did it lead to churn? A survey response alone rarely answers those questions. Connected data can.

Fourth, survey-only programs make employees carry the burden without giving them better tools. This is where CX and EX have to stop pretending they are separate worlds. When customers are frustrated, employees are usually somewhere in the blast radius. They are explaining a broken policy. They are apologizing for a system they cannot change. They are inventing workarounds. They are hearing the same complaint again and again, while leadership celebrates a one-point movement in a relationship score. And if they lose their cool in the moment, your employee’s behavior becomes your customer’s experience.

Employees do not need another dashboard that tells them customers are annoyed. They need evidence that leadership understands the cause of the annoyance and is willing to remove the friction. They need clear priorities, faster escalation paths, and tools that make the right action obvious. If CX asks employees to care but does not make their jobs easier, it should not be shocked when the energy fades.

Fifth, survey-only CX rewards measurement activity over business impact. It is very easy to confuse a mature reporting process with a mature CX capability. They are just not the same. You can have beautiful dashboards, disciplined governance meetings, tight statistical tracking, and a full library of verbatim themes and still not change the customer’s actual experience in any meaningful way.

One of the hardest lessons I learned early in my career is that CX programs fail because people are lazy or the intent is weak. Just kidding! I want to make sure you’re still reading! The lesson is that CX programs fail because the operating model is built around explaining metrics, and not changing the systems, processes, and products that drive the behaviors of your customers.

Senior CX and EX leaders should care about this because the boardroom patience for soft experience work is thinning. Now, it’s important to note that does not mean leaders do not care about customers. It means they are tired of work that cannot show a line from customer friction to business consequence, then from action to measurable improvement. They want to know what is broken, what it costs, what will be fixed, who owns it, and how fast the business will learn whether the fix worked, and what is the outcomes once in place.

That is not unreasonable. In fact, I think it’s and extremely healthy view. And if you can’t adopt that view, you may be in the wrong field.

All that said, the answer is not to kill surveys, or NPS or CSAT. The answer is to put surveys in their proper place. Surveys should be one signal in a larger system, not the center of gravity. They should help explain what customers felt and why, while other signals show what customers did, where the journey broke, what employees experienced, and what the business impact looks like.

Think about the difference between a survey-only feedback loop and an AI-forward action loop.

In the survey-only loop, the company asks, collects, reports, discusses, and maybe acts. In the AI-forward loop, the company listens across signals, detects patterns, prioritizes the highest-value problems, routes action to owners, supports employees with context, measures whether the fix worked, orchestrates the solution, even in real time, and keeps learning & improving.

These are two very different muscles.

It also changes the role of CX leadership. The best CX leaders are not dashboard owners. They are translators between customer behavior, employee friction, operational reality, and business value. They are helping the company see the full system. They are not asking executives to admire feedback. They are helping them make sharper decisions. And, most importantly, they keep the business accountable and pushing people to deliver value that balances customer needs and shareholder needs.

So what should leaders do immediately? Start with a brutally honest baseline. Not a maturity fantasy. Not the version you would present after three rounds of internal diplomacy, but the real one. And if you don’t know what that looks like, it’s the one that makes you feel like you may get fired for what you’ve just done, but you look at yourself in the mirror and hear the Rocky theme song playing.

First, map your current signals. List every source that tells you something about customer experience: surveys, complaints, call reasons, chat transcripts, reviews, social comments, digital behavior, renewal data, churn reasons, claims, returns, onboarding progress, usage patterns, employee feedback, QA notes, and frontline escalations. Do not worry yet about whether the data is clean. Just map what exists, where it lives, who owns it, and how often it updates.

Second, identify the dead zones. Where are you relying on surveys because you have no other signal? Where are you missing silent customers? Where are you blind to employee pain? Where do you have operational data but no customer language? Dead zones are dangerous because they create stories that sound complete but are not.

Third, pick one journey where the business already feels pain. Do not start with the entire enterprise. That is how good intentions go to die in a steering committee. Choose one journey with visible customer friction and business consequence: onboarding, billing, claims, renewal, service recovery, delivery, first use, account changes. Pick a place where improvement would matter. My go-to is always the product with the biggest revenue. Why? Because it also likely has the biggest dollar volume of a leaky bucket. What that means, in short, is the number you ultimately drive is not only quantifiable, it’s going to make peoples’ eyes pop out of their heads when you’re done with the work.

Fourth, connect three signal types for that journey. One customer signal, one operational signal, and one employee signal. For example, combine onboarding survey comments, activation delay data, and frontline notes. Or combine billing complaints, repeat contact rates, and employee escalation themes. You do not need a perfect data lake. You need enough connected evidence to stop guessing.

Fifth, create an action rule. This is where many programs get really wobbly. Insight without a rule becomes another interesting conversation in a governance forum. Define what happens when a pattern crosses a threshold. Who gets notified? What evidence do they receive? What decision do they need to make? What is the expected response time? What does closure look like? If nobody owns the action, the insight is white noise lulling you to sleep. This is where a RACI comes in very handy (Responsible, Accountable, Consulted, Informed).

Sixth, measure the fix, don’t just baseline the score. If the issue is onboarding confusion, measure activation time, repeat contact, drop-off, employee handling effort, and customer comments (sentiment) after the change. If the issues are billing surprises, measure bill-related contacts, complaint volume, payment delay, credits issued, and churn risk. Scores can support the story, but they should not be the only proof.

Seventh, build a regular cadence for learning. Monthly reporting can be too slow for transformation. A weekly rhythm may feel too frequent for some companies, but it does not need to be elaborate. It should just answer four questions:

1. What did we detect?

2. What did we decide?

3. What changed?

4. What did we learn?

The cadence keeps CX connected to action, not trapped in commentary.

This is where AI becomes useful, but only if the operating model is ready for it. AI can classify messy feedback faster than humans. It can summarize themes, detect emerging issues, measure sentiment, connect patterns across channels, and suggest next best actions. It can help leaders see the difference between loud complaints and expensive friction. It can help employees understand customer context without digging through five systems.

But AI will not rescue a CX program that has no ownership, no action rules, no connection to operations, and no appetite for changing how decisions get made. AI slows down weak operating models, and it makes strong operating models faster.

That is why the first move is not buying another tool. The first move is being honest about the gap between what you measure and what you can act on.

Here is a simple test for you. Pull your last executive CX readout. For every chart, ask, ‘What decision did this help us make?’ If the answer is vague, the chart is likely performative. Then ask, ‘What customer behavior did this connect to?’ If the answer is only ‘satisfaction,’ keep going. Finally ask, ‘Who changed something because of this?’ If nobody can answer, the program is not yet action-oriented.

That test may sting. Good! It should! It doesn’t mean you’ve done a bad job, but it does mean you’ve got a lot of work ahead of you.

CX does not earn influence by producing more slides. It earns influence by helping the business remove friction customers can feel and employees can name. The leaders in CX sense, decide, act, and learn faster than their competitors. That’s it.

Survey-only CX was built for a slower world. A world where feedback could wait for a monthly meeting, where averages were good enough, where leaders could manage experience through a handful of lagging indicators. That world is fading.

Customers are moving faster. Employees are carrying more complexity. Executives are asking harder questions. AI is raising the standard for what listening and acting should mean. Every. Single. Day.

The practical challenge for leaders is to stop treating CX as a measurement department and start treating it as an intelligence and action system. That shift is not cosmetic, nor easy. In fact, the question I ask first when someone says they want me to help them transform their customer experience is, “Do you have the budget and stomach for it?” Because the work changes the data you value, the meetings you run, the promises you make to employees, and the way you prove impact.

The good news is that you do not need to boil the ocean. You need a sharper baseline, one priority journey, connected signals, clear action rules, and a cadence that forces learning. Do that well, and you will learn more in 30 days than many survey programs learned all last year.

That is the work of Week 1. Stop letting surveys carry a job they were never designed to do alone. Keep the useful parts. Retire the worship. Build the system around action.

Next week, we go one level deeper: Finding Your CX North-Star Metric. Because if everything matters, nothing moves.

Paid Substack tools that go with this week

If you were reading this on LinkedIn, the main argument above is the free part: survey-only CX is too slow, too narrow, and too disconnected from the work to carry the full job anymore. The practical tools live with the full Substack edition for paid subscribers, because that is where leaders can take the idea and turn it into something their teams can actually use.

This week includes three working assets: the CX Maturity Curve, the Baseline Scorecard, and editable versions in Google Sheets, Docs, and Slides. I’ve also included a maturity framework (CX Maturity Detail) that outlines specific activities you can take over time to continue to enhance your customer and employee experience.

These documents are not meant to be pretty shelfware. They are meant to help you look at your current CX program without questioning or continuing with old bad habits, or pretending the dashboard is the operating model. Charming, I know. And they will always be documents in Google form so they’re editable. PDFs will and always should be free; don’t pay for PDFs.

Until next week: stay curious, move fast, and don’t be afraid to break some glass.

Read more