Serio Blog

Wednesday, 27 Dec 2006

This is a continuation of my last blog Telephony in IT Service Management.

Whilst my last blog entry looked at statistics, this blog entry will look at how Computer-Telephony Integration (CTI) can be used to make the job of the Helpdesk or Service Desk easier by discussing some of the common applications.

I’ll start with computer dialling. This is where you have a button on your ITSM tool that says ‘Dial’. You click it and the ITSM tool takes the number from the customer database and dials the customer for you, connecting you on answer. You may be thinking ‘so what?’ but I’ll say this – it is a really good time saver, and something you can very quickly get used to.

Another application is commonly referred to as ‘screen popping’. Whilst computer dialling is concerned with outbound traffic, screen popping addresses inbound traffic. What happens is this: when a customers calls you, the ITSM tool detects who is calling and then ‘pops’ a screen the tells you information about the caller, such as their name, which company they work for, and ideally shows you their recent Incident history – so they can be greeted with ‘good morning Mr Smith – how can I help you?’.

Screen popping works using a piece of data called CLI (Caller Line Identity). This is where someone calling a number makes their number visible. If you have used a mobile phone and observed the caller’s number being shown on the LCD display of your phone, then you’ve seen CLI in action.

What typically happens is this: your telephone system detects the incoming call, obtains the CLI data, and then passes this to your ITSM tool which scans its own database and identifies the caller – and this allows the ‘screen pop’ to take place with the right data.

If you deal with internal customers only then obtaining CLI information is usually unproblematic. If you deal with external customers, then CLI might not be available to you – some companies ‘hide’ their number when making outbound calls (though this unwelcome practice seems to be less common today than a few years ago). Another problem might be a large company applying the same CLI data to all outbound lines from their company, making it impossible for you to tell the actual individual calling.

If you are a Serio customer, you might be asking what Serio can do with CTI. The answer is that both outbound calling and screen popping are supported, but dependent upon your phone system having the right hardware and software capabilities. I’ll post later about what you need for CTI in terms of system requirements.

Friday, 22 Dec 2006

On behalf of everyone at Serio allow me to wish all blog readers and Serio customers a very happy and peaceful Christmas and New Year.
We are closed on 25th, 26th and Jan 1st. If you need help our support on these days simply email support __at__ and someone will pick it up. Make sure you put URGENT in the title somewhere.

Jackie, Blog admin

Telephony statistics, and telephony integration, is often overlooked in the IT service management mix. In this blog, I’m going to discuss a few aspects of these and how they can enable you to offer a better service for customers.

Firstly telephony statistics. Does your management reporting look at this kind of data? There are a number of key statistics you might want to look at, as follows:

  • Number of rings before pickup
  • Call abandonment rate
  • Distribution of incoming calls during the day

Number of rings before pickup. This how long does it take to get an answer when someone calls, and needs to be handled with a little care. An average number of rings figure is good to have, but you need to take into account ‘spikes’ that might be short-lived but point to unacceptable levels of service. For this kind of analysis it is sometimes useful to express this figure as a simply X-Y plot over time, or expressed with statistical measures such as standard deviation or max/min measures. You’ll typically get this from your ACD system.

Call abandonment rate. This is the number of times a caller gives up and puts down the phone. Apart from an actual count, it’s good to have this figure represented as a time-based graph so you can see if there are problems related to a particular time of day or shift pattern. Again this will come from your ACD system.

Distribution of incoming calls. This is a useful figure to have, as it tells you when your Helpdesk/Service Desk faces its highest volumes. In many cases you’ll see a smoothed day-by-day graph, a ‘twin bell’ shape, with a surge in the early to mid morning period, and again in the early to mid afternoon period. You often have two sources of information for this data – your can use your ITSM tool (Serio users see report IL14 ‘Daily Activity’) or your ACD system. My preference is the ACD system, as this captures all calls, even those made to discuss last night’s football results.

Telephony doesn’t just provide us with management data, useful though that is. You can also integrate your phone switch with your ITSM tool – something Serio has supported for some time. It’s called CTI (Computer Telephony Integration) and I’ll post later about the kind of things CTI can do for you.

