CX Early Warning

---
name: cx-early-warning
description: "Run a weekly CX early-warning check in Rippit — detect customer issue themes that are new or accelerating versus the prior four weeks, screen out classifier and tagging artifacts, and deliver the result to your chosen destination with verifiable ticket references. Use for 'early warning', 'what's new this week', 'any emerging issues', 'new themes', and regression or incident spotting between periodic readouts. Reads conversation data through Rippit, applies regime/composition/breadth guardrails, text-trends free-text summaries to catch themes tags would miss, enriches affected conversations for mechanism-level root cause, and reports only concentrated, verifiable moves. A clean 'nothing new fired' is a valid result."
---
# CX Early Warning

Catch regressions and incidents weeks before they'd surface in a periodic readout, by comparing a recent window against the prior four weeks.

**A clean "nothing new fired" is a valid and valuable result.** Do not manufacture a finding. The credibility of this check comes from it staying quiet when nothing is wrong.

## First run — make it yours

Before asking anything, LOOK at what is connected. List the available data sources. Describe the one or two tables most relevant to a conversation-level early-warning check, and note which columns could satisfy each parameter below: a date/timestamp field, a free-text summary field, a category or status field, an identifier, a source/channel field, and a place to deliver the report. If the connected data lacks something this skill fundamentally needs (e.g. no free text to trend, or no date field), say so plainly and ask how to proceed rather than running into a dead end.

Then ASK ONE QUESTION AT A TIME, leading with what you found and proposing a default. Substitute the real source, table and column names you discovered — never ship a literal placeholder.

1. **{{data_source}}** — which table is the input? (Propose the source you found.)
2. **{{date_column}}** — which column is the ticket date for windowing?
3. **{{text_column}}** — which free-text column to text-trend (independent of tags/classifier)?
4. **{{category_field}}** — which field carries the issue category for composition analysis?
5. **{{dissatisfaction_definition}}** — how is a dissatisfied conversation defined? (The author used the two lowest CSAT scores plus unresolved exits.)
6. **{{ingestion_lag_days}}** — how many days does ingestion lag? (Author used ~2.)
7. **{{normal_daily_volume}}** — what daily volume is normal, to spot half-loaded days?
8. **{{root_cause_values}}** — roughly how many root-cause values should enrichment allow?
9. **{{failure_type_values}}** — which failure-type buckets to classify into?
10. **{{output_destination}}** — where should the report land?
11. **{{schedule}}** — when and in which timezone should the scheduled run fire?

After the interview, restate the filled-in bindings for confirmation, then run. On later runs, reuse them unless the user asks to change them.

## Source

Read conversation data from {{data_source}} through the Rippit workspace. Relevant fields (map to the columns you confirmed on first run):

- {{date_column}} — ticket date
- {{text_column}} — text summary, the artifact-proof trend signal
- {{category_field}} — issue category for composition
- a predictive/CSAT or satisfaction score used by {{dissatisfaction_definition}}
- an internal ID and a source-system conversation ID
- a tags array (if present)
- a source/channel field (e.g. distinct systems feeding the table)
- routing cuts (group / form) if available

**DISSATISFIED** = whatever the user specified in {{dissatisfaction_definition}}.

## Windows

Ingestion lags ~{{ingestion_lag_days}} days. Recent window = 7 days ending (today − {{ingestion_lag_days}}); baseline = the 4 weekly buckets before it.

Verify the lag every run: pull daily counts and confirm the last included day sits at normal volume (~{{normal_daily_volume}}). If it's low, shift the window back. Skipping this reads a half-loaded day as a volume collapse.

## Three guardrails — do not skip

Conversation classifiers and tag vocabularies drift. A naive week-vs-baseline comparison fires dozens of false alarms.

**1. Regime check (first).** Compute the neutral (mid) score share per week over ~8 weeks. If neutral share moves >~8 points across your comparison boundary, absolute dissatisfaction rates **are not comparable**. Say so, and rely on composition.

**2. Composition, not absolute rate.** Compute each category's share *of the dissatisfied population* per week (category dissatisfied ÷ all dissatisfied that week). This is robust to a classifier moving its threshold, because it asks "of the unhappy customers, what were they unhappy about". Compare the recent week against the mean of the 4 baseline weeks.

