Serio Blog

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.

Tuesday, 17 Apr 2007

In the next IT-service related blog topics I’m going to post here, I’m going to look at Service Level Management (SLM). I'll assume that my readers are completely unfamiliar with this topic.

First of all, I’ll start with a definition. Service Level Management is a name given to management processes that include:

  • Identifying and agreeing the IT service level requirements of the organisation
  • Monitoring and reporting on actual service levels delivered to the organisation, identifying any weak areas in service levels achieved
  • Identifying cost-effective ways to improve service levels delivered.

If the above sounds vague I apologise – I’ll be adding some detail to this in later posts when I think it will become clearer. The bottom line is this: what does the business need, what is IT delivering, how can we improve and bridge any gap?

Of course I can’t talk about Service Level Management without mentioning Service Level Agreements (SLA). If you are a novice Service Level Manager, you’ll be wondering how you write an SLA. Well there is no such thing as a standard SLA first of all, any more than there is a standard company. Generally an SLA will have some or all of the following items contained within it:

  • Identification of services offered to users
  • Identification of different user groups or communities
  • Responsibilities of both the service provider and user
  • Reporting intervals and key IT/business representatives or stakeholders
  • Definition of service review mechanisms (usually face-to-face meetings)
  • Underpinning contracts (such as those we have with suppliers)

(I’ll expand on these items in later posts).

If you are reading this, & then looking at your ITSM tool which (like Serio) probably has all sorts of SLA measurement and monitoring features (often based around simple response and resolve targets), you might be tempted into thinking that you have a SLM process or (more prosaically) ‘we do SLAs’. Maybe, but too often when I ask questions... 

  • the SLA targets have not been agreed with all (or in some cases any) of the key business stakeholders,
  • key services are not identified,
  • reporting is ad-hoc and unstructured,
  • no proposals for improvement can be found.

These are all signs of an ineffective or non-existant SLM process.

My point is that SLM is a management process – the role of the ITSM tool is to help you manage your targets and monitor what you are delivering. The good stuff (meeting with business stakeholders and documenting what they need, costing this, documenting what you deliver, getting a statistic from your ITSM tool and interpreting it wisely, suggesting costed improvements) happens outside the tool. It’s the value-added things like this that tell how mature a Service Level Management process is, not how closely you monitor different alerts and warnings from your ITSM software.

What I’m going to do in future posts is expand on these ideas. I’ll be talking about Service Level Agreements to give you an idea of how you’d create one, the service catalog, and some of the benefits arising from SLM. Most of all I’m going to try to deal with specifics and practicalities.

Blog admin's note: follow-up posts are here, here, here and here as of May 7th 2007. 

Monday, 16 Apr 2007

This post will talk about SerioScript - the scripting engine that powers, amongst other things, the Serio Command Center. Specifically, I'm going to create a new script and use it to illustrate how you can display property values on the Command Center web pages - so you can see device values read from SNMP directly in your browser.

I'm going to assume that you know how to connect a script to a Device, and already have the web pages set-up.

1. Firstly, create a new Script using the SerioMIB (right-click on 'Validation Scripts' and select 'Add Validation Script'). Call the Script 'Blogtest'.

I'm going to get the Blogtest script to display the Free Memory (compared against an acceptable value) for a target machine on the Command Center web pages (I'll call these the CCWeb pages). Please note the standard (Default) script does this anyway, but this simple example will allow me to show you how you display a value on CCWeb.

In doing so, you'll see how to construct a script, from scratch, with your own Device Properties.

2. Click on the Device Property Definitions tab. Right-click on the page area, and select 'Add New Device Property Definition'. Use the following values.

  • Display Name: Minimum Free RAM
  • Description: Free RAM (Memory) available on the remote machine.
  • Device Property Type: Scalar

3. In the Symbols window below, right-click and select 'Add Symbol'. Use these values:

  • Display Name: Minimum Free RAM (MB)
  • Property Name: gnMinFreeMem
  • Description: Minimum Free RAM in Megabytes
  • Type: Number
  • Default: 80

4. Click OK to close the Symbol Editor window, and click OK to close the Device Property window, returning you to the Validation Script(Blogtest) window.

5. From the list of MIB variables in the left of the Validation Script window, notice that the top three are underlined? These are special places for you to attach code to. Right-click the one called 'InitializationSerioScript' and choose 'Add Validation Statements'.

6. Add this line of code.

displayPropertyAdd('gnMinFreeMem', 'gnMinFreeMem', 2, '', 1);

Don't worry too much about what the arguments mean right now (you can look them up in the SerioScript Reference). All this function says is that, from a CCWeb perspective, this is a value I want to display).

Click OK to return to the Validation Script window.

