Contact-Driver Tagger

The problem this kills

Your leadership keeps asking the same question: "Why are contacts going up, and what would actually bring them down?" And every quarter you answer it with a guess, because nobody has time to read 4,000 tickets and code them by hand.

So you fall back on the ticketing tool's built-in categories - the ones agents pick from a dropdown while they're racing a handle-time target. Those categories describe the symptom ("billing question") not the driver ("customer charged twice after a failed retry"). They drift. They get renamed. Half of them say "Other." You can't trend them, you can't compare quarter over quarter, and you definitely can't walk into a budget meeting and say "fix this one thing and we remove 9% of our volume."

The result: the contact-reduction case never gets funded, because it never gets made with numbers anyone trusts.

What you'll build

A small, private web app that turns a pile of ticket text into a trustworthy, trended view of why customers contact you:

• Load a CSV or Google Sheet of tickets (subject + body + ticket ID).
• Tag each ticket to a contact driver from your controlled taxonomy - the AI reads the ticket, proposes the best-fit driver, separates the surface symptom from the underlying root cause, and flags tickets it's unsure about or that might need a brand-new driver code.
• Approve as a human gate: an analyst reviews the AI's assignments and any proposed new codes, fixes what's wrong, and only approved codes count.
• Trend the approved data into top drivers, period-over-period movement, and the "if we fixed this, we'd remove N contacts" view leadership wants.
• Export / email a clean report so the numbers land in the right inbox on a schedule.

What's inside the Implementation Plan

The plan is a single file you paste into an AI coding agent (Claude Code), and it builds the tool with you step by step - no prior coding needed.

It opens by interviewing you about your business. Before a single line is written, the plan makes the agent ask about your current process, your ticketing system and exports, the exact column names in your data, your typical and peak ticket volumes, and - most importantly - your contact-driver taxonomy and the rules for what counts as which driver. It reads back a short tailored spec, you confirm it, and then it builds a tool shaped to how you actually work. This is not a generic template you have to bend to fit.

Inside you'll find:

• The full discovery interview, written out question by question.
• A data model built around a locked taxonomy (so this quarter is comparable to last quarter) and a symptom-vs-root-cause split.
• Copy-paste prompts for every build step, starting with applying your interview answers.
• The AI tagging step, the analyst review-and-approve screens, and the trend/report builder.
• A "No API yet?" fallback that reads a ticket CSV and writes a coded, summarized report - so you can ship value this weekend with zero integration.

The governance it includes (this is the point)

This isn't a script that quietly rewrites your reporting. Governance is built in from the first commit:

• Login so only your team can open the tool.
• Row-level security so each organization only ever sees its own tickets and codes.
• A human approval gate - the AI only ever drafts a driver; nothing feeds reporting until an analyst approves it, and proposed new driver codes need explicit sign-off so the taxonomy stays stable and trendable.
• A complete audit trail - who tagged, who approved, what changed, and when.
• Duplicate guards keyed on ticket ID, so the same ticket can't be coded twice and inflate your counts.

Who it's for

Support-ops analysts and CX leaders who are tired of arguing about contact volume with bad data and want to walk into the budget meeting with a defensible, trended contact-driver report - and who'd rather build the exact tool they need than wait for a vendor roadmap.

You've got this - open the plan, paste the first prompt, and let the interview tailor the build to your support org.