Before you access Settings

  • Service settings are only available to service (team) owners TEAM OWNERAlso see permissions.
  • Tenant administrators TENANT ADMIN have access to further service options via the Service Administration.
  • Regular users TEAM MEMBERS (Agents) will not see the settings option at all. 


(info) Access to certain features may be hidden from view or locked, despite having an admin role. Special service licensing may be required. Refer to Service types and Nimbus Features for a comparison.

Configuration and Settings concept

When the Nimbus Personal App is installed in your MS Teams client you can also access settings in the My Services overview. Access to Settings is shown for each service you are owner of:


Also Note:

  • Some settings rely on shared resources, workflows and other data entities which are created and managed via the central Nimbus Configuration.
  • All data entity visibility is determined by their Organization Unit (OU) affiliation - including Services and Users. Tenant wide entities  - not tied to one particular service OU -  can be made available to all of your your services by a tenant administrator.

General Tab

Contains general service settings such as the Service name, PSTN number, Opening Hours and Reporting settings.

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 Opening Hours for your service team. Handling and routing based on opening hours is part of your Workflows e.g. by routing the call according to the "Check Opening Hours" Workflow Activity.

(tick) To be selectable in this Opening Hours entry (data entity) must be created first - and made available within the same Organization Unit of the service or Tenant-wide.

Define primary and secondary opening hours

Ruleset: Primary and Secondary Opening Hours

Each team may decide if the opening hours are defined as primary or secondary. This is determined via service-individual Service Settings > "General" Tab.

Selected primary, secondary and currently active opening hours shown

Opening Hours Period Ruleset:

  1. If at least one defined period is found in the primary opening hours calendar, this period is prioritized.
  2. If there is no period in defined primary calendar, the secondary calendar period is applied.
  3. If no appointment is found in either calendar (with a secondary configured), the "Default" state of the first calendar is used.
  4. 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!

In this example there are two calendars defined: one provided the Admin (e.g. Company-Wide special holidays) and one "Service Specific" calendar created by a Team Owner.

(lightbulb) For simplicity we're assuming these calendars operate on a "whole day" basis for one week. Each day will be handled differently to illustrate a case from the rules above. The customer will find the service status to be as follows:

  • On Monday the primary calendar has a "holiday" defined. → The service workflow will react according to the path defined for holidays (usually a closed-announcement), otherwise the default applies (also closed).
  • On Tuesday the primary calendar is default "closed", however the secondary has a special period defined. → In this case the the secondary calendar takes precedence.
  • On Wednesday the primary calendar is default "closed", however the secondary has an "open" period defined. → In this case the secondary calendar "open" period takes precedence.
  • On Thursday the primary calendar and secondary calendar have a default status, but no specific periods defined. → The primary default "closed is used, secondary default gets always ignored.
  • On Friday the primary calendar has a special event type defined. → Depending on how the service workflow is configured, it will react to the "special" primary calendar period (e.g. same as Tuesday).

Reporting

(info) These values are mandatory Service Level Agreements (SLA) 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 the Dashboard is flagged as outside of SLA. 

(info) Shows as "Acceptance SLA" in both Reporting and historic Power BI reporting. Directly relates to Nimbus KPI Calculations.

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 Power BI reporting. Directly relates to Nimbus KPI Calculations.

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

Hide User Statistics from Reporting

Privacy setting - To be compliant with GDPR regulations and to respect your Nimbus user's privacy you can hide the "User Statistics" widget from the Service's respective Reporting view.

When enabled:

→ The "Task Heatmap" widget will utilize the remaining space within the Reporting view.
All users will not be able to inspect the "User Statistics " (accepted / not accepted) tasks anymore. This also includes team owners / service administrators.


(lightbulb) Note that this setting is only affecting the Frontend reporting and not the actual Nimbus Reporting Model. You can still evaluate / anonymize call data within Power BI Paginated Reports.

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 related to call distribution.

(info) Note that - once applied - these settings affect all current or future users in this service.

Users

Allows to configure settings that affect Nimbus user status handling and call distribution.

User Assignment Type

Shows how (new) users are assigned to this service. → See User assignment types.

