Serio Blog

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.

Monday, 07 May 2007

This post is another in the series I’ve been writing about Service Level Management. The last post on this topic is here.

My post for today is on a subject that seems to confuse and vex quite a few people –  service times and support times. What do we do if they are different?

For example:

A service desk within a call centre services company provides a sales order processing system that is used 7 days per week from 08:00 until 20:00. The service desk is open from 09:00 until 17:00 Mon-Sat.

Of course, it would be nice if this sort of thing didn’t come up at all – but life has a habit of being messy. Since Service Level Agreements are agreements, the answer is we handle this by agreement with our key customer signatories.

Typically, I’d expect the SLA to state that the service availability is 08:00 until 20:00 Mon-Sun, and I’d also expect the SLA to record the hours of availability of support (Serio Administrators please note, when you set-up and SLA in Serio that the start/end pairs refer to service availability, not necessarily support availability hours). This means our statistics on availability (something I’d expect to see in the SLA, as per my last post) would be produced on the longer seven days figure. If you are tempted to do otherwise remember that Incidents are probably still affecting the business and the weekends – you are just airbrushing it out of the statistics.

The objection to this usually comes from the service desk itself – Incidents are going to occur when there is no service devoted to their resolution, and will be impacted as a result. The answer is that you factor this into the SLA you negotiate your targets – which might have lower availability service levels specified than might otherwise be the case.

One of the benefits of this kind of discussion is there is a formal focus on IT service for the enterprise. One of the things that might be considered is extending service desk hours and providing a costed proposal for this,  or examining the costs of having a suitable support engineer ‘on call’ for the extended periods. Try to compare the costs of unavailability of our example sales order processing system with that of the costs of an extended support service (see our availability white paper for more info on computing the costs of unavailability). 

Friday, 04 May 2007

This is a continuation of the earlier post on the subject of IT Service eMail content.

Incident Confirmation (continued)

If you have a support website for your customers, advertise it by including a link to the website on the email. Do more than put the link there – give customers a reason to click it by explaining (in a concise style) what facilities are offered there.

Remember that you can include more information as well – such as the Asset/Configuration Item affected, the Company-Branch affected and more. You can then ask the customer to verify the detailks you’ve used are correct.

Routine Updates

By Routine Updates, I mean emails that are sent by support staff that do things like suggest resolutions or ask for further information.

For the most part, the bulk of the email will be the specific text from Agents entered whilst taking an Action.

Sender details. You should always include information about the person sending the email – resist the urge to be anonymous. Include the sender’s name, and a ‘sign-off’ as well that includes the sender’s telephone number and job title. This information is usually stored in the Serio user’s ‘Comments’ field for easy inclusion in the email. You’ll find it in the eDoc editor under ‘Sending agent/Sending agent comments’.

For routine updates though, you’ll get the best out of the system by creating a few ‘standard’ emails to cover things that you do all the time.

As an example, you could create standard emails that notify a customer when you assign an Incident to a third-party supplier. If you do a lot of password resets, you could create a standard ‘reset’ email that tells users what they need to do in order to regain access – even better if you combine the email into an Action you create for that purpose.

Hopefully you get the idea – there is no need to keep re-entering the same text, create a standard email or Action for the things you do frequently.

Resolution Confirmation

These are the emails that get sent when we resolve an Incident for a customer.

Customer satisfaction survey.  Ideally you should always invite the customer to comment on the service they’ve received from the helpdesk or service desk. Find out more about how to use this feature in the HowTo topic called ‘Customer Satisfaction Survey Roadmap’.

Resolution details. Make sure when you resolve an Incident that the resolving Agent documents what they did, and then send this to the customer. As this will be in the Agent comments entered when taking the Action, simply include this (‘Agent entered text’) in the email, but give it a meaningful title like ‘Incident resolution summary’ in the body of the email.

SLA Resolution Performance. I mentioned that the email confirmation can include SLA data. Your resolution email can contain both your target figures and actual accomplishments if you so wish, expressed as either hours/minutes or dates and times.

Wednesday, 02 May 2007

This post is for Serio users, and is on the subject of emails. I’ve blogged about this before, but in this article I’ll look at good and bad content ideas when the email is being sent to a customer.

