CXOps

CXOps, as this Atlas uses the word, is the operating system behind customer experience: it collects what customers say and do across the whole journey, routes each problem to someone who owns it, makes sure the fix happens, and checks that the experience actually improved. Surveys are one part; the others are journey maps, an inner loop that calls unhappy customers back, an outer loop that funds cross-team fixes, and metrics that report their own error.

Written for newcomers, voice-of-the-customer (VoC) managers and analysts, service designers and executive sponsors.

No standards body, professional association or foundation defines “CXOps” or “CX operations”. Sources opened for this page use the words in at least three ways:

1. Running customer service. Outsourcing vendors describe a contact-centre provider as running “an entire CX operation (people, processes, and technology)”.^[1] In this usage “CX” is a newer word for support.
2. Running the experience programme across the journey. Front notes that some organisations use “a broader definition of customer experience operations to track the full buyer journey from start to finish”.^[2] The Customer Experience Professionals Association (CXPA) does not use the label, but its competency framework describes this work: designing VoC programmes, mining unsolicited feedback from calls, web data and emails, KPI ownership, and executive accountability.^[3]
3. A services market. Constellation Research’s 2026 shortlist says “Customer experience (CX) operations services span everything from shaping organizational models and defining required technology capabilities to implementing CX technologies and, in some cases, providing technology and operations outsourcing.”^[4]

Usage also blends: one vendor blog gives CX Ops ownership of “the sum total” of touchpoints and also the job of making sure “there are enough people to keep the phones answered”.^[5] This page takes meaning 2. Forrester draws a similar line: “CX looks across the entire customer journey” and is measured on sentiment such as NPS and CSAT, while customer success is post-sale and outcome-measured.^[6] The split used across this Atlas, with reactive service on SupportOps, post-sale success on CustomerOps and journey-wide measurement and governance here, is an editorial distinction, not an industry standard.

• Not a survey team. Surveys without owners for what they find produce a dashboard. Bain’s outer loop exists because most customer-friendly changes cut across functions and need investment.^[7]
• Not the front line, user research or marketing measurement. Tickets and renewals belong to the neighbours above; studies to ResearchOps; brand tracking and attribution to MarketingOps.
• Not a delight programme. Gartner reports that service interactions are “nearly four times more likely to lead to disloyalty than loyalty”;^[8] CXOps mostly removes friction.

Without a feedback operation, customers repeat themselves in surveys, tickets and reviews and nobody joins the pieces. Each team improves its own touchpoint while the journey stays broken: Rawson, Duncan and Jones argued in HBR that a narrow focus on touchpoint satisfaction can make customers look happier than they are and distract from the end-to-end journey.^[9] And scores become targets (see gaming).

Does better experience pay? The evidence is real but contested. Fornell and colleagues found that ACSI satisfaction scores were significantly related to firms’ market value and that satisfaction-based portfolios beat the market at low risk;^[10] Jacobson and Mizik’s re-analysis found little evidence of widespread mispricing, with earlier results driven largely by a few computer and Internet firms.^[11] Treat “CX drives growth” as a hypothesis to test in your own business.

The parts are older than the label:

• Voice of the customer was formalised in quality engineering. Griffin and Hauser’s 1993 paper treated it as the first stage of Quality Function Deployment (identifying, structuring and prioritising customer needs) and found a self-selection bias in satisfaction measures used for incentive programmes.^[12]
• Moments of truth. Jan Carlzon, chief executive of the airline SAS, popularised the phrase; his book (English edition 1987) made employees at all levels responsible for turning these customer contacts to the company’s advantage.^[13] It counts ten million customers meeting about five employees for 15 seconds each: 50 million moments a year^[14] (the 1988 German edition says 12 and 60 million).^[15]
• Net Promoter Score was introduced by Frederick Reichheld in HBR in December 2003,^[16] and Bain later published the inner-loop and outer-loop practices for acting on it.^[17][7]
• Customer effort came from CEB research^[18] popularised in a 2010 HBR article, “Stop Trying to Delight Your Customers”.^[19]
• Standards: the current ISO editions date from 2018 and 2021 (methods and standards); CXPA’s five-area competency framework was validated by a 2020 job-task analysis with more than 300 practitioners.^[3]

The mental model is a loop with four stations, and the job is to keep every signal moving around it:

%%{init: {"flowchart": {"wrappingWidth": 120, "nodeSpacing": 20, "rankSpacing": 40}}}%%
flowchart TB
  S["1. Signal: survey, complaint, review, call, repeat contact"]
  O["2. Owner: a named person or journey owner accepts it"]
  F["3. Fix: inner loop for one customer, outer loop for the cause"]
  M["4. Measured effect: the journey metric moves, or it does not"]
  S --> O --> F --> M
  M -->|"no effect: reopen"| O
  M -->|"confirmed: close, tell customers"| S
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  class S,O,F core
  class M decision

