Testing the end user's messaging experience

When you create or update your messaging configuration for the Web Widget or mobile SDK channels, you can – and should – test the setup to experience messaging conversations from the end user's perspective.

The testing processes differ for a standard messaging widget and a messaging bot. In this article, we'll cover both scenarios.

This article includes the following sections:

• Testing a standard messaging Web Widget
• Testing a messaging bot

Testing a standard messaging Web Widget

When you're creating a standard messaging Web Widget, the preview panel displays a basic preview of how a conversation might appear to your customers. This is useful for getting a general idea about the customer experience, but doesn't provide a complete picture.

You can preview the full customer experience by launching a separate testing window. You can use the testing window at any point during the widget creation or editing process.

To test a standard messaging widget

1. Enable and configure a new Web Widget, or open the Web Widget you want to update and make your changes.
2. At the top of the preview panel, click Test it now.

   

   The testing window opens.

3. Click the launcher at the bottom of the window and begin interacting with the conversation, as if you were a customer.

   

   When you're done, you can close the window.

Testing a messaging bot

Flow Builder's in-product previewer is a great way to get an idea of how your messaging bot works. However, it doesn’t show things like:

• What happens when a user types in a question
• System flows like “I didn’t get that”
• The handover experience to an agent
• How and when triggers run, including Out of Office and CSAT messaging triggers.

In this section, we’ll explain a number of ways you can test your messaging bot's behavior from initiating a conversation to closing a ticket.

• Testing a bot in a live Web Widget
• Testing a bot in an unused Web Widget
• Testing your bot without exposing it to customers (Growth, Professional, and Enterprise plans)
• More testing tips

Note: When testing your messaging bot, real tickets will be created, so you may want to let your agents know that you’re testing it before you begin.

Testing a bot in a live Web Widget

In many cases, you’ll need to test your bot in a Web Widget that is already in use through a website, help center, or mobile SDK.

When testing changes to a bot in one of these live channels, those changes will be live to your customers as soon as they are published. To minimize exposing these changes to your customers, we recommend the following:

• Open the website or help center in an incognito/private browser window before publishing, then reload the page as soon as the new bot is published. Using an incognito or private browser allows you to start and view a conversation from the beginning, and having it ready to go before publishing minimizes the time it takes to test.
• Publish changes at a time that is usually quiet for your website or help center, to expose the changes to as few customers as possible before verifying the content.

To test a bot on a Web Widget currently in use

1. Open the bot you want to update, and make your changes by adding, deleting, or updating the bot's answers.
2. Open your website or help center in an incognito or private browser window.
3. Publish the updated bot.
4. In the private window, reload the page, then interact with the bot to experience its performance from a customer’s perspective.

Testing a bot in an unused Web Widget

Even if you are creating a new bot, for a Web Widget that isn’t currently embedded anywhere, it’s important to note that as soon as you enable messaging on a brand with an active help center – even if you haven’t yet published a custom bot – anyone visiting that help center will see the default response immediately. So again, we suggest testing this during a quiet period on your help center.

To test a bot with a new Web Widget on a help center

1. In Admin Center, click Channels in the sidebar, then select Bots and automations > Bots.
2. Configure the Web Widget and add it to your help center. The default response is visible to your customers as soon as you click Save settings on this page.
3. In a private browser window, navigate to your help center, reload the page, then interact with the bot to experience its performance from the perspective of a customer starting a new conversation.

When you’re done testing, if you do not want to continue offering the Web Widget for the time being, you must disable messaging at the account or brand level.

Testing your bot without exposing it to customers (Growth, Professional, and Enterprise plans)

Some account plans have options for testing a bot without exposing it to customers, by creating a testing brand or using a sandbox.

If you are on a Growth or higher plan type, you are allowed to create multiple brands. You can create a brand with a help center specifically for testing purposes:

1. Create a brand to use as a testing environment, and add a basic help center to it.
2. Enable messaging and create your flow.
3. Open a private browser window, and test the flow as described above.

Enterprise and higher account plans can use a staging sandbox to create a flow:

1. Follow the steps listed in Testing messaging in your sandbox > Adding web and mobile messaging to your sandbox.
2. Create and publish your bot, then test it in a private browser window, as described above.

More testing tips

There is some functionality, beyond the basic bpt you’ve created, that we recommend testing early on:

• Starting and returning to a conversation
• Testing automatic translation

Starting and returning to a conversation

In messaging, we store the customer's conversation history so that customers can leave a chat and return later. Because of this, the bot is disabled once they’ve started speaking to an agent, which can make it difficult to test your bot.

To see a conversation as it appears initially to a customer

• Use an incognito or private browser window to start a conversation as a customer would. This way, you can see the conversation as it appears to a customer starting one for the first time -- Answer Bot initiates a conversation with the customer, after they’ve clicked the icon to open the Web Widget.

When a customer returns to a conversation, even after a related ticket has been solved or closed, Answer Bot does not initiate the conversation. Instead, the bot waits for the customer to send a message.

To see a conversation as it appears to a returning customer

1. In a private or incognito window, start a conversation as a customer would. Follow the conversation through agent handoff, and have an agent change the related ticket status to solved.
2. Close the private browser window.
3. Open the private browser window again, making sure to use the same browser, and without clearing your cache.
4. Enter a message, and note the difference in how Answer Bot responds.

Testing automatic translation

Automatic translation allows agents to communicate with customers even if they are using different languages. The translation feature is enabled in the Agent Workspace. You can see how automatic translation works from both the agent and customer perspectives. See Supporting multilingual flows and Translating conversations in the Zendesk Agent Workspace for more information.

To test automatic translation

1. Create your bot, as described in the sections above, ensuring autotranslation is enabled.
2. Change your browser language to the language you want to preview in. You can use a plugin like the Locale Switcher extension for Chrome.
3. Open your bot and refresh the page. Note that this won’t work if you already have a conversation with an agent open.