Other day, I chanced upon a presentation put together on Conference Operations – an outsourced service offering to educational institutions for organizing conferences under their auspices. It includes, besides some rudiments of a business model, a comprehensive menu of services and even SLA’s for these services!
In the dark age of pre-SLA days, it had never been easy handling those real or imagined perceptions, often-not-clearly-understood expectations and not-easy-to-please personalities; it was like fighting shadows and you were always ‘had’ try what you might. Assessment of the services provided were often incident based.
Now, it is a far-cry from those days. SLA’s are popping up everywhere as the common currency in the business of providing and consuming services. The terminologies, service definitions, measures of performance, achievement levels all are consensually coded into the SLA’s and the services rendered are looked at thru the glass of SLA’s. This is just as well as economies world over are increasingly services based – it’s the Golden Age of services.
While these SLA’s have brought sunshine for service providers, there is a cloud or two that the SLA acolytes must fear. It is not uncommon to find the service provider performing quite well, going by the SLA’s and the users at the same time are ‘crabby’ as ever. Very recently I came across a stranger case wherein the service provider came out with glowing feedback in a user survey while the managers in user organization were equivocal!
What’s happening here?
Possible reasons for this ‘contradiction’ could be many:
– Very often, the few incidents of unsatisfactory performances get drowned in the averaged SLA performance and are not viewed by the service provider with the same seriousness as the affected users. And the bad news billowing out of these few incidents hang in the air for long after the incidents.
– In some cases, the computation of the performance is downright faulty or misleading. For instance, computing the availability or ‘uptime’ of a resource gets inflated if the idle night shifts or weekends are not factored out; the real problems if any escape attention until they build up to create an explosive situation.
– Below-par performance in one set of services is also seen to adversely affect the users’ perceptions of a second set of services.
– When SLA’s abound, it is easy to miss out alignment with key business expectations, not to speak of effort for computing the performance. Users’ disaffection is not a surprising outcome when one goes overboard on SLA’s. In one case just the mail service alone had tens of fine-grained metrics!
– More difficult to spot, especially in a multi-year contract, is when: a) the users don’t see the service provider raising the bar for himself with tougher SLA’s b) the users do not get a fair share of the productivity gains worked up by the service provider over the years or c) no new additional services are introduced or current services are not significantly enhanced. Users feel shortchanged and this gets manifested in unpredictable ways. This is the time to review the SLA’s, the services or even the contract.
– Above all, relationship with the users is the most important influencer in determining their disposition towards the service provider. SLA’s do not obviate the need to maintain good relations with the users.
With some imagination it is possible to forge SLA’s and relationship together into a magic key to achieving high levels of user satisfaction. Example: Select every month top 5 users who were most impacted by below-par services (measured by performance metrics). Make personal calls to them to honestly understand reasons for such performance. Make necessary course corrections and follow up with them in the next month to see if they did get improved service. Improved service delivery process is the win for the service provider while the users win better services. The trick is to find more reasons to reach out to more users, all driven by performance metrics.
How do we set ambitious SLA‘s for business enablement is saved for another day.