%%{init: {"flowchart": {"wrappingWidth": 140, "nodeSpacing": 22, "rankSpacing": 44}}}%%
flowchart TB
  SU["SupportOps: tickets, queues, transactional CSAT"]
  CO["CustomerOps: health, renewals"]
  MO["MarketingOps: brand and campaign measures"]
  CX["CXOps: survey method, loops, journey governance"]
  RO["ResearchOps: studies, participants"]
  PO["ProductOps: roadmap intake"]
  AN["AnalyticsOps: metric layer, models"]
  SU -->|"ticket themes, CSAT"| CX
  CO -->|"churn reasons"| CX
  MO -.->|"brand tracking"| CX
  RO -->|"study findings"| CX
  CX -->|"survey rules"| SU
  CX -->|"coded issues with evidence"| PO
  CX -->|"metric definitions to publish"| AN
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class CX core
  class SU,CO,MO,RO,PO,AN neutral

The charter below is this Atlas’s proposal; no official CXOps manifesto exists.

Mission: make sure every important thing customers tell us reaches someone who can act, gets acted on, and is checked.

1. Every signal has an owner, or a recorded decision not to act.
2. Close both loops. Follow-up without systemic fixes exhausts the front line; fixes without follow-up lose customers’ trust.^[17][7]
3. Journeys over touchpoints. Measure the outcome the customer wanted across channels.^[9]
4. Report the error bar: sample size, response rate and interval beside every score.
5. Do not pay people on scores they can influence by asking.^[17][23]
6. Ask less, use more. Every question feeds a decision; survey burden is a cost to customers.
7. Fix, then verify. Close a fix only after its effect metric is reviewed.

Non-goals: answering tickets, owning the product roadmap, designing campaigns, running user-research studies.

Small organisations combine these roles; the point is that each duty has one accountable person.

R = responsible, A = accountable, C = consulted, I = informed.

Each signal moves through captured → triaged → owned → acted → verified → closed; the CX lead watches for items that stall. An issue stays “acted” until its effect is checked, and “closed without effect” is allowed only if the issue is reopened or explicitly abandoned. Customers who gave feedback hear the outcome, as Bain’s outer loop recommends where relevant.^[7]

Bain’s outer loop is similar: a central team prioritises input with explicit criteria, recommends owners to executives, and insists on root causes before solutions.^[7]

%%{init: {"flowchart": {"wrappingWidth": 130, "nodeSpacing": 22, "rankSpacing": 40}}}%%
flowchart TB
  subgraph IN["Signals"]
    SV["Surveys: relationship, transactional"]
    UN["Unsolicited: complaints, reviews, chats, calls"]
    OP["Operational data: repeat contacts, drop-offs, delays"]
  end
  subgraph CORE["CXOps core"]
    ID["Identity and consent check"]
    CD["Coding and theme model"]
    HUB["Feedback store with journey and segment keys"]
  end
  subgraph ACT["Action"]
    IL["Inner loop: case to front-line team"]
    OL["Outer loop: issue log, owner, budget"]
    SC["Scorecard and effect reviews"]
  end
  SV --> ID
  UN --> ID
  OP --> HUB
  ID --> CD --> HUB
  HUB --> IL
  HUB --> OL
  OL --> SC
  IL --> SC
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  class ID,CD,HUB core
  class SV,UN,OP neutral
  class IL,OL,SC decision

Design choices that matter more than the tool:

• Join keys: a customer and a journey key on every signal, or comments cannot be linked to the order, ticket or channel.
• Consent and purpose checks at intake, not after analysis (privacy and compliance).
• Operational data beside sentiment: Bain lists it as a separate outer-loop input;^[7] behaviour often shows a problem before anyone complains.

sequenceDiagram
  participant C as Customer
  participant T as Front line
  participant X as CX triage
  participant J as Journey owner
  C->>T: 3/10: "refund took 3 weeks"
  T->>C: Call-back in 2 working days
  alt Not reached after 2 attempts
    T->>X: No contact: counts as missed
  end
  T->>X: Coded "refund delay" (policy)
  X->>J: Issue: 140 similar comments
  J->>X: Accepts, funds, sets metric
  J->>X: Fix shipped
  X->>T: Customers to inform
  T->>C: "Here is what changed"
  X->>J: Effect review at 8 weeks

Exception paths. (a) The customer cannot be reached (shown above): it still counts against the closed-loop rate. (b) No owner accepts the issue within one monthly council: the executive sponsor assigns one or records a decision not to act. (c) The effect review shows no change: reopen with the new evidence instead of declaring success. (d) The comment contains a safety, legal or data-protection matter: route it to the owning process (complaints, incident, privacy) immediately; it is not a “theme”.

1. Choose one actor and one scenario. NN/g defines a journey map as “a visualization of the process that a person goes through in order to accomplish a goal” and recommends one point of view per map.^[24]
2. Start from evidence: drop-off and contact data, coded complaints, customer interviews. A workshop-only map records internal beliefs.
3. Mark the moments of truth (first bill, first failure, cancellation); CXPA lists identifying them as a design skill.^[3]
4. Add the backstage. A service blueprint adds what the customer cannot see: frontstage and backstage actions, support processes and the line of visibility. NN/g calls it a “part two” to the journey map.^[25]
5. Name an owner for every pain point and a metric that would show it improved. A map without owners is wall art.
6. Revisit when the journey’s metrics move or the process changes; date every version.

