A key part of any contract negotiations is nailing down the Service Level Agreement's (sea's). Yet most buyers of analytics tools, Marketers now, in my experience don't pay too much attention to this important element.
You are going to shell out a hundred thousand dollars for a base configuration of the web analytics tool, and you'll have to pile on a bunch more rupees / pounds / pesos / dinars if you want to warehouse and intelligence add-ons and so on and so forth.
What you buy has a implication on the contract amount, but what you might not quite be aware of is that the SLA's you require / demand will inflate the yearly contract by substantial amounts (and to some extent that is not the Vendor's "fault", they price certain standard components / SLA's into their base pricing and anything you want beyond that obviously costs them more to provide).
It is critical that you as purchasers of the tool think through what you need and then ensure that during contract negotiations you ask for what you need (and price it out).
Don't have a handy check list of things to think about? For the second time in a four months friend of the blog Steve Medcraft to the rescue.
What follows is a list that Steve created for vendor negotiations after running his own pilot process with two top vendors. I think he did a fantastic job in covering pretty much everything anyone could possibly as for.
It is likely that you won't ask for all this but I believe that you'll find this list handy as you great ready for your own contract negotiations…..
Web Analytics Vendor Service Level Agreements Checklist:
* Availability and Response of software/functionality
+ Standard availability / guaranteed up time
+ Speed of service – e.g. screens to be returned in x seconds (probably tricky to enforce as depends on bandwidth)+ Response of service in relation to unexpected increase to load/traffic volume, load distribution etc
+ Permitted downtime (emergencies etc.)
+ Compensation for downtime – service credits, reduced contract period etc. for x mins of downtime per month (outside of planned or emergency maintenance etc)
* Availability of reports/data
+ Collected data to be reflected in reports within x hours
+ Availability of results after initiating query* Technical / Best Practice Support
+ Vendor resources available / dedicated to us (no of account managers, technical, consultants etc. assigned/dedicated to project)
+ Response to customization/change requests (quotation, delivery of service etc)+ Response to traffic volume increase
+ Issue escalation procedures – (on-line, phone, email, priority levels, status reporting and response times)
+ Supporting material – availability of on-line help, accuracy of documentation, live support
* Security
+ Physical hosted environment, protection of data/servers
+ User access to the system, data+ Back-up, archiving and recovery
+ Monitoring in place and availability of that data
* Communication
+ Agreed points of contact (on either side)
+ Timings of notifications (planned maintenance/outage, status reports etc.)
Here is my recommendation of follow on tasks for you:
- It is likely that you don't care about all of the above, pick what you need.
- For each item you pick above identify the threshold (in terms of downtime or amount of best practice sharing hours or how quickly you want data or amount of email support you need etc).
- I highly recommend you identify a range for the threshold and not a absolute number, give your wiggle room. Share with your contract negotiators.
- Be explicit with the Vendor (it is the least you can do for them) and ask them to explicit you back. :)
- Get stuff written down, it would make a nice addendum to the standard contract the web metrics vendor will send to you.
- When deciding which tool to pick remember to judge based on features you want, size of the contract (total size of the contract), and, lots of people do this wrong, the amount of value you can provide your company from each.
Sometimes you might not pick the most feature rich vendor because you can't imagine that you can provide $1.2 million dollars of value back to your company (with that being the total size of the contract – tool + support + sla's).You might go with the one that is $.05 million dollars even if it does not have that one niche feature you need.
The toughest thing you'll do is pick a web analytics vendor, and like the spouse you might pick in real life divorce is hard.
Besides if you are the one choosing a paid vendor with contracts then it might be hard for you to change your mind (easier for your successor though) and even then you are locked in for a year or two. Be patient and cover all your bases.
Here's a post from a while back (first time Steve helped us out) that I highly recommend:
I want to once again thank Steve profusely for sharing this hard work with us, I am confident we will all benefit from his generosity.
Ok now its your turn!
Please share your perspectives, critique, additions, subtractions, bouquets and brickbats via comments. Thank you.
[Like this post? For more posts like this please click here.]
Via 
First and foremost regarding SLA's. Be honest, brutally honest: As a client, are you prepared & *capable* of taking your supplier to court when they fail to meet their SLA's?
If you aren't? You're wasting time and money all round by even bothering to have them. They become a pretty document that everyone (un)happily ignores.
Personally I detest SLA's. IMNSHO they set a MAXimum standard, not a minimum. The buyer should always treat the SLA as the maximum service you'll get.
The other nasty trap is "outages". Two types of trick here:
1. They start from when you report them, not from when they start. This weaselling is way more common than people realise.
2. "Scheduled Outages" aren't counted in uptime numbers. And if you do the worst case math, many providers can quite legitimately take you off the air for *weeks* over the course of a year.
Oh yes. 99% uptime is ~ 3 days downtime. DO the math! Image how devastating 3 days downtime from Mon->Wed inclusive could be!
And watch out for *when* they do scheduled work. 8pm might just be the peak period on the other side of the country.
Just a quick 2c on the Joys of SLA's… :-)
Cheers!
– Steve
Steve : It is not about filing a law suit (though I have never seen anyone file one based on missed SLA's).
It is about:
* Forcing you to think through what your expectations might be and then having a formal checklist to go through those with your Vendor.
An amazing amount of time Clients feel that that level of support and love they will get after the contract will be exactly the same as during the Pilot. :)
* SLA's are great at comparing differences between Web Analytics Vendors. Some give you more, some give you less. Would you not want to know?
* SLA's as detailed as the one Steve shared will also bring out the best in vendors (not!). That should help illuminate all elements of a Vendor's personality, which is precious in of itself.
I want to stress that you should think and carefully deliberate what you want in terms of SLA's, remember it will cost you.
Net net I think of SLA's as having the same impact as discussion of a prenuptial agreement before you hitch up with your spouse.
It seems like a yucky conversation to have, but 50% of the time (approx divorce rate in the US) you'll be glad you did.
-Avinash.
It is almost spooky that you write about exactly what I need! This is the third time.
We are in the middle of vendors evaluations, we have two tools on our site right now to replace Visual Sciences, and this list is very timely. Exactly what I needed.
Thank you.
Oh no disagreement. :-)
I suspect it's more semantic (again :-) ). In that over here, SLA's are a formal part of the contract. Appendix A usually.
You appear to be implying that over your side of the pond, they're more of an informal "promise"???
We aim for XYZ based on our current performance data style of thing???
If so? Then that very definitely changes the expectations, and hence response, when not met.
Cheers!
– Steve
Hi Avinash.
I am sitting in Paris, waiting for my flight to Washington – going to Emetrics like you.
(…reading my usual Blogs to kill some time AND get wiser and the same time).
I think you are spot on. However a few comments from a vendor.
When we talk about “Availability” we always separate:
– Data Collection
– Reporting Interface
As we provide (for obvious reasons) a much “higher” SLA on Data Collection (99.9%) and a little less on Reporting (99%).
Furthermore “Security” tends NOT to be part of the SLA (and if you ask me, it shouldn’t be) – we of course have a grand 15 page security document which describe how we plan to deliver SLA’s as the above, but it is more marketing/communication than promise.
The SLA is contractual and I have to PAY UP if I do not deliver; which of course neeeever happens ;-)
I think I will post out full SLA on my blog later – so people can check it out and start to compare it to your post and other vendor SLA’s
I will post a link here later.
Cheers
dennis
Dennis R. Mortensen, COO at IndexTools
My Web Analytics and Online Marketing Blog
Dennis:
Furthermore “Security” tends NOT to be part of the SLA (and if you ask me, it shouldn’t be)
No, No & … urm … No. :-)
This is an all too common misunderstanding of what Security actually IS.
Security most emphatically is part of the SLA. In fact, I'd go so far as to suggest that security is more tightly entwined through your SLA than you realise. :-)
Most people think of Security as but 1 thing: keeping secrets. ie Confidentiality. Which it is. But alas, the story does not stop there.
Supposing I broke into Avinash's blog, and started changing subtle but important parts of older postings and comments. Is that not a security problem too? ie Integrity.
Again, suppose I do some subtle changes in the config or otherwise that totally breaks Avinash's site. Such that it goes off the air for several hours at a time. Is that not a security problem too? ie Availability.
Put it differently, I can have a highly secured system that no one can use. At that point, it's useless. Systems need to be used and any use introduces vectors for attack/misuse and hence risk.
Just remember CIA, Confidentiality, Integrity and Availability. Those are the three pillars of all Security. ALL Security.
HTH? & Cheers!
– Steve
Blown away by the $1.2 mil aside:
$1.2 mil for a year for analytics? Wide-eyed gulp!!
Musing:
If you spent $1.2 mil in analytics, you'll need to raise site sales apx three-fold that just to break even (depends on your margins and costs, of course). That's not counting the personnel to use the system, which brings us to…
People. Citing (hopefully not mis-citing) Avinash's 90:10 rule, that $1.2 mil in software translates into $10mil in analyst payroll… that's over 100 staffers running the system ?!?
Zounds!
Alan
You've all missed the most important point: You need the right to terminate the contract and receive a pro-rata refund if service turns out to be terrible.
As a practical matter, there is no way to force the vendor to do what its salesman promised. If you litigation, the most you can get is reimbursement of damages caused by the vendor's breach contract. And you don't want to be stuck in a contract with a vendor you are suing.
Indeed, are you aware that SLA credits were invented by telephone companies as a way of capping their damages for terrible service? Per a typical SLA, the most you can get in credits per month is 25% of base fees–even if the service is out for the entire month.