The first thing you have to consider is format: are you going to use HTML, Text, or a combination of both? HTML allows you to control formatting and fonts, but has the disadvantage that some (very old) email readers might have trouble with it.

There are many types of emails we can get the Serio system to send to customers, but probably the most important are (in Incident Management) Incident Confirmation, Routine Update, and Resolution Confirmation. I will look at each in turn, describing what I think should be included in each. Firstly though, there are a few things that should be found on all three.

If you’ve never tried to edit the content of an email before, it’s easy. Login to SerioAdmin, open up a new Document Explorer, expand ‘email documents’, click ‘eDoc Definition’ and then double-click to edit the email template of your choice. You’ll see you can define two formats (text and HTML) and over on the right you’ll see data (called Placeholders) that contain data. You use these to add variable content to the email – like the customer’s name for instance.

Elements that should be in all outgoing emails

Incident Description. I’ve usually found it best to place this at or toward the bottom of the email. Customer can easily forget what the Incident is about, or confused with reference numbers, so every outgoing email should include the original Incident description. In the Placeholder list, look under ‘Issue/Issue Description’.

Reply Reference. The Reply Reference is usually just the reference number for the ticket with a few characters prefixing it. Including this on your correspondence helps Serio recognise the incoming email as a reply, and correctly affix it to the ticket. Look under ‘Issue/Reply Ref’

Incident Confirmation

This is the email usually sent to customers when they log a new Incident.

Assigned Agent. It’s not always included, but sometimes it’s worthwhile to give the customer information on who is handling their Incident. See ‘Issue Assignment/Assigned agent name’. Alternatively, if you use Owners to manage Incidents (rather than the Assigned Agent) you can include the Owner as the point of contact.

Response Target and Resolution Target. If you have an agreed Service Level Agreement, you can consider including your SLA targets. There are two approaches you can take: include the figures in hours and minutes (as in ‘we will try to resolve this Incident in 8 working hours’) or as a target time (‘we will try to resolve this Incident by Wednesday 3rd May 14:00’). Both the response and resolution targets are available to use, and you’ll find them under the ‘SLA’ group – for example ‘SLA/Target primary callback mins’ or ‘S:A/Target completion date time’. Some Helpdesks/Service Desks seem to feel uncomfortable about doing this, but my personal view is that, provided you have a negotiated SLA it is a positive thing to do.

I’ll continue this post tomorrow.

Monday, 30 Apr 2007