**3. Breadth test.** A move across most or all categories at once is a pipeline change, not a customer event. A real incident is **concentrated** in one or two. Only escalate concentrated moves.

Also screen for **mean reversion**: a category rising back to its level from 5–6 weeks ago is not news. Check the pre-regime level before calling anything a rise.

### Tag taxonomy caveat

Tag vocabularies can change mid-window. Before comparing raw tag combinations, spot-check 2–3 high-volume combos for week-over-week continuity. If the vocabulary shifted inside your window, don't report tag-level "new themes" — note it and lean on text trending. If tags carry more than one vocabulary (e.g. different formats per source system), segment by the source field before comparing.

## The step that actually catches new themes

**Text trending on {{text_column}}** is independent of both the tag taxonomy and the score classifier, making it the most reliable detector. Use a case-insensitive substring match and aggregate weekly counts over ~10 weeks.

Workflow: read recent dissatisfied conversations, notice distinctive recurring phrasing, then trend that phrase. A several-fold jump against a flat baseline that keeps climbing is a genuine new theme. Composition analysis alone tends to surface *chronic* issues and can miss a fast-rising new one — always confirm a candidate this way before reporting it.

## Name the root cause

For whatever survives the guardrails, create a worksheet of the recent week's dissatisfied conversations in the affected categories, then enrich in **one call** (cost scales with rows, not columns):

- **Root Cause** — `unspecified_enum`, ~{{root_cause_values}} values. Demand mechanism-level specificity, not a restatement of the category. Good: "benefit eligibility check failed even though the partner confirmed enrollment". Bad: "partner inquiry".
- **Failure Type** — `enum` over {{failure_type_values}}.
- **Newly Broken Signal** — `boolean`. True **only** when the customer says it worked before, stopped working, or started recently. Require explicit language; forbid inferring from topic. This is the sharpest early-warning indicator — expect a small share true, and a cluster inside those is the story.
- **Account / Partner** — `string`, else "not named". Detects concentration in one account or partner program.

Pass the category as a context column. Poll `get_enrich_status` in a loop until `done: true`. Then `read_conversations` on 3–5 newly-broken tickets for real verbatims.

## Key conversations are required

Every flagged theme carries a table of **3–5 specific tickets** so the reader can verify the finding rather than taking the aggregate on faith. Read each conversation before listing it. Per row:

- **Ticket ID, hyperlinked** so it is one click to open. Pull the external ID and source, and build the link from the confirmed link shape for that source system. Never print a bare unlinked ID, and never invent a link shape you haven't confirmed from the data.
- **Predictive/satisfaction score.**
- **One line on why it's worth reading** — the clearest case, the tightest timeline, the best proof it's a bug rather than policy, the simplest reproduction, the worst handling.

Make each row earn its place; five interchangeable tickets are worse than three distinct ones. Order most-useful-first, prefer `Newly Broken Signal = true`, and add one line on what the set has in common (all bot-handled, all one partner, all one region).

## Include the handling / QA angle

How an issue was *handled* is often more actionable than the issue. For each real theme, note whether any bot escalated, whether it recited policy correctly while missing the customer's actual problem, and whether chats closed prematurely. The handling failure is frequently the more fixable half of a finding.

## Output — deliver to {{output_destination}}

Deliver one report to {{output_destination}}. Compact, scannable, markdown, real markdown tables (never ASCII art).

1. Title with the period + metadata line (window, conversations in scope, lag exclusion)
2. One-line verdict: how many new themes fired
3. Per real theme: small metrics table (volume, baseline, multiple, week-by-week trajectory, dissatisfaction vs overall), mechanism in plain language, 1–2 verbatims as blockquotes, the handling angle, the Key conversations table, suggested owners
4. **"Looks alarming but is NOT real"** — artifacts and mean reversion, one-word verdict each. Include even when short; this is what makes the check trustworthy
5. Closing line naming what was checked and stayed flat
6. Worksheet link, noted as generated with Rippit

Never expose column names, filter expressions or query syntax — describe filters in plain business language. Never hand-compute a figure; take every number from a tool result and use a script for arithmetic.

When nothing fires, send a short message saying so with the flat-trend evidence and any data-quality notes — no Key conversations table needed.

## Scheduled task

Runs on {{schedule}}. The task prompt is self-contained but defers to this skill when present, so improvements made here take effect without editing the task.