New Design for Attendant Console
This page describes both Attendant Console 1.0 and the new 2.0 redesign. You can change between designs right within your settings.
💡 Note: For more recently onboarded Nimbus customers, this choice might be disabled and you will be using the 2.0 design by default.
Attendant Console 2.0
Attendant Console 2.0 - Service Transfer
By default, Nimbus supports internal service to service transfers without further requirements. For Attendant Console users, a service transfer does not visually differ from any Blind Transfer or Safe Transfer. However, special restrictions and behaviors apply.
🔎 Related concepts: The steps below refer to UI elements and concepts explained on the Attendant Console main page.
Transfer Scenarios
Let's assume a simple scenario where Nimbus Service A is acting as receptionist desk, forwarding calls to a Nimbus Service B.
Scenario |
Outcome |
|---|---|
| Safe transfer |
→ We recommend using "Blind Transfer" in a service-to-service transfer scenario. Make sure to check the presence status of the receiving service to ensure that users are available to handle the call. |
| PSTN transfers |
|
| Context Transfer (of Parameters) |
|
Please note that in all Transfer scenarios general limitations apply. These are listed in the following.
Transfer Limitations
INC Transfer Limitation List
💡In the following we list all known Transfer limitations, either by design or external circumstances.
Context Handover during Transfers
INC Context Handover Limitations
The Transfer of Custom Context Parameters works within Attendant Console. Currently Supported Scenarios are:
- Attendant - Safe Transfer → To User or Service (note that restrictions apply3)
- Attendant - Blind Transfer → To User or Service (note that restrictions apply3)
- Attendant - Consultation Call → Session Transfer not supported.2
| Transfer | …to User | …to Service |
|
By User on |
✅ Call Data + Customer.Custom Fields ⬜/✅ Custom Context Parameters only if enabled in respective Service Settings. |
✅All Call Data + Custom Fields, System Data and |
| By Service… | ❌ No Context gets transferred.1 |
✅All Call Data + Custom Fields, System Data and |
CONTEXT TRANSFER LIMITATIONS
The following Context Transfer limitations are known. We are actively working to improve this in a future update.
- 1 Workflows > “Transfer” Workflow Activity: A Custom Context Transfer from within a Service workflow to any target will not work.
-
2 No Transfer out of Conferences: MS Teams Conference calls - created during Attendant Consultation - do not support transfers, which also prevents Context Parameters from being handed over.
→ If you require Context to be transferred, use Blind or Safe Transfer scenarios respectively. - 3 No Multi-Transfer: Currently you can only transfer Sessions (and related Context) once. Afterwards, the “Transfer” button will be disabled.
Transfers and RONA State
INC Transfers and RONA State
✅ Note: Only applies if “Persistent RONA” is enabled via Distribution Service Settings.
-
When the target User is already is in RONA state.
⮑ A message will be shown after a transfer attempt is made: “Transfer cannot be started to a User, who is in a Nimbus Task”. There will be no User Session for Nimbus Reporting.2 -
When the target User ignores / doesn't answer the transfer (e.g. Timeout), Nimbus will not flag users with RONA state1.
⮑ User Session in Nimbus Reporting marked “Cancelled”2 - When the target User actively declines a transfer will also not flag users with RONA state.
⮑ User Session in Nimbus Reporting marked as “Declined”.2
1🤔 Why is RONA not applied in this the case? There is no persistent RONA state if User has not been selected by the Nimbus Task Queue and Distribution.
2 Depending on the Attendant Console transfer scenario (safe/blind), the call will return to the initial User or be lost. This is not related to RONA behavior.
Transfer to Teams Auto Attendant and Call Queues
INC Transfer to Teams Auto Attendant and Call Queues Limitation
☝Transfers towards the UPNs of Teams-native Auto Attendants’ or Call Queues’ Resource Accounts will fail. Based on the PSTN connectivity option used, transfers towards the Resource Accounts' assigned phone numbers will work as summarized in the table below.
| Transfer Type | Direct Routing | Calling Plan | Operator Connect |
|---|---|---|---|
| Attendant - Safe Transfer | 🛠 | ❌ | ❌ |
| Attendant - Blind Transfer | ✅ | ✅ | ✅ |
| Attendant - Consultation Call | 🛠 | ❌ | ❌ |
Workflow Conversation Handling Activities > Transfer > “Leave Nimbus” disabled |
🛠 | ❌ | ❌ |
Workflow Conversation Handling Activities > Transfer > “Leave Nimbus” enabled |
✅ | ✅ | ✅ |
🤔 Why are transfers failing? Is there a workaround?
🔎Analysis: This is caused by Microsoft Teams limitations on what voice applications (such as Call Queues, Auto Attendants, and Nimbus) are allowed to do. This cannot be circumvented by Nimbus.
🛠 Workaround: For these transfer types to work, Reverse Number Lookup (RNL) has to be disabled in the Resource Account's Phone Number Assignment. RNL can be disabled by executing the following Teams PowerShell command:
Set-CsPhoneNumberAssignment -PhoneNumber <phone number assigned to the CQ/AA resource account> -ReverseNumberLookup SkipInternalVoip⮑ After disabling RNL for a Phone Number Assignment, Teams will automatically forward the call to the Direct Routing SBC, which then needs to redirect it toward the Resource Account of the Call Queue or Auto Attendant.
Transfer to PSTN Licensing and Limitations
INC Transfer to PSTN Limitation
☝Out of the box, Nimbus and related addons can only perform PSTN transfers according to Microsoft's licensing and constraints.
🤔Which PSTN license do I need to acquire?
As of 2023, "Microsoft Teams Phone Standard" licenses are no longer supported by Microsoft. Previously, those licenses were viable for Nimbus. Regardless if you are using Direct Routing, Calling Plans, Operator Connect, the "Microsoft Teams Phone Resource Account" license is now always required.
| Your Setup | Required License |
|---|---|
| Direct Routing |
"Microsoft Teams Phone Resource Account" |
| Calling Plan |
"Microsoft Teams Phone Resource Account" + "Microsoft Teams Domestic Calling Plan" or "Microsoft Teams Domestic and International Calling Plan" or "Microsoft Teams Calling Plan pay-as-you-go" + "Communication Credits" (if these aren't already included as part of your plan) |
|
Operator Connect |
"Microsoft Teams Phone Resource Account" |
☝Please note that Luware staff cannot give recommendations on which license plan is best suited for your needs. Depending on your scenario, additional Teams App licenses may be required. Exact details are to be discussed with your Microsoft contacts.
🔎Also see: https://learn.microsoft.com/en-us/microsoftteams/teams-add-on-licensing/virtual-user
🤔How does PSTN licensing affect Service and call transfers?
Assuming that the initially called Service has (no) PSTN license assigned - the following scenarios may unfold:
Scenario A - Service A has a PSTN license. Transfers to other Services occur.
⮑ The PSTN license carries over throughout transfers to other Nimbus Services B and C.
⮑ As the license carries over, a PSTN transfer to an external target is possible from either Service.
Scenario B - Service B has no PSTN license. A Transfer to Service C occurs which has a PSTN license.
⮑ The customer skips over Service A and manages to reach Service B instead.
⮑ The PSTN license is missing on Service B, so nothing is carried over to Service C.
⮑ Even if Service C has its own PSTN license, a PSTN transfer to an external target is not possible.
🌟Learnings:
- Nimbus will use the PSTN license – and create a (transfer) Session – from the FIRST Service responding to a call.
- Regardless of how many internal Service transfers are performed thereafter, the FIRST Service PSTN license remains in effect.
- If a PSTN license is missing, the transfer task will fail and be treated accordingly by the System.1
- Even if a Service being transferred towards has a PSTN license, it cannot be added in post, as the Call Session is already ongoing from the first-responding Service.
✅ For your licensing needs this means: If you require PSTN transfer functionality, you'll need to ensure that this Service is handling all your incoming calls.
- For ONE first-level / Front Desk Service, you'll need a PSTN license for this particular Service.
- For MULTIPLE first-level Services scenario, you'll need PSTN licenses for all first-level Services.
1🔎 Assumption: Workflow takes the normal “Exit” Announcement route and Service Session will conclude with a “Transfer failed” outcome. For more details on analyzing your Reporting results, refer to Nimbus Reporting and Static Dimensions > "Service Session Outcomes"
☝Note that handling and tracking of running cost for PSTN licenses is outside of the Luware support scope. If you however require assistance in extending and/or configuring your Nimbus Services for PSTN, our support will gladly assist you:
Luware Support Address
| Luware Website | https://luware.com/support/ |
|---|---|
| Luware Helpdesk | https://helpdesk.luware.cloud |
| Cloud Service Status | https://status.luware.cloud/ |
Transfers and Nimbus Reporting Outcomes
INC Transfers and Nimbus Reporting Outcomes
🔎Rule: Last Outcome
Rule for Nimbus Reporting > Outcomes & Sessions List Task Results: The overall Service Session outcome in a “Transferred-by-user Scenario” is set according to the outcome of the last User Session.
| Transfer Scenario | User A - Session 1 Outcome | User B - Session 2 Outcome | Expected Service Session Reporting Outcome1 |
|---|---|---|---|
| User A transfers to Internal Destination B, which accepts | Transferred Internally | Accepted | User Internal Transfer Success |
| User A transfers to Internal Destination B, which does not respond (ignore) | Transferred Internally | Cancelled |
On safe transfer: → Last User A outcome On blind transfer: User Internal Transfer Failed |
| User A transfers to Internal Destination B, which rejects | Transferred Internally | Declined | Declined |
| User A transfers to Destination B Voicemail 2,3,4 directly | Transferred Internally | None, as no User Session is created for user B.2 | User Internal Transfer Successful |
1 See Nimbus Reporting Model > Static Dimensions > “User Session Outcomes”
2 Voicemail and Reporting: Any direct "Transfer to Voicemail" Actions via Attendant Console are not creating a new User Session or any related User State checks for the Nimbus Reporting Model.
3 Automatic Voicemail prevention: When the destination doesn't accept - and has Voicemail enabled - the transfer will NOT reach the Voicemail. → This is expected Contact Center behavior to avoid a potential call loss.
4 Disabled Voicemail: Refer to the “Transfer to disabled Voicemail” limitation below.
Transfers to disabled Voicemail
INC Voicemail Limitations
☝KNOWN LIMITATION: Currently, there is no way to check ahead if a (target) user has voicemail features enabled. This is a design limitation by Microsoft which Nimbus currently cannot circumvent.
Additionally, the voicemail feature may also be deactivated as part of a tenant-wide IT policy by your administrator. There are also known cases where Microsoft accepts transfers to voicemail but the recipient has no means to check (e.g. MS Teams Client / License restrictions). We highly recommend using this feature only in case voicemail is enabled for the Microsoft Teams user.
Attendant Console 1.0
By default Nimbus supports internal Service to Service transfers without further requirements. For Attendant Console users a Service Transfer does not visually differ from any Blind Transfer or Safe Transfer. However, special restrictions and behaviors apply.
Transfer Limitations
In the following, let's assume a simple scenario where Nimbus Service A acting as receptionist desk, forwarding calls to a Nimbus Service B.
Scenario |
Outcome |
||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Safe transfer |
→ We recommend using "Blind Transfer" in a Service to Service transfer scenario. Make sure to check the presence status of the receiving Service to ensure users are available to handle the call. |
||||||||||||||||||
| PSTN transfers |
TRANSFER TO PSTN LIMITATIONOut-of-the-box, Nimbus and affiliated addons can only perform PSTN transfers according to Microsoft's licensing and constraints. Which PSTN license do I need to acquire?As a tenant administrator you need to acquire the following licenses and assign them to the application instance of the respective Nimbus SOURCE service (team) that will act as PSTN transferor:
How does PSTN licensing affect Service and Call Transfers?Assuming that Service A has a PSTN license assigned - but further Services don't - the following scenario may unfold:
☝ Note that handling and tracking of running cost for PSTN licenses is outside of Luware support scope. Luware Support
🔍 Refer to the external reference: Microsoft Teams PSTN connectivity options and Microsoft Teams add-on licenses. |
||||||||||||||||||
Reporting Outcomes
Assuming the same Service A to B scenario above, the following Power BI related outcomes apply:
- For each Service a separate Service session is created respectively for reporting.
- Both sessions are combined in a unified / user session (customer journey).
The Nimbus Reporting Model outcomes :
| Task Result | Successful | Not Successful |
|---|---|---|
| User Session | Service Task Transferred Internal | Service Task Accepted |
| Service Session | User Internal Transfer Success | User Accepted |