Precondition: The settings are only accessible to team owners. Normal users (team members and guests) will not see the settings.

When the Nimbus Personal App is installed you can also access settings in the My Services overview. The overview is showing all the teams you are a part (and owner) of:

Some settings rely on resources, workflows and other entities which are created and managed via the Configuration.

General Tab

Contains general service settings such as the Service name, PSTN number an Opening Hours

Service

Contains functions that help with Nimbus provisioning or testing of your service, which is particularly useful when testing changes or connectivity.

(question) Why are Service settings locked? 

Full settings are are accessible to Tenant Administrators and part of the Nimbus installation procedure. Changes to these details require Tenant Admin consent to make changes and require a script to apply the changes. Refer to Nimbus Installation for further details.

As a Service / Team Owner you can see the following details. Entries marked with (warning) require a (re)execution of a Provisioning Script. → See Note above. 

Name -Name of the Team as it is defined in Microsoft Teams client. Nimbus 
Service Display Name(warning)

Outwards facing Clear Name of the Service as Callers / Customers will see it.

(lightbulb) by default equal to the "Team" Name as it is shown in Microsoft Teams. Can be overridden if needed.

Service UPN(warning)The UPN (User Principal Name) under which the Service can be reached via user directory.
Application ID-The Application ID is provided during initial setup and cannot be changed. Used only for reference, e.g. during support cases or when adjusting Required Permissions.

Test Calls

A test call will directly call the Nimbus call-bot and establish a connection to your service. You can use this feature to test your workflows and/or distribution settings.

(lightbulb) Please note that this feature will not test any PSTN numbers assigned to your service. To test a PSTN you need to call via cell phone or landline.

Changes on (existing) Services

Changing a Service Display Name

  • Nimbus bot operation is not affected by service name changes.
  • A service name change will also not impact the (search-discoverable) service UPN name specified.
  • Nimbus users will see team name changes reflected in their "My Teams" listing immediately.

As team owner you can change your team name directly within Microsoft Teams (native, non-Nimbus functionality):

  1. Within Teams, locate your team 
  2. Click on the "..." icon or right click the team name
  3. Select "Edit Team" → A dialog will open
  4. Change the team name (and optionally the description) to any desired content. → The Nimbus "settings" tab will reflect the new team name upon next load. 


Triggering Changes / Admin Consent

UPN and Service Display name changes are tied to Tenant Admin Consent and a Nimbus Installation provisioning script rerun which can take several minutes to take effect. Any change is therefore marked with a (warning) Warning in the UI.


(tick) If Runbook has been deployed by a tenant administrator, the Trigger Runbook link may be used by any team owner to automate the settings-change process. However, a tenant administrator still has to give consent to each change.
(lightbulb) Note that any changes can have an effect on search discoverability / address books and directories that list the Service under its previous name.

PSTN

Allows to assign a public telephone number (Public Switched Telephone Network) to your service. 

This setting should not be enabled without subject-matter knowledge or prior Tenant Admin / Nimbus support contact consultation. Refer to the Installation Prerequisites for further info on PSTN / Number requirements.

(question) Why is this necessary? Administration and licensing of PSTN numbers is outside of Luware control. Number assignment may result in additional set-up efforts and running costs. Get in touch with your Nimbus support representative if you need to change this setting anytime after your initial Nimbus deployment.

Opening Hours

Allows you to apply the Opening Hours (outwards-facing status & reachability) of your service team.

(tick) Opening Hours entries must be created first to be applied here. Entries may be created as tenant-wide or team-only.

Define primary and secondary opening hours

Ruleset: Primary and Secondary Opening Hours

  • If at least one defined period is found in the primary opening hours calendar, this period is prioritized.
  • If there is no period in defined primary calendar, the secondary calendar period is applied.
  • If no appointment is found on both calendars (with secondary configured), the "Default" of the first calendar is used.
  • The default of the secondary calendar never applies in a two-calendar scenario. If the secondary calendar has no periods defined it is effectively ignored.

