Weekly Complaints Risk Review

---
name: weekly-complaints-risk-review
description: "Weekly legal and conduct risk review of complaint-tagged customer conversations. Reads a chosen week of complaints through the Rippit connector, rebuilds each complaining customer's recent contact history into one timeline, and flags serious cases that compound or were mishandled against the risk signals you configure. All findings are phrased as potential exposure for a specialist team to review, never as a legal conclusion. Delivers a structured summary to your chosen destination or back in the chat. Use whenever the user says \"weekly complaints run\", \"complaints risk review\", \"check complaints for legal risk\", or asks whether repeat complainers or missed welfare signals add up to exposure, even if they don't name the skill."
---
# Weekly Complaints Risk Review

Weekly review of complaint-tagged conversations. A single chat usually looks like venting. Added up over a recent window, the same customer's contacts can show a pattern that matters: unanswered substance, a threat closed without a reply, or a welfare signal that was met with the wrong response.

All output is phrased as **"potential exposure for your Compliance/Legal team to review"**, never as a legal conclusion. Do not say a case is actionable in court.

## First run — make it yours

**Look first, before asking anything.** Inspect what the user actually has connected:
- List the available data sources with `list_data_sources`.
- For the most relevant conversation table, call `describe_table` and note the columns that could satisfy each parameter: a topic/category column (for {{complaint_category}}), a creation timestamp (for the date window), a customer identifier such as an email column, a spend or deposit metadata block, and any complaint-subtype field.
- If the connected data is missing something the skill fundamentally needs (no category field, no per-customer identifier, no timestamp), say so plainly now and ask how to proceed rather than running the interview into a dead end.

**Then ask, one question at a time, leading with what you found and proposing a default:**
1. {{complaint_category}} — e.g. "Your source has a topic-category column; which value marks the conversations you want reviewed?"
2. {{date_window}} — "What window should each run cover by default?"
3. {{lookback_days}} — "How many days of each customer's prior history should be rebuilt into their timeline?"
4. {{risk_signals}} — "What signal categories should I score against?" (see note below)
5. {{output_destination}} — "Where should the finished summary go?"

For {{risk_signals}}, offer the author's two-group example as a default the user may adopt or replace: a **legal/regulator path** (lawyer correspondence, explicit threats of lawsuit/court/ombudsman/regulator/chargeback, a formal complaint closed without a reply, the customer's central argument never answered, an escalation requested and ignored) and a **customer-welfare group** (distress about time or money, very high or accelerating spend met with no welfare check, a loss-chasing message answered with a promotion, extreme contact frequency). Ask which categories matter to them.

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

## Data sources
- The Rippit conversation table discovered on first run. Call `describe_table` to re-check column ids each run.
  - Category filter: the category column = {{complaint_category}}.
  - Date: filter on the conversation-creation timestamp, NOT a last-updated field — bulk operations re-touch old conversations and a last-updated filter returns stale chats.
  - Customer key: the identifier column. Some customers carry two identifiers (e.g. two email addresses): group them as one customer.
  - If a summary column is empty for these conversations, read transcripts instead.
- `read_conversations` (max 10 IDs per call). Each result carries a metadata block with spend, deposit and balance figures, level, brand and country — use it for spend and welfare context.
- The conversation system's own API as a fallback for contacts the Rippit workspace lacks.
- The messaging connector for {{output_destination}}.

## Workflow

1. **Pull the week.** `read_table` with the {{complaint_category}} + creation-timestamp BETWEEN filter (limit 200+). Group rows by customer (merge multi-identifier arrays). Report chat count and distinct customer count.
2. **Pull context.** Run `aggregate_table` grouped by customer over `[window_end - {{lookback_days}}, window_end]`, once for complaints only (count per customer) and once for all categories (total contacts). Heavy contact counts are a risk signal on their own.
3. **Triage into a read list.** Read in full: (a) every customer with 2+ complaints in the window, (b) every chat mentioning legal/regulator/lawyer/chargeback, (c) every sender that looks like a firm (non-customer email, law-firm signature), (d) top spenders and anyone with a welfare signal. List chats not read as "metadata only". Never imply full coverage.
4. **Build a timeline per customer** (dates, channel, who handled it, outcome). Judge each customer as ONE story, not chat by chat. If sub-agents are available, run one per customer; otherwise do it inline.
5. **Score** using {{risk_signals}}. Keep only serious customers: patterns that compound or were mishandled. Drop one-off venting that was answered correctly.
6. **Deliver** the report to {{output_destination}} (format below), then tell the user where it landed and the main caveats.

## Severity
- **HIGH**: explicit legal/regulator path, firm correspondence, unanswered formal complaint, or a welfare failure met with the wrong response.
- **MEDIUM**: compounding complaints or heavy spend with no explicit threat, or a slow/boilerplate reply.
- **LOW / reviewed**: mention in one line so the reader knows it was checked.

## Report format
Plain markdown. If the destination limits message length, split into multiple messages (a thread reply where supported).

Header: `**Weekly complaints risk (<window>)**`
Then:
- **Scope** line: chats, customers, how many read in full, the lookback window, and the "potential exposure, not a legal conclusion" disclaimer. Include the conversation link pattern once.
- **A. Legal / regulator path**, numbered, each with: customer identifier (brand, country), severity, 2-4 bullets of what happened (dates, amounts, short quotes), the failure, and conversation IDs.
- **B. Customer welfare**, same structure, plus spend/net-loss figures and what the agent offered.
- **MEDIUM**, **Reviewed, lower risk**, **Not read (metadata only)** with unread repeaters.
- **Regulatory frame** (one short paragraph, flagged to verify against primary source text).
- **Suggested next steps** grouped by team.
- **Limits** line: anything not covered, missing data, tools unavailable.

Keep quotes short. Customer identifiers and amounts are personal data: do not repost the content elsewhere without asking.

## Rules
- Never contact customers, add notes, or change any ticket. Read-only except the delivered report.
- Do not post to a shared channel or tag people unless the user confirms.
- State clearly what was and was not read. If a figure comes from a metadata block, say so.
- Attachments are usually unreadable via the tools: say so and tell the specialist team to open them in the source system.
- If the table, columns or date window return nothing, say so rather than guessing.