• Write the decision first: “If reset CES falls below X, the identity journey owner funds Y.”
• State relationship or transactional; Bain’s practice adds a “why?” question either way.^[17]
• Keep wording and scale stable; AAPOR’s advice for trend data is “If you want to measure change, don’t change the measure.”^[26]
• Pretest with a few real customers (AAPOR recommends cognitive interviews or another qualitative method) and order questions so earlier ones do not steer later answers.^[26]
• Cap contact frequency across all surveys. Qualtrics, for example, lets an administrator limit how often a contact receives messages and advises spacing invitations 30–60 days apart.^[27]
• Make it accessible (WCAG 2.2)^[28] and short enough to finish on a phone; a survey screen-reader users cannot complete biases the sample.

Gartner’s 2019 research found that “Only 9% of customers report resolving their issues completely via self-service” and that customers switch channels during a single issue.^[29] The UK Service Standard requires public services to “Provide a joined up experience across all channels”.^[30] In practice: one policy text in every channel, case status visible to every agent, and a journey metric that follows the customer across channels.

Automation helps where volume is high and judgement is low: routing cases, deduplicating comments, suggesting codes. Large language models can code text well; in one study on 2,382 tweets, ChatGPT’s zero-shot labels beat crowd workers on four of five annotation tasks.^[34] That was tweets, not your customers’ comments in your categories, so measure agreement against a human-coded sample before trusting the counts (Lab 3 shows how) and re-check after any model or coding-frame change.

Three cautions:

• Automated outcomes can flatter. Intercom counts an “assumed resolution” when a customer leaves its AI agent without asking for more help.^[35] Pair such figures with repeat contacts across channels.
• Emotion from voice is regulated in the EU: banned for workers, high-risk for customers; see privacy and compliance.
• Inferred sentiment is not a survey. It covers everyone who talked to you but measures tone, not the customer’s judgement; see the judgement call.

This Atlas teaches survey metric design once, here; SupportOps and CustomerOps apply it.

The questions and scales are in the glossary.

Choose by question: advocacy (NPS), one interaction (CSAT), ease (CES); never all three on the same moment.

A score describes the people who answered. Bain’s guidance treats response rates below about 40% for consumers or 60% for businesses as a red flag in its experience, and gives an example: with a 20% response rate, responders scored an NPS of 50 while nonresponders scored −40, so the true figure was −22.^[38] Practical rules:

• Report response rate by segment; a segment’s falling response can move the score with no change in experience.
• Check who is invited: triggers, exclusions and channel mix decide the sample.
• Run scenario bounds for nonresponse (Lab 2).

NPS is a difference between two proportions, so it is noisy. A good default is the adjusted-Wald interval that Lewis and Sauro recommend, based on Rocks (2016): add 3 to the sample size and ¾ to the promoter and detractor counts, then use the variance of the difference.^[22] Comparing two periods uses the same pieces in a two-sample test.^[39] For CSAT, report a Wilson interval, as the SupportOps page does.

Bain wrote in 2012 that car-dealership staff “are notorious for begging for top-box scores”;^[38] in 2021 it called linking scores to frontline bonuses an abuse that made staff “care more about their scores than about learning to better serve customers”.^[23] Reward the loop (call-backs made, issues fixed and verified), not the number, and never rank individuals: two or three responses each are noise.

Any change to wording, scale, trigger, channel, timing or sample is a method change: run old and new in parallel on split samples for a reporting period, record the break, and never splice the series silently.^[26]

Assumptions for this reference build: a mid-sized consumer business with a website, an app, a contact centre and three priority journeys (join, get help, leave). The artefacts are templates to adapt, not a certified method.

Example status: syntax-checked by the validator (YAML), not connected to any survey platform.

survey: help-ces
version: 3
owner: help-journey-owner
decision_it_feeds: >
  If CES top-box for password resets is below 70% for two months,
  the identity journey owner reviews the reset flow.
type: transactional
trigger:
  event: contact_closed
  require_resolution_set: true      # do not survey on status alone
  exclude: [auto_closed, complaint_open, legal_hold, under_16]
sample:
  rate: 0.33
  frequency_cap_days: 60            # shared with all other surveys
questions:
  - id: ces
    text: "[Company] made it easy for me to handle my issue."
    scale: {min: 1, max: 7, labels: [Strongly disagree, Strongly agree]}
  - id: why
    text: "What is the main reason for your answer?"
    type: free_text
    redaction: [card_number, email, phone, health_terms]
analysis:
  report: [n, response_rate, top_box_share, wilson_interval_95]
  break_by: [channel, contact_reason]
inner_loop:
  case_when: "ces <= 3"
  route_to: team_that_closed_contact
  contact_within_working_days: 2
change_control: parallel_run_one_period

1. A case is created for every detractor (NPS 0–6), every CES of 1–3, and every complaint flagged “call me”.
2. The team that served the customer owns the call. Target: first attempt within two working days; two attempts, then close as “no contact”.
3. The caller fixes the individual problem within existing authority and does not promise policy changes.
4. The caller codes the reason and adds one sentence of root cause if known.
5. Safety, legal, vulnerability or data-protection matters leave this process at once for the owning process.
6. Huddles review the week’s calls for learning; individual scores are not ranked.^[17]