(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 Provisioning.

Distribution Policy

Contact Center Service Type feature.

(question) Why is this setting locked? Distribution Profiles and Policies are managed and changed via the Service Administration, depending on your service type and licsense.

New users immediately active

The "Active" setting 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.


An "Active" state 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 Workflowsand 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.

(question) Don't see this setting? Active state toggles do not apply for skill-based services. 

Conversations Distribution

Determines call distribution based on user presence state as set in their MS Teams client.

(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.

Setting Effects

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) IM presence states considered by Nimbus are:

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

Related settings to check

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

  • Workflows - as activities inside - such as "Availability-based Routing" or "Queue" will affect call distribution, reaching more or fewer (active) users respectively. MS Teams presence is also re-evaluated depending on the "Distribution Type" setting in the "Queue" workflow activity:

    "Queue / " workflow activityDistribution Type settingAvailability ScenarioEffective Task distribution

    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) the user is included for distribution.
    Direct

    When a user turns back to "Available " and a direct distribution task is in the queue.

    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 (e.g. in Dashboard)

    During the next distribution iteration (e.g. RONA timeout) this user included for distribution.

    (lightbulb) A message will be shown on mouse-over that the IM presence is preventing task handling.


    None, see node exit ►

    No One Available

    Currently all users are inactive (or active but set "offline" in MS Teams)

    None, see node exit ►

    In Time Available

    Currently active users are not immediately available e.g. "DND/Away/Busy" or when occupied by another call.

    None, see node exit ►

    Direct Available

    Currently at least 1 user is available = MS Teams presence set "available" and also set to "active" in Nimbus).

  • Reporting Settings  (Settings > General > Reporting ) - as user related distribution and availability changes can directly affect your reporting SLA.

After Call Work (ACW)

Contact Center Service Type feature.

ACW time (in seconds) is added to the end of a call session until the user is considered available again to take the next task.

(lightbulb) Usually this time is given to note down sales & task completion Codes in the My Sessions view or any external CRM system.

    • Default: 00:00:20s

    • Max: 1h (3600 seconds)

    • Min: 1 second

→ An "ACW" status will also be shown in the My Sessions view of the corresponding user.

Notes on After Call Work (ACW)

  • When a user goes offline in Microsoft Teams it will terminate the remaining ACW time for that user.
  • Changing the ACW Toggle / Time in settings during productive hours will have an impact on new Tasks only.
  • Users are blocked from all other Nimbus service calls during their ACW.
  • Also tracked in Power BI for reporting purposes. Reports ACW time in seconds or "Null" if disabled. Total ACW time in a single service session is summed up from all involved user sessions.

Outbound Service Call

Enterprise Routing Service Type feature. Allows all users of that service to impersonate as the service during an outbound call.

Preconditions

  • Users of this feature must be part of a Enterprise Routing Service.
  • The service must be configured for "Outbound Service Call" via the  Service Settings > Distribution Tab.
  • The service needs to have a PSTN number assigned in order to dial out to an external number. → Also see "Known limitations" chapter below.

To initiate Outbound Service Calls:

  1. Navigate to the My Overview or My Services view and click on the telephone icon next to the service you want to call as.
  2. → A teams dial out popup opens. You can now dial a number.
    (lightbulb) Before calling you can still choose between all services which are available to you (and enabled for "Outbound Service").
  3. To start the outbound conversation, click on the "Call" icon .

Call button states and interaction

  • Nimbus interactions will  disable the call button, e.g. when the user has incoming/connected/ACW task.
  • Offline and DND will not disable the button, User related "Busy Available/ Away Available" settings - made via Service settings > Distribution Tab > Conversations Distribution - are also ignored.

Known Limitations

Currently Known Limitations

  • PSTN Licensing: When the selected Service doesn't have an applied phone number, the dial pad is disabled. Dial out to a UPN is allowed. → Also refer to the "Transfer to PSTN Limitation" below.
  • UI visibility : "Outbound Service" calls are currently not shown in any UI like My Sessions or  Attendant Console - as a result user won't be able to park/transfer/consult/etc.
  • Reporting visibility: Terminated outbound calls are not reflected on any reporting view (Reporting, Dashboard or Power BI)
  • O365 Search: In order to retrieve and call to O365 contacts, a tenant admin need to grant "User.Read.All" consent for all Nimbus users, as described on the required user permissions page. We are investigating if these permissions can be reduced.


Transfer to PSTN limitation

Out of box Nimbus and affiliated addons can only perform PSTN transfers according to Microsoft services licensing & constraints.

Which PSTN license do I need to acquire?

(tick) As a tenant administrator you need to acquire and assign the following licenses to the application instance of the respective Nimbus SOURCE service (team) that will act as PSTN transferor:

Your SetupRequired License
Microsoft Phone System Direct Routing
"Microsoft Teams" (App license, available as part of the Microsoft 365 E1 / E3 / E5 and other packages)
+ "Microsoft Teams Phone Standard" or "Microsoft Teams Phone Standard - Virtual User"
Microsoft Phone System with Calling Plan


"Microsoft Teams Phone Standard" or "Microsoft Teams Phone Standard - Virtual User" 
+ "Microsoft 365 Domestic Calling Plan" or "Microsoft 365 Domestic and International Calling Plan"
+ "
Communication Credits" (if these aren't already included as part of your plan)
How does PSTN licensing affect Service and Call Transfers?

