Best Practices - Omni Channel Contact Center

Best practices for building an omni-channel Contact Center in Nimbus.

This Use Case is meant to give you a step-by-step walkthrough through best practices of a multi-modal contact center. You can visit this page to learn more about the modalities supported by Nimbus.


INC Icon Legend Accordion

Show Icon Legend

💡 = A hint to signal learnings, improvements or useful information in context. 🔍 = Info points out essential notes or related page in context.
☝ = Notifies you about fallacies and tricky parts that help avoid problems. 🤔 = Asks and answers common questions and troubleshooting points.
❌ = Warns you of actions with irreversible / data-destructive consequence. ✅ = Intructs you to perform a certain (prerequired) action to complete a related step.

Best Practice 1: A Structured Approach

Start structured

Start by defining the structure of your organization and the respective services, users, and their skillset. Think about the following questions:

  • What do I want to use the services for?
  • Who will be part of which service?
  • What are the opening hours of a service?
  • Do my users serve different modalities?
  • Will I be using the services for outbound calls?  

✅ As you answer these questions and read the contents of this page, we recommend opening the admin-side configuration so you can follow alongside in the Nimbus UI.


Think about a good structure for your Organization Units (OUs)

Most companies organize their organization units in Nimbus according to their Microsoft Entra organization structure. OUs give permissions from down to top, which means the lower level sees all above, but the upper level doesn't see any objects that have been created underneath. Think about how many teams are involved and who are the supervisors.

🔍 In Nimbus, Organization Units determine the “visibility” of all Configuration items, Users and Services. Each of these entities must have one position in the Organization Unit hierarchy tree, allowing you to share (or hide) them from each other.


Best Practice 2: Configuration Preparation

Set up workflow templates for your modalities

As a Nimbus user with admin rights, you can create Workflow Templates. These templates can be locked against change in varying degrees, depending on how much flexibility you want to give to your service team owners and supervisors.

Keep in mind that templates also bear some operative risk, as you can overwrite properties meant to be individual. We recommend designing your “common ground” templates together with other team owners and also agree on naming conventions to indicate purpose and intent.

🔍 In Nimbus, Workflow Templates will unify your task handling structure and can be designed for every modality individually. Each service can apply the workflows in their Modality Service Settings. Note that you need to make the templates available for the corresponding Organization Unit (levels).


Making use of skills, responsibility profiles, and distribution policies

For the optimal distribution of tasks, assign your users Skills and Responsibility Profiles, and define distribution policies for your settings. By doing so you can handle customer issues more quickly, by picking the most-skilled (or responsible) person and avoiding unnecessary internal transfers.

Example: Categorizing skills and responsibilities for later use in user-side responsibility profiles

🔎Refer to Use Case - Setting Up a Contact Center for step-by-step instructions.


Best Practice 3: Service Concepts

Single-modality vs. multi-modality services

Either you want to have single-modality services (e.g. a service that distributes only calls) or services which use multiple modalities (e.g. call and Instant Messaging), there are pros and cons to consider. The table below gives you an overview.




Single-modality services
  • Clear performance metrics - Monitoring and evaluating agent performance and contact center efficiency are more straightforward with a single communication channel, as there's less complexity in tracking metrics and analyzing reporting data.
  • Individual settings and configuration - Opening Hours, Playlists, ACW, RONA, etc.  can be defined for each modality individually.
  • Better customer experience - service agents can focus on the service channel they are opted in to and provide a better customer experience.
  • Limited reach - Customers who prefer a different communication channel may experience frustration, resulting in decreased customer satisfaction and a potentially losses.
  • Increased wait times - During peak times, if there's only one channel of communication available, customers may experience longer wait times as the queue for that channel builds up, resulting in decreased customer satisfaction.
  • Inflexibility - Single-modality services may struggle to adapt to changing customer preferences.
  • Requires routing via IVR or manually.
  • Higher license costs due to potentially more services.
Multi-modality services
  • One point of configuration - with Modality Service Settings being in once place, it's easier to switch between workflows and keep the distribution experience consistent. 
  • Enhanced customer experience - Multi-modality services address different customer preferences, leading to improved overall customer experience and satisfaction.
  • Reachability - If one channel experiences technical difficulties or high traffic, customers can use alternative channels, ensuring the continuity of the service.
  • Lower license costs due to potentially fewer services.
  • Complexity - As each service can handle only a few select modalities with individual Distribution Service Settings, the added flexibility can also lead to hard-to-compare KPI differences.
  • Quality of Service - Maintaining consistently high service quality across all communication channels can be challenging to your users.
  • Shared settings and configuration - The same Opening Hours, Playlists, ACW, RONA, etc. apply to all service modalities.
  • No individual Distribution Policies possible per modality.
  • Reporting will combine all modality tasks in one view, making it necessary to use the Nimbus Power BI Template to get a clearer picture on trends.