Issue title:            <journey> - <symptom in the customer's words>
Journey and step:       e.g. Get help > refund after return
Evidence:               coded comments (n, period), complaints (n), repeat contacts,
                        operational facts (e.g. median refund time), 3 verbatim quotes
Size:                   customers affected per month; revenue or cost at risk (method)
Suspected cause:        frontstage / backstage / policy / product / partner
Proposed owner:         journey owner or function head
Effect metric:          one metric, baseline, target, review date
Decision (council):     fund / defer until <date> / decline with reason
Customers to inform:    who, how, when the fix ships

All three labs use Python 3.8+ (standard library) and synthetic data, with no cost or accounts. The expected outputs are real outputs from runs on 2026-10-23 with Python 3.8.10.

Objective: compute NPS with an adjusted-Wald interval and test whether two periods differ. Prerequisites: Python 3.8+; a terminal; an empty working folder.

Example status: executed locally with Python 3.8.10; reproduces the published MeasuringU example.

"""NPS with an adjusted-Wald confidence interval and a two-sample test.

Method: Rocks (2016) as described by Lewis and Sauro (MeasuringU, 2021).
Usage: python3 nps_ci.py DET PAS PRO [DET2 PAS2 PRO2] [--conf 0.90]
"""
import argparse
from statistics import NormalDist


def adjusted(det, pas, pro):
    n = det + pas + pro
    if n == 0:
        raise ValueError("no responses")
    n_adj = n + 3
    p_pro = (pro + 0.75) / n_adj
    p_det = (det + 0.75) / n_adj
    nps_adj = p_pro - p_det
    var_adj = p_pro + p_det - nps_adj ** 2
    raw = (pro - det) / n
    return {"n": n, "raw": raw, "adj": nps_adj, "var": var_adj, "n_adj": n_adj}


def interval(s, conf):
    z = NormalDist().inv_cdf(1 - (1 - conf) / 2)
    moe = z * (s["var"] / s["n_adj"]) ** 0.5
    return s["adj"] - moe, s["adj"] + moe


def compare(a, b):
    diff = a["adj"] - b["adj"]
    se = (a["var"] / a["n_adj"] + b["var"] / b["n_adj"]) ** 0.5
    z = abs(diff) / se
    p = 2 * (1 - NormalDist().cdf(z))
    return diff, z, p


def main():
    ap = argparse.ArgumentParser()
    ap.add_argument("counts", type=int, nargs="+", help="det pas pro [det pas pro]")
    ap.add_argument("--conf", type=float, default=0.90)
    args = ap.parse_args()
    if len(args.counts) not in (3, 6) or min(args.counts) < 0:
        ap.error("give 3 or 6 non-negative counts")
    groups = [adjusted(*args.counts[i:i + 3]) for i in range(0, len(args.counts), 3)]
    for i, s in enumerate(groups, 1):
        lo, hi = interval(s, args.conf)
        print(f"sample {i}: n={s['n']}  NPS={s['raw'] * 100:+.1f}  "
              f"{args.conf:.0%} CI {lo * 100:+.1f} to {hi * 100:+.1f}")
    if len(groups) == 2:
        diff, z, p = compare(*groups)
        print(f"difference (adjusted) {diff * 100:+.1f} points, z={z:.3f}, p={p:.3f}")


if __name__ == "__main__":
    main()

Steps. (1) Save the file as nps_ci.py. (2) Validate the method against the published example (8 detractors, 13 passives, 15 promoters versus 12, 12 and 7).^[22][39] (3) Run the illustrative quarters at 95%.

python3 nps_ci.py 8 13 15 12 12 7
python3 nps_ci.py 41 63 108 45 60 82 --conf 0.95

Expected output:

sample 1: n=36  NPS=+19.4  90% CI -2.4 to +38.3
sample 2: n=31  NPS=-16.1  90% CI -36.2 to +6.8
difference (adjusted) +32.7 points, z=1.815, p=0.070
sample 1: n=212  NPS=+31.6  95% CI +20.8 to +41.5
sample 2: n=187  NPS=+19.8  95% CI +8.1 to +30.8
difference (adjusted) +11.7 points, z=1.489, p=0.137

Validation: the first block must match MeasuringU’s published values (−0.02 to 0.38, −0.36 to 0.07, z = 1.815, p = .07); the interval is centred on the adjusted NPS, so it is not symmetric around the raw score. Interpretation: an 11.8-point fall on about 200 responses per quarter is not statistically clear. Troubleshooting: give 3 or 6 non-negative counts means a count is missing; different numbers usually mean the order (detractors, passives, promoters) is wrong. Teardown: delete the folder.

Objective: see how the silent majority could change an NPS, using Bain’s scenarios.^[38] Prerequisites: as Lab 1.

Example status: executed locally with Python 3.8.10; reproduces Bain’s published example.

