<< Click to Display Table of Contents >> Navigation:  Accelerators > Help Desk

Overview

The following example is a version of a Help Desk system that allows you to efficiently manage employees’ incidents and requests in a single process, providing effective solutions in the lowest time. Bizagi Help Desk allows to improve employee productivity and to handle their activities with a continuous improvement concept: delivering control of case records in the knowledge base and requesting actions improvement. This way, every case becomes positive feedback that will reduce case opening and standardize the attention of frequent incidents.

 

Scope: the process starts when a call center agent opens a case with the information given by a customer. It will be assisted by the Help Desk Agent.

 

The Help Desk Agent must verify the case information and check whether further information is needed, if the case must be escalated or if he/she can resolve it. Once all the required information is complete and the case is addressed by the person who is able to resolve it, the solution is sent. Then, the case is recorded in the KB, if required, and finally is closed by the Help Desk Agent.  

 

The Help Desk process depicts an example of the use of Bizagi 11 features and options to take advantage of the Experience Design concept, to best address unstructured processes.

Unstructured processes are those which you may catalog as highly unpredictable or dynamic, mainly because these processes may involve at some point a very large number of possible alternatives in the workflow.

It represents how the Stakeholders (knowledge workers) are able to make decisions to define the flow of a case, that cannot be predicted beforehand.

The scope of the Emergency room case is the attendance of a patient.

 

Through Experience Design you will be able to make the most of: Empowering knowledge workers, presenting a personalized user experience, and using contextualized BPM capabilities, among others.

 

Bizagi Modeler Process Description (Bpm)

The complete documentation of this process can be found within its Bizagi Modeler file (.bpm). From there, you can generate a Word document with all its information.

 

Identify the general process and milestones

Identify the general process, or happy path, providing a high level business description of what will be automated. Identify the most common outcomes (in this first stage do not include exceptions) and the stages of the case, or milestones.

The milestones of the Bizagi Help Desk are:

•Ticket registration

•Ticket resolution

•Ticket Closure

 

Stakeholders

Bizagi 11 presents a Work portal which allows knowledge workers to make informed decisions, such as when to start a process or update data, boosting agility and productivity.

 

Various stakeholders can be associated with the case. However, each stakeholder may directly or indirectly influence the case. Not all stakeholders listed have to be involved with every instance of the case.

 

Identifying Stakeholders is important to be able to personalize their experience.

•Call Center Agent

•Help Desk Agent

 

Experience design

In Bizagi Studio each Stakeholder has their experience designed in the Experience Designer menu. Each tab (Actions, My Stuff, Search) has a definition according to each user’s available options.

 

Keep in mind that to enable a group to be available in My Stuff section, the Stakeholder must have a Direct or indirect collection to an entity.

 

Thus, the Help Desk Agent for instance, has a collection to Tickets. That way, each Help Desk will be assigned to one or more ticket, and will be able to view them in the Work portal, and manage them if there are actions available to manage them.

 

 

Manage Stakeholders