In the meantime, have a happy Christmas and pie-filled New Year!

Wednesday, 20 Dec 2006

This post is for a customer fresh from an ITIL foundation course, looking for guidance or help with getting started with a Configuration Management Database (CMDB).

I’ll start with a reminder of what the CMDB is. It is a documentation for your IT infrastructure, describing how various parts (called Configuration Items, CIs) fit together to deliver services to customers. It typically shows dependencies between CIs, and carries a lot of business-related information in addition to the technical data you would expect.

It is an important underpinning resource, used in Change Management for example for performing important tasks such as impact assessment.

There is another discipline sometimes confused with this – Asset Management. This is where you keep lists of computers for reasons such as accounting purposes. In Asset Management you have lists of equipment, but these are typically not linked together – so you can’t use this data to understand how services are delivered to users.

Having given that definition, let’s come back to the subject of this which is getting started with a CMDB.

I’ll write in the form of Do’s and Don’t.

Do: Create your CMDB as part of a wider IT service management programme. In other words, what is your level of IT service management process maturity? Do you have an effective Incident Management process for example?

Do: Think very carefully how you will keep the data up-to-date. This may be your biggest challenge. The answer is to use Change Management to ensure that the data you are spending so much time to create is as accurate now as in six months.

Don’t: Necessarily start with desktop data. One thing we’ve noticed is a tendency for desktop equipment to be the first data entered into the CMDB, but you should ask yourself, particularly at the start ‘is this right?’. I’m not saying this is wrong, but just to stop and ask the question ‘what do I want to be in the CMDB and what is the best place to start’. I’ve blogged about this before in ‘What should be in the CMDB’ but you may want to start with your server infrastructure, particularly if the most important services you deliver to customers are server-based.

Do: Create your data in phases. If you are creating data for a complex infrastructure, one technique I’ve used is to isolate different systems and infrastructure (I’ll call these sub-domains), and to then concentrate on creating a representative model in the CMDB for each sub-domain. Doing this gives you a series of deliverable milestones, and allows you to perform checks and validation on each sub-domain as it completes. You can create sub-domains based in services offered to users, or physical location – whatever makes sense to you.

Don’t: Start before agreeing with interested parties what data will be held. For example, are you going to store warranty information (usually yes)?

Do: Be clear about who owns the data. Usually this will be your Configuration Manager, but it is important that the data has an ‘owner’ who will be responsible for it’s integrity and quality.

Don’t: Leave the ownership of the data to a group or to ‘the team’.

Don't: Limit what is in the CMDB to hardware Items. Instead, remember that CIs can be virtual, representing important entities such as database server instances, software firewalls and web servers.

Monday, 18 Dec 2006

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:

  • An entry in the Serio Journal
  • A Serio Message
  • A Text Message
  • An EMail

Reminders have a number of nice little touches. One of these is that by default, if an Incident on which outstanding Reminders is resolved, the reminders are cleared (there is a setting to change this however).

You can also place Reminders independently of Incidents. All you need to do is click the ‘Reminders’ chapter – this also shows you all the Reminders you have pending.

You set and cancel Reminders by taking Actions. To set a Reminder, your Serio Administrator needs to have done a little set-up beforehand. He or she should have created some standard Reminder Types, and then created two Actions for you – one to add a Reminder, the other to allow you to cancel it later, if you change your mind.

Friday, 15 Dec 2006

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.

Having said that, this post is about some of the techniques which we’ve used in the past to solve a variety of integration problems. They are in this order: simplest to implement first.


So simple it can be overlooked. Serio can send emails, and you can control precisely the content of those emails through the eDoc editor. Therefore, email is quite a powerful tool for sending information externally.

The kind of information you can include is up to you, but typically there are around 200 information types – such as service level requirements, detailed customer information, CI (Configuration Item) information, Incident data and so on. If you wish, you can use the eDoc editor to encode this in a machine-biased format such as XML for use in situations where structured data is required.

Serio can also read information from emails in structured form, which is useful for automated ticket logging.


