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.
Note:
Virtual Agents in NDEP must be assigned to at least one Agent Group and a Business Unit. Business rules determine how chat traffic is routed to agents. Consider assigning the Virtual Agents to dedicated agent groups with no other types of agents assigned. However, if your virtual assistant is only meant to operate outside of live agent office hours, you might choose to assign it to an agent group where live agents also coexist.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
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:
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:
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:
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
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.
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.