Use Case - Creating a Call Workflow

Creating your Workflow

As a Nimbus newcomer you might be interested in knowing that workflows - like all other data entities in Nimbus are assigned to one Organization Unit (OU). Think of this as a position in a file tree at which the workflow will be visible to you or other users. 

1. For simplicity's sake let's assume that you are just part of the "Documentation Team" OU with the same name as your underlying service team.
2. Via "Add Workflow" we'll start a new workflow.  We base it on a "Blank" template to start from scratch.
   

The Workflow Editor

As we're now in Workflow Editing mode it's time to explain a few concepts: 

1. Note that the Organization Unit of your Workflow is now fixed and can only be re-assigned by a tenant administrator. 
   This will ensure that no one else manipulates your workflow if not part of your team and OU.
   Vice-versa this also means that all team owners within "Documentation Team" can see and edit this workflow once you save it.
   
2. Pick a workflow name that is easy to identify in a large list of workflows. The name can be changed later at any time.
   
   
3. The next area that might catch your attention is the huge editing area with a "Start" line. We'll get to that in the next step!
   
   
   
4. The third area is the list of available workflow elements or "Activities" as we call them. 
    The list and available options inside a workflow activity may vary depending on your enabled Nimbus Features.
   

Adding Activities to your Workflow

Now it's time to structure your first workflow. Each typical service call must contain the "Accept Call" activity, so Nimbus knows when to a session for recording and handling purposes. 

1. Let's add and connect a "Accept Conversation" activity first so we don't forget about it.
   1. Drag and Drop the item from the list onto the editing area

   2. Connect the "Start" to your activity via drag and drop.
      
      

      

      Note that the "Accept Conversation" and "Disconnect Conversation" activities are mandatory for each of your workflow in order for Nimbus to properly track the call for Reporting and Dashboard metrics.

      "Accept Conversation" doesn't necessarily need to be at the start of your workflow.

      
      
      

2. With just accept and disconnect activities your service wouldn't really work - so let's add a basic "announcement" and "queue activity" to your workflow. 
   1. Drag and drop an "Announcement" onto the workflow area, followed by an "Queue" activity
      You can add activities as you like first and connect them later.
      
   2. Afterwards connect their exit nodes by drag and drop and arrange them to make visually sense to you.
      Activities can have multiple exit nodes, so you should arrange them on the workflow area first and think of the handling before starting to connect.
      You can rearrange activities later with drag an drop as needed, the node connections will remain until you delete either them or the activity in between.
      
      
      
3. Remember the "Disconnect Conversation" activity requirement from earlier? Let's close up with that activity before we forget about it
   
   
   

4. Don't forget to "Save" your work until now.

Congratulations - At this point you have your first functioning workflow.

Applying the Workflow

By default, any new data entity in Nimbus (such as a workflow) doesn't do anything by itself until it is assigned to a service. Since your new workflow is ready to go you can apply it to take effect.