You can read (please note, not write) data directly from the Serio database. We’ve blogged about this previously, in the Custom reports blog entries available here, here and here. This is a reasonably straight-forwards task for any SQL programmer, and if you use the Views we provide the job not only gets easier, but there should be little or no problems between releases, as we always try to maintain the Views as stable as possible.


Didn’t know Serio had a scripting language? Well it does, and it’s called SerioScript. SerioScript is amazingly versatile and it can be used to log Incidents and take Actions on Incidents, and can interact with remote technologies in a variety of ways, namely:

  • By using SNMP technology
  • By using custom-written DLL libraries (it can load and use DLLs)
  • By interacting with web systems (it can read web pages, for instance it can log-onto a site, access pages and log-off again)
  • By reading files
  • By running programs with specific arguments (it has a shell-out function)

SerioScript is part of the Command Center tool.

SS COM Libraries

SerioServer is a DCOM server. There are a number of COM objects (called SS [SerioService]) available on this server that can be used to integrate Serio. For example, you can log Incidents, or read Incident data. You can take Actions (such as resolving an Incident) or access customer details. This is probably the most complex because only a programmer could tackle this job, but it is also the most powerful. Our SerioWeb application was implemented using these COM objects.

The SS libraries are licensed, which means they may not be used without an appropriate Serio license.

Have a great weekend, and if it's your christmas party night have a good one!


Wednesday, 13 Dec 2006

This is a follow-up to this post about Incident backlogs.

Firstly, I omitted something very important: contract/agency staff as a possible option (thank you to commentator Robert for pointing that out). Out of all the things I suggested, this is probably the one that has the greatest potential for reducing the backlog – provided you have, or can get, the additional budget you need.

In this post, I’m going to discuss some of the problems that might arise if, like Linda, you are actively attempting to reduce a large Incident backlog.

I’ll start with contract staff, great if you can get the right people – but if you recruit the wrong person it will make the job of the Helpdesk/Service Desk Manager harder. My advice to Linda would be: make sure the spread of technical skills is right (naturally), but look for someone with a positive attitude who can manage themselves without close supervision. Always check references and qualifications carefully (I have experienced a number of fake CVs in my time) and don’t be afraid to set a small technical test. It will be an opportunity to see how the person copes, but if doing this make sure your candidate knows before the interview what you plan to do.

Referring back to my original post, and Linda’s new role, there is potential problem with my suggestions in terms of quality. If we make the focus one of closing Incidents, then we run the risk of overdoing this, and Incidents that are not resolved (even though we think they are) are closed. Although this makes are statistics look better for a short while, it does the business we are trying to serve no good whatsoever.

Therefore we need to take steps to prevent this. Firstly, make sure you communicate to your staff the need for quality and explain the potential problem to them, and remind them from time to time about this as the backlog is reduced.

Secondly, consider introducing a two-stage completion process for Incidents if you don’t already have one. This is where an Incident that an engineer believes to be resolved is set to a Pending Complete stage, and then someone else contacts the customer to ensure that the Incident is actually resolved – and then and only then sets the Incident to Complete. This will increase your workload of course, but has the advantage of stopping premature closure issues much sooner.

Thirdly, monitor the number of Incidents re-opened after closure on a weekly basis.

Tuesday, 12 Dec 2006

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.

Serio Description Templates can help you improve the quality of Incident and Action descriptions. A Description Template is just what it says, template text for Incident/Action descriptions that you can add to, and that can act as a checklist or script of prompts, so that relevant information isn't missed.

Description Templates in Incident/Change Logging

For example, suppose that you are logging a fault about an application called "Action Reports". To help resolve such faults, several standard pieces of information are important, and you would like to provide a template for the description of any such Incident.

Here's an example Description Template for such an Incident. Notice how it provides prompts, spaces where you can provide extra detail, and options from which you can delete those non-applicable.

"Version of Action Reports: [4.5/5]

Name of affected report:

Operating system: [Windows 2000 WS/Windows XP/Vista]

OS patch level:

Error message (if any):

Application Hung?: [Y/N]

What action was the user taking prior to error occurring:

Any other comments:"

