Nimbus Glossary

After Call Work - Time granted to complete tasks that are necessary after an incoming call, e.g. CRM updates, closing Conversation Context, adding Task or Sales completion Codes to the My Sessions view.

ACW can be configured for each Service via the Service Settings.

Several meanings in Nimbus:

• Tenant / Partner Administrator (Role) - Performs administrative tasks such as Service Provisioning.
• Service Administrator (Role)  - Mixed role with access to both → Portals. Can perform Administration tasks as well as configure Service Settings.
• Admin Portal the Administration interface of Nimbus,

See Role Access Concept for further details.

From Microsoft docs: 

Adaptive Cards are an open card exchange format enabling developers to exchange UI content in a common and consistent way.

In Nimbus Adaptive Cards are used to display call information in a shared teams channel. The cards can be updated (adaptive) to reflect status updates or provide further functionality such as a link to the recorded call voice message.

A term commonly used in service- and call center context, referring to professionalized → Users answering to very specific targeted → Customer calls.

In Nimbus context, Agents are a subset of Nimbus users, which have specific Skills and Responsibilities assigned. These skillsets are used for grouping users in skill-based Distribution Policies during incoming calls.

Agents may operate "standalone" outside the typical Nimbus portals, in favor of getting individual call context via → Assistant app.

Nimbus extention - See Assistant - a Nimbus extension that provides and opens additional context during an incoming direct call and can operates outside of your My Sessions Dashboard. Assistant is also part of the Nimbus Frontend UI, but can also be installed on your PC as separate App, allowing you to get call information or open websites without the need to keep Nimbus open in your browser.

Nimbus extention - can mean two things in context:

• Attendant Console - an additional option to Nimbus used for individual call distribution
• Attendant (person) - the term to describe a receptionist / call operator that takes incoming customer calls to find the most suitable internal contact for further service.

Cloud platform and services hosted by → Microsoft. Used to host Nimbus infrastructure and services.

The term "Caller" generally applies to someone externally calling (inbound) to the → Service, which triggers the gathering of → KPI metrics inside of a → Session.

In most cases used synonymously with a calling Customer. In the context of this Knowledge Base the caller is an actor within our List of Use Cases speaking to a Nimbus → User.

Can be used in My Sessions to complete after-sales work, e.g. to mark a Selling and Task Completion via specific codes. Codes can be defined globally, then and applied individually within Service Settings for each Nimbus service. 

CodesCodes are tracked as part of the Call Session reporting and accessible via the Power BI OData interface.

Establishes the means to connect Nimbus data sources to other systems, either to retrieve or store data.

Also see Microsoft Power Automate Connector or Power BI.

A reference entry (user or service) within Address Books, mainly accessed via Attendant Console when handling and forwarding individual calls.

Access to contacts usually requires special permissions to see the Calendar and presence status, but of course may also involve external contacts with just a telephone number or mail address.

A specific Service type of Nimbus, also described in Nimbus Features.

→ See "Caller". A person calling a Nimbus service.

Data Analysis Expressions (DAX) is a library of functions and operators that can be combined to build formulas and expressions in Power BI, Analysis Services, and Power Pivot in Excel data models.

https://docs.microsoft.com/en-us/dax/

Used as term in Nimbus KPI Calculations.

In Nimbus reporting there are two types of tables → Fact table, and Dimension table. A Dimension table is a table that keeps descriptive information that can slice and dice the data of the fact table

 The term is primarily used in Power BI and describes data gathered for Nimbus Reporting Model.

A ruleset / requirement set of → Skills and Responsibilities required that a Nimbus user must fulfill in order to receive a → Task.

Also see Distribution Policies.

State that signals if a is ready and capable to receive calls. Based on →  Skills within their current user-chosen → Responsibility Profiles the "Duty State" is a combined signal flag for Nimbus to consider the user for call distribution as per → Distribution Policy.

Also see: Duty States. Responsibility Profiles

Facts are business process events and metrics gathered with appropriate measures. A fact table is a table that keeps numeric data that might be aggregated in the reporting visualizations. 

 The term is primarily used in Power BI and describes data gathered for Nimbus Reporting Model.

Multimodality is the application of multiple literacies within one medium. Multiple literacies or "modes" contribute to an audience's understanding of a composition. → See Wikipedia.

In Nimbus the modality describes which means of contact (Instant Message, Call) is being used by customers to interact with a service. A "multimodal" contact center supports any means of contact.

In Nimbus the equivalent to a Service → Administrator.  There are two types of owner roles to distinguish:

