Static dimensions consists of a fixed member list. This list is static on every deployed system and may change only by a Nimbus system version update.
🔍OUTCOME GROUPS
- 💡Outcome Groups - To generalize and simplify reporting, all Service Session outcomes are classified into groups.
Id |
Name |
|---|---|
| 1 | Handled By User |
| 2 | Handled By System |
| 3 | Hangup By Customer |
| 4 | Not Handled |
| 5 | Error |
| 6 | Outbound Accepted |
| 7 | Outbound Not Accepted |
- 💡Outcome Calculation - Note that these columns are not provided by the OData feed, but calculated in the Power BI Template.
- 💡Description columns are generally not part of the dataset.
- 💡Lines greyed out (if shown) are used for error-handling. They are not included in the dataset.
Service Session Outcomes
Service Session Outcomes
Service session outcomes determine how a task has concluded (Handled or Not Handled), with a more detailed outcome.
Id |
MeansHandled |
HandledText |
GroupId |
Outcome |
Description |
|---|---|---|---|---|---|
| 1 | False | Not Handled | 3 | Customer Hangup Before Accept | Customer hang up the call before it was accepted into the Nimbus system. Where "accepted into the Nimbus system" refers to the session going through the "Accept" Activity in the Workflow. |
| 2 | False | Not Handled | 3 | Customer Hangup In Ivr | Customer hung up the call before it was put into the queue |
| 3 | False | Not Handled | 3 | Customer Hangup In Ivr After Queue | Customer hung up after the call left the queue |
| 4 | False | Not Handled | 3 | Customer Hangup In Queue | Customer hang up the call during the time the task was enqueued |
| 5 | True | Handled | 1 | User Accepted | User accepted the task and was connected to the customer, this includes Consultation Call (without merge or transfer) and External Tasks |
| 6 | True | Handled | 1 | User Internal Transfer Success | User accepted the task and transferred it to another service Line or User. This includes as well the case if a User transfers the call after a consultation call |
| 7 | True | Handled | 1 | User External Transfer Success | User accepts the task and transferred to a non Nimbus service line or User. This includes as well the case if a User transfers the call after a consultation call |
| 8 | False | Not Handled | 4 | Workflow Disconnect After Queue | Workflow terminates the call conversation or task (external, email) after it was put once into the queue |
| 9 | False | Not Handled | 4 | Workflow Disconnect | Workflow terminates the callconversation or task (external, email), which was never put into the queu |
10 |
False |
Not Handled |
5 |
System Failure |
An severe unhandled error occurred. May relate to Microsoft infrastructure. |
| 11 | True | Handled | 2 | Workflow Conversation Recorded | Workflow recorded a voice message / mail |
| 12 | True | Handled | 2 | Workflow Internal Transfer Successful | Workflow transferred the call to another Service Line or a User from the same o365 tenant successfully |
| 13 | False | Not Handled | 4 | Workflow Internal Transfer Failed | Workflow couldn't transfer the call to another Service Line or a User from the same o365 tenant |
| 14 | True | Handled | 2 | Workflow External Transfer Successful | Workflow transferred the call successfully to a non Nimbus service Line target (e.g to an external target or phone number) |
| 15 | False | Not Handled | 4 | Workflow External Transfer Failed | Workflow couldn't transfer the call to a non Nimbus service Line target (e.g to an external target or phone number) |
| 16 | True | Handled | 1 | User Internal Transfer Failed | User accepted the task and transferred it to another service Line or User, but didn't succeed |
| 17 | True | Handled | 1 | User External Transfer Failed | User accepts the task and transferred to a non Nimbus service line or User, but didn't succeed |
| 18 | True | Handled | 1 | User Conferenced | User accepts the task and adds a 3rd Participant (Expert, Merges a Consultant) into the customer session |
| 21 | False | Cancelled by External System | 4 | External System Cancelled Before Accept |
The task was terminated via Power Automate before it was accepted by the system Analogue of Hangup Before Accept in AV conversations |
| 22 | False | Cancelled by External System | 4 | External System Cancelled |
The task was terminated via Power Automate before it was put into the queue Analogue of Hangup In IVR in AV conversations |
| 23 | False | Cancelled by External System | 4 | External System Cancelled In Queue |
The task was terminated via Power Automate after it left the queue Analogue of Hangup In IVR after Queue in AV conversations |
| 24 | False | Cancelled by External System | 4 | External System Cancelled In Queue |
The task was terminated via Power Automate in queue Analogue of Hangup In Queue in AV conversations |
| 31 | True | Handled | 6 | Destination Accepted | User and Destination (customer) both accept an outbound task |
| 32 | False | Not Handled | 7 | Destination Declined | User accepts an outbound task, but Destination declines |
| 33 | False | Not Handled | 7 | Destination Not Reached | User accepts an outbound task, but Destination ignores, Destination is offline, or MSFT cannot reach Destination by some other reason |
| 34 | False | Not Handled | 4 | User Aborted | User either does not accept CallOnBehalf task or terminates outbound task during dial out to Destination before Destination reacts to it |
| 35 | False | Not Handled | 4 | Lost in Queue | Workflow terminates outbound call after it was put once into the queue |
| 41 | True | Handled | 2 | Workflow Marked as Handled | Workflow marked Email session as handled. |
| 42 | True | Handled | 2 | Forwarded by Workflow | Workflow forwarded Email to any email destination. |
| 43 | True | Handled | 1 | User marked as handled | User marked Email session as handled without any other action (e.g. no reply or forward). |
| 44 | True | Handled | 1 | User forwarded | User forwarded Email to any other email destination. |
| 45 | True | Handled | 2 | Standby Duty Accepted | Internal Standby Duty Destination accepted and confirmed via DTMF tone the customer session. |
| 46 | True | Handled | 2 | Standby Duty Accepted | External Standby Duty Destination accepted and confirmed via DTMF tone the customer session. |
💡 Lines greyed out are used for error-handling. They are not included in the dataset.
User Session Outcomes
User Session Outcomes
When a task is handled by multiple Nimbus Users, each User has an individual session with own outcome.
Id |
Name |
ActionGroup (🔍▲) |
Handledtext (🔍▲) |
Description |
|---|---|---|---|---|
| 1 | Accepted | Accepted |
Accepted |
User accepts a service line task or User transfer attempt (transfer via Nimbus UI, i.e. Attendant Console or Assistant) fails |
| 2 | Declined | Declined |
Not Accepted |
User declines a service task |
| 3 | Ignored | Missed |
Not Accepted |
User does not accept a service task within the defined time (RONA) |
| 4 | Canceled | CustomerAbandoned |
Not Accepted |
User couldn't accept a service task because it was cancelled by the system or customer |
| 5 | Transferred Internally | Transferred | Accepted | User transfers the call to a Nimbus service line or Nimbus User and the corresponding target accepts (successful transfer). |
| 6 | Transferred Externally | Transferred | Accepted | User transfers the call to a non-Nimbus service line or non-Nimbus User and the corresponding target accepts (successful transfer). |
| 8 | Consulted | Accepted | Accepted | User made a consultation call after accepting a service call |
| 9 | Consulted Transferred | Transferred | Accepted | User made a consultation call after accepting a service call and transferred the customer to the consultant. |
| 10 | Consulted Merged | Conferenced | Accepted |
User made a consultation call with the Attendant Console after accepting a service call and subsequently merged the customer's call with the consultation call - creating a conference with all 3 parties.
🔎 For more information about consultation calls and the merging scenario → see Attendant - Consultation Call > "Consultation conference". |
| 11 | Outbound Accepted | Accepted | Accepted | User accepted a task to make an outbound call on behalf of a service. |
| 12 | Outbound Not Accepted | Declined | Not Accepted | User received but did not accept a task to make an outbound call on behalf of a service. |
| 13 | Outbound Aborted | Declined | Accepted |
User accepted a task to make an outbound call on behalf of a service, but aborted it. |
| 14 | Outbound Destination Not Reached | Destination Unreachable | Accepted |
User accepted a task to make an outbound call on behalf of a service, but the destination did not respond in time. |
| 15 | Outbound Destination Declined | Destination Unreachable | Accepted | User accepted a task to make an outbound call on behalf of a service, but the destination did reject the call. |
| 16 | Marked as Handled | HandledByUser | Accepted | User marked Email session as handled without any other action (e.g. no reply or forward). |
| 17 | Forwarded | HandledByUser | Accepted | User forwarded Email to any other email destination. |
| 18 | Internal Transfer Failed | Transfer Failed | Accepted | User blind transfer attempt to a service line or Nimbus User fails (e.g. User declines or target service has respective modality disabled.) |
| 19 | External Transfer Failed | Transfer Failed | Accepted | User blind transfer attempt to a non service line, external target or phone number failed (e.g. User declines, etc.) |
Distribution Algorithm
Distribution Algorithm
The distribution ordering algorithm determines how a task was distributed to a User, either preferring task queue duration or qualification.
Id |
Name |
|---|---|
| 1 | Longest Idle |
| 2 | Best Qualified |
🔍 Also see Distribution Order and Skills and Responsibilities.
Distribution Type
Distribution Type
Describes in which way the call was sent to a Nimbus User.
Id |
Name |
|---|---|
| 1 | Direct |
| 2 | Broadcast |
| 3 | Pickup |
| 4 | Pickup Through Transfer |
| 5 | Direct Conference |
| 6 | Pickup Conference |
🔍 Directly relates to the "Queue" Workflow Activity which defines Distribution Type setting. Also refer to Task Queue and Distribution for more details.
Modality
Modality
Describes the Modality (communication channel) of handled tasks.
Id |
Name |
|---|---|
| 0 | Used for Data Aggregation (not modality-specific) |
| 1 | Audio / Video |
| 2 | Instant Messaging |
| 3 | External Tasks |
| 4 |
🔍Note that Data Aggregation is done in specific time intervals per modality in both Service and User sessions. Services (and Users) may only handle Modalities (and thus create reporting sessions) when configured via Modalities Service Settings.
Task Type
Task Type
Describes the type of a task.
Id |
Name |
TaskDirectionId |
IsService |
TaskTypeGroupId |
|---|---|---|---|---|
| 0 | Inbound Service | 1 | TRUE | 1 |
| 1 | Call on Behalf | 2 | TRUE | 2 |
| 2 | Outbound Service Call | 2 | TRUE | 2 |
| 3 | Inbound Direct | 1 | FALSE | 3 |
| 4 | Outbound Direct | 2 | FALSE | 4 |
🔍 Also refer to the "Tasks" tab in Slowly Changing Dimensions. Outbound Tasks refer to an Outbound Call scheduled via Flow Actions. Manually initialized calls by Users that are not using Nimbus Call On Behalf functionality are not tracked in reporting.
Transfer Session
Transfer Session
Describes Transfer Session source and targets and results.
|
TransferSessionDestinationTypes
|
TransferSessionTypes
|
||||||||||||||||||||||||||||||||||||||||||||||||||
|
UserTransferActionTypes
|
TransferSessionOutcomes
|
🔍Transfers are primarily started via Attendant Console. Refer to:
User State Type
User State Type
Describes the status of the User, defining the ability to accept and handle tasks.
Id |
Name |
|---|---|
| 1 | Offline |
| 2 | Off Duty |
| 3 | Selectable |
| 4 | Not Selectable |
| 5 | Ringing |
| 6 | Connected |
| 7 | After Call Work |
🔍 Also refer to User States for more in-depth explanation on how Nimbus defines these states.