Zendesk: choose when your AI asks a customer to verify

Put the check before the restricted work

Before an AI helper shows private customer information or starts a sensitive task, decide how the customer proves they may use it. Make that choice part of the service design, including what happens when the check fails.

Zendesk announced email-code verification for messaging AI agents on November 2. An administrator can add an Email verification step to a scripted conversation. The customer receives a code by email and enters it in the chat.

For a team planning a verified self-service task, this creates another option alongside a sign-in connection built by a developer. It does not automatically change existing conversations.

Read the announcement: Zendesk: November 2 email-code verification announcement.

Weigh setup work against customer effort

Zendesk describes the email-code step as an option that needs no coding. Customers must leave the conversation to retrieve the code, while the developer-built alternative can check sign-in in the background.

The option also supports channels such as WhatsApp, where Zendesk says that background sign-in method is not supported. Check the channel your customers actually use.

There are important access limits. Codes require a scripted dialogue and cannot be used with essential AI agents. They also cannot be sent to staff accounts, including administrators. Confirm your account entitlement and running charges before making a purchase around the feature.

Understand the session you are creating

Zendesk says successful verification can link an existing customer record and messaging session with the current conversation. Ask the administrator to demonstrate which record the customer reaches, using test accounts.

For website chat, Zendesk also documents that page scripts can read the browser storage holding the messaging session. Its guide recommends the developer-built sign-in alternative when that risk does not meet the business requirements. Have the person responsible for the website assess this before using restricted records.

Our perspective: a useful verification choice balances customer effort with the access the task needs. Checking a code should lead to a deliberate choice about which information or action becomes available, with clear limits.

Design both outcomes

The conversation builder has separate branches for successful and failed verification. Give each a clear next step so customers can continue or reach a person. Do not let failure lead into the restricted task.

1. Choose the first request that genuinely needs verification.
2. Confirm the scripted AI agent and messaging channel support the option.
3. Test a successful code, an incorrect code and a customer who cannot receive the email.
4. Check the customer record reached and the route to a human before publishing the conversation.