Incident Management is one of the most heavily used parts of the Beetil at the moment. Most users, I guess feel a sense of comfort in this area of the app especially if they’re migrating from ticket based systems. However, incidents are only a fraction of Beetil’s full potential and often mark the beginning of taking further action later down the track.
By definition an Incident is anything that is a disruption in the service that may affect the quality of the service (or something that has the potential to!). Keeping it simple – where something has gone wrong, or is about to go wrong.
An Incident can also be a Service Request, this can range from a request for information to a task you’re required to perform for a customer.
We use Incidents for just about anything and everything, if we spot something wrong with Beetil or if someone sends feedback, an Incident is raised.
One of the handy things about doing this is that it makes you think about the priority of the Incident, the priority is made up of the impact and urgency (clicking the Priority link will representing this visually in a Priority Matrix) giving you a better indication of how soon the incident needs to be resolved.
Incidents are relatively straight forward, there’s a symptom, which is simply what’s wrong, and possibly how to reproduce it.
There’s room for discussion so you can discuss the Incident as you work towards a resolution, which is how you can get the customer back on their feet, or indicate that this has been resolved.
When creating an incident we tend to assign it to someone if it needs to be fixed, or if it’s not urgent and there’s no specific person who should resolve it, we assign it to a group (groups can be created in admin). Where anyone can grab the incident and reassign it to themselves later down the line.
One of the most powerful features of using Incidents properly is are the Suggested Matches. If you use Incidents and log everything that happens within your service you’ll be able to easily identify similar incidents that have occurred in the past, and also note recurring themes, allowing you to identify any proactive action that you may need to take, i.e. creating problems, but that’s a topic for another day.
Incidents are often related to problems, changes, or even releases. We’ve found that incidents are normally always related and should be linked to one of these unless its a service request in which case it may not required. Quick one-off fixes are normally associated to releases, Incidents are also sometimes caused by changes which have gone live (i.e. changes that are out of the testing phase), or may even be part of a known problem with the service.
You can also grab a hold of reports on Incidents too, the link to reports can be found on the very top right beside the feedback and logout links. Currently we offer reports on:
Also do note we’re always welcome to suggestions for reports to offer in the future.