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 FrontStage’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 FrontStage handles (telephone call, e-mail, SMS, social networks, webchat, contact form, …). An operator, or any FrontStage 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, FrontStage can be integrated with external ticketing systems.
An image of the FrontStage 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 FrontStage 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 |
FrontStage 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 FrontStage 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 FrontStage 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 FrontStage? |
|
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