Assuming that Service A has a PSTN license assigned - but further Services don't - the following scenario may unfold:

  • Scenario A - Service A workflow is configured to transfer the caller to Service B. The license of Service A is used, the PSTN transfer occurs. The PSTN license is re-used throughout further transfers to Services C..D...x.
  • Scenario B - Service B is called directly instead. Now the workflow of Service B attempts a redirect to either service A or transfer to C. The PSTN transfer fails due to a missing license on Service B.

Learnings

  • For one first-level-response Service: If you handle first-response calls always via the same Service you need a PSTN license for that particular first-level Service.
  • For multiple first-level-response Services: If you handle first-response calls always via multiple Services you need a PSTN license for all those first-level Services .
  • Nimbus will attempt to use the PSTN license of the first service that responded to a call, regardless of how many further internal service transfers are performed thereafter.
  • If no PSTN license is found on a service that requires it for a transfer, the transfer task will be considered as failed and be treated as such by the system (e.g. workflow exit announcement, reporting "transfer failed" outcome).

(warning) Note that handling and tracking of running cost for PSTN licenses is outside of Luware support scope.
If you require assistance in extending and/or configuring your Nimbus services for PSTN our support will gladly assist you:


(info) Refer to the external reference: Microsoft Teams add-on licenses.

Context Tab

Enterprise RoutingContact Center

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

Conversation Context 

Enterprise RoutingContact Center

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 (Primary, Secondary) 

Enterprise RoutingContact Center

Allows users to specify Primary and Secondary codes to be stored alongside a customer interaction in the My Sessions view. Codes will stored as part of historic reporting and available via Power BI.

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

(tick) Primary and Secondary Codes must be configured beforehand before they can be added.


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 and get in contact with your Nimbus sales contact if you require a demonstration.

Attendant Console

Enables Attendant Console in the main menu, providing each Nimbus user in your team with an individual switchboard UI for incoming call management and forwarding.

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

My Sessions Dashboard

The  My Sessions tab will only show contents during an ongoing call.  Widgets in the My Sessions view can be individually toggled on and off.

(tick) Note that Codes and Conversation Context widget features required such items to be configured and applied to the respective service.

Toggles to enable single UI elements

Interact Tab

(lightbulb) Interact allows customers to directly communicate with your service agents via website, without the need to install or run a chat client on their side.

Preconditions

TENANT ADMIN The tab becomes visible when Interact was enabled in Tenant administration. Once configured Interact allows customers to reach the service directly from external URLs (websites) via small chat or voice widgets.

The following options can be configured:

Element

 Description

Service Enabled
  • When enabled. Current Service is active as a contact for Interact calls.
  • When disabled the service is deactivated as a contact for Interact.

(lightbulb) Nimbus distributed service calls will still reach the service despite of this setting.

Restrict Access

Toggle that applies Interact Domain Templates (CORS) as "whitelists"

  • When enabled, web page access to this service is limited to domains specified in the CORS templates. 
  • When disabled. any web page may access the service.
Domain Template

Lists Interact Domain Templates (CORS) available under the same Organization Unit as the current service.

Service Snippet

Default script with settings of current Service, which is later can be inserted into a the web page and used as a contact widget.

(warning) Please note that the "Contact ID" and "WidgetKey" are unique to the current service and should not be mixed.

(lightbulb) Use the "Copy" button for easy Snippet Code retrieval.

Agents Tab

Contact Center

Preconditions

TENANT ADMIN The "Agents" tab becomes visible when the Service type is set to Contact Center (skill-based distribution) and has Agents / Owners assigned via Service Permissions.

User Skills and Levels need to be configured as assignable items first before they can be assigned to agents. Refer to our Use Case - Setting up a Contact Center for a full walkthrough.


TEAM OWNER You will see this tab when your service has Contact Center Features enabled and "Agents" assigned.

Any service owner can access the "Agents" tab to adjust the individual skill levels for each Agent assigned to the service. 

Please note:

  • Skills are required for Agents to be considered for call distribution by any skill-based service.
  • Skill changes on Agents are considered for all services that the Agent is assigned to. The skill change also is visible to all other users that have permissions to change this user (e.g. Admins or other Service Owners).
  • The active Distribution Profiles and Policies set in each service's Settings > Distribution tab will take effect immediately and consider users once you change their skill levels or assign new skills to their user account.

(lightbulb) An example:

  1. An Agent is part of 3 services A, B and C but his skill levels allow only distribution according to service A's Distribution Profiles and Policies.
  2. You decide to change that Agent to a higher language proficiency level. Service B requires that proficiency and will not consider the Agent as well.
  3. The Service owner of C will also add a completely new skill to this Agent. The next time you edit the Agent, you will see this new skill and can change it.