This is another in the series of Service Level Management posts I’ve been writing – the last one was on the subject of initial statistics (I'll pick up more about why the initial statistics are needed in later posts). I’ve also posted about defining the services you deliver.

If you are trying to create a Service Level Agreement (SLA) from scratch, there are a few ways I’ve seen of structuring your document.

Based on Services

You can structure your SLA around services, using the Service Catalog as a start point. To give you ideas, here’s an example based on an Invoicing System:


Major Incident: System down, with no availability to users, or significant business process impact with no workaround. High Priority Incident: System available, but with some significant business process impact for which a short-term workaround is available Regular Incident: No significant business process impact, or a small (less than 4) number of users affected


System is required from 8:00 to 18:00 Mon-Fri, excluding public holidays

Service Level Targets:

Major Incident: Achieve 90% resolution within 4 working hours
High Priority: Achieve 90% resolution within 8 working hours
Regular Incident: Achieve 90% resolution within 12 working hours

Notice that what I’ve written above is specific to a particular service, defines ‘grades’ of Incident by severity, and sets targets for Incident resolution. If you are preparing a real SLA for a customer, you’ll need more detail than I have created above. Issues such as reporting intervals, type of metrics to be used, escalation and others may need to be taken into account.

The above example does raise a question it is worth stopping for a moment to consider. If our Invoicing System is delivered over the network, and our network fails, is this an Incident affecting the Invoicing System or Network? If the Invoicing business process is affected then the answer is both and the Incident would be classed as a Major Incident.

Serio users taken note: this is exactly when Incidents can be logged against multiple Systems – so that, for reporting purposes, a single Incident can have multiple affects.

Based on Customer Groups

In addition to services, you can use different customer groups – by departments if you are providing support internally, or by company if you support external customers. Here each group is often a budget holder, which allows for negotiation to take place on service and costs.

In a customer-group model, each group has their own specific SLA (which is often broken down again into services). The SLA specifies clearly to which Incidents it will apply, and tries to anticipate any confusion that might arise when a single Incident affects multiple groups. 

Wednesday, 25 Apr 2007

This is another in the series of posts on the subject of Service Level Management – my last post in this thread started the topic of how to develop a Service Level Agreement (SLA) by defining the services you provide to users (more commonly referred to as the Service Catalog).

In this post I’m going to look at some of the data you might need to have before you enter into discussions about an SLA with a customer. I’ll start with the scenario of someone providing support to an internal customer base looking to set-up their first ‘formal’ SLA.

So, what data do you need? Speaking personally, I’d want to know approximately what our position was before any negotiations took place – so we can see if the gulf between what the customer might want, and we can deliver, is too large that we can expect to cross it with efficiency gains alone. Specifically I’d want to know:

  • The average of expected number of Incidents and Change requests logged each month
  • My average time to resolve Incidents, broken down by Priority. I’m not a big fan of average figures, so if possible I’d want a ‘spread’ graph that shows my the distribution of resolution times. For Serio users, this would mean SLA12.
  • I’d probably want a few different ‘slices’ of Incident and Change logging data. For example, I’d like to know which user groups (departments or companies for example) logged Incidents and Changes with us.
  • Most importantly, I’d want data on service availability (see our Availability White Paper for more information). I’d want our key service availability expressed as a percentage, and I’d also want some downtime statistics (in hours, per system).
  • Information on customer perceptions of service – specifically data gathered from satisfaction surveys.
  • Statistics on our callback performance.
  • What Service Level Agreements we have, if any, with out most important suppliers.
  • A few other miscellaneous statistics such as our first time fix rate, number of major Incidents, number of complaints received.

Ideally, I’d probably want this data over at least a 3-month period as well because availability statistics in particular are subject to ‘bouncing’ due to one-off major Incidents.

The reason I’d want all this is because it does no-one any good to sign-up to SLAs that are unachievable – you’ll simply set unrealistic expectations in the minds of your customers, and demoralise the IT staff that are working to meet the SLA. Of course it might be that your business needs a better service – but sometimes this requires additional investment in staff, training and infrastructure. Your discussions about SLAs should as a matter of course include these as subjects for discussion.

I’ll continue these series of posts later by looking at how we structure our SLA, and who we enter into these discussions with.

Monday, 23 Apr 2007

In today's post, I'm going to introduce you to Serio's Contract Management features.

Serio provides for two types of Contract Management:

  • Customer Contract Management. Manage the contracts your Helpdesk/Service Desk has with the people it provides support to. Clearly, this applies most to Service or Help desks with external clients.
  • Supplier Contract Management. Keep track of support contracts for third party suppliers providing service to you.

I'm going to focus today on the Customer Contract Management features within Serio – we'll return to Supplier Contract Management in a later post.

Before dealing with a new call, Service Desk staff usually need to know whether the caller has a valid support contract.

Customer Contract Management enables frontline staff to answer basic questions about the Customer's entitlement to support, such as:

  • Has the Customer's support contract expired?
  • Has the Customer reached their quota of calls for this year?
  • Does the Customer's support contract cover the piece of hardware about which they are calling.

Whereas Service Level Agreements (SLAs) define the level of service that customers can expect when they contact you, Customer Contract Management keeps track of who is entitled to support and for what.

Here's an overview of how to get up an running with Customer Contract Management. If you need more detailed instructions, please refer to the online help for SerioAdmin.

Enabling Contract Management Features

Firstly, you need to make sure that your SerioClient users can see information relating to Customer Contracts through SerioClient. Turn on Contract Management features in SerioClient by ticking the option 'Enable Contract Management Features in SerioClient' on the 'Issue Logging-2' tab page of the user's Agent Profile in SerioAdmin.

Creating The Contracts

Next you need to create your Customer Contracts within SerioAdmin.

Open a new Configuration Explorer from the 'File' menu, and expand the 'Customer Contracts' section. (Note that if you use Serio Helpdesk rather than Serio Service Desk, the presence of Customer Contract Management will depend on the modules you have purchased.)

Customer Contract Types

Customer Contract Types enable you to organise contracts into different categories based on the type of service offered to the customer. You might create Contract Types such as 'Gold Support', 'Silver Support', '10 Call Support Pack', 'On-site', 'Server', etc.

Customer Contracts

Start creating your Customer Contracts by selecting 'Customer Contract Management' under 'Customer Contracts'.

First, set the Contract No., Contract Type, the Customer's Company, and, if necessary, Branch.

Each Contract carries an expiry date – information available from SerioClient when you are logging calls, so that you can instantly see if the Customer has a valid support Contract with you.

Support Pack Contracts

If you switch to the 'Contract Terms' tab page of the Customer Contract form, you can choose to make the Contract at Support Pack. This means that the Customer can only raise a limited number of Incidents (say 20) under the Contract. Again, the Incident logger can see automatically in SerioClient whether or not the Customer has any calls left in their Support Pack. Of course, you can also still apply the expiry date to a Support Pack contract.

Support Pack contracts work like this. Each time you resolve an Incident for a Customer at the client's Company, you specify whether that Incident should be deducted from their Support Pack. This discretion is essential, because you may not want all types of Incidents to count against the the Customer's Support Pack – for example, if the Customer is raising a complaint.

Items Covered by the Contract

After you save the Contract in SerioAdmin, you will notice that an 'Items' tab appears. If you have an Asset or Configuration Management Database (CMDB), you can indicate on the 'Items' tab which of the Customer's Assets are covered by the Customer Contract, so that you may identify when working within SerioClient whether or not the specific piece of hardware for which the Customer is reporting a fault is covered by a Customer Contract.

In Conclusion

Customer Contracts provide an invaluable tool for determining whether someone calling the Service Desk/Helpdesk is entitled to the support they are requesting, and of providing differentiated levels of support. If you're a Serio user with a large number of external clients, you're bound to be storing this information somewhere already. Why not make life easier for your Service Desk staff and store the information in Serio where they can see it?

Friday, 20 Apr 2007

This is a follow-up to Wednesday’s post about Service Level Management for Beginners. What I’m going to talk about now is how we might approach the creation of a Service Level Agreement (SLA), again assuming that you are a complete novice.

Please note, this is not the only way you can approach things, or necessarily the best way to approach creating an SLA. I’m trying to suggest ideas which those attempting this can use.

Define the Services you Provide

This is one of those things that sounds easy but often isn’t. Ask yourself what Services you provide to customers/end users, and try to document them. Examples might be:

  • Email access (local and internet)
  • Http (web) access
  • Accounts system

The difficulty in defining a Service is one of perspective. Do we use a customer’s definition – something meaningful that they use – or adopt a provider view where the components of a service is considered a service in its own right? I’ll illustrate by example. Suppose you have an accounts system delivered (say) by Windows Terminal Services. For it to be used you need a working software system on the server and a working network infrastructure. Does that equal one service (‘the accounting system’) or two (‘the accounting system’ and ‘the network’?).

The ITIL Service Delivery book (Pub. by TSO) provides a useful definition: ‘A service is one or more systems that enable a business process’. This puts the emphasis firmly on the user perspective.

Whatever view you take, define the Services you provide. Then add additional information such as:

  • The departments, customers or companies using the service
  • Number of concurrent users (just take an average)
  • Any 3rd-party (supplier) contracts that we have in connection with the service
  • Typical hours of use
  • Value of Service

The last one – Value of Service – is sometimes controversial, but something I’ve found valuable. Not all Services are created equal. The disappearance of some Services for a few hours causes inconvenience but nothing more, but failures on other Services cause immediate and widespread disruption to the normal operation of the enterprise. Typically I’ve used Critical, High, and Routine – but of course you can use a numbering scheme 1-5 or any other method.

You can store this in a matrix in something as simple as a spreadsheet. Alternatively, you can usually store this an a CMDB. In Serio, the ‘System’ structure was specifically created to allow you to hold this kind of information within the CMDB – and use it within things like Incident Management.

Those more familiar with ITIL and IT Service Management will recognise this as a Service Catalog.

Whatever comes next in defining our SLA, it’s useful to have information about what ‘the service’ is when we consider the requirements of the business.

I'll continue this thread next week.