A Virtual User is an AI-powered assistant that interacts directly with calling customers - greeting them, providing retrieved information, capturing context to store in parameters and handing the conversation result back to Nimbus Workflows for further routing.
Use Cases
Virtual Users enable responsive, scalable self-service bots that can detect caller intent and integrate with external systems before — or instead of — handing over to a human agent. The list below showcases a few examples.
| Call triage | Captures the callers intent and routes to its downstream flow. Set up with Virtual User Outcomes: such as "Create ticket", "Check status", “Escalate” |
| Identification gate | Outcomes: Identified, Not Verified, Fraud Suspected — personalized self-service vs. manual verification vs. priority security queue. |
| FAQ with escalation | Outcomes: Answer Found, Low Confidence, User Requests Agent — answer in-bot, offer alternative handling, or hand straight to an agent. |
| Payment / transaction | Outcomes: Successful, Failed, User Aborted — confirmation, retry, or graceful exit. |
| Password reset | Outcomes: Reset Successful, Reset Failed, User Locked Out — confirmation, retry, or escalation to support desk. |
| Survey | Outcomes: Completed, Partial Completion, Drop Off — thank-you message, follow-up, or callback workflow. |
| Card blocking | Outcomes: Card Blocked, Identification Failed, User Cancelled — confirmation with audit log, high-priority escalation, or safe exit. |
| Transcription | Optionally, all Virtual User actions can have Transcription features enabled. This allows to extract the spoken transcript via Power Automate Connector for further storage, quality assurance or case evaluation purposes. |
INC AI and Virtual User Preconditions
PRECONDITIONS: AI Features, Bots and Virtual Users
Admin Consent: AI Features
✅ Nimbus Tenant Admin consent is required to enable the use of AI features. This is done in the Data Privacy Tenant Settings. AI use will require your Tenant data (e.g. caller information) to be processed by external services
💡Good to know - shared setup effort: Once consent is granted, both Admin Roles “Tenant Admins” and “OU Admins” are able to create various AI Configuration items in the Nimbus Admin Portal. This also includes:
- Access to Service Distribution Settings, e.g. to test workflows with your configured Virtual Users.
- Steer feature visibility via Companion Service Settings (e.g. when activities are supposed to happen unobtrusive in the background).
Virtual User Licensing
✅Nimbus License Management:
-
Contact Center Enterprise Routing service licenses are required to use AI-driven Virtual User functionality.
⮑With the license applied, corresponding Service Features (e.g. workflow activities, configuration tabs) are enabled. -
Individual Virtual User license requirement: Same as regular Nimbus users, each Virtual User requires a separate license. This license can be applied individually in the Virtual User configuration - or in bulk - via Admin > Licensing view.
⮑The license enables usage of the “Add Virtual User” Workflow Activity, without it the activity will be skipped over. For additional Virtual User licenses on your service, get in touch with your Customer Success representative.
Virtual User Bot Configuration
Virtual Users rely on Nimbus Configuration items:
✅ ALL: Virtual Users require Bots to be configured. Your bot choice also determines the underlying AI LLM into which the Nimbus Virtual User integrates. Your bot typ and profile should therefore be chosen with the intended use case in mind.
INC Language model comparison matrix
| Defined in Bot Configuration | Defined in Virtual User Configuration | |
|
Type Nimbus managed or BYO |
Agent Type Underlying LLM |
Virtual User Profile Pre-built configurations to fulfill a certain use case |
| Nimbus AI Services | Azure OpenAI – GPT Realtime 1 |
|
|
Custom AI Services
|
|
|
| M365 Copilot Direct Line 3.0 |
|
|
Notes
1 Due to Microsoft Azure AI foundry availability in limited regions, data processed by a Nimbus Virtual User “GPT”-Realtime" integration might temporality leave due to failover scenarios:
- Nimbus Cluster DE01, DE02, CH01, CH02, UK01, EU01, AU01 computation will be primarily performed in Sweden Central region.
- Nimbus Cluster US01 computation will be primarily performed in the US East region.
✅SPECIFIC AI services / Agent technologies (e.g. Microsoft Copilot) may require additional configuration items such as:
- Bot Response Templates, to map bot answers back into Nimbus workflow parameters.
- Speech Recognizers (Transcribers) to convert the Customer voice into text for the bot to process.
🔎For more details and specific configuration steps, refer to our AI Use Cases category and the specific Use Cases and pages linked above.
General
General
Nimbus-related general settings for the Virtual User.
| Field | Description |
|---|---|
| Name | The name of the Virtual User, as it will appear in other selection dialogues of Nimbus (e.g. within Workflows). |
| Organization Unit | Determines where the Bot will be available for selection. |
| Description |
A Nimbus-internal description, e.g. “Support Bot for first response IVR”. 💡This field is optional, just for identification within the Nimbus UI and will have no impact on the Bot behavior. 💡Limited to 256 characters. If you previously saved a longer description, the UI indicates the overflow. |
Bot Configuration
✅Dependent on the “Organization Unit” selected: Provides a selection of previously configured Bots (AI models) and related configuration profiles.
⮑ Based on the Bot and profile choice, other tabs and options become available .
| Property | Description | Notes |
|---|---|---|
| Bot |
✅Pick a previously configured Bot. ⮑ The Bot's underlying model determines which options become available in the following. |
🔎More details in the Preconditions above. |
| Profile |
Various configuration profiles that steer the AI behavior. Choices are:
⮑ The choice automatically changes the visible properties on the tabs described further below. |
✅ Required except for “Copilot Direct Line 3.0” |
|
Bot Response Template
|
Bot Response Templates map the JSON response your Bots (external APIs) deliver, with the goal to use that response as criteria within your Workflows. | ✅Required when “Copilot Direct Line 3.0” was selected as a Bot. |
Modalities
| Property | Description | Notes |
|---|---|---|
| Modalities |
Enables the bot to handle and react to Audio/Video (calls). ⮑ Depending on Bot selection, an additional Speech Recognizer may be required → See below. |
💡Currently the choice is locked. Further modalities will be made available in future. |
| Speech Recognizer |
Speech Recognizers (used for speech-to-text transcription) to be configured for selection in this menu. 💡 Speech Recognizers are used to parse the language of the calling customer into text for the bot to process. They can be configured as multilingual-capable, but are more effective when set to a specific language. |
✅Required when “Copilot Direct Line 3.0” was selected as a Bot. |
Licenses
| Property | Description | Notes |
|---|---|---|
| Licenses |
✅When you configured a new Virtual User: You need to save and re-open your Virtual User configuration before you can apply a “Virtual User” license. ⮑ This actively draws from your License Management pool and allows services to effectively use your “Virtual User” in production.
|
💡If you require additional Virtual User licenses, get in touch with Luware Customer Success. |
Behavior
Behavior
✅ This tab and contents are shown depending on General > Bot Configuration. It steers general instructions for the Virtual User, e.g. the instructions sent to the AI model. It also defines the Messages, Voice & Language and Persona settings.
| Property | Description | Notes |
|---|---|---|
| General Instructions |
The main free-text prompt.
|
10,000 chars limit Supports Custom Parameters and System Parameters |
Messages
| Property | Description | Notes |
|---|---|---|
| Initial Message to Customer |
Not an instruction or prompt, literal message of the first thing the caller hears when the Virtual User joins the workflow. The message is delivered in the language defined in the → “Voice & Language” settings. 💡When the Virtual User is invoked in Outbound Calls with Workflow, this is the message played when the called party picks up. |
500 chars limit Supports Custom Parameters and System Parameters |
| Final Message to Customer |
Final line the bot says before the activity exits. 💡Useful for handing the caller over politely ("Connecting you now…") or closing the loop on a self-service interaction. 💡May get dynamically translated when the conversation language got swapped mid-call. |
500 chars limit Supports Custom Parameters and System Parameters |
Timeouts
| Property | Description | Notes |
|---|---|---|
| Max Session Duration (seconds) | Maximum total duration the Virtual User stays in the call. | seconds |
| Inactivity Timeout (seconds) | How long the bot waits for caller input before taking the Idle Timeout exit. | seconds |
Voice & Language
| Property | Description | Notes |
|---|---|---|
| Language / Voice |
Optional spoken-language. 💡Not available for Copilot Bots, which are configured via Speech Recognizers instead. |
✅Only visible on bot profile: “AI Workflow” or “Intent Analyzer” |
| Virtual User Voice |
Voice selection for the chosen language. 💡Not available for Copilot Bots, which are configured via Speech Recognizers instead. |
Persona
| Property | Description | Notes |
|---|---|---|
| Verbosity |
Short label describing how chatty the bot should be:
💡Combined with Tone to color the bot's style. |
✅Only visible on bot profile: “Open Profile” |
| Tone |
Short label describing the desired conversational tone (e.g. "Friendly and professional", "Concise and factual"). 💡Combined with Verbosity to color the bot's style. |
|
|
Role (deprecated1) |
Short label describing the persona the bot plays (e.g. "Customer service representative", "Pharmacy advisor"). 1 Deprecation Note: The Role field will be phased out soon, to be merged with the Behavior > “General Instructions” in a future release. |
Outcomes & Tools
Outcomes & Tools
✅ This tab and contents are shown depending on General > Bot Configuration. It steers how the AI interacts with external systems and how to orchestrate the tool flow when interacting with the customer.
| Property | Description |
|---|---|
| Outcomes & Tools Instructions |
A single free-text field on the Virtual User that tells the model…
|
💡Tips on writing Outcomes & Tools Instructions
- Keep it concrete and step-driven. The model performs best when it can read the description as a numbered playbook rather than as prose:
- Spell out the conversation phases (greet → identify → look up → confirm → close).
-
Name each tool by the exact label it has on the Virtual User — "call the
OrderLookupWeb Request", not "call the order system". -
The order of execution (e.g. FIRST validate
bank name,IBAN, THEN retrieveuser name,ONLY THEN answer theinquiry) -
Mandatory and optional steps with clear signal words (e.g.
these steps must be successful | this step can be optional) - Handle errors, outlining what to do if the tool fails or returns nothing.
- Avoid duplicating the General Instructions (role, tone, language). The Outcomes & Tools Instructions field is about the technical information flow, not personality.
☝️Note: The following examples are mere reference points, not functionally verified with specific use case scenarios or products.
Example 1 — Web-Request-only (order status bot)
1. Greet the caller and ask for their order number.
2. Call the OrderLookup Web Request with the order number the caller provided.
3. If OrderLookup returns a result, read back the order status (shipped / processing / cancelled)
and the expected delivery date.
4. If OrderLookup returns no result or an error, apologise, offer to transfer to a human agent,
and end the conversation.
5. After confirming the status, ask whether there is anything else. If not, say goodbye and close.
Never invent an order status. Only state what OrderLookup returns.Example 2 — MCP-Server-only (internal Jira helper)
1. Greet the caller and ask which Jira ticket they are calling about.
2. Use the JiraServer MCP Server to look up the ticket by ID.
- Prefer read-only tools first (get-issue, search-issues).
- Only use write tools (add-comment, transition-issue) if the caller explicitly asks for it
and confirms with "yes" before you make the change.
3. Summarise the ticket: title, status, assignee, last update.
4. If the caller asks for a change, perform it through the JiraServer, then read back what changed.
5. Close by confirming what was done and offering to do anything else with the same ticket.Example 3 — Mixed Web Requests + MCP Servers (concierge bot)
You handle two kinds of requests: account questions and ticket questions.
Account questions:
- Use the CustomerLookup Web Request to identify the caller by phone number.
- If CustomerLookup returns no match, ask the caller for their customer ID and try again.
Ticket questions:
- Use the JiraServer MCP Server for everything related to support tickets.
- Always look up the ticket first; never quote a status from memory.
General rules:
- Never expose internal IDs, URLs or raw tool output to the caller.
- If a tool fails twice in a row, apologise and offer to transfer to a human agent.
- Keep answers under three sentences unless the caller asks for detail.Outcomes
Outcomes represent the customer intentions the Virtual User can detect during a conversation. Instead of relying on a single Success conversation outcome, you define multiple, outcome-driven results and decide how each one continues in the Workflow.
✅Preconditions
🔎"Outcome" feature availability: Outcomes are available using either “Nimbus AI Services” or "Custom AI Services", for the following Bots: Intent Analyzer, AI Workflow and Open Profile,
-
☝️Migration: Previous “Virtual User” activities: Previous Virtual User workflow activities had AI exits created on the workflow level (Audio Intent Analyzer) or hard-wired "Success" exits (AI Workflow, Open Profile) in the element. With the introduction of flexible Outcomes, manual migration is necessary to avoid any disruptions and configuration errors.
- Simply replace the “Add Virtual User” activity with a new one to leverage flexible Outcomes:.
- Define at least one exit Outcome on the Virtual User configuration page, and map the exit on the workflow level. With no exit configured, the workflow will take the “AI Fallback”.
- 💡No migration required for Copilot bots: Copilot uses its own exit handling1. Copilot "Topics”, of which the outputs are then mapped into Bot Response Templates.
1 Depending on selected bot mode, the“Add Virtual User" Conversation Handling Activity is changing available configuration and exit properties.
| Property | Description |
|---|---|
| Outcome Name |
Mandatory, unique name for the outcome — this is the label you later select on the “Add Virtual User” activity when mapping it to a Workflow exit. 💡Keep it to one word and avoid special characters (e.g. create_ticket) so the AI model detects it reliably. |
| Instructions | Mandatory free-text that tells the Virtual User when to assign this outcome (e.g. “The caller wants to create a new support ticket”). |
| “This outcome triggers an exit” (toggle)1 |
Steers the behavior of this outcome during the activity:
|
| Parameters | Optionally attach up to 10 Parameters for storing customer-provided data. The AI decides which conversation data to write into them. 💡The AI can immediately return the parameter contents back to the customer, e.g. to verify if it has correctly understood the instructions. |
✅ Related Action
- 1 At least one exit outcome must be defined on the Virtual User. It also needs to be mapped on the “Add Virtual User” activity before that activity can be saved. Otherwise the Virtual User would not know when to exit that activity
☝️ An exit-triggering outcome cannot be deleted while it is already used in any Workflow — the delete option is disabled to avoid breaking the Workflow.
Tools
💡These settings allow to extend the Virtual User with external system capabilities: MCP Server and Web Requests. They are optional, to be used either independently or together. Unselecting a tool keeps its stored configuration, so re-selecting it later restores everything you entered.
✅Precondition: Available when Bot Profile: “AI Workflow” or “Open Profile” were selected in the ”General" tab.
☝️PLEASE NOTE:
- Failure Case handling: For both MCP and Web Request your Outcomes & Tools Instructions don't need to handle failure cases manually. This is done in the "Add Virtual User" Conversation Handling Activity. You can also define multiple → “Outcomes” and treat them each like a different case.
- We highly recommend to limit and purpose-scope retrieved context via MCPs and Web Requests. If too many tools added, the Virtual User may slow down from tool usage or get the context wrong if too much data is provided. Also refer to our Best Practices - Virtual Users in Nimbus for further considerations.
Web Requests
Web Requests
A previously configured Web Request can be bound to the to the Virtual User, so the model can call it mid-conversation. Each binding has two fields on this page — the Web Request name itself, and an Instructions field that tells the model when to call it.
✅Precondition: Requires at least one configured configured Web Requests from the same (or a parent) Organization Unit where your Virtual User lives in.
💡Use this when …
- … you want transparent definition and orchestration in Nimbus.
- … the validation logic must be auditable directly in Nimbus.
- … your called APIs are time-sensitive and tightly sequenced.
☝️Accounting for delays: Virtual User AI models are optimized for timely responses to a customer. A missing web request status code may be interpreted as “unresponsive”, which results in the “Failed” condition exit in Workflows being taken.
✅ Recommendation: When using AI-driven workflows, always enable “Wait for response” in your Web Requests > Response configuration. This is especially important when your AI workflow depends on the data being available.
💡Of course “Wait for response” also means that long-running requests may incur a delay that the customer will perceive as silence from the AI. (Expected) long-running requests should therefore be announced to the customer beforehand. Also, timeout exit codes are expected be sent by the target system so the AI knows when to move on.
| Property | Description |
|---|---|
|
Web Request (selection) |
Each Web Request:
☝️Outcomes & Tools Instructions dependency
💡Example: Unlike MCPs more capability-based flow, Web Requests should have a clear order sequence to the flow, as information retrieved can be often co-dependent, specific and granular. An example Web Request-centric flow description could therefore look as follows: |
| Instructions |
This field tells the Virtual User how the Web Request is to be used. ☝ Note: The model does not see the Web Requests generic Description from its config page. Instead, use this Instructions field to describe it to the model. 💡The Instructions field should therefore also provide a precise description to the model, outlining the functional goals of the Web Request and necessary field descriptions to match with the customer conversation. |
MCP Server
MCP Server
An MCP Server attaches a Model Context Protocol server endpoint to the Virtual User. Once attached, the server's tools are exposed to the model in real time during the call.
✅Precondition: Requires you to connect to a running, external MCP server, which offers more flexibility. The MCP server uses reusable Authentication configuration items — 🔎 also see Authentication in the property table row below.
💡Use this when…
- …you already operate or connect to existing MCP servers.
- …you want tools and capabilities to evolve independently of Nimbus, but constrain their usage.
- …you want long‑term flexibility with less UI configuration.
🔎Notes
- Scoped use: The AI model identifies each MCP Server by its Name and the Instructions. The individual tools inside the server are advertised by the server itself via the MCP protocol — Nimbus does not rename, scope or filter them in any way. If you require scoped access, you should limit the capabilities server-side – e.g. via proxy – to prevent any unwanted tools from being (e.g only READ, not WRITE).
- Purpose | Order: The model will not follow the order in which the MCP servers were added into the Nimbus UI. In the general → Outcomes & Tools Instructions, you should clearly define “how” MCP tools are to be used. The AI decides the order of usage itself.
- Good to know: Nimbus Virtual User is compatible with MCP servers designed for OpenAI GPT‑Realtime, including remote MCP servers exposed over HTTP. More information can be found in the OpenAI MCP connector guide and Realtime API documentation.
| Property | Description |
|---|---|
| Name |
Each MCP server:
☝️The MCP Server “Name” Must be unique on the Virtual User. The model reads this name when deciding which server to call — use the same label inside the Outcomes & Tools Instructions (e.g. "use the |
| URL | The MCP Server's SSE endpoint (e.g. https://jira.example.com/mcp/sse). Nimbus opens a streaming connection to this URL for every Virtual User session that uses the server. |
| Instructions | Free-text summary of what the server is for and when the model should reach for it (e.g. "Internal Jira instance. Use for any ticket lookup, comment, or transition."). |
| Authentication |
✅Requires a (reusable) Authentication configuration to secure the connection to the MCP Server. 💡The dropdown lists the Authentications available in the Organization Unit of your Virtual User (and its parent units). Supported authentication types:
🔍 Notes:
|
Follow-up Steps
✅Follow-Up in other areas:
- In order to take effect, (licensed) Virtual Users must be added as a “Add Virtual User” Workflow Activity to your workflows.
- We highly recommend to do test-calls to your service and thoroughly test every Virtual User change.
Limitations
INC AI and Virtual User Limitations
General note on AI-driven interactions
AI driven replies are very dependent on what the Customer is saying. For example, if the Customer is saying “I have trouble with my modem” it is not necessarily given that the bot will associate “Internet” as your workflow routing exit, unless specifically handled in your Virtual User integration and instructions. We therefore highly recommend to test and account for “creative” or “non-tech-savvy” wording when designing your Virtual User interactions within your workflows.
🔎Recommended reading for beginners: We collected and wrote down some Best Practices - Virtual Users in Nimbus to help you with considerations and risks when replaying human interaction with AI.
General Virtual User limitations
The current Nimbus implementation with AI-driven bots underlies the following limitations:
- Supported Modalities: Virtual Users (Bots) are currently available for Audio/Video modality tasks.
- Virtual User Reporting: Sessions involving Virtual Users are not reflected as dedicated User Session. Virtual User session reporting is planned for a later point this year.
Microsoft Copilot Limitations
- Expect processing delays: Processing AI answers takes a few seconds for voice-to-text-transcription, followed by AI processing and then the same transcription back into a voiced response. Luware is trying to minimize the delay on Nimbus call infrastructure, but the dependency on external APIs will always incur this delay. The Customer will hear silence during this processing and no audio feedback / silence detection.
-
Ensure you have no ambiguity in your topics. For instance, the word “
Service” may be too generic if you want to transfer to different services. Rather usehealthcare|medical|emergencyas identifiers or use more complex Regular Expressions to identify replies.
Nimbus AI Services Limitations
| Bot Configuration Profile | 🔎 Design Notes (not limitations) |
|---|---|
| Intent Analyzer | The Nimbus Virtual User Intent Analyzer is primarily designed to handle intent detection, as described under Use Case - Setting up a Nimbus Virtual User for Intent Analysis. Other use cases, such as self-service and customer feedback surveys are not supported by Intent Analyzer. |
| AI Workflow |
|
| Open Profile |