1. Head to "My Services" > Service Settings > Workflow tab
2. Assign your new Workflow as the "Active Workflow" and Save.
    Note that Workflow changes (both in the workflow itself and in the service settings take effect immediately. 
   Be careful not to touch productive workflows or services during operation hours. It's always advisable to test
   

Test Call

You can try a test call to your service to test the new workflow. head to your Service > Service Settings > General > "Make a Test Call".

Workflow customization and properties

While testing your first workflow you may realize that certain default settings are not behaving like you want? No problem! Head back to your workflow editor and make adjustments:

1. After First we notice that our announcement didn't really play anything back. That is because we didn't select what to actually announce. 
   1. Open the "Announcement" Activity properties via its header arrow
   2. Select "Text to Speech" and a Language engine of your choice.
   3. Paste a text of your choice
   4. Press "Play" and test the text-to-speed engine.
      The playback will be the same as the customer will hear it.
      You may also define Resources (single audio files) as announcement.
      Note that pasted text is not language-sensitive or region-specific. Nimbus just plays back the resource "as is". You need to manually direct the user to the correct language, e.g. via "User Input" activity leading to specific or different services each with their own "Announcement" and workflow. For simplicity's sake we leave this with a simple English announcement for now.
      
      
      

2. Your "Queue" activity properties can be unfolded the same way. There are quite a few options, so let's just focus on the "Distribution Type" for now.
   
   

   Distribution Type	Description	When to Pick
   Broadcast	Rings users simultaneously, selected in a batch size of 10 longest-idle users. The first user to pick up the call via Microsoft Teams will handle the task. Does not apply RONA status as it would otherwise flag the entire user batch size.	Achieves a higher visibility, but the ringing call sets 10 selected agents as "Not Available", not allowing further calls to be distributed to them in the meantime. Makes little sense in high-speed scenarios when the agents are dedicated only to the client to accept calls within a few seconds. Situationally for very large teams where high-volume call handling is more important than equal work distribution.
   Direct	Will distribute tasks directly to team members, prioritizing the longest idle (active) team member. RONA time is adjustable. No further actions are necessary aside from accepting the call via Microsoft Teams.	The call with the selected team member is first established via a Teams peer-to-peer call, before it gets escalated to the regular Nimbus conference session. Useful if you have "Busy on Busy" features enabled for your users. Otherwise slower than "Direct Conference" and generally not recommended.
   Direct Conference	Same distribution as "Direct", but in this mode, the selected team member is directly invited to the Nimbus conference session, allowing them to join much faster and be able to talk to the original caller sooner.	Our General recommendation for most services. Ensures faster handling of calls without blocking too many users at once for the same ringing call. Conference invitations get cancelled if a task was aborted (e.g. Hangup by User, Queue left, Max Wait Timeout Reached ). → See Nimbus Reporting Model.
   Pickup	Will show extra "Pickup" controls in the Tasks list of the called team. A call session will be directly established without further intervention, and no further call reporting is possible after this point. If the Nimbus user is unavailable or the session is otherwise ended the call will be lost.	In small teams (e.g. volunteers) where it's acceptable to lose a call and reporting data isn't as important. Pickup by itself does not allow call transfers as Nimbus has no further control over the session.→ If you want to use Pickup with transfer, use "Pickup with Adjustable RONA" or "Pickup Conference" instead. KNOWN ISSUE When any "Pickup" type is selected, skill-based Contact Center Service types may still show the call in a queue, however without a pickup button. → We recommend not using any "Pickup" distribution type in a skill-based distribution scenario.
   Pickup with Adjustable RONA	Same as Pickup, but with adjustable RONA. A call session that is not accepted (after "Pickup" is clicked) within the given RONA time can be re-inserted into the task queue or handled otherwise.
   Pickup Conference	Same as "Pickup with Adjustable RONA", but will directly invite the agent to the Nimbus conference session, allowing them to join much faster and be able to talk to the original caller sooner.	Best performance of all "Pickup" types. Unanswered calls can be re-inserted into the queue and no reporting data is lost. Suitable for scenarios in which the agents can keep an eye on the app. Or to "park" calls in a queue so that other calls can be answered first and then the parked call can be retrieved from the waiting queue. Conference invitations get cancelled if a task was aborted (e.g. Hangup by User, Queue left, Max Wait Timeout Reached ). → See Nimbus Reporting Model.

   
   Above is just an excerpt. Refer to the Workflow Activities for a full reference on the "Queue" activity properties.
   Note that the parameters change on the selected "Distribution Type". Some types might also be limited by your enabled Nimbus Features.
   
   Don't forget to test these distribution types with a few other users in your team to see their effect.

Adjust Service Distribution Settings

The "Queue" activity interacts with your Service Settings > Distribution in such a way that users may still be available for distribution even when busy.

A simple example for Queue and Presence interaction: 

• Let's assume both Service A and B use the same workflow
• However Service A Service Settings are set to allow its "busy" users to receive conversations to be distributed via Nimbus, while Service B doesn't. 
• If a "busy" user is part of both services A and B, the "Queue" activity will only consider that user for A Service Queue distribution.

Add dynamic Opening Hours to your service

Assuming that your service is not open 24/7 it make sense to restrict the outwards facing Opening Hours. Outside of these hours, your Nimbus service is shown as offline and calls will not be distributed.

Preconditions:

At this point you've already learned the Organization Units concept - and as you might have guessed it - those apply to Opening Hours as well. In this context this means that Opening Hours can either be shared across services (e.g. defined by an Administrator) or kept individual. 

Please read the Opening Hours chapter carefully be fore continuing below. We assume that you have defined your own Opening Hours calendar by now so we can focus on the workflow and related settings.

Now let's define hours in your service workflow and settings: 

1. Make sure that you have at least one defined "Opening Hours" Entry defined and available for your Organization.
   In our example we will call this "Documentation Team Hours", but you can name it as you like. The name is not tied to a particular service or OU.
2. Open your existing workflow in the editor.
3. Drag and Drop the "Check Opening Hours" Activity into your workflow.
4. Remove the connector after your "Accept conversation" activity.
5. Re-connect nodes between the "Accept Conversation" activity and your new "Check Opening Hours" activity
   You'll notice that the "Check Opening Hours" activity has a lot of node exits. This means that it is a "dynamic" activity that reacts to conditions - e.g. in this case the time of day on which the service is called.
6. Define the exit connectors of your "Check Opening Hours" activity.
   You can keep it minimal by ensuring that your selected workflow has at least the "Open" and the "Default" node connected.
   The default state of your calendar is defined in the Opening Hours (when you created the calendar entry). In this example we are "default" closed so opening hours are only periods we define manually.
   
   A minimal workflow could look as follows: 
   
7. Add further handling as needed. In the example above we added a 2nd announcement that informs the calling customer of the service opening hours. Of course you can define anything you like.
8. Don't forget to Save and Close your workflow.

Applying your Opening Hours

Once you are satisfied you can apply the opening hours in your Service Settings > General Tab.
You will see the state of your service reflected immediately. 
Optionally you can apply Secondary Opening hours in your settings. If no primary periods are defined, the secondary calendar periods apply, otherwise the default applies. To test a simple case you can just go with defining the "Primary" hours for now.
More information on this can be found on the Service Settings > General > "Opening Hours".