Reporting of incidents and problems

 

Background and limitations

This documents is only related to reporting of incidents and problems in the TEO platform (online and apps). Issues relating to development of new features is not included in this document.

 

Definition

We are using ITIL-framework definitions:

  • An incident is an unplanned disruption or degradation of service. Based on the definition provided, an incident is something that needs to be resolved immediately. This can either be through a permanent fix, a workaround or a temporary fix. Eg. Sending of sms failed.
  • problem is a cause of one or more incidents. An incident can raise a problem, specially if there is a high possibility that the incident might happen again.

 

Why do we need one way to report issues?

In order to resolve issues efficiently we need to monitor and have an overview over all issues. This means that all issues should to be reported in a structured way and in a place where we can:

  • Have a complete overview over all issues
  • Identify common/duplicated issues reported from different customers and employees.
  • Prioritize issues
  • Identify if incidents actually are problems

How to report incidents and problems

When an incidents or problems occur this shall be reported to ZenDesk. ZenDesk is TargetEveryone´s support system for customer questions.

 

To report an issue:

 

To ensure a swift handling of an incident or a problem please add as much information about the issue:

  • The account where the issue occurred: E-mail of the accounts admin user
  • Type:Choose the type of issue/request based on the definitions above.
  • Subject: Keep it brief and use correct terms. A best practice is to include the name of the feature where you found an issue. A good example would be `Contact management – Unable to import contacts from an excel sheet.
  • Description/ Summary: If you feel the name is not sufficient, briefly explain the bug with words. Write it in a natural language. Keep in mind that your description might be used to search in ZenDesk so be sure to use the correct language.
  • Environment: Depending on your browser, operating system, zoom level and screen size, websites may behave differently from one environment to another. Make sure your developers know your technical environment.
  • Source URL: Make it easy for your developers spot the problem by including the URL of the page where you found the bug. Big time saver!
  • Visual Proof: A picture is worth a thousand words. Although it might not be enough, a visual element like a screenshot or a video will help your developers understand the problem better and faster.
  • Steps to reproduce: A screenshot is a proof that you had a problem but keep in mind that your developer might not be able to reproduce the bug. Describe with as much detail as possible the steps you took before you encountered the bug.
  • Expected Results & Actual Results: Explain what results you expected and be as specific as possible. The app doesn’t work as expected is not useful. Also, describe what result you actually experienced.
  • Optional: You could also include extra information such as the severity (critical, major, minor, trivial, enhancement), the priority (high, medium, low), the name of the reporter, the person assigned or a due date.

 

Ticket handling

When a ticket is received support personnel will give it a preliminary priority and might reclassify the ticket to an incident or a problem. If you are not satisfied with the priority you can answer to the automatic request a-mail sent to you after submitting the ticket.

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

Comments

0 comments

Article is closed for comments.