Getting started

Virtual assistants connected to the Nuance Digital Engagement platform (NDEP) are automatically recognized as agents, with the Virtual Agent role, in the NDEP system. Before you create a virtual assistant in Mix, you’ll need to ensure that the required NDEP configuration is in place (such as dedicated agent groups, business units, and business rules), and that NDEP Virtual Assistant Adapter (NVAA) has been set up. NVAA acts as middleware between the virtual assistant and the NDEP Agent Engagement API (AEAPI), enabling seamless integration. Therefore, before you begin, ensure this essential configuration is in place. Check with your NDEP administrator.

First interaction

Plan the interaction with the user carefully. The welcome message (also called opener) that will appear at the start of a conversation can originate from the NDEP platform, or from the virtual assistant itself.

  • If the NDEP platform is going to issue the welcome message, make sure that your dialog design does not include such a message. For example, you may omit the initial message in the question and answer node that starts the conversation, to avoid greeting the user twice.
  • On the other hand, if you want the virtual assistant to send the welcome message, you must perform these prerequisites:
    • Configure the chat interface (CI) to connect to the agent immediately (auto engagement)
    • Disable any openers at the chat skin level if necessary
    • Suppress openers in NDEP business rules, if configured

Channel strategy

NDEP supports 12 predefined messaging channels. Although you might expect your virtual assistant to behave the same across multiple channels, creating your Mix project with the complete standard set of channels is advisable. This will still allow you to define consistent behavior for all, or for a subset, of the channels, as well as behavior that is specific to any one of these channels.

If your Mix project has channels with names that don’t exactly match the NDEP standard channel names, or if you choose to create a project with less channels (for example, only Digital and Social), this will require additional configuration in NVAA—that is, you will need to define which NDEP channels correspond to each of your Mix channels. Ask your NDEP administrator for assistance.

Language strategy

An NDEP agent normally supports one language only. If your virtual assistant must support multiple languages simultaneously, please contact your Nuance representative for assistance. Alternatively, you might consider building a separate virtual assistant for each language, from a single multilingual Mix project, as a workaround.

Configuration requirements

Once your Mix project has been created, you will need to add some variables (and schemas) to hold information to be exchanged between NDEP and your dialog application, and one custom event.

Reserved variables for NDEP

Some NDEP features—for example, rich media widgets, or forced navigation—involve exchanging information between the dialog application and the virtual assistant via reserved variables. Some reserved variables allow your dialog application to relay NDEP-specific information to the transfer destination when transferring the user to a live agent. Other reserved variables hold transfer queue information from NDEP that the dialog application can use. To access this data, variables with the same name (case-sensitive) as the ones that will be used on the NDEP side must also exist in your dialog design.

Information to send to NDEP

Variables with information for NDEP
Variable Type Description
agentAttribute AgentAttribute object Key-value pair specifying a desired attribute or skill, to narrow down the pool of targeted agents upon transfer (for example, the ability to speak English, or being with the Sales department).
agentAttributes AgentAttributes object List of key-value pairs specifying all desired attributes and skills, to narrow down the pool of targeted agents upon transfer.
businessUnit String ID of the targeted business unit for queueing and transfer.
ndepClientDetails NdepClientDetails object Holds the customer name, language, and the title of the chat. Used to Pass client details from a virtual assistant to NDEP.
ndepCommandName String Name of the NDEP script command to execute (for example, forcedURLNavigation for the user’s browser to navigate to a specific URL).
ndepCommandPayload String Payload for the specified NDEP script command to execute, if needed.
ndepCustomEvent String Name of the custom NDEP event to trigger. See Pass custom events from a virtual assistant to NDEP.
nvaaMessageData String JSON object literal representing rich media of type freeform, to be rendered in the chat interface.
siteId String (Optional) Represents the targeted site.
transferDestination String ID of the desired agent group for queueing and transfer.
transferPriority String Initial engagement priority of the engagement request. A higher number indicates a higher priority in the queue. Maps to the priority parameter of the engagement request on the NDEP side (refer to CEAPI endpoint reference, in the NDEP documentation).
transferQueueThreshold String Queue threshold value for the engagement request. Used to calculate whether this engagement goes into the queue in cases where agent slots are not available. Maps to the queueThreshold parameter of the engagement request on the NDEP side (refer to CEAPI endpoint reference, in the NDEP documentation).
AgentAttribute schema

Add this schema to your dialog design project and use it to create the complex variable agentAttribute. This schema has two fields:

AgentAttribute schema
Field Type Description
name String Name of the desired attribute or skill.
value String Value of the desired attribute or skill.
AgentAttributes schema

Add this schema to your dialog design project and use it to create the complex variable agentAttributes. This schema has one field:

AgentAttributes schema
Field Type Description
attributes List of AgentAttribute Key-value pairs specifying multiple desired attributes and skills.
NdepClientDetails schema

Add this schema to your dialog design project and use it to create the complex variable ndepClientDetails. This schema has three fields:

NdepClientDetails schema
Field Type Description
clientName String Name of the user.
language String Language of the chat.
chatTitle String Title of the chat.

Transfer queue information to get from NDEP

Variables with transfer queue information from NDEP
Variable Type Description
ndepAvailability Boolean true if there is an agent or a queue slot available at the transfer destination, at the time of the transfer request; otherwise, false.
ndepAvailableSlots Integer Number of chat slots available for the target agent group, considering the specified agent attributes if any. -1 (default) if NDEP was unable to determine the number of chat slots available.
ndepEstimateWaitTime Integer Estimated wait time, in seconds, in the target destination queue. -1 (default) if NDEP was unable to estimate the wait time.
ndepInHOP Boolean Only returned if siteId was provided: true if the specified site is within hours of operations; otherwise, false.
ndepQueueDepth Integer Number of chats already in queue at the transfer destination. -1 (default) if no agents or slots are available. Only relevant for transfer requests that don’t specify agent attributes. For escalations targeting agents with specific attributes, use ndepAvailableSlots instead.

Events for NDEP

NDEP has the ability to pass data to the dialog service by triggering an event called NdepData (case-sensitive). Adding a custom event with this name and an event handler for this event to your dialog design allows you to account for such updates, should they require changing the course of the active conversation (see Manage events, in the Mix.dialog documentation for more information).

A conversation in NDEP is asynchronous. It can span multiple engagements. The first engagement opens a session, and the session only closes after it has remained idle for a certain time, typically 25 hours. However, you can configure a parameter in NVAA that allows it to trigger the predefined event UserDisconnect at runtime. Adding an event handler for UserDisconnect in your dialog design, will allow you to catch this event and perform actions that will allow NVAA to end the session at the desired moment—for example, immediately after the user closed their browser.