Nimbus Glossary
Term / Abbreviation | Definition |
---|---|
ACW | 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.
|
Admin(istrator) | Several meanings in Nimbus:
|
Adaptive Card | 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. |
Agent | A term commonly used in service- and call center context, referring to professionalized → Users answering to very specific targeted → Customer calls.
|
Assistant | 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. |
Attendant (Nimbus Extension) | Nimbus extention - can mean two things in context:
|
Azure | Cloud platform and services hosted by → Microsoft. Used to host Nimbus infrastructure and services. |
Caller | 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. |
Codes (Primary/Secondary). | 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. |
Connector | Establishes the means to connect Nimbus data sources to other systems, either to retrieve or store data.
|
Contact | A reference entry (user or service) within Address Books, mainly accessed via Attendant Console when handling and forwarding individual calls.
|
Contact Center | A specific Service type of Nimbus, also described in Nimbus Features. |
Customer | → See "Caller". A person calling a Nimbus service. |
DAX |
|
Dimension | 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
|
Distribution Policy | A ruleset / requirement set of → Skills and Responsibilities required that a Nimbus user must fulfill in order to receive a → Task.
|
DTMF | 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. |
Duty / Off Duty | 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.
|
E.164 | Phone number format used in some parts of the system (for example PSTN Numbers, contact details) → See Wikipedia. |
Fact | 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.
|
Frontend | Generally refers to the → Portal (Front-facing) user UI of Nimbus and related products. |
KPI | 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 | 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. |
MSFT | Abbreviation for Microsoft (stock symbol). In this context generally used when we refer to services provided by Microsoft, such as → Azure. |
OU | 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:
|
Partner | Mainly used in context of Role Access Concept to refer to "Partner Administrators".
|
Portal | The general graphical interface of Nimbus for all users, requiring authentication to interact with. Divided into:
|
PSTN | 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. |
Responsibility (Profile) | Enabled and tied to a skill category, e.g. knowledge about a product X or a certain language Y.
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.
|
RTC | 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). |
RONA | 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).
|
SDK | 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.
|
Service | An instance in Nimbus with an outwards-facing → UPN and → PSTN.
|
Session (Call) | 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.
|
SIP | 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. |
Skill / Skill Category | 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.
|
SLA | Service Level Agreement. A threshold value that defines whether or not a → Fact calculation formula is meeting business criteria or not.
|
Snippet | 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 | Tags are individual descriptive words to be used in My Sessions to describe and distinguish call sessions for reporting purposes.
|
Task | 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. |
Tenant | 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. |
TTS | Text To Speech - a software engine to translate written text into an emulated voice that also factors in regional / language differences and nuances such as intonation. |
UI / UX | User Interface / User Experience - refers to everything a Nimbus user can interact with, e.g. a configuration dialogue, call controls, buttons, toggle switches, etc.
|
UPN | User Principal Name - A UPN (for example: john.doe@domain.com) consists of the user name (logon name), separator (the @ symbol), and domain name (UPN suffix). |
URI | 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://"). |
User | Has various meanings depending on context:
|
Workflow | A sequence of steps (or "Activities") that describes how an incoming → caller is processed.
|