In this Use Case we're setting up a Virtual User to determine the intent of a customer in a direct conversation, store the customer intent directly into parameters and analyze the intent directly for call routing. 

To achieve this, we're going to cover the following topics in this Use Case: 

• How to configure Nimbus in order to use the Virtual User in your workflows.
• How to configure parameters, to instruct the Virtual User AI on how to select parts of a customer's requests as stored data.
• How to set up the workflow and make service calls for further adjustments.

Preconditions

Use Case Overview

Details will be covered below in this Use Case. As a quick tl;dr, here is an overview of items you will need: 

Step 1 - Nimbus AI Bot Setup

Configuring the Bot

✅ The Bot is your “mapping” to the Bot and API endpoint you configured above, including the authentication.

1. Head to Nimbus Administration > Configuration > Bots and create a new Bot.
2. Give your Bot a descriptive name. 
   💡This name is just for Nimbus UI purposes, and must not match Copilot. 
3. Define the Organization Unit under which this Bot will be selectable. 
4. Type is Nimbus AI Services - Audio Intent Analyzer.
5. Save and Close.

Configuring the Virtual User

✅ Virtual Users. Here you can give your AI bot instructions on how to interact with the Customer.

1. Head to Nimbus Administration > Configuration > Virtual Users and create a new Virtual User.
2. Give your Virtual User a descriptive name, e.g. Virtual Front Desk Concierge.
   💡This name is just for Nimbus UI purposes, e.g. for later selection in your Workflows → Next step.
3. Define the Organization Unit under which this Virtual User is selectable. 
   💡Should ideally match your intended Services and Workflows accessing this Virtual User. Of course you can pick a “higher” OU if you want to share this definition among similar Services that will use the same kind of Agent for Customer interaction.
4. Define the Language and Voice of your Virtual User.
   💡Nimbus development aims to expand this list of supported languages gradually, ensuring that every User Voice is also compatible with each Language selected.
5. The “System Instructions” acts as a behavioral guideline for your Virtual User.
   

   💡Note that this field is optional in Nimbus:

   The underlying AI will engage with the Customer automatically. Optionally you can use these instructions to go directly into the first Conversation Topic. By adding Custom Parameters or System Fields and Parameters (retrieved via CRM using Flow Actions) you can also lead directly into a more direct conversation. 

   ---

   A possible example of an System Instruction could be:

   You are a Front Desk Operator of an insurance company. If available, greet the Customer with their Client ID and $(CustomContextParameters.DOC_ClientId) Company $(Customer.Company). Politely ask for their reasons for calling.

   💡Of course your flows using these parameters need to ensure that these Parameters have Defaults or a fallback in your data-retrieving Power Automate Flow Actions, so the Virtual User can operate normally when no additional data is available.

    
6. If you want to use your Virtual user productively, ensure your Virtual User has a license applied. This license can either be applied directly in the Virtual User configuration steps below or - in bulk - via Admin > Licensing view. 
   ⮑ Applying the license enables usage of the “Add Virtual User” Workflow Activity.

Step 2 - Preparing your Parameters

✅During the live conversation with the customer, the Virtual User will use Parameters to fill in customer responses. As you configure the workflow further below, you will need to specify 3 parameters for the “Add Virtual User” Conversation Handling activity: 

• One “Fallback Parameter” which will be used by the AI if the customer request cannot be fulfilled. For example, if your bot is supposed to decide between “Sales” and “Support”, but the customer has a different question or problem to discuss, this parameter will contain the topic the AI identified as “Fallback”.
• Optionally: Two Parameters per Workflow “Add Virtual User” activity exit. 
  ☝Note that these parameters require “Virtual User Context” to be provided with the Parameter definition itself. Any information that helps the AI to fill in the correct information can be filled in.
  
  ✅If you want to handle more exits with corresponding data (e.g. Sales, Support), add more parameters and Virtual User Context as needed.

Step 3 - Configuring your Nimbus Workflow

✅Last but not least you need to configure a new Workflows to handle the Audio/Video interaction between Customers and your new Virtual User.

1. Head to Nimbus Administration > Configuration > Workflows.
2. Design or adjust any existing workflows you want to repurpose. 
   💡We recommend creating a copy of an existing Workflow so you can switch and test it with ease and return back should something not work as intended.
3. In your Workflow, Accept a call as normally. 
   💡Important: Do NOT add a “Queue” activity unless you want to involve human interaction in your workflow as well (e.g. after the Virtual User interaction).
4. Instead, connect your Caller to the AI by using the “Add Virtual User” in your workflow. You can find it in the Conversation Handling Activities. 
5. Configure the “Add Virtual User” activity as follows:
   1. Virtual User: Select from your list of Virtual Users as previously configured previously above.
      💡Note that the Virtual User will greet the Customer with the “Initial Message” field instructions provided. If any Parameters have been retrieved, they will be part of that message as well.
   2. Max Input Timeout: Define this to a reasonable time where no answer has been given by the Customer - e.g. 1 minute. → The activity will take the “Idle Timeout” exit.
   3. Define a Fallback Parameter which is used as the topic for the Virtual User if no resolution can be found.
      💡A good way to route this exit would be a regular “Queue” step, so a human can take the call instead of the Virtual User. 
      💡The Parameter can also be shown in the Extensions Service Settings (e.g. within My Sessions) as additional context for the receiving service user.
6. Optionally: Add additional activity Exits taken within your Workflow. An Exit is defined as follows: 
   1. Name of the exit, as shown in the activity bottom.
   2. Context for the AI on when to take this exit. These can be instructions like: 
      “The customer mentions an invoice, billing or other payment-related issue.”
   3. Up to two Parameters, as previously configured → in the chapter above.
      💡Note: When a parameter lacks “Virtual User Context” it will be shown with a warning. You may still select it, but the Virtual User will most-likely not know what part of the customer answer to fill into this parameter, so it will remain at its default value.
      
   4. Optionally: Add additional Exits and respective parameters as needed.
7. Finally: 
   1. Don't forget to route your all your Activity exits, e.g. Failed/Idle Timeout conditions.
   2. Establish a fallback route to Service Queues, Voicemail or Transfer where necessary.
   3. Don't forget the “Disconnect” activity at the end and to Save your workflow.

Known Limitations