Brand Specific Weekly Conversation Drill-Down

# Weekly Support Conversation Drill-Down

A recurring weekly analysis of a brand's customer support conversations and emails, built in Rippit. It builds issue themes bottom-up from the actual data, and verifies every critical/escalation claim against real transcripts and per-account Slack searches — never assumptions or keyword matches.

## First run — make it yours

Before pulling any data, interview the user one question at a time, then restate the filled-in settings for confirmation before running. On later runs, reuse these unless the user asks to change them.

1. Which brand or account should this drill-down cover, and what data value identifies it, so we don't conflate it with sibling brands? -> {{brand_filter}}
2. What weekly window do you want each run to cover? Default is last Friday through yesterday (Thursday). -> {{date_window}}
3. Which issue buckets do you want detailed treatment on, with everything else rolled into an Other bucket you still scan for repeat patterns? -> {{in_scope_categories}}
4. Where should I keep the running trend-memory note between weeks — an existing note to reuse, or a fresh one on the first run? -> {{memory_note}}
5. Are account/backoffice links approved for inclusion in this report, or should they be masked given they're sensitive data? -> {{backoffice_link_policy}}
6. How many parallel sub-agents am I authorized to fan out per run? -> {{subagent_cap}}

## Before starting: security

Account links and player/customer data may be sensitive. Only include {{backoffice_link_policy}}-approved links in the report; otherwise mask them.

## Step 0: Confirm the date range

Use {{date_window}} (default: last Friday through the most recent Thursday). Confirm the brand filter is {{brand_filter}} — treat this as distinct from any sibling brands in the same underlying data, and verify the brand value on every record you cite (the backoffice-link domain is often the only reliable brand signal, especially on cross-referenced tickets).

## Step 0.5: Load last run's memory FIRST

Before pulling data, read the trend-memory note ({{memory_note}}) directly by its stable id; if that 404s, search for it by title and update the reference. This condensed, running tracker of recurring bugs and carryover cases lets a fresh conversation know what was already flagged without re-reading old reports. Use it to: check carryover tickets for continuation, know which bugs already have a confirmed root cause and Slack thread (so you go straight to "is this still happening"), and avoid re-litigating resolved items. If it doesn't exist yet (first run), skip and create it at the end.

## Step 1: Pull the data (Rippit MCP)

1. `list_data_sources` -> find the MAIN table (conversations/tickets).
2. `describe_table` -> confirm column ids (external_id, first_seen, backoffice-link column, user email, source_type).
3. `aggregate_table` -> volume splits: conversation vs email vs admin_initiated (exclude admin_initiated — not customer-raised).
4. `create_worksheet` -> filter to {{brand_filter}} + {{date_window}}, all columns.
5. `enrich_worksheet` -> add Issue_Category, Contact_Reason, Is_Critical in ONE call (cost is per-row).
6. `get_enrich_status` -> poll until done.
7. `read_table` / `aggregate_table` on the worksheet to pull results back.

## Step 2: Build categories bottom-up

Don't start from a fixed taxonomy. Read a sample of the actual AI Contact Reason summaries and name themes after what's genuinely happening that week (e.g. "Deposit below the real minimum, silently rejected", not just "Deposit issue"). Give detail on the {{in_scope_categories}} buckets; route everything routine to Other, but still scan Other for repeat patterns worth naming. For each theme, note count, number of distinct players, and example ticket ids.

## Step 3: Critical-flagging rules

- Do NOT flag scam/fraud/"didn't win" accusations as critical without actual corroborating proof; a specific checkable technical explanation from the agent counts as the issue being explained, not proof of wrongdoing.
- A closure/self-exclusion request is Critical ONLY when driven by a genuine withdrawal/deposit/game/bet/technical fault that looks like the operator's fault — NEVER when the reason is luck, a losing streak, or RG sentiment, even if mishandled. The trigger is operational fault, not player upset.
- If a loss/RG/luck-driven closure was mishandled (never applied, RG question ignored), flag it as a "Compliance / Process Gap" item (its own section, `compliance` style, `is_critical_verified: false` with a `critical_note`), not Critical.
- A case is genuinely Critical when (a) a real unresolved fault has no proof of escalation, or (b) there's concrete corroborating evidence (Jira ticket, Slack thread, agent admission) an operational fault went wrong and stayed wrong.

