Handling Major Incidents

I’ve been blogging previously about Incident Management, and no discussion about Incident Management would be complete without mentioning Major Incidents.

First of all, let me offer a definition: A Major Incident is any Incident that has a significant or substantial effect on part of all of the business.

Leaving aside the issue about VIPs (a stuck keyboard belonging to your Chief Executive causing panic on the help desk), we can say that Major Incidents usually affect significant numbers of employees, and involve important enterprise level services.

SerioReports - step forward SLA16!

This post will be on the topic of reports you can run in SerioReports – I am going to pick a few and talk about them in detail.

OK, so where is SerioReports? If you don’t have an icon for it on your desktop, remember that it’s an application and needs to be installed (though please remember that it is licensed, so you may need to purchases additional licenses before doing so). Please remember that SerioReports also has it’s own help file distributed with the product.

Making use of Agent Status

This post is an addendum to my earlier post on The Incident Life Cycle.

That post discusses a status value called the that is ‘signpost about where we are with an Incident’. This post will talk about where that is in Serio, and how help desks and service desks can use it.

Firstly this is referred to in Serio as Agent Status. There are two types of status value: A and B. These are functionally equivalent – rather than giving you a single status value to use, we gave you two, called Agent Status A and Agent Status B.

Introducing MIBs and the role they perform

This is a continuation of the post from a few days ago SNMP for Beginners.

At the end of the post I posed a question about interoperability. How do management applications know the data that network devices can provide, or what their capabilities are? This is where the MIB comes in. Think of a MIB as a definition of what the device can provide, or a menu of its capabilities. If you give the MIB to the management application, it can has knowledge of what the device can provide.

Using CTI with Serio

This is a follow-on post on the subject of CTI in Serio (whilst the earlier CTI posts look at CTI more generally).

Serio CTI depends upon the capabilities of your telephony system (the ‘switch’) completely. It relies on your switch for data about incoming calls – not just Caller Line Identity (CLI) but for information about when events (like incoming call or hang-up) are happening, and getting this information in good time (remember, caller waiting!). Serio CTI relies on your switch for making calls, and for data on the progress of those calls.

Using Reminders

This post is about a really useful feature of Serio – Reminders.

As you might expect, Reminders are there to remind you to do things. You might set them on an Incident to remind you to call a supplier about an Incident they are handling for you, or to remind you about a customer meeting. You can set as many Reminders as you want on any given Incident, Problem or Change (and cancel them independently also).

When Reminders become due, you can be notified in the following ways:

Integrating Serio with other Applications

Integrating Serio with other systems is almost always not a technology issue (though there are always challenges in this area to overcome). The real issue is the end-to-end process – how the two systems interact, who is responsible where, what status information we need and what management reporting is required. As always, the devil is in the detail and so any integration exercise needs to be handled with careful preparation and managerial planning.

Using Description Templates to Standardise Incident/Action Descriptions

Ever been assigned an Incident to resolve, only to find that you have to return to the customer to ask for details that should have been collected when the fault was logged?

Or have you ever looked through the history of an Incident and been baffled by monosyllabic comments describing what was done and how it was resolved.

Low quality descriptions are a bugbear of Helpdesks/Service Desks, wasting time and preventing lessons being learned.


Subscribe to RSS - serio