Understanding bot flow step types

A conversation flow consists of a sequence of steps that are created and configured by you in Flow Builder, or are part of the out-of-the-box behavior . Each step represents a message the bot is able to show to your customer during a conversation.

This article discusses the following step types:

• Send message
• Present options
• Show help center articles
• Ask if question resolved
• Make an API call
• Transfer to agent
• Add a business hours condition

After getting to know the elements here, you can begin Using Flow Builder to create bot flows.

Send message

Send message displays a piece of text to the customer during a conversation.

Usage:

Send message inserts a predefined piece of text into the conversation. It can be a greeting, useful information about your business, or an automated direct reply in response to end user free-text messages and quick reply option selection.

Configuration rules:

Message steps can be added anywhere in your flow. After they're displayed, they move the conversation immediately to the next step in the flow.

Table 1.

Flow Builder view	Customer view

Example:

In the example below, the customer entered “Receiving error ‘unsupported platform’” which triggered the automated reply about supported platforms. That reply was configured in Flow Builder as a send message step; the messaging bot assessed the customer's free-text entry, identified that preconfigured message as the most likely to address the customer's needs, and moved the conversation to that step in the flow:

Present options

Present options displays up to six preconfigured quick replies that the customer can interact with during a conversation.

Usage:

This step displays up to six preconfigured quick reply options that can be offered to your customers during a conversation, allowing them to select a likely response rather than typing it in.

These options can be used to represent commonly-asked questions, branch the conversation, or help your customers navigate through a conversation flow. You can drag-and-drop options in the Configuration panel to reorder them.

Configuration rules:

You cannot end a flow with a Present options step – it must be followed by one of the other step types, which must be also configured before you can publish and move on to another step. In the example below, three options are followed by a Show help center article step, and one by a Transfer to agent step.

Table 2.

Flow Builder view	Customer view

Example:

In the example below, a customer is contacting a scooter sales and rental company. Because the company knows that most customers want information on buying, selling, or renting a scooter, after the initial greeting they immediately offer three options:

Note that as a result of conversational shortcuts, typing the message “I want to buy a scooter” in the example above will have the same effect as clicking the quick reply.

Show help center articles

Show help center articles presents up to six help center articles to the customer during a conversation.

Usage:

The Show help center articles step recommends specific articles to your customers that may help them self-solve their questions. This differs from the automated article suggestions, which searches for relevant articles in your help center based on customer’s free-text entries.

Note: The article preview does not support embedded video. If an article includes only the embedded video, we recommend including a brief text introduction above the video describing its content for your end users.

Configuration rules:

A maximum of six articles can be configured per step.

Only articles visible to everyone can be included in this step. See Creating and editing articles in the knowledge base for information on article permissions.

To use this type of step, you must have an active help center with publicly-available articles.

Table 3.

Flow Builder view	Customer view

Example:

In the example below, the customer selected a quick reply option, "I want to buy a scooter", and received a specific article recommendation in response, which also included the text responses prior to the recommendation:

Ask if question resolved

The Ask if question resolved step type asks your end users whether an answer resolves their support issue, and offers response options they can choose from.

Usage:

The Ask if question resolved step provides a way to capture end user data to measure how well each answer is performing, and indicates which answers can be refined and optimized.

Note: Explore reports capturing the number of sent feedback requests, as well as the number and types of responses left by end users, will be available by the end of Q4, 2022.

The step type inserts a piece of text into the conversation, followed by two quick response-style options, which are in turn each followed by a message or additional step.

Configuration rules:

This step cannot be the first step in an answer, and cannot be added after a Transfer to agent step.

By default, when you insert this step into an answer the following text appears in each element:

• “Was this helpful?” (Question resolved bot message)
• “Yes, problem solved” (Resolved response)
• “No, I still need help” (Unresolved response)
• “Great. Knowledge is power. You can ask me another question at any time.” (Follow-up message to resolved response)
• ”Got it. Try rephrasing your question.” (follow-up message to unresolved response)

These elements must be present in the step for the answer to be published successfully.

The text above can be customized as needed. Additionally, the follow-up messages can be deleted and replaced by other step types.

While the text in the Question resolved and response messages is customizable, the resolution status by end user’s responses is fixed. That is, when the end user selects the first/left hand option (“Yes, problem solved”) it is considered a positive, or resolved response. The second/right hand option is captured as a negative, or unresolved response (i.e., “No, I still need help”).

