{"id":89244,"plugin_id":"plugin_asdk_app_6a860a7e55888191a2186b19e03fe4b1","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-11-10T15:20:16.859Z","digest":"136c253b310fca3eb8b4464fdfaf971b28322e3748211bb50848727f379d37c1","against":null,"payload":{"description":"Build and run a repeatable \"ticket-insights\" QA program that measures something meaningful on EVERY support ticket — contact reason, root cause, avoidability, resolution quality, product signal, and churn/at-risk — instead of just scoring agents. Use this whenever the user wants to redesign, rebuild, or stand up a QA or support-analytics program; shift QA from agent scorecards to ticket/insight focus; systematically tag, classify, or score every ticket; find contact drivers, avoidable volume, product feedback, or at-risk accounts from support conversations; or set up a recurring support-insights readout. Trigger even if the user doesn't say \"QA\" — e.g. \"what should we measure on every ticket\", \"turn our support tickets into insights\", \"find what's driving contacts\", \"which tickets put revenue at risk\". Works with ANY helpdesk or conversation data source and ANY set of connectors; do not assume a specific integration.","included_files":[],"name":"rippit-qa-program-revamp","skill_md_contents":"---\nname: rippit-qa-program-revamp\ndescription: >-\n  Build and run a repeatable \"ticket-insights\" QA program that measures something\n  meaningful on EVERY support ticket — contact reason, root cause, avoidability,\n  resolution quality, product signal, and churn/at-risk — instead of just scoring\n  agents. Use this whenever the user wants to redesign, rebuild, or stand up a QA\n  or support-analytics program; shift QA from agent scorecards to ticket/insight\n  focus; systematically tag, classify, or score every ticket; find contact\n  drivers, avoidable volume, product feedback, or at-risk accounts from support\n  conversations; or set up a recurring support-insights readout. Trigger even if\n  the user doesn't say \"QA\" — e.g. \"what should we measure on every ticket\",\n  \"turn our support tickets into insights\", \"find what's driving contacts\",\n  \"which tickets put revenue at risk\". Works with ANY helpdesk or conversation\n  data source and ANY set of connectors; do not assume a specific integration.\n---\n\n# Ticket-Insights Program Builder\n\nHelp the user design and run a QA/support-analytics program organized around the\n**ticket**, not the agent. The old model asks \"did the agent follow the rubric?\"\nThis model asks, on every ticket: *why did this contact exist, was it preventable,\ndid the customer actually get helped, and what does it tell the rest of the\nbusiness?* Agent quality falls out as a lightweight byproduct.\n\nYou are acting as a **thought partner**, not an order-taker. Push back on vague or\nover-broad goals, help the user sharpen them, and make sure every measure ladders\nup to a decision someone can own. A measure nobody will act on is noise — cut it.\n\nThis skill is **integration-agnostic**. It assumes nothing about which helpdesk,\nCRM, or connectors exist. You will discover what's available at runtime and adapt.\n\n## The core idea: measure a causal chain, not a topic list\n\nA strong per-ticket schema follows a chain, because one enrichment pass then feeds\nmany different questions:\n\n**contact reason → root cause → avoidable? → resolution outcome → product signal → customer risk**\n\n- Volume-reduction questions read *reason, root cause, avoidable*.\n- Resolution-quality questions read *outcome, effort*.\n- Product questions read *product signal, product area*.\n- Revenue-risk questions read *sentiment, churn/escalation risk*.\n\nDesign around this chain and you avoid the classic failure mode of tagging surface\ntopics that look tidy but drive no action.\n\n## Workflow\n\nFollow these steps in order. Use a task list to track them. Don't skip the\nelicitation step (Step 2) — getting the goals right is the whole game.\n\n### Step 1 — Discover the data and connectors (before asking anything heavy)\n\nGround the conversation in what actually exists so your questions are concrete.\n\n1. List the available source-of-truth data tables / conversation sources (e.g. a\n   Rippit-style `list_data_sources`, a data-warehouse connector, an uploaded\n   export). Inspect the schema of the most relevant ticket/conversation table to\n   see what's already captured (status, timestamps, channel, subject, agent) vs.\n   what must be derived from transcripts.\n2. Take stock of **other connectors available in this Claude session** — search\n   the connector registry and note anything that could supply business context:\n   CRM/Salesforce/HubSpot (account value, ARR, tier), help center (docs to\n   reconcile against), Slack/email (escalations), product analytics. You will use\n   these later to enrich and to size at-risk tickets.\n3. If no ticket data is reachable at all, say so plainly and offer paths: connect a\n   helpdesk/warehouse connector, or upload an export. Don't fabricate data.\n\nReport back briefly: what data you found, roughly how much (row count / date\nrange), and which connectors could add business context.\n\n### Step 2 — Elicit goals and focus areas (REQUIRED, use a structured question)\n\nDo not design the program from assumptions. Use the environment's structured\nquestion tool (e.g. `AskUserQuestion`) to ask — and always include these two:\n\n1. **What do they want to measure in the new program?** Offer the common goals as\n   selectable options (they can pick several), and make clear these drive which\n   columns get built:\n   - Cut contact volume (reason, root cause, avoidability)\n   - Improve resolution quality (outcome, effort, reopens)\n   - Surface product/feature signal (bugs, requests, friction, doc gaps)\n   - Protect at-risk revenue (frustration, churn/escalation signals)\n   - Agent coaching (kept as a byproduct)\n2. **Is there a particular area they want to focus on that you haven't asked\n   about?** Leave explicit room for a custom answer — a specific product line,\n   channel, customer segment, language, compliance concern, a known pain point,\n   or a metric unique to their business. This catches the thing your menu missed.\n\nAlso worth clarifying when ambiguous: who consumes the insights (support/QA lead,\ncross-functional, execs) and whether agent performance should be dropped entirely,\nkept as a byproduct, or deferred.\n\nThen reflect their answers back with a short POV: which goals are cheap to serve\ntogether, where you'd push back, and what you recommend leading with. If they\npicked everything, note that the same core measures serve all of it but the\nprogram needs one clear lead metric and owner to avoid becoming a dashboard nobody\nopens.\n\n### Step 3 — Design the measurement schema\n\nTranslate their goals into a concrete set of per-ticket measures along the causal\nchain. Start from the default set below and **adapt**: drop measures for goals they\ndidn't pick, and add measures for the focus area they named in Step 2. For each\nmeasure, note the goal it serves and the owner who'd act on it.\n\nDefault measure set (adapt freely):\n\n| Measure | Type | Serves |\n|---|---|---|\n| Contact reason (L1) | fixed categories | volume, product |\n| Contact reason (L2) | free / open-ended, clustered | volume, product |\n| Root cause type | bug / limitation / knowledge gap / UX / working-as-intended / external | volume |\n| Avoidable | self-service / product fix / proactive comms / not avoidable | volume |\n| Resolution outcome | resolved / workaround / escalated / awaiting / unresolved | resolution |\n| Customer effort | low / med / high | resolution |\n| Repeat / recurring signal | first-time / recurring / systemic | volume, resolution |\n| Product signal type | bug / feature request / usability / docs gap / none | product |\n| Product / feature area | open-ended, ~10–15 clusters | product routing |\n| Customer sentiment | positive / neutral / frustrated / angry-at-risk | risk |\n| Churn / escalation risk | none / low / elevated / high | risk |\n| Agent handling quality | strong / adequate / needs-improvement (byproduct) | coaching |\n| One-line issue summary | free text | readout fuel |\n| Customer account/company | free text, extracted from transcript | risk sizing |\n\nFor every enum, include a catch-all (\"unknown\"/\"unclear\") so rows the model can't\njudge don't get forced into a real bucket. Write instructions assuming the model\nreads the FULL transcript — root cause, whether it was truly resolved, and how the\ncustomer reacted live in the conversation, not the subject line.\n\nShow the user the proposed schema and get a quick thumbs-up before running.\n\n### Step 4 — Validate on a small sample first\n\nNever commit to a full run cold. Build a worksheet over a **representative random\nsample** (~50–75 tickets) and enrich it with the full schema in ONE pass (all\ncolumns fill together per row, so cost scales with rows, not columns — batch them).\nRead back the distributions and sanity-check that the labels are clean and useful.\nIf a measure is producing mush, fix its instructions or enum and re-run just that\ncolumn before scaling.\n\nPresent the pilot results as proof the framework works, and confirm scope for the\nfull run (which source, what time window).\n\n### Step 5 — Run at scale\n\nRun the same enrichment across the agreed population (e.g. \"all tickets, last 90\ndays\"). Poll the job to completion — don't ask the user to check back later. Then\ncompute the real distributions with aggregation queries (never hand-transform\nnumbers that will appear in a deliverable).\n\n### Step 6 — Connect business context (esp. for at-risk sizing)\n\nIf protecting revenue is a goal, size the at-risk tickets by account value using\nwhatever is reachable — this is where the connector discovery from Step 1 pays off:\n\n- If a CRM/warehouse carries account value/ARR/tier keyed by account or domain,\n  extract each ticket's account (from metadata if present, else from the\n  transcript) and join to it.\n- Be honest about coverage. Report matched exposure as a **floor**, name what\n  couldn't be matched, and recommend the connection that would close the gap\n  (e.g. connect the CRM directly, or map a company ID).\n\nIf no business-context source exists, still deliver the at-risk *queue* (accounts\n+ issue + risk level) and note that value-sizing needs a CRM connection.\n\n### Step 7 — Deliver the report\n\nWrite an executive-quality, scannable report. If the environment provides a report\nformat guide (e.g. a `get_report_guide` tool), read and follow it. Lead with the\nanswer; use a rendered visual for any multi-cut distribution rather than walls of\nprose; ground themes in real quotes/summaries; end with 2–4 owner-tagged actions\nand concrete follow-ups. Link the underlying worksheet/dataset so the reader can\ndig in. Keep a genuine niche insight only if one truly emerged — a forced insight\nerodes trust in the rest.\n\n### Step 8 — Offer to make it recurring and self-building\n\nThis is not a one-off. After delivering, **offer to schedule it** as a recurring\ntask and let the user choose the cadence (daily, weekly, monthly — their call).\nUse the environment's scheduling tool. Frame the value as compounding over time:\n\n- Each run appends to / builds on the prior data rather than starting fresh, so\n  trends emerge (is avoidable volume shrinking after a doc fix? is a new contact\n  driver rising? which product area is heating up?).\n- The recurring readout can highlight **deltas vs. the previous period** and flag\n  new at-risk accounts the day they appear, not at quarter-end.\n- Over time the L2/product-area clusters stabilize into a taxonomy the whole org\n  shares.\n\nMake the offer concrete: propose a cadence based on their volume (high volume →\nweekly; lower → monthly), state what each run will produce, and set it up if they\nsay yes.\n\n## Principles\n\n- **Adapt, don't impose.** The default schema is a starting point; the user's goals\n  and the named focus area from Step 2 should reshape it every time.\n- **Every measure needs an owner.** If you can't name who acts on it, cut it.\n- **Sample before you scale.** Cheap validation prevents an expensive wrong run.\n- **Be honest about coverage and limits.** A floor with a named gap beats a\n  confident number built on a shaky join.\n- **Build toward a habit, not a one-time report.** The recurring, self-building\n  cadence is where this becomes a program instead of an analysis.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}