Processing of request on the Helpdesk

Getting started

The article contains essential information and procedures regarding requests and tasks raised by the Helpdesk team.

Table of contents:

1. General information
2. Request types (Helpdesk vs DEV)
3. Helpdesk working hours
4. Helpdesk reaction time
5. Request categorisation
6. Definition of PRIO1
   1. What is the key process?
7. Definition of PRIO2
8. Raising requests - best practices
9. View of a sample answer sent by us from Easy Redmine system

General information

Helpdesk request Workflow

• EasyRedmine is a bug tracking system that we use to handle customers' requests.
• To send any kind of request, just send an email to helpdesk@tauceti.email.
• After a while, the system registers the ticket and we confirm its acceptance.
• Our answers are sent directly from the Bugtracker level and then they reach the sender by the e-mail message.
• The e-mail sent to helpdesk@tauceti.email may contain everything that the standard mail message contains.
• If you want to reply to a message received by us - simply reply to the email you have received.

Request types (Helpdesk vs DEV)

In general, requests are divided into two types:

Helpdesk requests

• All requests described later in this article

Dev requests

• DEV requests are non-standard requests that require the involvement of the development team in order to execute a given request (e.g. a request that cannot be executed by the HD team using the administration panel).
• All DEV-type requests should be processed on Asana.

Helpdesk working hours

Helpdesk provides technical support to the client and is available in the following periods:

1) excluding Polish public holidays
2) only Blocking Anomalies can be reported in Emergency Operator Support time.

3) excluding Polish public holidays
4) only Blocking Anomalies can be reported in Emergency Operator Support time.

Emergency Operator should be contacted by e-mail: helpdesk@ tauceti.email or by phone +48660599425 (Robert Wrębiak), +48660599416 (Maciej Bochyński).

 Helpdesk reaction time

Helpdesk reaction time

Emergency operator reaction time

Definitions

Response Time – specifies the maximum time period before the Helpdesk (or Emergency Operator) confirms receipt of the issue notification and assigns priority to this issue.

Report Delivery Time – specifies the maximum time period between Response Time and the moment of delivery of the progress report on the issue to the CUSTOMER. The progress report will include: the status of the issue, verified priority level, estimated time of the solution or proposal for temporary solution if available.

 Request categorisation

Requests in the context of importance are categorised into:

• PRIO1
• PRIO2
• PRIO3
• Non-issue

PRIO1 - this corresponds to SLA category 1 requests, i.e. failure of critical services.

PRIO2 - this corresponds to SLA category 2 requests, i.e. partial failure of critical services or non-critical services.

PRIO3 - all incidents/problems that are not PRIO1/2.

Non-issue - request of nature (examples):

• request for support in explaining how the mechanism works - "how to"
• An idea or a suggestion

  RememberIt is possible to automatically mark a sent e-mail request as PRIO1, PRIO2 or PRIO3. To do that you have to type the priority level in the e-mail title for example:

PRIO1 Slovakian website is not working
PRIO2 Unable to search for products on PL PROD
PRIO3 Product is not visible on CZ PROD

By doing that it will allow us to react to the issue more swiftly. Please remember that it is case-sensitive, so our system won't recognize "Prio1", or "PRIO 1". It has to be "PRIO1".

 Definition of PRIO1

The PRIO1 request is a serious problem with the highest priority. There is a separate handling procedure for this request. Types of problems that can represent the definition of “PRIO1":

• Entire unavailability of the website, where the website means a full set of pages available under a given domain (desktop/mobile), for all users
• The time of loading pages of the website excludes the use of the website, for all users
• The key process does not work for all users
• The integrity of key data has not been preserved
• The security of key data has not been preserved
• The security of personal data has not been preserved
• Unauthorized access to the system
• Unauthorized change of data

What is the key process?

Key process - division:

1. From the customer side:

• User registration
• User login
• Order execution
• Functionalities in the basket enable the execution and finalization of the order

2. From the business user's side:

• Logging in to the administration panel
• Failure of the administration panel element to act directly and immediately affect key processes for the consumer (for example support of the on/off-site functionality) 

3. From the system side:

• The exchange of order data between the web platform and the logistics system ("YRMA Logistics") does not work in a way that affects the key processes for customers
• The exchange of payment data does not work in a way that affects and is visible to customers
• The failure of integrations that directly affect the operation of key processes for customers

 Definition of PRIO2

PRIO2 requests are partial failures of PRIO1 type critical services, however:

• Their occurrence is not massive or continuous
• Critical processes are not interrupted

Examples of problems that can be classified as "PRIO2":

• The order confirmation email is not sent to the customer, but the order itself can be placed correctly by customers
  
• Partial unavailability of the website
• Product search engine on the website does not work properly
• Password reminder functionality does not work

 Raising requests - best practices

1. Giving the appropriate title to the request. The title of the e-mail will be identical to the title of the registered request in our bug tracking system. The appropriate title will significantly improve the detection of the source of the problem.
2. One email sent to helpdesk@tauceti.email causes one separate ticket to be registered in our system. Therefore, the commonly used, best and strongly recommended by us practice is to describe one problem in one email.
   1. Applying threaded answers to our feedback to avoid generating new tickets which would be duplicated.
3.  Giving as many details as possible about the request. This will make it much easier for us to detect the problem and solve it more efficiently.
   1. Giving exact reproduction steps.
   2. Adding bug illustrating attachments (screenshot, video).
   3. Providing information when a problem occurred.
   4. Determining where the problem occurs - only on the desktop version, only on the mobile version or on both.
   5. Determining whether the problem was one-off or repeatable.
   6. It is often useful to provide information about the device on which the problem occurred.
      1. device model
      2. operating system version
      3. information about the browser (and the version you are currently working on)
4.  Information on whether the problem occurs in a mass/global scale or only for one user.
5. Specifying the environment in which the problem occurs.
6. In case of a PRIO request by typing in the e-mail title PRIO1, PRIO2 or PRIO3 you will change the priority of a task in our system automatically to the written PRIO level. This will allow us to handle your request swiftly.

 View of a sample answer sent by us from Easy Redmine system 

Visualization of an example helpdesk response message