(lightbulb) Rule of thumb: Primary Defined > Secondary Defined > Primary Default

Reporting

(info) These values are mandatory Service Level Agreements to specify as they are integral part of your team's Reporting and the Nimbus Reporting Model KPI calculation.

SLA Acceptance Time in Seconds

Maximum allowed time in queue before a task (read: incoming call) in your Dashboard is flagged as outside of SLA. 

(info) Shows as "Acceptance SLA" in both Reporting and historic Nimbus Reporting Model.

SLA Hangup Time in Seconds

Minimum allowed time in which the caller can hang up on a call without it being flagged as outside of SLA. 

(info) Shows as "Hangup SLA" in both Reporting and historic Nimbus Reporting Model.

(lightbulb) Hung-up calls will still be considered as failed and thus show up as "Hangup in Queue" (red) in Reporting.

SLA = Service Level Agreement

Workflow Tab

Shows workflow related settings. Use the pull-down to choose any of the Workflows of your team. 

Potential live business impacts!

Note that changing or editing any productive Workflow will immediately apply to your current service once you press "Save and Apply". In case of an incomplete or erroneous workflow this may cause interruptions to your daily service.

  • If you want to make changes without impacting current productive work, make changes in the workflow tab instead, e.g. by working on a separate workflow that you can test on a separate service team first. When finished editing you have the possibility review changes first before setting the new workflow as your productive one.
  • We recommend to perform workflow switches at certain points or outside business hours. 
  • Existing call sessions will be handled with the workflow settings they were created with.

Voice Message Channel

Some workflows can contain steps that create voice messages, e.g. shown within Adaptive Cards. Any Microsoft Teams channel within your team can be used, "General" being the default.

(lightbulb) Nimbus chat bot will automatically post voice messages to the new channel, however existing messages are not transferred.

Distribution Tab

Contains settings that directly related to call distribution. 

(info) Note that these settings apply universally to all current or future users in this service. 

Users

Allows to configure settings that affect Nimbus service team users.  as they are invited to become Nimbus users.

User Assignment Type

Shows how (new) users are assigned to this service.

(lightbulb) The default for Nimbus is "Microsoft Teams Based". Users are directly synched to the Teams channel related to the current service.

(question) Why is this setting locked? The assignment type is determined during service creation. Further options are available via the Service Administration.

New users immediately active

The "Activesetting determines if Microsoft Team "Members" are considered as users for Nimbus call distribution. Enabling this feature will automatically add new team members to your Nimbus service team.

This has the following effects:

  • Only "Active" users may receive Nimbus distributed calls. Users may still be part of a team but remain inactive for the team's designated Nimbus Service.
  • Team Members that are set "Active" at least once in a month will count into statistics of the Nimbus Administration.
  • Active Members are immediately part of the Nimbus task queue distribution according to the set Workflows and may handle calls for the service team.
  • They also appear as "Active" in the Dashboard for all other team members.

Good to know

  • Both Team Owners and Team Members themselves can toggle their "Active" state at any time within either the My Services tab of the personal Nimbus app or the Team Dashboard >"My State" widget.
  • Toggling this state acts as a quick "gate" to opt-in and -out of multiple Nimbus Services in case you want to balance your personal customer interaction as user and Nimbus capacity per service team.
  • In addition to the "Active" state the "User Presence" (within Teams) also needs to be in a state that allows for call distribution → see below.
Conversations Distribution

Defines settings that determine call distribution based on user presence state.

(tick) Precondition: Regardless of Microsoft Teams IM presence, a user always needs to be "Active" in the service to receive Nimbus distributed calls → See above.

(lightbulb) Scenarios for enabling "Away" or "Busy" users for call distribution could be:

  • Service engineers working "away" abroad , e.g. with a mobile teams client running, but should still remain reachable.
  • Users being occupied "busy" in meetings, but still can take important calls.