"""How far could nonresponse move an NPS? Scenario bounds, not an estimate.

Usage: python3 nonresponse.py INVITED DET PAS PRO [SILENT_NPS]
Scenarios for people who did not answer:
  same      - they score like responders (the hidden assumption of most dashboards)
  half      - a 50-50 mix of passives and detractors (Bain 2012: for many consumer firms)
  detractor - all detractors (Bain 2012: probably close in B2B settings)
  custom    - an NPS you assume for them, e.g. from a follow-up sample
"""
import sys


def nps(det, pro, n):
    return 100.0 * (pro - det) / n


def main(argv):
    if len(argv) not in (4, 5):
        sys.exit(__doc__)
    invited, det, pas, pro = (int(x) for x in argv[:4])
    resp = det + pas + pro
    if resp == 0 or invited < resp:
        sys.exit("need at least one response and INVITED >= responses")
    silent = invited - resp
    print(f"response rate {resp / invited:.0%} ({resp} of {invited})")
    print(f"same      NPS {nps(det, pro, resp):+.1f}")
    print(f"half      NPS {nps(det + silent / 2, pro, invited):+.1f}")
    print(f"detractor NPS {nps(det + silent, pro, invited):+.1f}")
    if len(argv) == 5:
        mix = (resp * nps(det, pro, resp) + silent * float(argv[4])) / invited
        print(f"custom    NPS {mix:+.1f} (silent group assumed {float(argv[4]):+.0f})")


if __name__ == "__main__":
    main(sys.argv[1:])

python3 nonresponse.py 1000 20 60 120 -40
python3 nonresponse.py 640 41 63 108

Expected output:

response rate 20% (200 of 1000)
same      NPS +50.0
half      NPS -30.0
detractor NPS -70.0
custom    NPS -22.0 (silent group assumed -40)
response rate 33% (212 of 640)
same      NPS +31.6
half      NPS -23.0
detractor NPS -56.4

Validation: the custom line of the first run must equal Bain’s −22. Interpretation: these are bounds, not estimates; if the range is wide, phone a random sample of nonresponders before reporting a trend. Troubleshooting: the usage text means an argument is missing. Teardown: delete the file.

Objective: compute the closed-loop rate, time to contact and the share of detractors linked to an outer-loop issue, and check how well an automated theme coder agrees with a human. Prerequisites: as Lab 1. The data are twelve invented rows.

Example status: executed locally with Python 3.8.10 on the synthetic file below.

id,score,received,contacted,human_theme,model_theme,issue
f01,2,2026-09-01T09:10,2026-09-01T15:00,delivery,delivery,ISS-14
f02,9,2026-09-01T10:00,,praise,praise,
f03,5,2026-09-01T11:30,2026-09-04T10:00,billing,billing,ISS-09
f04,6,2026-09-02T08:45,,delivery,returns,
f05,3,2026-09-02T12:00,2026-09-02T16:30,app,app,ISS-21
f06,10,2026-09-02T13:00,,praise,praise,
f07,4,2026-09-03T09:00,2026-09-03T11:00,delivery,delivery,ISS-14
f08,7,2026-09-03T10:20,,returns,returns,
f09,1,2026-09-03T17:55,2026-09-07T09:00,billing,delivery,
f10,6,2026-09-04T08:00,2026-09-04T12:00,returns,returns,ISS-30
f11,8,2026-09-04T09:30,,app,praise,
f12,5,2026-09-04T14:10,2026-09-05T16:40,delivery,delivery,ISS-14

"""Closed-loop metrics and coder agreement from a feedback export.

Usage: python3 loop_metrics.py feedback.csv [SLA_HOURS]
Eligible for follow-up: score 0-6 (detractors). Times are local ISO strings.
The SLA is in clock hours; a working-day SLA needs a business calendar.
"""
import csv
import sys
from collections import Counter
from datetime import datetime
from statistics import median


def hours(a, b):
    fmt = "%Y-%m-%dT%H:%M"
    return (datetime.strptime(b, fmt) - datetime.strptime(a, fmt)).total_seconds() / 3600


def kappa(pairs):
    n = len(pairs)
    observed = sum(a == b for a, b in pairs) / n
    left = Counter(a for a, _ in pairs)
    right = Counter(b for _, b in pairs)
    expected = sum(left[k] * right[k] for k in left) / (n * n)
    return observed, (observed - expected) / (1 - expected)


def main(argv):
    if len(argv) not in (1, 2):
        sys.exit(__doc__)
    sla = float(argv[1]) if len(argv) == 2 else 48.0
    with open(argv[0], newline="") as fh:
        rows = list(csv.DictReader(fh))
    eligible = [r for r in rows if int(r["score"]) <= 6]
    waits = [hours(r["received"], r["contacted"]) for r in eligible if r["contacted"]]
    on_time = sum(w <= sla for w in waits)
    linked = sum(bool(r["issue"]) for r in eligible)
    print(f"rows {len(rows)}, eligible detractors {len(eligible)}")
    print(f"contacted within {sla:.0f} h: {on_time}/{len(eligible)} = "
          f"{on_time / len(eligible):.0%}")
    print(f"never contacted: {len(eligible) - len(waits)}")
    print(f"median hours to contact (contacted only): {median(waits):.1f}")
    print(f"linked to an issue: {linked}/{len(eligible)} = {linked / len(eligible):.0%}")
    obs, k = kappa([(r["human_theme"], r["model_theme"]) for r in rows])
    print(f"theme agreement human vs model: {obs:.0%}, Cohen's kappa {k:.2f}")
    top = Counter(r["human_theme"] for r in eligible).most_common(3)
    print("top detractor themes (human-coded):", top)


