|Term / Abbreviation
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:
🔍 See Role Access Concept for further details.
From Microsoft docs:
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 the Assistant app.
|Nimbus extension (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 part of the Nimbus Frontend UI, but can also be installed on your PC as a separate App, allowing you to get call information or open websites without the need to keep Nimbus open in your browser.
|Attendant (Nimbus Extension)
Nimbus extension. Can mean two things in context:
|Cloud platform and services hosted by Microsoft. Used to host Nimbus infrastructure and services.
The term "Caller" generally applies to someone externally calling (inbound) 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. marking a Selling and Task Completion via specific codes. Codes can be defined globally, and applied individually within Service Settings for each Nimbus service.
Establishes the means to connect Nimbus data sources to other systems, either to retrieve or store data.
💡 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.
🔍 Used as a 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
A ruleset/requirement set of Skills and Responsibilities that a Nimbus user must have/fulfill in order to receive a Task.
🔍 Also see Distribution Policies.
|Dial-tone multi-frequency signaling. Used in Nimbus Workflow Activities (e.g. "Input Customer" to route calls according to the choice made by the incoming caller).
State that signals if user 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.
Phone number format used in some parts of the system (for example PSTN Numbers, contact details)
🔍 See Wikipedia.
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.
|Generally refers to the Portal (Front-facing) user UI of Nimbus and related products.
|Key Performance Indicators. Data calculated from facts gathered during a session/call. Examples for KPI are "% of lost calls" or "Time that a customer spent in queue".
|Modality is the channel of communication (chat, call, email, etc.) being used by customers to interact with a service in Nimbus.
Multimodality is the application of multiple modalities within one medium.
In Nimbus, the modality describes which means of contact (instant message, call, etc.) is being used by customers to interact with a service. A multimodal contact center supports any means of contact.
|Abbreviation for Microsoft. In this context generally used when we refer to services provided by Microsoft, such as Azure.
|Organization Unit. Used to organize teams of people with same background for definition in programming rule sets (e.g. for call-routing or access management).
|Owner (Service, Team)
In Nimbus the equivalent to a Service Administrator. There are two types of owner roles to distinguish:
🔍 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:
🔍 Also refer to User Roles 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).
A responsibility Profile forms a combination of both skills and responsibilities. Multiple profiles can be 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 therefore 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. Ensures that the call doesn't get lost and is instead redirected to the queue (or handled otherwise via the workflow). 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.
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-directed UPN and PSTN.
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.
|Session Initiation Protocol. Also used as short descriptor for SIP-address. Peer-to-peer protocol standard developed by the Internet Engineering Task Force (IETF), used for initiating—and also managing and terminating—voice call sessions over the internet.
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 a responsibility.
🔍 Also see Skills and Responsibilities
Service Level Agreement. A threshold value that defines whether a fact calculation formula is meeting business criteria.
|A small piece or brief extract of a larger data entity (e.g. Service). Can also refer to a code or HTML snippet to be included in your website, e.g. in context of Use Case - Setting up Interact.
Tags are individual descriptive words used in My Sessions to describe and distinguish call sessions for reporting purposes.
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.
|Text to Speech (TTS) is a technology to translate written text into speech sounds imitative of the human voice.
User Interface/User Experience refers to everything a Nimbus user can interact with, e.g. a configuration dialog, 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.
|A User Principal Name (UPN) is an internet communication standard for user accounts. It consists of a prefix (e.g. user account name) and a suffix (domain name), joined by the separator (@ symbol), e.g. firstname.lastname@example.org.
|A Uniform Resource Identifier (URI) is a string of characters that unambiguously identifies a particular resource. To guarantee uniformity, all URIs follow a predefined set of syntax rules, but also maintain extensibility through a separately defined hierarchical naming scheme (e.g. "http://").
The term User has various meanings depending on the context:
A sequence of steps (or "Activities") that describes how an incoming caller is processed.