One of the oft-neglected areas of an ICT contract is the list of suggested customer obligations provided by a prospective service provider.

Items on this list can be mundane, loose and, as I discovered this week, downright cheeky.

In any services-based arrangement the service provider will have dependencies upon the customer — apart from prompt payment, of course — in order to enable service provision.

That’s the role of a customer responsibilities list: to set out what the customer needs to do and to provide a reference point for who’s to blame if the customer, by failing to do what’s on that list, causes the service provider to fail.

The customer responsibilities area is often the weak link in the chain.

If the service provider doesn’t set out this list in enough detail, the customer doesn’t know what it’s supposed to do. Equally, many customers are guilty of not knowing or caring what’s on this list, adding significant risk to their own projects.

But there’s also a temptation for service providers to use the customer responsibilities list as a back door way of providing insurance if something goes wrong by creating a loophole which enables it to blame the customer for failing to comply.

At the very least, customer responsibilities should be made as specific as possible.

I’m used to turning requests such as “Customer shall provide all necessary support and facilities” into specific commitments for which the customer can actually plan.

This week I found possibly the largest loophole I’ve ever seen put forward by a service provider.

On top of a payment specifically to conduct acceptance testing, it wanted a customer to commit to “Identify all errors in its deliverables that are reasonably discoverable” and “Identify all elements of any work products that are not fit for purpose”.

The problem here is that the customer is being asked to underwrite acceptance, and the service provider is using the customer responsibilities list as a way to pass the buck for non-compliant developed software back to the customer.

The suggested customer responsibilities would cause a real fight about whether a latent defect in the software is a service provider breach or something that could have reasonably been picked up, and therefore a defect caused by customer failure.

If service providers are holding themselves out as the expert suppliers, it should be part of their quality control procedures to pick up obvious or reasonably discoverable errors. Customers should not be expected to do their job for them.

Alistair Maughan is a partner at law firm Morrison & Foerster