Serio Blog

Thursday, 24 May 2007

WiFi internet access on trains is the last piece in the jigsaw puzzle for real productivity on the move. Passengers have been hamstrung by patchy network access as trains pass through tunnels but that is changing.

T-Mobile is fanfaring its WiFi hotspot service on the Heathrow Express train as a technology breakthrough. The company that installed the system is claiming a first for using WiMAX technology underground on the route. T-Mobile’s service, available to all, not just T-Mobile customers, promises broadband internet access at 2Mbps throughout the journey, including a 6km tunnel. But the service comes with health warnings, more of which later.

WiFi Hotspot access passes are sold on the trains for rates ranging from £5 for an hour up to £40 for 30 days. This compares to £2.95 for an hour on a GNER train, £9.95 for 24 hour access.

The aficionado of train WiFi might want to track the proceedings of Train Communications 2007 held in London on the 6th and 7th of June. The organisers concede that despite great progress in this sector and in the face of overwhelming public demand for such services, only a handful of train companies have so far managed to supply customers with an internet connection. This might be partly due to security worries.

The Times newspaper has uncovered evidence that criminals are using a technique known as an 'evil twin attack', where victims think that they are logging on to a genuine T-Mobile network but are in fact being diverted to a hacker’s connection. In the article T-Mobile said it was aware of the technique but hadn’t had any reported instances in the UK.

Security experts say that it would be hard for T-Mobile to spot this happening though. The security conscious might want to think twice about accessing critical data through these services which is a pity as WiFi hotspot broadband access is broadening all the time and is being offered free of charge to coach passengers.

Passengers on the Oxford Tube coach service can now access the Internet while they travel between the university city and London. Access is via Moovera Networks' mobile WiFi equipment and Vodafone 3G broadband network with access speeds of up to 1.4Mbps on the Stagecoach coaches.

Stagecoach says passengers have switched from the train to its Oxford Tube service to London after it offered customers free email and web access as part of the trial of WiFi technology. Around 4,500 users registered for the service during the three-month trial which was hailed a success – with more than 16,000 online sessions of an average duration of 42 minutes – and free WiFi access is now a permanent fixture. 

In order to increase the range of content available on this blog, we are creating a new category – Technology. We’ll be publishing articles to this category on a regular basis, alongside our existing ITSM and Serio product posts. We hope you find the new posts informative and useful.

Jackie, blog admin

Monday, 21 May 2007

(See also handling difficult customers.)

A while ago I was asked for any ideas I had on a complaints procedure from a customer whose business is the management & provision of a support service – providing a helpdesk/service desk service for external clients. I’ve chosen this as my subject for this post because it fits in nicely with the service level management posts I’ve been writing recently. Most of what follows is just as applicable to bother internal and external providers of support services, but my guess is that those who provide paid support services will be the most likely to implement a complaints procedure.

Complaints procedures are useful things to have because of their ability to avoid disputes, and to maintain or repair what might otherwise be a damaged customer relationship.

From a customers point of view, a complaints procedure will have more credibility when it is advertised, is simple, is confirmed in writing, has a few key timelines on it, and is considered by people who are (ideally) at arms length from the staff the customer usually deals with.

Let’s look at each of these in turn.

Advertising. Advertising (or making visible) a complaints procedure is important, and should describe the basics of how to raise a complaint, and how it will be considered. Good places to put such information might be your IT customer services portal (integrated with your SerioWeb pages if you are a Serio customer). Avoid a long description of your complaints handling procedure – focus on how and where, and what the timescales for resolution are.

Confirmation. Make sure you confirm the nature of the complaint, and agree it with the customer in writing particularly if it has been reported by telephone. Some organisations only take written complaints to avoid any confusion.

Timelines. Have a target response time for complaints (be careful to avoid the term ‘resolution’ – it can take much longer than your initial response). Ideally this will be 5 working days of less.

Fairness. Make it clear who will be investigating the complaint – ideally someone a little removed from your normal IT helpdesk/service desk. Your Service Level Manager might be a good choice.