## Step 4: Escalation verification

For every case cited as critical, escalated, or a confirmed bug:
- Never assume a resolution or escalation. Pull the real transcript with `read_conversations` and quote what the human agent (author_type "agent", never "bot") literally said about cause and next steps.
- Use the agent's own stated reason to judge real issue vs player-side mistake, unless the transcript contradicts it.
- Search Slack using the player's exact account/backoffice link as the literal query string; if empty, fall back to `players/<id>` then the bare numeric id, in that order, before concluding there's no record. Generic theme searches produce false negatives.
- Before citing any cross-referenced (e.g. Jira) ticket, confirm its embedded link domain matches {{brand_filter}}.
- Report per player/per-ticket, not per-theme — a theme can mix escalated-confirmed, escalated-unconfirmed, and not-escalated.

Note: `read_conversations` on a busy ticket can exceed a tool call's output cap; if so, read the saved local file paginated or grep with a narrow (<=300 char) window.

## Step 5: Token efficiency via memory

Same quality, fewer tokens — the memory note is the lever, not shortcuts on rigor. Don't re-diagnose bugs the note already has a confirmed root cause for (ask only "is this still happening, to whom, fixed yet"). Sample fewer tickets once a pattern is established (2-3 representative instead of 5-6). Consolidate players into fewer, slightly larger clusters by shared root cause. Skip Slack searches memory already answered (single confirmation search). Don't full-scan the Other bucket every week — aggregate and sample. Reuse known column ids and worksheet structure. Track your own sub-agent token totals run over run.

## Step 6: Scale via sub-agent fan-out

Dispatch up to {{subagent_cap}} `general-purpose` sub-agents in parallel, each covering a small cluster of 1-5 related players/tickets (fewer, larger clusters where memory suggests a shared root cause). Each prompt must be fully self-contained and instruct the agent to: (1) `read_conversations` for the given ticket ids; (2) quote only literal human-agent messages about cause and escalation; (3) search Slack by the exact account link with id fallbacks — never generic keywords (single-shot confirmation if memory already confirmed the thread); (4) return structured JSON (external_id, chat link, backoffice link, agent quote, escalation-language flag, Slack result). Launch each batch in a single message.

## Step 7: Build the report

Produce a 6-sheet .xlsx from JSON inputs (flagged rows with per-row Specific_Theme, notable other-bucket themes, top repeat contacts, and verified per-player findings):
1. Summary — narrative grouped by theme, prose bullets, every example with inline backoffice + chat link, clearly distinguishing "confirmed via transcript + Slack" from "not yet verified"; Compliance/Process Gap items in their own section.
2. Slack & Jira Cross-Check — one row per player/case with the agent's actual words, the exact-player Slack result, and a verdict.
3. Conversations - Flagged — ticket-level detail for the in-scope categories with verified critical flag (apply Step 3 corrections).
4. Emails - Flagged — same, emails only.
5. Other Bucket - Notable Themes — with links and explicit verified-escalation-status per theme.
6. Top Repeat Contacts — ranked by total contacts per account with a verified judgment per player.

## Step 8: Update the memory note (every run, including the first)

Update (don't replace or endlessly append) the {{memory_note}} note. Keep it condensed as a trend tracker: Known Recurring Issues, Carryover Individual Cases, Confirmed Bugs With Engineering Tickets, and Resolved / Stop Watching. Prune aggressively so the note stays roughly the same length week to week.

## After delivering

Present the finished .xlsx and keep the chat summary concise: what changed from a standard week, what's newly critical vs downgraded, and anything that could not be verified — flag it rather than smoothing it over. Mention the sub-agent token delta versus last week if available.