if __name__ == "__main__":
    main(sys.argv[1:])

python3 loop_metrics.py feedback.csv
python3 loop_metrics.py feedback.csv 24

Expected output (first run; the second differs only in “contacted within 24 h: 4/8 = 50%”):

rows 12, eligible detractors 8
contacted within 48 h: 5/8 = 62%
never contacted: 1
median hours to contact (contacted only): 5.8
linked to an issue: 6/8 = 75%
theme agreement human vs model: 75%, Cohen's kappa 0.68
top detractor themes (human-coded): [('delivery', 4), ('billing', 2), ('app', 1)]

Validation: by hand, eight scores are 6 or less; f03 (70.5 h) and f09 (87.1 h) missed 48 clock hours and f04 was never called, so 5 of 8 met the target. Interpretation: the median looks excellent while 3 of 8 detractors missed the target. The lab uses clock hours; under the SOP’s two-working-day rule f09 (Thursday 17:55, called Monday 09:00) would be on time, so fix one clock definition before reporting the rate. f09, the angriest customer, was also mis-coded and linked to no issue. Kappa on twelve rows is very unstable; use at least 100 coded comments, as the assurance audit does. Troubleshooting: a ValueError on time data means a timestamp is not YYYY-MM-DDTHH:MM; a KeyError means a missing column; real exports also need time zones. Teardown: delete the two files.

All three scenarios are illustrative; the public-service one applies a published standard but describes no real service.

Experience scores show how customers feel; loop metrics show whether the operation works. The loop metrics are this page’s proposals.

Worked calculation (illustrative). In September the get-help journey produced 640 eligible cases (detractor CES or complaint with “call me”). 512 were contacted within two working days, 71 later, and 57 never. Closed-loop rate = 512 ÷ 640 = 80%. Of 410 coded detractor comments, 287 were linked to issues: linkage = 287 ÷ 410 = 70%. Three issues were closed in the quarter and two had effect reviews: verification = 2 ÷ 3 = 67%. Survey burden: 96,000 invitations for 60,000 active customers = 1.6 per customer per year; the 60-day per-person cap allows at most about six. The weakest number is verification: the operation is busy but not yet learning whether fixes work.

Targets. Set them from your own baseline, with a fixed definition of “eligible”.

What applies depends on jurisdiction; the points below are examples as of October 2026, not legal advice.

• Surveys versus marketing (UK example). The ICO says “Contacting people to conduct genuine market research is not direct marketing”, but research messages that include promotional material, or research done in order to market to the people involved, are direct marketing (“sugging”, selling under the guise of research).^[40] Keep offers out of survey emails.
• Free text collects sensitive data you did not ask for, such as illness or religion; UK GDPR protects special category data, and the ICO’s guidance covers inferences too.^[41] Redact, restrict raw comments, set retention.
• Emotion recognition (EU AI Act). A system that infers emotions or intentions from biometric data is an emotion recognition system;^[42] the Future of Privacy Forum’s (FPF) summary of the Commission’s guidelines gives the voice or a facial expression as examples.^[43] Using one on workers (say, scoring agents’ emotions on calls) is prohibited except for medical or safety reasons, since February 2025.^[44][45] A permitted one, for example on customers’ voices, is high-risk under Annex III point 1(c),^[46][43] with those obligations moved by the AI Omnibus to 2 December 2027 (as of October 2026).^[45] Article 50, applicable from 2 August 2026, already requires deployers to “inform the natural persons exposed thereto of the operation of the system”.^[47] FPF also notes that the Commission’s guidelines treat systems capturing both workers and customers only superficially and put emotions inferred from written text outside the prohibition.^[43] Sentiment on transcript words alone uses no biometric data; data-protection rules still apply.

The large costs are people: front-line call-backs, analyst coding and journey owners’ fixes. Size the inner loop as a workload: 640 cases a month at 12 minutes each is 128 hours, close to one full-time person. Without that capacity, narrow eligibility (for example, detractors who asked for contact) rather than let the closed-loop rate decay. Customer time is a cost too: cap invitations.^[27] Repeat contacts, drop-offs and complaints cost customers nothing to give.

Check monthly that the operation is honest:

• Sample audit: 20 random detractor cases: call, timing, code.
• Coding audit: re-code 100 comments by hand each quarter (Lab 3 method).
• Trigger audit: after any helpdesk, app or CRM workflow change, confirm who is surveyed.
• Orphan and burden audits: themes with no issue, issues with no effect metric, customers over the invitation cap.