Referencing to a trade body for arbitration. Although commonplace in the building and other sectors, paid IT support doesn’t seem to have much in the way of specialist arbitrators (correct me if I'm wrong though). However, here in the UK may be able to help.

On the administrative side, it’s essential you have a clearly defined way of recording complaints – so you can report on the number of complaints received as a service level metric. For Serio users, that typically means having an Issue Type of Complaint and having (usually) a special SLA that is used (with the response time set accordingly).

Friday, 18 May 2007

This is a follow-up post to KPIs for Service Level Management

Continuing the list I started on Wednesday…

6. Times to resolve. There are lots of ways to slice and dice this – resist the urge to produce many different variations – pick just one or two, by Priority or Impact for instance. I have a personal dislike of averages here, because I think they can often do more to hide the truth than is useful. Instead, so time to resolve in a ‘banded’ form using a graph, so that the distribution of time can be seen. If you are a Serio user, have a look at SLA12.

7. Evidence of meetings. Is there evidence of your Service Level Manager (you have one, right?) actually meeting with customers to go through some of the metrics mentioned in my last post? In particular, are there action points produced and evidence of these being carried through?

8. Responsiveness and callback performance. I’m always surprised this is overlooked by Helpdesk/Service Desk staff, but it really matters to customers. Ideally your SLA will state a callback date and time for customers reporting Incidents – make sure part of your metrics is devoted to reporting on the timeliness of these callbacks.

Just a quick word about the various information resources we offer to customers, and information about where product documentation is located.

Product Documentation – Serio HowTo

Product Documentation (including documentation on SerioClient and SerioAdmin) is not available on the web. This data is for customers, and you’ll find it distributed with the product. Both general use and administration information is contained within the HowTo guide. You can access this from any machine with SerioClient or SerioAdmin installed, either by pressing F1 or by using the Start menu.

Serio Website at

This contains general product overviews, key features and the blog. The blog contains articles about IT Service Management and articles about the product. These product articles are created to supplement what is in the HowTo guide and offer ideas to customers for additional areas of functionality they can use. It also offers us a place where we can announce upgrades and enhancements.

Support website at

This contains troubleshooting knowledgebase articles, and our support portal you can use to log and progress Incidents. This website is for customers with a valid support contract only.

Regards, Jackie – blog admin

Wednesday, 16 May 2007

The post today is on the subject of Key Performance Indicators (KPI) for Service Level Management. I’ve posted about KPIs before, see Incident Management KPIs and Problem Management KPIs and of course the metrics white paper we have on our home page.

I’ll state again what a good KPI does: it tells us, as managers of a process, that the process is working (or at least, not fatally broken). So our Service Level Management KPIs should tell us that our SLM process is functioning, and point to weak areas where need to drive improvements.

Also bear in mind that not all KPIs actually come from your ITSM tool. Recently I was asked to comment on a customer’s Incident Management process, and prior to the day on-site I asked for KPI’s of the Incident Managers choosing to be ready for me to have a look at. To the customer’s great credit, amongst the data he produced were

  • Meeting notes with service teams (where he was discussing some quality issues) from which action points were produced (with a plan for checking the actions where indeed actioned).
  • Evidence of him checking and correcting Incident data quality issues (such as poor descriptions, poor resolution information and bad categorisation from some Service Desk agents).
  • Call logging scripts he had introduced in the past 6 weeks.

(Although I wrote a 2 page summary afterwards, my conclusion was ‘you’re doing a great job’).

But I digress. Coming back to the point of this post, let’s have a look at some data you can use as a KPI. Some of these come from your ITSM tool, others not.

1. SLA in place? Do you actually have a well-drafted, clear and unambiguous SLA in place that is agreed by all the relevant parties? I’ve blogged about this earlier this month.

2. Are you reporting regularly? I’d look for evidence of reports being produced along the lines indicated in our white paper. Namely a summary of results, conclusions, weak areas and recommendations for improvement.

3. Availability against target for key services. Most customers seem to choose to express this as a percentage (eg, email service available 99.4% of the month as opposed to 99.5% target). If you are a Serio user, without question the best way to obtain these stats is through the tool itself, as I’ve blogged about here.

4. Customer satisfaction survey results. You can either use data recovered from customer responses after Incident resolution, or a monthly/quarterly survey, or both. These results can be hard to summarise so try to determine if the trend is up, down or neutral. Something like ‘customer satisfaction with our IT Helpdesk/Service Desk improved over the month’. If you are a Serio user, report svy_6 is a pretty good way to do this statistically.

5. Number of instances of service breach over the reporting period. This is linked to 3 – how many times, per service, did we have a service outage?

I’ll follow this up with a few more ideas in my next post.

[ Note from blog admin: the follow-up post is here ]

Tuesday, 15 May 2007

A colleague in Australia at the moment asks for a post about one of our products called the Sentinel. Serio Sentinel is a server monitoring product. Over the years much of its functionality has been transferred into the Command Center/Serio Inventory Agent toolset, so that as of today most customers who are performing monitoring of Windows 2000 and 2003 servers don’t need it.

There are some special things however that, from the Serio product family, only the Sentinel can do. These are as follows.

1. Server Event Log Monitoring. Some applications (usually Windows Services) report errors by simply writing records into the Windows Event Log. One of the things that the Sentinel can do is ‘watch’ the local Event log and tell you about different Events recorded there.

It is basically a straight-forward thing to do, but the power comes in the filters you can apply. Most messages in the Event Log are probably of no consequence and would be irritating if reported to administrators. That’s why when you start monitoring for Events you can apply filters for which Log you are interested, the Source, Message Type and Event ID.

See the function EventLogAddEventToMonitor in the SerioScript Reference for more information.

2. Custom DLL execution. We have some pretty smart customers, and some have written Dynamic Link Libraries that monitor applications that they’ve written themselves. The Sentinel can load a DLL, can a function, and then interrogate the return code for success of failure, interacting with the Command Center as required.

Unless you want to do either of the things listed above, you are unlikely to need the Sentinel.

Monday, 14 May 2007

This post is for Serio Configuration Managers (or any Serio user changing Item data) on an often overlooked part of the Serio system called Item Attributes.

Item Attributes offer a flexible way to store data against Items (Configuration Items [CIs], or if you like Assets). Typically, an Item Attribute is used to store a characteristic – for instance, the amount of memory installed in a computer, or the type of keyboard it has, or the port number used by a particular webserver. Anything which is part of the make-up of a Configuration Item.

One of the things to remember about Item Attributes is that it’s a one-to-many relationship. In other words, you can have a single Configuration Item and one, two, ten or a hundred different attributes associated with it. This makes Item Attributes the most flexible way of extending the data you store with a CI.

Aside from being easily to search for types of Item with a given Attribute, you should bear in mind that Attributes can be managed, applied and deleted from many Items in a single step. For instance, if you wanted to record a memory upgrade on 100 computers you could do that in a single operation by deleting the old installed RAM value and replacing with the new – on all 100 computers in a single operation.

To do this, you need something called the ‘Configuration Builder’. To access this, open a Configuration explorer in SerioAdmin, right-click on the report area (the list), and select ‘Launch Configuration Builder’. For there, it’s pretty straight forward to use, but you can find out more about it in the HowTo guide distributed with the product (press F1 in SerioClient or SerioAdmin).

One area these sometimes vexes users is this: when should I use an Item Attribute, and when should I create and link to another Item? The answer is to refer back to your own guidelines when you scoped your CMDB, and tried to define what an Item was going to be (a subject covered previously in this blog). Attributes are for things that of themselves are not CIs.

If you are not sure, use this as a rule of thumb. Ask if the ‘thing’ in question will be covered by Change Control. If Yes then it is probably a CI, if no it is probably an Attribute.

Friday, 11 May 2007

This is another post about Service Level Agreements and Management. The last post on this topic is here.

This post is on the subject of things which could form part of your Service Level Agreement. I’ll list these things in two groups: core and additional. For core read ‘items covered even when the IT group and organisation is quite small’, whilst for additional read ‘items often found in larger enterprises’. The list isn’t exhaustive, but it will give you a general idea and hopefully pointers for when you come to try to create your own.

Core items

Overview and introduction. A paragraph describing the main aims and scope of the agreement.

Key parties. From both the customer and provider side (names of people, not just departments).

Scope. If there are specific exclusions or exceptions state them clearly. Sometimes it’s just as useful to say what you don’t cover as what you do.

Services covered by the SLA. Describe each Service carefully, avoiding unnecessarily technical language. I’ve discussed this at length here.

Hours of Service availability. Typically this will be expressed in terms of a day of the week and then a start-time and an end time. Usually exceptions will also be listed – such as public holidays. In some Service Level Agreements that I’ve seen, a seasonal element has been introduced – for example, extended availability in the run-up to the Christmas period.

Hours of support availability. As I’ve discussed previously, this is not necessarily the same as your hours of Service availability. The times I’m talking about here are when the ‘support function’ (such as your Helpdesk or Service Desk) is available. Like Service availability times, you will specify a start and end time with exceptions and special cases as required.

Reporting. Monitoring and Reporting is key, and in itself should form part of the agreement. Ideally a complete sample report will be part of the SLA, showing performance against target and highlighting areas for improvement. Your reporting interval should be clearly defined here also.

Performance Targets. I’ve touched on how to describe these in previous posts (with examples), but here you are looking at quantifying service returned. Availability of the services covered by the SLA is a good place to start. You can express this as a percentage, or as a maximum permitted downtime interval in hours – for more see our availability white paper. You can also include targets for incident response and resolution, as well as extending this to cover escalation procedures for different types of Incident.


Performance benchmarking. If we are defining services as part of the SLA, you sometimes need to bear in mind (as I’ve blogged about previously) that defining when a service is down can be tricky – for instance, if transactions are succeeding but slow. As part of your SLA you can specify acceptable transaction times for key business processes.

Expected volumes. If you are describing your performance benchmarks, you should describe the volumes on which they are based. For example, if your customer employs 50 extra staff over the holidays for sales order processing without warning the service provider, then this could have a very detrimental effect on overall performance.

Change performance. Targets around the processing and execution of user-requested IT Change.

Procedure for requesting extensions. Sometimes organisation need to have extended service availability. You can include the procedure for obtaining as part of the SLA, along with notice required by the service provider, and any associated costs.

Thursday, 10 May 2007

Customer Vince asks for guidance on setting-up a SerioWeb customer portal for his customers on the internet, having not undertaken this kind of task previously.

The first thing to consider is this: host local or remotely? By this, I mean is the web server machine in your offices, or hosted in a specialist hosting facility? A local solution is easier to set-up, but you may prefer the resilience and uptime that might be offered by a hosted solution. Local solutions are cheaper, and require less specialist technical knowledge that a hosted solution. Hosted solutions required a virtual private network (VPN) to be established between SerioServer and the remote IIS web server.

In Vince’s case, the best solution from a cost and complexity viewpoint, is almost certainly a local solution, and it is this that the rest of this blog post will concentrate on. I’m going to assume traffic calculations to support the expected number of users has been performed.

So, how do you connect the web site to the internet?

First of all, you need connectivity.  That means either using your existing broadband connection with a fixed IP address, or purchasing a dedicated (leased) incoming line also with a fixed IP address. Using your existing IP connection with fixed IP is cheapest, but check that placing a web server there does not violate your ISP’s terms of service.

If you are following closely, you now have internet connectivity with a fixed IP address, and a computer that sits on the end of the broadband connection. This is the computer that will often run the webserver that hosts SerioWeb (though if you have the expertise you can usually set-up routing such that another computer on your network is used).

Placing any computer on the internet providing a web server requires you to think about security – making sure the system is correctly patched, runs a firewall, has anti-virus software – and so on. An in-depth discussion of this is outside the remit of this blog, so you may wish to seek specialist advice at this point.

The next thing you need is a domain name. Of course, a domain name is not mandatory as such, in that you can tell your visitors to use an IP address, but a domain name is much nicer to and more familiar to users. If such a service is provided, you can obtain a domain name from your ISP, or you can use a specialist company to register the name and associate the IP address with the domain – one such being (again, make sure you are not violating your ISP’s terms of service).

Finally, you can choose to use SSL (encrypted communications) with your web site. If you do this you’ll need to buy a certificate. There are many providers – try googling for providers in your country such as ‘ssl certificates UK’ or ‘ssl certificates Australia’. Pick a provider that has very good step-by-step instructions for your web server, and who will re-issue the certificate free of charge if you make a mistake.