Thursday, December 2, 2010

Service Level Agony

I've always approached information systems Service Level Agreements (SLAs) with caution. In theory, if we provide great service that a customer loves, then why would we need a contract?  If we don't provide great service then we shouldn't provide that service.  Simple black and white choice, right?  Unfortunately, reality introduces some shades of gray.  What happens if customer expectations of great service are not aligned with our perception of great service?  Or, what happens, when staff change on both sides?  They bring new attitudes to the relationship.

The real value of a service level agreement forces both parties to come to consensus about what we both define as great service.  As people change over time, this definition remains constant because of the agreement. Attitudes may change but the contract ensures consistency.  It allows both sides to plan for the future with some certainty.

But what happens when motivations for entering into the agreement are skewed?  For example, getting consensus when one or both parties have ulterior motives can certainly be difficult.  Do you voluntarily sign a deal you don't believe in, for the sake of maintaining organizational harmony?  Or, what happens when you don't have the necessary resources to provide a mandatory service?  Finally, does the customer realize they have as many obligations in a well written SLA as you do?

I don't have good answers to any of these questions.  However, I do have one simple success measure.  The best service level agreements are the ones that are never used.  A good relationship transcends any contractual obligation.

~

2 comments:

  1. The final sentence says it all.

    Corey S.

    ReplyDelete
  2. In my days with Abebooks/Amazon, all signed agreements had very specific SLA's, and they were managed to ensure we had quick "outs" in case we found better prices or vendors. Much more a legal tool than management tool. Seems, in restrospect, probably not the most effective use of SLA's.

    ReplyDelete