You can set up a number of Description Templates for different types of Incidents. In fact, Description Templates are also very useful for Change Requests, where you often need descriptions to follow a standard pattern.

You can create new Description Templates using SerioAdmin – choose 'New Serio Explorer' from the 'File menu, expand 'Issue' and select 'Description Templates'.

When logging Incidents or Changes, you can select the Description Template that you want to use by clicking the Lookup (…) field to the right of the Description field on the Logging form.

Description Templates for Action Comments

You can also use Description Templates to provide a standard structure for Action Comments. This means that for each type of Action, such as 'Resolve' of 'Phone User', you can prompt your Helpdesk Agents to enter specific standard information. For example, a Description Template for 'Phone User' might look like this:

"Spoke to customer: [y/n]

Message Left: [y/n]

Name of person spoken to:

Details of discussion: "

When combined with Actions, Description Templates are a powerful way of providing standard text for emails. If you find you are writing the same email over and over again, then putting all that standard blurb in a Description Template may be the solution.

Of course, you could set up an eDoc for your standard eMail, but Description Templates have one major advantage – you can modify any of the text within a Description Template when you are sending the eMail. You can even combine Description Templates and eDocs to create eMails containing some standard and some standard-but-modifiable content.

To create a Description Template for a Action Comments, first create the Description Template in SerioAdmin, as described above for Incidents. Then to link the Description Template to the Action Type as follows:

  1. Select 'Issue Actions' > 'Actions' in SerioAdmin.
  2. Open the Action record you are interested, and switch to the 'Action Comments' tab page.
  3. Select the Description Template you created, and save (Ctrl + S).
  4. Try out the Action in SerioClient!

Friday, 08 Dec 2006

I blogged previously for someone taking up a Change Manager role in a small company, and this post is a continuation of that.

The Change Board

Change Managers interact with the Change Board – but don’t be put-off by the civil service sounding title. The Change Board is simply a forum that meets to discuss IT Change on a regular basis. If you are the Change Manager, you may chair these meetings, making sure that each Change presented is fit to be considered (as in having an impact assessment and so on) and then handling the outcome of the meeting afterwards.

Generally, you’ll present Changes for consideration, asking for approval, rejection, clarification or deferment.

The composition of the Change Board varies a lot in my experience. However there is usually someone from the actual user community present. As an example, if you provide a sales order processing system, your Change Board might have the person responsible for the sales function within your company as a member. Involvement like this helps bring a perspective on the value of certain Changes over others, or a user view on timing and implementation, that may otherwise be missing.

The actual running of the meeting varies between organisations. Some hold the meetings monthly, others weekly. Some publish the Changes in advance of the meeting, others simply introduce them when the meeting starts.

Advice for Change Manager: make sure you get the composition of the Change Board right. Make sure you are properly briefed before each meeting – you are sure to have a lot of questions to field. Make sure you record the outcome of the discussions accurately, and confirm your understanding afterwards.


In a smaller company, the Change Manager will become involved in the scheduling of Changes, and will be responsible for liasing with users of IT services that are subject to Change, particularly when downtime is involved. You may find that the Change Board provides you with a ‘window’ into which you can perform implementation tasks, but the actual timing is for you to sort out.

Advice for Change Manager: try to avoid an optimistic estimation of downtime. Be sure to communicate clearly with maintenance is taking place, even if it has been discussed at the Change Board.


You want to make sure that Changes are performed correctly, so one of the functions a new Change Manager performs will be one of review. In a nutshell, what can you learn from the Change just undertaken? Could we have performed it quicker, and with less risk? Did it deliver the benefits we had hoped for?

Advice for Change Manager: Review the completed Change against what you started with, making recommendations for improvement as required.

Owning the Change Process and the Changes

As a Change Manager, you’ll ‘own’ the Changes. You will look for Changes that are late, badly presented or thought out, intervening as and when required.

Advice for Change Manager: even if someone else is handling the Change, you still have some responsibility both for it and the overall smooth running of the Change process.

We've added a much improved search feature to this blog and to the site as a whole, as the old Wordpress search facility didn't cope with the amount of content we have now. You can access this new feature by clicking the 'Search this blog' link on the right.