A term used again and again where service levels cannot be agreed is ‘reasonable endeavours’. ITIL expert Simon Cook MBCS CITP asks what it means.

Yes, it’s better for the service provider than the poorly termed ‘Best Endeavours’ which should never be used as it means ‘the best you can do’ and therefore in theory it could be argued, better than your agreed SLA’s. However the term is one that bothers me and should bother you as a client or a service provider.

Wherever the word ‘reasonable’ is used you should always approach with caution it’s a word that causes friction and almost always leads to dispute. The best way to approach this is to think that your understanding of reasonable is unreasonable.

Not convinced? Ok let’s re-focus by moving away from IT services which is where this word is commonly heard and use in a more common environment. If we take a car analogy which most can associate with:

Your car has broken down and you have taken in to a repair shop, they tell you the gearbox has a fault and a sensor needs replacing. You ask ‘how long will this take’ and the technician replies ‘a reasonable amount of time’.

Would this be acceptable to you? What’s reasonable here? Is the reasonable amount of time based on the complexity of the fault or does the technician just mean in general. There’s a ton of variables that could be used to define reasonable.

In most cases you would ask for a rough estimate of timing, a day, three days, a week - give me some idea!?

So here’s the crux, saying ‘reasonable’ in most cases is not a reasonable answer to the question ‘how long will this take’.

If you wouldn’t as a consumer accept your car being fixed in a non-defined reasonable amount of time then why would you expect your business to be adopting it?

Although it may seem like it I don’t completely disagree with the use of the term but would suggest where possible you try to be clear about it. 

For example if you have a computer system that is outdated and still requires support - not an unusual situation especially if you have an application that would cost thousands to re-develop on a newer platform - your support provider may come back and tell you that the system is so outdated they may have to source parts from eBay.

This actually means it could be anything from one week to never actually sourcing the part. Now you can document and agree ‘reasonable endeavours’ but with a joint understand of what ‘reasonable’ actually is. Off the back of this a simple risk assessment with considered input from provider and client will help to comprehend the risk, its probability, any impact and mitigation.

The great thing here is expectations have been set. The provider has given details and the client can review this information and better decide the way forward. Assuming that any immediate mitigation is not possible then when the proverbial does hit the fan the client has an idea on how long it will take, expectations are pre-set and impacts fully understood.

So remember to always use the term ‘reasonable’ with a reasonable amount of respect and wherever possible find a better route or define your terms.