7. From the list of variables in the left of the Validation Script window, right click on the variable that hold the current free RAM setting. It is called serioVarFreeMemKB. Right-click this and add these lines of code.

lnFreeRAMMB: number;

// Convert free RAM to MB.

lnFreeRAMMB := serioVarFreeMemKB / 1024;

// Check it against our expected value, and update the web pages accordingly

if lnFreeRAMMB < gnMinFreeMem then


displayPropertySet('gnMinFreeMem', numToString(lnFreeRAMMB,1)+' <=== Error!');

end else


displayPropertySet('gnMinFreeMem', numToString(lnFreeRAMMB,1));


// Display a print value as well on the console

Print("Free RAM in MB for "+serioVarDeviceName+" = "+numToString(lnFreeRAMMB, 1));

8. Now attach the script to a Device, and Go Online.

You'll see your target minimum free memory figure displayed against the current figure. When the observed value drops below the minimum for the Device (by default 80MB) you'll get a little 'error chevron displayed as well.

Friday, 13 Apr 2007

This post has been requested as a follow-up to my earlier ‘difficult customers’ post which seems to have been well received judging by the email feedback I’ve had. For those that don’t have it my email address is georger _at_ seriosoft _dot_ com - or of course post your comments below.

Whilst the role play seems like everyone to be a good idea, it seems it might be worthwhile going over some possible scenarios for your role play exercises, and more detail on how they should be conducted.

Starting off, I’d want to identify who should take part in our difficult IT support customer role-play. Emailer Rob asks if all staff who deal with customers (like engineers) should be involved, or just the service desk? My own preference is just the helpdesk/service desk – your central point of contact. This is the group we expect to excel in customer contact, and on whom suitable training will have the best results. Others can be included of course, depending upon the level of customer interaction you expect them to perform.

As an aside, emailer Karen objects to the use of the word ‘difficult’. Instead she suggests the terms ‘frustrated’, ‘angry’ or ‘concerned’ (or presumably all three at once - a FAC customer?). Despite Karen’s objection, I’ll stick with Difficult as a shorthand for all three as I can’t think of a better single word to describe what I’m writing about.

Make sure that is understood clearly by all those participating is that the role-play is not a test – it’s a training exercise. Make sure that your staff realise that they can’t ‘fail’ and that there will be no penalty if they find it tough.

If your staff are those fielding the test calls, you next need to decide who will play the role of the difficult customer or user. My preference would be for a peer-group exercise if at all possible – pick one of your more articulate, experienced and outgoing staffers to play the customer.

The environment should be private – with just the helpdesk/service desk staff participating in the exercise. My preference would be to complete the role-plays as a group, with each team member able to hear the others efforts. Calls should be played-out over the telephone, with the person playing the customer in another room. At the end of the exercise, when all have had a turn, have a group discussion where people review what they’ve learned.

Give your staff no warning about the calls, just brief them on the scenarios below.

1. Customer Bert calls to ask why the accounting system is down.

Scenario - Accounting system. The accounting system, used by 15 customers, is down having crashed in the mid-afternoon on a Monday. It’s the third such Incident in a 15-day period. You have no time estimate for when the system will be restored. Your manager has taken the afternoon off to play golf.

Key points: Demands to know when the system will be back. Attitude is somewhat aggressive. He wants to know what is being done. Wants to know why it keeps happening. Repeats that it ‘just isn’t good enough, some of us have work to do’. Asks ‘will any of your staff be here to help when I have to work late’. Refuses to put the phone down until satisfactory answers are given. Resorts to mild swearing.

2. Customer Kath calls.

Use scenario from 1.

Key points. Kath is calm – could be described as passive aggressive. Asks to know how many other such Incidents there have been recently. Asks the opinion of the person taken the call on the quality of service, she asks 'it's unprofessional isn't it'?. Demands the service is restored immediately. Then asks to speak to a ‘supervisor’.

3. Customer Arthur calls.

Scenario - Monitors. A colleague has replaced a monitor of a VIP who complained the original was fuzzy.

Key points. He says his ‘new’ monitor is worse, and is fuming because your colleague closed the call without asking him if he was happy. He demands you get up from your desk immediately to return his old monitor. Asks ‘do you like working here?’, and asks, of your boss, 'is this the level of service he is happy with' asking you to comment on your boss.

4. Customer Bill calls.

Scenario - CRM. Bill manages the CRM system and can’t access a particular report.

Key point. We need to know the error message listed in the Event Log on the computer, but Bill will not co-operate or follow the instructions of the first-line technician he has called. He repeats ‘this is a problem with the upgrade you did, don’t waste my time’ and every suggestion is rejected. Bill will not co-operate to get his problem fixed.

I hope you enjoy the role-plays, & have a great weekend!