cx-contact-driver-taxonomylisted

# Designing a contact driver taxonomy A taxonomy exists to answer one question: **what should we fix to remove this contact?** Most taxonomies cannot answer it, because they were built from the helpdesk's default categories or the org chart rather than from why customers actually get in touch. The result is a category list that describes support and prescribes nothing. ## Diagnose the existing one | Symptom | Fault | | --- | --- | | >10% of contacts in "Other" or "General" | The taxonomy doesn't fit the contacts | | Categories map to teams, not causes | Built from the org chart | | Top category is 40% of volume | Too coarse to act on | | Nobody can name an owner for a category | It describes a topic, not a driver | | Categories haven't changed in three years | Not maintained; drifted from reality | | Agents pick the first plausible option | Too many, too deep, or too ambiguous | | Analysts don't use it | It doesn't predict or explain anything | ## The distinction that makes a taxonomy useful **A topic is what the contact was about. A driver is the cause you could remove.** | Topic (weak) | Driver (actionable) | | --- | --- | | Billing | Charged twice after a failed-payment retry | | Delivery | Tracking page shows "delivered" before it arrives | | Account | Password reset email lands in spam | | Refunds | Refund ETA in the app contradicts the policy | Every row on the right names something a specific team could change, and predicts the contact would stop. Nothing on the