Building a Zendesk Chat Bot

Most support bots fail at the same two points: they answer things nobody asked, and they trap people who need a human. A Zendesk chat bot is no different, and both are design problems.

Start free trial All guides

Messaging first, bot second

Bots in Zendesk live on the messaging channel. That means the modern web widget, the mobile SDKs and the social channels, rather than the older live chat product. If your account is still on legacy chat, migrating is the first job and it isn't a five minute one.

Messaging is asynchronous by design. A conversation can pause overnight and resume, which is a much better fit for a bot than a live session where a stalled reply feels like a hang. See the messaging guide for the channel itself.

What the Zendesk chat bot builder gives you

Zendesk's visual builder, usually called Flow Builder, lets you draw a conversation as a branching set of steps without writing code. The exact step names and which ones your plan includes have changed over time, so check the current list in the builder itself. Broadly you get:

Send a message and present options, the two steps every flow is mostly made of.

Ask for details and store the answer, so the resulting ticket arrives with a field already filled in.

Show help centre articles, matched to what the customer typed.

Branch on a condition, including business hours, so the flow behaves differently at 2am.

Transfer to an agent, which is the step that matters most and gets the least attention.

Call an external API on higher tiers, which is what turns a script into something that can look up an order.

Above the hand-drawn flow sits intent detection, which routes a free-text message to the right branch instead of forcing the customer through a menu. That capability is tier and add-on dependent.

Scope it to what you can prove

Pull your last three months of chat conversations and count the intents. You'll find a handful cover most of the volume, and that handful is your entire first release.

Three rules that hold up. Never ask more than three questions before doing something useful. Every single branch must end in either a resolution or a human. And never let the bot guess at anything involving money, policy or an apology.

A bot handling six things well beats one handling thirty things badly, and customers judge you on the worst interaction, not the average.

The handoff, which is the whole game

When the bot gives up, what happens next decides whether the customer forgives it.

Pass the transcript into the ticket so the agent can see what was already asked. Never make the customer repeat their order number. If agents are offline, say so plainly, take the details, and set an expectation for when someone will reply. Vague reassurance at midnight generates a complaint by morning.

And put an obvious escape hatch in every step. "Talk to a person" should be reachable from anywhere, immediately, without argument. Hiding it doesn't reduce contacts. It just moves them to your worst channel, angrier.

The mistakes that show up in every first build

Menus that are really a phone tree. Five options, each leading to five more. If the customer has to navigate, you've built an IVR with nicer fonts.

Asking for information you already have. A logged-in customer on your own site shouldn't be typing their email address.

Cheerfulness in the wrong place. A bot that says "Great!" after someone reports a failed payment reads badly, and people remember it.

No dead end handling. Something will fall outside every branch you drew. Decide what happens then, rather than letting the conversation just stop.

Building it once and never touching it. Your product changes and the flow doesn't. Six months later the bot is confidently describing a screen that no longer exists.

That last one is the quiet killer. Put a recurring review in the calendar, quarterly at minimum, and treat the flow as a living document rather than a project you finished.

Testing and measuring

Test in a sandbox with real transcripts, not with the polite questions you invented while building. Real customers type fragments, misspell products and ask two things in one sentence.

Then track three numbers. Containment, meaning conversations that ended without an agent. Follow-up rate, meaning how many of those people contacted you again within a few days. And CSAT on bot conversations specifically, separated from agent CSAT.

Containment on its own is a vanity metric. Containment minus follow-ups is the real one, and the gap between them tells you exactly which branches are lying to you.

FAQ

Frequently asked questions

Is Zendesk Flow Builder the same as the messaging bot?

Flow Builder is the editor; the Zendesk messaging bot is what customers meet. You draw the conversation in Zendesk Flow Builder and it runs on the messaging channel.

Do I need the paid AI add-on to build a Zendesk chat bot?

A basic flow-built bot has been available without it on Suite plans. Free-text intent detection and richer conversation handling sit higher up. Confirm what your tier includes in the builder itself.

Can a Zendesk bot look up an order?

Yes, through an API call step, on plans that include it. That step is what separates a useful bot from a menu.

Does the bot work on WhatsApp and Facebook?

Bots run on the messaging channel, which covers social messaging as well as the web widget. Behaviour varies by channel, so test each one separately.

What happens when nobody is online?

Branch on business hours. Tell the customer plainly, collect what you need, and set a realistic expectation instead of implying someone is about to reply.