• Service Owner = Refers to a Nimbus specific owner of a service. Has access to Configuration and Service Settings.
• Team Owner = Refers to owner of a Microsoft Teams "Team". Depending on which User assignment types used for a Nimbus service this role can be synced. A "MS Teams Owner" then becomes the equivalent of a Nimbus "Service Owner".

Refer to Role Access Concept for more details. 

Mainly used in context of Role Access Concept to refer to "Partner Administrators".

Luware has an integration partner program in place that allows for quick turnaround times. Our partners help with your Nimbus onboarding, setup and training needs.

The general graphical interface of Nimbus for all users, requiring authentication to interact with. Divided into:

• Admin Portal - the Administration → UI for Partners, Tenant- and Service Administrators.
• Frontend Portal (or "Portal" for short) - the main User Interface for Service Team Owners and Members.

Also refer to User Permissions to see which roles have access to the individual portals.

Public Switched Telephone Network - synonymous with the telephone numbers we know of today.

→ Refer to Installation Prerequisites for technical information on phone numbers and PSTN.

Enabled and tied to a skill category, e.g. knowledge about a product X or a certain language Y. 

Example: For Product X we defined various responsibility levels (First Call Responder, Tech Expert, Product Lead)

Also see : Skills and Responsibilities

A responsibility Profile forms a combination of both → skill and responsibility. Multiple profiles can assigned to users, allowing them to switch between various stages of responsibility.

Example: Our Support team has 3 profiles defined, each with different responsibility levels. During travel they switch to the "Abroad" Duty States and are less-responsible and get fewer calls.

Real-time communication (RTC) is a category of software protocols and communication hardware media that gives real-time guarantees. In Nimbus context this protocol enables to establish → Sessions between customers and service (agents).

Redirect On No Answer. A Nimbus user in MS Teams is given RONA status if they ignore a service call or do not answer it within a set period of time seconds. Ensures that the call doesn't get lost and is instead redirected to the queue (or handled otherwise via the workflow).

As part of the User States model of Nimbus RONA is also included in the Nimbus Reporting Model. 

A software development kit (SDK) is a collection of software development tools in one installable package. They facilitate the creation of applications by having a compiler, debugger and sometimes a software framework.

Nimbus offers an Interact SDK to allow customers to create their own → UI to trigger certain → RTC interactions such as starting a call session between customer and agent.

An instance in Nimbus with an outwards-facing → UPN and → PSTN.

Nimbus distinguishes by different Service types, each with individual Service Settings. Also read our Installation Prerequisites before going on with Service Provisioning.

Mainly mentioned in terms of reporting. A call session is created once a customer is connected to the service. In extension, the term "session" refers to single, quantifiable → user and service interactions within Nimbus.

 Also see: My Sessions / Nimbus Reporting Model / Nimbus Reporting Model.

Any (comparable) trait or characteristic to define a user by. Skills must be sorted in a (pre-configured) skill-category which also defines if its a skill with levels or → responsibility.

Also see : Skills and Responsibilities

Service Level Agreement. A threshold value that defines whether or not a → Fact calculation formula is meeting business criteria or not. 

 SLA are part of Nimbus Reporting Model and pre-defined formulas are part of the Power BI reports that come with Nimbus.

Tags are individual descriptive words to be used in My Sessions to describe and distinguish call sessions for reporting purposes.

Tags are part of the Call Session reporting and visible in the Power BI Template.

Service tasks are the middle layer between callers and service. Tasks are created when calls are accepted by any Nimbus service.

A task is "handled" by accepting calls from the queue or "not handled" (e.g. aborted by caller or not taken by Nimbus user). Every task ends with a specific result according to the Nimbus Reporting Model and is shown in Reporting UIs.

A tenant is a group of users who share a common access with specific privileges to the software instance. Nimbus adds its own Organization Units model on top of the tenant model to share (or withhold) common data entities within the same tenant within selected user groups and → services.

To operate within the tenant, Nimbus has certain Required App Permissions, usually granted by the tenant admin during Service Provisioning.

User Interface / User Experience - refers to everything a Nimbus user can interact with, e.g. a configuration dialogue, call controls, buttons, toggle switches, etc.

The UI of Nimbus is divided in → Admin Portal and User Portal, usually referred to as → Frontend Portal or just Portal.

Has various meanings depending on context:

• Mainly: Users of Nimbus, which can assume a certain function or role → See Role Access Concept.
• All Microsoft Teams "Team Members" and "Team Owners" accessing Nimbus features are also considered Nimbus users.
• In the context of "Call Center" software, a user can also be an → Service Agent or Owner / → Attendant or Administrator, or any other role with a given set of Permissions.

A sequence of steps (or "Activities") that describes how an incoming → caller is processed. 

 Also see Workflows / Workflow Activities / Trigger Events (as part of Workflows)