Table 4.

Flow Builder view	Customer view

Make an API call

The Make an API call step can be used to push conversation details out to your CRM, or pull product information into your bot messages, and more.

Usage:

This step is used when you want the bot to present external data in its response such as retrieving movie reviews from IMDB’s API or push data into an external end-point such as Amazon Event Bridge or Google Analytics. It is especially useful when a customer requests information that may be updated regularly or is particular to them, such as system status or current wait time for assistance. It can also be used to send events for analytics or tracking purposes, for example emitting events to Google Analytics or Pendo.

Configuration rules:

API call steps can be added anywhere in your flow. Adding this step splits the flow into two branches:

• If success, which appears when the external source is queried, and supported information is returned
• If failed, which appears when the API call fails, due to a client or server error, or if the response is not supported by Flow builder

Information returned from the queried source must be in JSON format, and be less than 2MB.

Admins must include the following information in the step configuration:

• Supported HTTP request method. Supported HTTP request methods are GET, POST, PUT, PATCH, DELETE
  • POST, PATCH and PUT must include a Body field sent with request
  • GET and DELETE operations do not have a Body field.
• Endpoint URL, the URL of the external source.

Admins must add step type after each branch before publishing the flow.

Admins can create variables during the configuration of this step that can be used when creating bot messages subsequent to this step.

The Add an API call step has a number of configuration options that may require assistance from a developer on your team. See Using the Make an API call step for more information.

Example:

Let's say the customer selects the quick reply option “Zendesk office location” which triggers the Make an API call step. The API call is configured to get the information from Google’s Places API.

If the external system returns a response, the Success branch is triggered, and the information is inserted into the response framework created by the admin, and presented to the end user.

If a response is not returned, or the response is not supported by Flow Builder, the Failed path is taken, and fallback behavior defined by the admin is presented to the end user.

You can use the following URL as an endpoint to test the Make and API call step:

https://run.mocky.io/v3/19e020de-4ee1-47f7-94ea-d68df3c4df71

Transfer to agent

Transfer to agent escalates the conversation to an agent.

Usage:

Adding in this step hands off the conversation to a human agent. For Web Widget implementation, it can also be used to collect information about the customer prior to an escalation.

Configuration rules:

In this step, you can configure:

• An initial message.
• Ticket fields (text or dropdown types) to capture customer data, such as name and email, as well as other information that can be helpful to agents entering the conversation. Note that only the first 20 values in a dropdown type fields are displayed.
  Note: To use text and dropdown ticket fields in a flow, permissions for those fields must be set to Editable for end users. See Adding a custom ticket field for agents and end users.
• A final message displayed after those details are entered.

Transfer to an agent is an end step, which means it is the last step in the conversation, and you cannot add any more steps after it. As part of this step – unseen by the customer – a ticket is created, which includes their conversation history to help the agent address the issue.

Table 5.

Flow Builder view	Customer view

Example:

In the example here, a customer has chosen a quick reply option that indicates they need assistance with upgrading their plan, which requires agent involvement:

Add a business hours condition

Add a business hours condition allows you to use your schedule to branch the conversation.

Usage:

This step can be used to configure the bot to respond differently based on your business availability. Adding this step will split the flow into two branches:

• when open, which appears to the end user during scheduled business hours
• when closed, which appears to the end user outside of scheduled business hours

Tip: Deleting the business hours condition step removes both subsequent branches from your flow. We recommend designing your flow with this in mind, and that you consider placing it towards the end of the flow.

Configuration rules:

You must set a schedule in order to include a business hours condition step. Once you have set a schedule, you will see a preview of your business hours in the configuration panel, to indicate when customers would be sent down the open or closed branch depending on the time of day. Note that holidays are not shown in the preview, but will be respected by the condition.

If you have set multiple schedules (available on Enterprise plans only), a dropdown will appear in the configuration panel to select the appropriate schedule.

You cannot end a flow with a business hours condition step. It must be followed by one of the other step types, which must be configured before you can publish. In the example below, the business hours condition step is followed by a Transfer to agent step in both the open and closed branch. The message content is configured differently in each branch.

Table 6.

Flow Builder view	Customer view (When open)	Customer view (When closed)

Example:

In the example below, the agent transfer step is configured differently when open and closed to explain what will happen next in each context:

Table 7.

End user experience during business hours	End user experience outside of business hours