HelpDesk Module (Case Module)
The HelpDesk module is used to record and manage tickets, i.e., for
incident management. It is useful for companies that do not serve anonymous
clients and that wish to improve the level of support provided. The module is
also suitable in situations when the response to a client’s request is not
finished in a single call or e-mail message but requires more interactions from
various communication channels.
The module benefits include a quick ticket registration, delegation to the right
solvers and assurance of the required service level for accommodating a client’s
request. Statistical values are monitored throughout the solution time to
facilitate backward analyses, which are used for corporate process optimization.
In CSM’s terminology, a ticket is referred to as a ‘case’. A case can be
described as a virtual envelope that contains all communication pertaining to
the given problem. The communication includes e-mails, SMS etc. received from or
sent to the client. A case also registers all internal business processes and
notes or comments. Moreover, partial tasks can be created within a case, which
can then be delegated to authorized solvers. Metadata (time, solver, …) is
recorded for every event that the case includes.
A case passes through several mandatory or optional phases, which start with
‘new/open’ and end with ‘closed’. These two states are mandatory for the correct
distribution and registration. Between the state of new (newly open) and
finished (closed), a case may have any user-defined status. The processing
procedure is firmly defined for each of the request categories, and a group of
users with the necessary know-how for processing the request is designated for
each of the statuses. The status can be changed only once all mandatory tasks
have been completed. Any number of dynamic forms can be associated with a case,
which ensure a quick and procedurally correct registration and management of the
client requests.
Opening a case
Cases are typically opened by operators based on input stimuli, such as client
requests from the voice or e-mail channel. Generally, a request can be received
and a ticket established from any communication channel that CSM handles
(telephone call, e-mail, SMS, social networks, webchat, contact form, …). An
operator, or any CSM user with a relevant right or license, may open
cases (tickets) manually or they can be opened automatically by the system. The
inputs can be identical as in the manual mode; however, in addition, CSM
can be integrated with external ticketing systems.
An image of the CSM environment
Statuses
A ticket always has a specific status. Apart from the ‘Open’/’Closed’ statuses,
which are required for proper system operation, there are also optional statuses
that can be defined by users. There is no limit to the number of user-defined
statuses; thus, you can often see statuses such as ‘Submitted to BackOffice’,
‘On hold’, ‘Waiting for client’s response’ etc. The below workflow can be used
to define an order of statuses , thus ensuring that a request gets properly
procedurally processed.
Categorization / Priority
Every request is assigned a category or topic to which it relates. Requests can
be categorized manually or automatically based on the available metadata and
determines the method of further processing including the input priority.
Ticket Queues
Based on the assigned categories, cases are queued for processing. Solvers can
manually take them from the queues or the cases are assigned automatically based
on user rules.
Workflow
A specific Workflow can be defined for every group of tickets, which represents a
set of rules indicating how and by whom the ticket will be processed. The solver
is selected based on a system of authorizations and parameters that ensures that
requests are processed by solvers with sufficient know-how.
Information Availability Across the Company
Throughout the ticket’s existence, all information is available to selected
CSM users. This feature is key primarily for front-end businesses whose
staff, such as contact center operators, can use the accurate information to
give precise answers to all of their clients’ questions, including details on
their request status, who owns the request and when the result will be
available. Since the system records every step, ticket editing or handover to a
different solver, sophisticated analyses can be performed over the resulting set
of data to improve the effectiveness of communication with clients and
professional approach by operators as well as to optimize processes within the
company.
Service Level/Escalation
The required service level (SL) can be set in the system for every topic-related
group of tickets. The system then ‘monitors’ the time from request reception to
its closure or the maximum time limits by which the ticket needs to pass through
each of the phases or statuses. If the defined limits or their percentage
portions are exceeded, operators can be made aware of the situation visually by
the ticket’s color changing or the ticket can be subject to one of the
escalation rules.
An image of the supervisor’s environment
Notification
When the ticket status changes or when a certain time interval has been exceeded,
a notification can be sent. This message can be sent by means of any of the
natively served communication channels, typically by SMS or e-mail. The
notification can be internal, e.g., it displays in the supervisor’s application,
on the notice board or wall board, or the system can respond to it
automatically, e.g., by creating a task. Integration with external systems is
also frequently used.
Statistics
All the values recorded, whether entered in the system by users or acquired
automatically, can be statistically analyzed and displayed in well-structured
graphical reports.
An image of the reports, perhaps PowerBI
Archiving
All system events are archived, and the archiving policy can be defined. This
means primarily setting the duration of archiving in respect of the topic
processed, ticket result, and also defining access rights to historical
information. Any cases that have been archived or closed can be reactivated at
any time.
FAQ on HelpDesk
Parameters of in-bound, project-related and distribution rules |
CSM solution |
Is communication with another client also recorded for a given
case if it pertains to the same issue? For example, when the
client’s wife communicates on behalf of the client? |
|
Yes, communication with multiple clients or persons can
be recorded under once case. Pairing can be done automatically based
on the clear content or manually by the operator or any CSM
user who has the relevant license and rights. |
Is it possible to set a higher priority to cases established
with selected clients? |
|
Yes, every case has the priority attribute. This
attribute is set by algorithms that incorporate client information
but also the request topic, time spent in the queue, time to end of
work hours etc. |
Which options does the client have to find out the current
status of their case? |
|
Throughout the time while the case is being solved, the
client can be kept informed by notification messages (when the
status changes or when defined time limits are reached). Moreover,
the solution can be complemented with a website where the requested
information is available once the client logs in. |
Can I assign cases based on the operators’ knowledge level?
|
|
Yes, the system ensures that cases are processed only by
those agents who have sufficient know-how on the given topic. The
knowledge of operators or users is defined in a knowledge matrix.
This ensures that cases of a given category are always handled by
the best available operators. |
Can I assign requests from a particular client primarily to a
specific operator? |
|
Yes, the system has the functionality of a preferred
operator. |
Can I as client be informed if my request gets to a different
solution phase? |
|
Yes, for this purpose the system has a workflow
functionality that allows notification messages to be sent. Any of
the integrated communication channels can be used for notifications.
The channels most frequently used include e-mail, SMS and Instant
Messaging on social networks. Notification is also possible through
the voice channel using an autodialer. |
Apart from being able to see the history of communication, can
the operator for a particular case also listen to the available
recordings? |
|
Yes, yet only if CSM is used to serve the voice
channel also or if it is integrated with a third-party recording
solution. Recordings can be accessed only with relevant access
rights; thus, it is possible to ensure that an operator can only
listen to their own recordings or to the recordings of the
same team or to recordings pertaining to a particular case phase or
status. |
Is the information provided to the operator limited only to the
given case or is it possible to view a complete history of
communication with the client to find its historical
context? |
|
The set of information that is displayed to operators is
be defined by users. The standard information displayed includes all
the communication pertaining to the given case, such as the history
of communication with the client over the past X months. The system
primarily automatically displays the information when there is an
incoming interaction (call, e-mail, SMS), which makes the work much
easier and faster for the operator. Every user, provided that their
rights allow them to do so, can of course find the client’s
communication history to any selected level. |
Can multiple cases be created from a single interaction, e.g.,
from one telephone call or e-mail? |
|
Yes, this is a common situation when one client wants to
resolve multiple issues or questions in a single e-mail or telephone
call. |
Is it possible to merge duplicate requests in CSM?
|
|
Yes. Moreover, the client’s history is displayed when
the operator accepts a case. This way it is easy to determine
whether the request is already being solved or not. |
Extended functionality, Standard functionality