Most support teams drown in the same 20 questions. Someone asks where the billing settings are. Someone asks how to invite a teammate. Someone asks what the refund policy is. The hard tickets — the ones a human actually needs to think about — are buried under them.
A well-set-up AI chatbot cuts the repetitive layer by 60–80% within the first month. That's not a hypothesis; that's what our customers consistently report, and it's what the public data from Intercom, Tidio, and Zendesk shows too. But "well-set-up" is doing a lot of work in that sentence. This post is the playbook.
The ticket-reduction math
Before the tactics, it's worth understanding what you're actually optimizing. In a typical support queue:
- 50–70% of tickets are repetitive — the same 20 questions, asked in different words
- 20–30% are semi-unique — they need specific account info but follow a template
- 5–15% are genuinely novel — they need judgment, tone, or a real decision
An AI chatbot can realistically handle the first bucket (50–70%) with a good knowledge base, and the second bucket (20–30%) with integrations that let it look up customer context. The novel bucket should always go to a human — attempting to automate it erodes trust fast. So the ceiling on AI deflection is roughly 70–80% of your current ticket volume.
Step 1: Stop calling it "deflection"
The word "deflection" is the biggest mistake in this space. It frames AI as something that keeps tickets away from humans — which makes the team measure it by how many tickets didn't happen, which pushes teams to make the bot hard to escape from.
The right frame is first-touch resolution by AI. That one word change shifts the optimization from "reduce ticket count" to "make the visitor's first message the one where they get their answer." Different behavior, different product, different outcome.
Step 2: Write your top 20 KB articles before you launch
The single highest-ROI investment in an AI chatbot rollout is writing short, specific knowledge base articles for your 20 most common support questions — before the bot goes live.
How to find the 20: open your current support inbox, sort by month, tag every conversation with one of 30 topics, count. Done in a day. Every platform from Zendesk to Intercom to Dchat has the raw data; you're just asking "what patterns do I see?"
What makes a good KB article for AI:
- One question per article. Don't combine "how do I upgrade" with "how do I cancel" — the AI will mash the answers together.
- Lead with the specific answer, not the context. "Upgrade from Settings → Billing → Change Plan" beats "If you're thinking about upgrading, we have several options available to suit different needs..."
- Name things the way visitors name them, not the way your product team names them. If users say "password" but your product team calls it "credentials," title the article with "password." Match visitor vocabulary.
- Short is better than comprehensive. 150–300 words each. Comprehensive articles confuse the AI and bury the actual answer.
Dchat's knowledge base pulls from manual articles, imported URLs, or a site crawl — most teams start with the top 20 as manual articles and add crawled content for breadth.
Step 3: Set proactive triggers on the pages where questions happen
Reactive chat (only responds when clicked) captures maybe 2% of possible conversations. Proactive triggers — where the bot sends a message based on context — can push that to 10–15%.
The four proactive triggers that work in almost every industry:
- Pricing page, 30 seconds on page. "Want a comparison with [competitor]?" or "Questions about any plan?" — catches high-intent visitors who are about to bounce.
- Docs page, scroll past 70%. "Stuck on something? I can help." — catches people who are trying to self-serve and failing.
- Checkout page, 60 seconds with no action. "Need help completing your order?" — directly recovers abandoned carts.
- Returning visitor on any page. "Welcome back. Pick up where you left off?" — reactivates visitors who didn't convert the first time.
Don't stack all four. Start with the one that fits your business model, measure the lift, then add the next.
Step 4: Make the human handoff feel invisible
The moment where AI hands off to a human is the most important UX in the entire product. Done well, the visitor doesn't notice. Done badly, they feel shipped around and churn.
Three things matter:
- Same thread, no re-introduction. The human picks up in the same conversation window. The visitor doesn't have to explain what they already said.
- Context preservation for the agent. The agent sees the full AI transcript with the moment AI hit its limit highlighted. They know exactly what's been tried.
- Transparent but not awkward. A line like "Let me bring in a teammate" signals the handoff without making it feel like AI failed. Avoid: "I can't help with that, connecting you to a human."
Every modern AI chat platform claims same-thread handoff. Not all of them deliver. Ask to see a live demo where you request a human mid-conversation and watch what the visitor sees.
Step 5: Handle the cases AI should never touch
Some questions should always go to a human. Hard-code them:
- Anything involving billing changes, cancellations, or refunds
- Anything involving account access (password resets are the exception — those are safe to automate with verified flows)
- Technical questions that require real-time system lookups the AI can't do
- Any message matching escalation keywords: "manager," "complaint," "lawyer," "unacceptable"
- Conversations where the visitor has already expressed frustration
In Dchat these are configured as routing rules in the workspace. Most platforms have an equivalent. Set them on day one — don't wait to discover the problem via an angry tweet.
The three metrics worth tracking
Once the bot is live, the temptation is to watch 40 metrics. Three actually matter:
- AI-only resolution rate. Percentage of conversations AI resolves without a human. Target 60–80%. Below 40% means your knowledge base is too thin. Above 90% means you're probably trapping people who should have been escalated.
- CSAT on AI-only conversations. If visitors rate AI-resolved conversations 4+/5, deflection is real. If ratings drop below 3.5, the bot is "resolving" conversations by making visitors give up — a different, worse problem.
- Handoff-to-first-human-reply time. When AI escalates, how long until a human actually responds? Under 5 minutes is excellent. Over 30 minutes is where visitors start churning mid-conversation.
Ignore raw ticket count as a success metric. Ticket count goes down when you set up an AI chatbot regardless of whether it's working well — visitors give up and leave. CSAT tells you if they're leaving happy or leaving frustrated.
What "70% reduction" actually looks like in practice
A typical rollout timeline for a 5-person support team handling 800 tickets/week:
- Week 1: Launch with 20 KB articles + proactive triggers on pricing and docs. Expect ~30% AI-only resolution. CSAT probably uneven — that's normal.
- Week 2–3: Read every AI-only transcript. Find the 15 questions AI answered badly; write articles for them. AI-only resolution climbs to ~50%.
- Week 4–6: Tune proactive triggers based on conversion data. Add escalation keywords based on real frustration signals. AI-only resolution settles at 60–70%.
- Month 2–3: Add account-lookup integrations so AI can answer "where's my order" type questions. Gets to 70–75%.
Your team shifts from answering 800 repetitive questions a week to having real conversations about the 200 that actually need judgment. That's where the ROI shows up — in what your team spends their day on, not just the ticket count.
Try it on your own site
Dchat's free-forever tier is designed for this playbook. One site, 500 AI messages a month, same-thread human handoff, knowledge base with site crawl, proactive triggers. See how it fits your support volume before spending a dollar.