Best Practice: One Modality per Service

It is best practice to start with one service per modality instead of mixing modalities together within a single service. Start with an inbound calling service and set it up completely. Then gradually add more Features and modalities as needed. This also keeps Configuration complexity initially lower, as you test with individual Service Settings and perhaps include Power Automate Use Cases for integration.

💡 The advantages of having only one modality per service in more detail:

  • The service KPIs are defined at service level - You cannot define different KPIs for different modalities, unless you spread the modalities over different services.
  • The distribution profiles are assigned at service level - The skillset which is enabled for the service applies to all modalities within that service. You can still en- oder disable modalities on each user, but all your users are pooled together for distribution. 
    If you split modalities into distinct services, users can use responsibility profiles to adjust their active skillset and thus shift priorities towards different modalities.  For example, a duty profile called “No Calls - Only Text” could enable the skills needed in an Email and Instant Messaging service, while disabling the ones needed for inbound and outbound calling services.
  • The My Sessions page is highly configurable at service level - Administrators or supervisors can decide what information to show on this page. For different modalities you might want to show different fields. You can do this only if you split modalities into distinct services.
    For example, a service focused on handling only external tasks for all of your incoming tickets might want to show only specific information about the ticket and perhaps even embed the ticketing system's website directly into the My Sessions view.
  • Personal and Non-Personal Dashboards can be catered towards multiple services not just to distinguish modality, but also also per service, e.g. to keep the different KPI, visual thresholds and individual User Availability States apart.
  • All other distribution settings except of the workflow are defined at service level - This means they apply to all modalities and include:
  • The service management is less complex following the one modality per service approach. This also minimizes productive impacts from (unexpected) changes to KPIs, Workflows or other related Distribution Settings.

💡At a glance: At the service level, you can do the following individually:


Best Practice 4: Portal UI Adjustments

Organize custom Dashboards by purpose

You can create Non-Personal Dashboards in the admin portal and make them available to your users. It is recommended to organize them by topic or purpose, e.g.:

  • Supervisor dashboards focus with widgets about on User States and provide Dashboard Supervision features like listen-in, barge-in for existing calls.
  • Service dashboards provide service-centric and comparative KPIs among other useful statistics of services and users, usually targeted for a wider audience to see.

Learn more about this by reading on Dashboard Supervision and individual Dashboard Widgets which you can customize with various filters and thresholds via the Dashboard Widget Properties.


Add Nimbus Assistant for your users

We highly recommended you to enable Nimbus Assistant for Contact Center agents. Nimbus Assistant shows the task flow for each incoming task. This works independently of the modality type (call, IM, etc.).  Users can also log their absence with Not Available Reasons.

Assistant showing internal call flows and other rich-context to the user

🔍 Refer to Use Case - Setting Up Assistant for a walkthrough on the configuration. Make sure to visit the Assistant page to learn about the full scope of available features.


Best Practice 5: Leverage Power Automate

Use Power Automate for integrated Contact Center functionality

Once your services are up and running, you should be ready to integrate Nimbus with other tools in your organization. By using Power Automate, you can greatly extend the interaction range of Nimbus, e.g. by retrieving and storing customer data from external databases, storing them in Nimbus to show as Parameters.

🔍 Refer to our list of Power Automate Use Cases for inspiration.


Use a Global Power Automate Account for All Flows

We recommend to read about the Nimbus Power Automate Connector in full detail before starting with first integrations scenarios. As a best practice, a dedicated MS Flow account should ideally be a member of the Nimbus tenant administrators group in your Entra ID, which grants them access to all your Nimbus services and configuration items such as Address Book objects that you wish to maintain. This way, the account does not need to be setup for a team or service owner of specific services, avoiding additional configuration effort.

💡 Multiple users can utilize this account to make changes if needed, without being dependent on one specific individual who may be out of office at a crucial time.

Avoiding data conflicts and performance issues

Multiple users setting up individual Power Automate flows for the same Nimbus services and events can lead to conflicts when concurrently retrieving, processing, and returning data. This can become extremely hard to troubleshoot as the flows will not automatically become visible to everyone in your organization. 

→ It is therefore recommended to use a dedicated service or user account with a single Power Automate license to create and maintain all Nimbus-relevant Power Automate flows in one place.


Table of Contents