1. Detect (day 0). The weekly scorecard flags a change larger than the interval. Before anyone celebrates, the VoC analyst opens a ticket “CSAT step change, cause unknown”.

2. Check the instrument (day 1). Invitations rose 40% while contact volume was flat. The change log shows that on day −3, tickets auto-closed after seven days without a reply began moving to a Done status. In products such as Jira Service Management Cloud a CSAT survey fires when a work item reaches the Done status category, whether or not a resolution is set,^[37] so customers whose tickets lapsed (many of whom had solved the problem themselves) are now surveyed.

3. Contain (day 2). Restore the original trigger: survey only when a resolution is set, and make sure auto-close leaves the resolution empty (or exclude the auto-close status). In Jira Service Management Cloud that means changing the workflow and customer-notification settings, not one toggle (as of October 2026).^[37] Mark the two weeks in the scorecard as a method break.

4. Restate (day 3). CSAT on the original population is 77.9%: no real change. Tell everyone who saw the 86%.

5. Prevent (week 2). Add survey triggers to the helpdesk change checklist, show “invitations per contact” beside every score, and log the incident in the survey specification.

What made it hard: the wrong number was good news, so nobody wanted to question it.

• “NPS predicts our growth.” The originators claimed a strong link; an independent longitudinal study did not reproduce the claimed superiority over other measures.^[36] Test the link on your own retention data before relying on it.
• Survey everything after every contact. Burden rises, response falls, and the remaining responders are less typical.
• Only call angry customers. Bain calls this a misconception: happy customers can have unresolved issues and promoters give constructive suggestions.^[17]
• The dashboard is the programme. If no issue has an owner and an effect review, it is reporting, not CXOps.
• “The AI will tell us what customers feel.” It measures tone, may mis-code, and is regulated when it uses voice.

Use a dedicated CXOps function (a person or a team) when:

• customers cross several teams or channels to reach one outcome, and complaints bounce between them;
• you already collect feedback in several places and nobody joins it;
• an executive is willing to own journey outcomes and fund cross-team fixes.

Do not build one yet when:

• one manager can still read every complaint: a weekly review and a fix list are enough;
• the real problem is the support queue (staffing, SLAs): start with SupportOps;
• the real problem is churn in a known segment: start with CustomerOps;
• no one will fund outer-loop fixes. Surveys without fixes teach customers that answering is pointless.

Exit condition: if after two quarters no issue has completed an effect review, stop adding surveys and fix the governance.

%%{init: {"flowchart": {"wrappingWidth": 150, "nodeSpacing": 22, "rankSpacing": 36}}}%%
flowchart TB
  Q1{"Do customers cross several teams or channels for one outcome?"}
  Q2{"Is the main pain the support queue?"}
  Q3{"Will an executive fund cross-team fixes?"}
  Q4{"More than a few hundred feedback items a month?"}
  A1["No CXOps: weekly complaint review by a manager"]
  A2["Start with SupportOps"]
  A3["Not yet: secure a sponsor before adding surveys"]
  A4["One CX lead: register, inner loop, monthly council"]
  A5["CXOps team: coding, issue log, effect reviews"]
  Q1 -->|"no"| A1
  Q1 -->|"yes"| Q2
  Q2 -->|"yes"| A2
  Q2 -->|"no"| Q3
  Q3 -->|"no"| A3
  Q3 -->|"yes"| Q4
  Q4 -->|"no"| A4
  Q4 -->|"yes"| A5
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class Q1,Q2,Q3,Q4 decision
  class A4,A5 core
  class A1,A2,A3 risk

The thresholds are judgement, not research: a few hundred items a month is roughly where one person stops reading everything.

This is this Atlas’s model, not an industry standard.

Quick wins: call ten detractors yourself; delete one unused survey question.

Quick start

• One executive sponsor and a written charter with non-goals
• Signal register listing every survey, complaint channel, review source and operational signal
• Three priority journeys, each with an owner
• Inner-loop SOP tested on ten real detractors

Before launching or changing a survey

• The decision it feeds is written down
• Relationship or transactional, stated; trigger and exclusions documented
• Pretested with real customers; accessible on a phone and with a screen reader
• Frequency cap shared with all other surveys
• No promotional content; privacy notice and retention set
• Analysis plan written; parallel run if it replaces a measure

Monthly governance

• Closed-loop rate and late tail reviewed by team
• Every theme above threshold has an issue or a recorded decision not to act
• Every closed issue has an effect review or a date for one
• Trigger and burden audits done

One-page CXOps charter

Purpose:        Every important thing customers tell us reaches an owner,
                is acted on, and is checked.
Sponsor:        <executive>          CX lead: <name>
Journeys:       1. <journey> (owner)  2. ...  3. ...
In scope:       signal register, surveys, inner and outer loops, scorecard
Out of scope:   ticket queues, renewals, campaigns, research studies
Principles:     owners for every signal; close both loops; report error bars;
                no pay on scores; ask less, use more; fix then verify
Cadence:        daily huddles, weekly triage, monthly council, quarterly review
Measures:       closed-loop rate, issue linkage, effect verification,
                journey outcomes, NPS/CES with intervals, survey burden