IM presence states considered by Nimbus are:

  • Available
  • Busy
  • Do Not Disturb
  • Away
  • Offline

Effects of this Setting: On the My Services dashboard a user will be shown in state: "(Not) Available" according to the configuration above:


Notes:

(lightbulb) When a user is part of multiple teams and already taking a call for one service line, the user is also marked as "Not Available" in all other Nimbus teams.

(lightbulb) During already ongoing tasks the Teams presence is also re-evaluated depending on "Queue" activity "Distribution Type" setting:

    • Broadcast: When a user turns back to "Available" and a broadcast task is in the queue →  During the next distribution iteration (timeout criteria or decline by other users) this user included for distribution.
    • Direct:  When a user turns back to "Available" and a direct distribution task → During the next distribution iteration (e.g. RONA criteria or decline by previously selected) this user included for distribution.
    • Pickup: When user is "Not Available" Pickup controls are disabled in the Dashboard. → A message will be shown on mouse-over that the IM presence is preventing task handling. During the next distribution iteration (e.g. RONA timeout) this user included for distribution.

Related settings to check

Whenever you make adjustments to your Distribution we also recommend to check the following settings:

  • Workflows - as activities inside such as "Availability-based Routing" or "Queue" will affect call distribution, reaching more or fewer (active) users respectively.
  • Your General Service Settings (see above) - as user availability affects your reporting SLA, which you might want to adjust if more or fewer (active) users are available to take calls in time.


Context Tab

(lightbulb) Please note that this a Enterprise Routing Feature

Allows to configure additional information (codes, context) that may be shown alongside a service call.

Conversation Context 

Enterprise Routing

By adding Context a separate URL (e.g. a CRM or Support-Tool) can be opened in additional browser tab.

(tick) Available items must be defined via the Conversation Context page as part of your Service Configuration

Preconditions

(warning) Limitation: The Microsoft Teams client currently has no possibility / permissions to open extra Context-Tabs automatically, so your additional Conversation Context may not show.


Prerequisites for using this feature:

  • The the Nimbus Personal App must run in a browser tab for each team member that want to receive context during a call. You can open the app via the "Go to Website" Icon located at the top right of your Nimbus app.
  • Ensure that no blockers or URL filters are active (e.g. IT policy, Ad-Blocking Addons, Browser Settings) that could prevent opening of extra tabs.

(lightbulb) Note: Context defined here generally entries apply to all your team members, so all of them need access to the (outside) URL or system that you may define as context to open.

Codes (TCC, CSC) 

Enterprise Routing

Allows Enterprise Routing users to specify Task Completion and Cross Selling codes to be stored during a customer interaction in the My Sessions view.

(tick) The corresponding TCC, CSC Widgets need to be enabled in → Extensions Tab (see chapter below). 

Extensions Tab 

Manages features such as the My Sessions tab and Attendant Console. Enabled features are immediately available to all Nimbus service team members.

Before you enable extensions

Please note that some extensions will only provide their full functionality when your license is expanded. Refer to Nimbus Features for an overview.

Attendant Console

Enables Attendant Console in the menu, providing each Nimbus user in your team with an individual "Switchboard" for incoming call mangement and forwarding.

(tick) TENANT ADMIN Note that this option uses Address Books to be configured in the Configuration Administration (Admin of Nimbus).

My Sessions Dashboard toggle

My Sessions Dashboard

Enables My Sessions in the menu, providing each Nimbus user in your team with an individual session history. 

(tick) Note that this option requires Codes and Conversation Context features to be configured and applied for each service.

(lightbulb) The My Sessions tab will only show contents during an ongoing call. → Once active this feature will be accessible all team members.

My Sessions Dashboard toggle

Widget Configuration

Allows to enable or disable available widgets in the My Sessions view. Useful when you want to reduce visual complexity or not want to use certain features (yet).

Toggles to enable single UI elements