Zendesk Flow Builder

Zendesk Flow Builder is a visual editor for bot conversations on the messaging channel. Easy to start, easy to build something nobody can escape from.

Where Zendesk Flow Builder flows live

Flow Builder sits on the messaging channel, which 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, that migration comes first and it isn't a small one.

A flow is attached to a specific messaging channel and brand, so a multibrand account can run different conversations on different sites. Changes are drafted and then published, and a draft does nothing at all until you publish it. Write that on a sticky note. It accounts for a good share of the "the bot ignored my change" reports.

The strategic side of bot design, what to automate and what not to, lives in the chat bot guide. This page is about the building.

The steps a flow is made of

Step names and availability shift between plans and releases, so check the palette in your own builder. It's a moving target. In broad shape you get:

Send a message. Text, and often a carousel or image. The connective tissue of every flow.
Present options. Buttons the customer picks from. Keep it to four or five, because a long menu reads as a phone tree.
Ask for details. Collect an email, an order number, a free-text description, and store it so the resulting ticket arrives pre-filled.
Show help centre articles. Matched to what the customer typed. Cheap deflection when your articles are good and irritating when they are not.
Branch on a condition. Business hours, customer attributes, values collected earlier in the same conversation.
Call an external API. On higher tiers. This is the step that turns a script into something that can look up a real order status.
Transfer to an agent. The most important step in the flow, and the one that gets designed last.

Branch without building a maze

The temptation with a visual builder is depth. Every extra question feels like precision, and to the customer it feels like an interrogation.

A rule that holds up well: three steps to a resolution or a human. If your flow needs six questions before anyone helps, the flow isn't the problem, the process behind it is.

Prefer intent detection over menus where your plan supports it. Letting someone type "where is my order" and landing on the right branch beats making them navigate to it. Intent coverage is tier and add-on dependent, and custom intents are their own project, so plan a menu fallback for everything the model misses.

Reuse branches. Several entry points converging on one authentication sequence is much easier to maintain than four copies that slowly diverge.

And don't be precious about the bot. Where the fastest honest answer is a person, say so early and route there. Customers don't grade you on how clever the automation was. They grade you on whether they got helped.

Handoff is the part that matters

Every branch needs a route to a person. Every single one, including the ones you are sure will resolve themselves. If somebody asks for a human twice, they're not going to be talked out of it, so stop trying.

Handle out of hours explicitly. Branching on business hours so the flow says "we are back at 9am, leave the details and we will reply" is a two-minute build that prevents a genuinely bad experience.

Check what carries across when the transfer happens. The full transcript should land on the ticket, along with anything the flow collected, mapped into real ticket fields rather than buried in the conversation text. A ticket that arrives with the order number in a field routes itself. One that arrives with it in paragraph four does not.

The traps

Dead ends. A branch that ends without an option and without a handoff leaves the customer staring at a widget. Walk every path before publishing.
Unpublished drafts, covered above, and worth repeating because it wastes so much time.
Testing as an admin. Test signed out, on a phone, on the real site. Your logged-in desktop test is the least representative journey available.
Answering things nobody asks. Build the flow from your top ticket drivers, not from a workshop about what customers might want.
No measurement. Track containment against CSAT for contained conversations. Containment alone rewards a bot that traps people.
FAQ

Frequently asked questions

Is Flow Builder the same as the bot builder?

Yes. The Zendesk bot builder is Flow Builder, where you draw the Zendesk conversation flow the Zendesk flow builder bot follows on the messaging channel. A Zendesk messaging flow is what that drawing produces.

What's Zendesk Flow Builder?

The visual editor for building bot conversations on the Zendesk messaging channel. You draw a branching flow of steps without code, then publish it to a channel and brand.

Do I need code to build a Zendesk bot?

No for the standard steps. Calling an external system needs an API step, which is higher tier and usually needs a developer to build the endpoint it talks to.

Can Flow Builder run on email tickets?

No. It's a messaging feature. Automating email work is a job for triggers, automations and macros instead.

How do I test a flow before customers see it?

Use the preview in the builder for the shape, then publish to a test brand or a staging site and walk every branch signed out on a real device. Preview will not catch everything.

Why did my changes not take effect?

Almost always an unpublished draft, or a change published to a different channel or brand than the one you're testing on.

Bots create tickets too

A contained conversation that reopens by email tomorrow becomes a second ticket. Ticket Merger folds it back into the first.

Start free trial

14-day free trial. No credit card required.