What AI actually looks like in a customer success team

Customer success is one of the best places to implement AI. The work is high-volume, often repetitive in structure, deeply dependent on knowing your product, and has clear quality signals — you can tell pretty quickly whether an output is good or not.

Here's what it actually looks like when CS teams do it well.

What's genuinely working

First-draft responses to common ticket types. Not full automation — Claude drafts, a human reviews and sends. For the top five most common ticket types (account access, billing questions, how-to questions, feature requests, bug reports), this typically cuts handle time by 40-60%. The human's job shifts from writing to editing, which is faster and still catches errors.

Setup: a Claude Project with your product documentation, your tone guidelines, and instructions to always acknowledge the customer's frustration before solving. You're not replacing the human — you're giving them a strong starting point.

Summarising long ticket histories. Customer opens a ticket, it's their fourteenth interaction this year. Previously, the agent had to read through thirteen previous tickets to get context. Now: paste the history, ask Claude to summarise the situation and what's been tried. This alone saves meaningful time per complex ticket.

Drafting customer-facing documentation updates. When a feature changes, someone has to update the help docs. CS managers typically know these need updating but never have time. Paste the old doc and the release notes — Claude produces a draft. Human reviews and publishes. What used to sit on a backlog for three weeks happens in an afternoon.

What doesn't work as well as expected

Full ticket automation without human review. The teams that tried this (sending Claude's response directly to customers) saw a spike in negative CSAT for edge cases. Claude is good at typical cases. Edge cases — angry customers, unusual account situations, billing disputes — need human judgment. Keep humans in the loop for anything customer-facing.

Using Claude without product-specific context. Generic Claude giving generic answers to product-specific questions produces answers that are helpful-sounding but subtly wrong. "Claude said our API supports X, but it doesn't" is a trust-destroying experience. Connect Claude to your actual documentation before using it for product questions.

Prompting for empathy. You can instruct Claude to "be empathetic" — it will use empathetic language. But customers can often tell the difference between genuine and performed empathy. Use Claude for the informational parts; have humans handle the emotional ones.

The adoption pattern that works

Don't roll it out to the whole team at once. Start with one agent who's enthusiastic about the tool, let them work out the rough edges, and document what's working. Then expand. The early adopter's learnings — what prompts work, what the Project instructions should say, when to trust the output — are more valuable than any training you could write in advance.

The metric to watch

CSAT by ticket type. If first-contact resolution rates go up but CSAT goes down for a specific ticket type, Claude is producing technically correct answers that miss the emotional register. That's fixable — but you need to be watching for it.