As you download this template, make sure you have created at least one user per Stakeholder and have configured them in the Admin option of the Work Portal. If you don`t have one user per Stakeholder, this template will not work.

 

Go to the Admin option and for each Stakeholder create a new record, by creating a new user and filling in all additional required information.

 

 

Keep in mind that to manage Stakeholders in the Work Portal we have already defined the management forms for them. These forms will display what information to be shown and requested when configuring a user as a Stakeholder.

 

In Studio we defined a Display form that depicts the columns of the Stakeholder’s main view.

And an Add and Edit form, that relate how a Stakeholder record is added and edited.

 

 

 

Identify Activities, what Stakeholders can do

This involves the activities the stakeholders can initiate and other case related operations they can perform, categorizing their allowed interactions with the Work that will be enabled for them.

 

Defining if Activities are mandatory under certain circumstances or are available but executed at the Stakeholder’s discretion will help categorize an activity as an Action available as part of an unstructured process.

 

Many activities in a case are not always available for execution. Only when certain milestones are reached in the case or specific conditions are met, will the activity be applicable. Activities can be withdrawn: when they are no longer relevant, they should not be presented to stakeholders.

 

 

Identify Actions, Activities, Contexts and Data

 

Call Center Agent

 

 

Help Desk Agent

 

 

Processes Description

After reviewing the actions available, we can create the structure of a core process and processes that will be launched via Actions to support the case structure.

 

The process starts with a customer making a call, the call is received by the Call Center Agent. The agent searches the information of the user and registers the information given by the customer. Once the case is opened, Bizagi allocates the case to the Help Desk Agent.

 

The assigned Help Desk Agent analyzes the case and determines if the information given by the customer is enough to resolve the case; when the information is enough, the agent proceeds to close or resolve the case, registers an activity related to the case or escalates it to a higher Services Level. Otherwise, the agent requests more information to the customer, the case will wait for the information until the expiration of the time defined by the SLA of the case.

 

When the case is resolved, the agent who resolved the case reviews the closure information and determines if the case should be registered in the Knowledge Base. Once the Agent completes this activity, the case in Bizagi will be closed.

 

Customer Information process is a process in which the Call Center Agent can change the Customer Information when the customer requires to updated his/her information.

 

Main process: Help Desk

Support process: Customer Information

Actions processes (supporting processes for unstructured management):

Main facts in the Process Construction

 

Data Model

 

 

The process entity of the Help Desk process is “Ticket” which has all the attributes and relationships necessary to save main case information.

 

There are two Stakeholders created, that have their Experience designed to give a unique Work portal for each one:

•Call Center Agent

•Help Desk Agent

 

Templates

When browsing over data, either regarding results of data searches or lists of information which are part of My stuff, you may customize the information displayed for these resulting records.

 

By default, Bizagi uses a basic template that chooses random attributes of the entity to which a record belongs to.

 

We have defined a data template for the Ticket entity.

 

 

Conditional events

Conditional events are used in processes to enable of disable process paths according to a data condition in the process. In this template, we use the events Wait for additional information and Case closed.

 

When the Help Desk Agent requests more information, the status of the ticket changes to On Hold and the Timer event that waits for the additional information waits until the customer send such information (when the Ticket.Continuewiththecase attribute is true) and it is in that point where the Agent can perform the Analyze and resolve activity again.

 

The condition to enable or disable the conditional event is set in the fourth step of the process wizard, Define Expressions, as show below.

 

 

To set the Ticket.Continuewiththecase attribute to true or false and thus enable or disable the event, we use an action on Exit the event Register Information sent within the Process Request More Information.

 

 

When the Call center agent receives the information sent by the customer, and expression registers this activity in the log and changes the value for Ticket.Continuewiththecase to true using the Set Status rule:

 

 

When the process has been completed, the Ticket.Continuewiththecase attribute will be true and the Analyze and resolve activity is enabled again and allocated to the Help Desk Agent.

 

The other conditional event is activated when case is closed or resolved, that is to say, when the Ticket.TicketStatus is Resolved or Closed.

 

The condition to enable or disable the conditional event is set in the fourth step of the process wizard, Define Expressions, as show below.

 

 

Setting the Ticket.TicketStatus attribute to Resolved or Closed and thus enable the event depends on the way of how the ticket changes its status. A ticket may become Resolved only when the Help Desk Agent registers an Activity of type Solution (Code = 5) in the Activity Analyze and resolve. Moreover, a ticket may become close when the Help Desk Agent registers an Activity of type Close (Code = 9) in the Activity Analyze and resolve, when a Call Center Agent cancel the ticket using the action Cancel Ticket from the search of cases, or when the SLA time has expired and the case is waiting for more information.

 

For the case when the Call Center Agent requires to cancel the case, he/she searches the case and launch the form action Cancel Ticket, in this action the status of the case is changed to Closed in the expression which sets the default value for the Cancellation date:

 

 

When the case is closed because the case did not receive the information requested, we use an action on Exit the timer event the Process Request More Information.

 

 

An expression registers this activity in the log and changes the value for Ticket.TicketStatus to Closed using the Set Status rule:

 

 

Last Updated 8/24/2022 5:17:36 PM