Review date:    <date>

Effect review

Issue:            <id and title>
Fix shipped:      <date>          Owner: <name>
Effect metric:    <metric, definition, data source>
Baseline:         <value, period, n>
After:            <value, period, n>      Interval or test: <method, result>
Comparison group: <unchanged journey, region or cohort: before, after>
Other changes in the period that could explain the movement:
Verdict:          effect confirmed / no clear effect / worse
Next step:        close / reopen with new hypothesis / roll back
Customers and staff told on: <date>

Worked effect review (illustrative). A refund fix ships in the north first. Repeat refund contacts per 1,000 refunds fall from 180 to 120 there and from 175 to 160 in the unchanged south. Before/after says −60; against the comparison group it is (120 − 180) − (160 − 175) = −45. This difference-in-differences logic assumes both regions would have moved alike without the fix, so check that their trends ran parallel for months before it.^[48]

Is CXOps a real job title? Titles with “CX operations” exist, but vendors also use the words for contact-centre work^[1] or a blend of staffing and journey ownership,^[5] so read the job description, not the title.

Should we use NPS, CSAT or CES? One well-run measure per moment; see the comparison.

Our NPS fell five points. Should we worry? Check the interval and the instrument first, then read the comments.

Can we tie executive bonuses to NPS? Avoid it (why). If executives must have a customer goal, use verified journey outcomes and loop metrics they control through investment, and keep the survey method out of their hands.

Who owns CX if every department touches the customer? Journey owners own outcomes; the CX lead owns the method and the loop; the executive sponsor owns arbitration.

• Established: relationship and transactional surveys, the two loops, journey maps and blueprints, complaint-handling standards, adjusted-Wald NPS intervals.^[22]
• Still settling: LLM coding with human audit;^[34] testing which survey measure predicts retention in your business; Bain’s “earned growth”, an accounting-based counterpart to NPS.^[23]
• Regulated or contested: inferring emotion from customers’ voices (EU duties phase in until December 2027);^[45] replacing surveys with inferred satisfaction for every interaction; publishing NPS to investors, which Bain says has added to confusion without an explanation of the process.^[23]

• What it is: signal → owner → fix → measured effect, across the journey; the label is ambiguous.
• Decide: build CXOps only when journeys cross teams and someone funds fixes.
• Practise: signal register, owned journey maps, survey specs under change control, two loops, monthly council.
• Measure: closed-loop rate, issue linkage, effect verification, journey outcomes, NPS/CES with n and interval, survey burden.
• Watch out: trigger changes, nonresponse, bonuses on scores, unverified fixes, emotion analytics.
• Next action: add n and interval to every score you publish this month.

Situation (illustrative). A telecom company’s twice-yearly relationship NPS has a 12% response rate. A vendor offers sentiment scores for 100% of chats and calls, coded by a language model, and suggests retiring the survey.

Option A: retire the survey; coverage jumps to everyone who contacted the company, with no survey burden and daily data. Option B: keep a smaller random-sample survey (chasing some nonresponders by phone) and use sentiment as a separate signal for routing and theme discovery.

Assumptions. Most customers do not contact the company in a given month, and those who do are more likely to have problems. The vendor’s model infers emotion from voice as well as words.

Reasoning. Option A looks better because it removes nonresponse, but it swaps one bias for another: it measures only customers who made contact, and measures tone rather than a judgement of the relationship. If the model reads acoustic voice features, the EU AI Act’s emotion-recognition duties apply (privacy and compliance). Option B keeps a measure of the silent majority and uses sentiment for what it does well.

Decision. Option B, with a review: if after four quarters the survey adds no predictive value for retention beyond behavioural data and sentiment, retire it then, with evidence. Uncertainty: the answer depends on how many customers ever contact you and how well the survey predicts outcomes in your business.

After this page you should be able to:

1. Explain the three meanings of “CX operations” and the editorial distinction this Atlas uses.
2. Design a survey specification that names the decision it feeds.
3. Compute and interpret NPS with an interval and test a change between periods.
4. Design inner- and outer-loop processes with owners and metrics.
5. Diagnose a score change caused by the instrument rather than the experience.
6. Decide whether an organisation needs a CXOps function.

“CXOps” is not a settled discipline. What is settled is the work beneath the label: hearing customers across the journey, getting each problem to someone who can fix it, and checking that the fix worked. The hard parts are not the survey tool but ownership across teams, error bars on every score, no pay on scores, and verified effects before victory is declared. An operation that does those four things earns the right to ask customers for more of their time; one that does not should ask less.

Every source below was opened on 2026-10-23; dates are the source’s own. Claim-level support, caveats and sources that could not be fetched are in the evidence ledger (research/cxops-ledger.md).

Changelog:

• 2026-10-23, first version (labs executed locally).
• 2026-10-23, revision 1 after independent review r1 (AI Act high-risk status, sources, glossary, Lab 3 clock rule, figures); details in reviews/cxops-r1-response.md.
• 2026-10-23, post-score polish: AI Act and GOV.UK precision, worked effect review, repetition trimmed (reviews/cxops-polish.md).