Can you trust your service provider?

Can you trust your service provider?

Summary: On-demand providers face an uphill battle in convincing customers to trust them. This suggested five-point code of practice may help.

TOPICS: Outage

How do you know that your service provider is actually delivering the 99.9% (or whatever) of uptime that you have been promised in the service contract? This is the question posed by Talkback contributor jmjames in response to my posting last week about service level commitments. He makes a number of excellent points, and this is the crux of his argument:

"Do you honestly think that a TPV [third party vendor] is going to accurately report to you their downtime or SLA misses? No way! I should know, I worked for quite a while for a major TPV in managed services, and I got to see first hand the lies that the customer was fed."

He's absolutely right to raise this, because it's an issue This kind of duplicity and deception has been rifethat on-demand providers have got to face up to. This kind of duplicity and deception has been rife among conventional managed service providers, with the result that the new generation of on-demand providers face an uphill battle in convincing customers that they're any different. Maybe some of them aren't, which makes the task even more difficult for those who are determined to act with integrity and transparency.

But if providers get this wrong — if they allow themselves to take the kind of short cuts with customer trust that jmjames describes — then they will consign their entire industry to the status of also-rans. The only way that providers can earn the lasting trust of customers is by dealing honestly and openly with them at all times — which can only happen if the provider instills a culture of integrity and plain dealing throughout its organization.

How do you achieve that? Here is my suggested five-point code of practice for on-demand providers. Customers should carefully evaluate how well their provider measures up to this list. If the provider falls short in any respect, then customers must ask why not, and if the answer they get back doesn't satisfy them, they must seriously consider whether they really can trust their provider.

  • Say exactly what the contract does and doesn't deliver.
    Customers have a right to know what service levels they're signing up for — and providers, who know a lot more about what can go wrong than prospective customers, have a duty to spell out what's not included.
  • Spell out what to do if something does go wrong.
    If the service is suddenly inaccessible, it helps a lot to know there's another website users can go to for news, or that they'll receive an email within the hour telling them what's going on, or that the helpdesk is guaranteed to answer their phone call in less than five minutes — provided, of course, those procedures are robust enough to still work when all hell breaks loose at the provider's support center!
  • Report live service level metrics.
    All customers should be able to view the same dashboard for their services that the provider's own operations staff get to see. If no such dashboard exists, then isn't it high time the provider put one in? This is crucial to providing the accountability that jmjames so rightly argues for.
  • Let customers download their data whenever they like.
    On-demand providers should go out of their way to make it as easy as possible for customers to move their data elsewhere (configuration data too, if applicable). Nothing else a provider can do offers a better expression of confidence in customer loyalty — except the next and final point.
  • Accept 30 days' notice of termination at any time, no questions asked.
    Even though larger customers prefer to negotiate two-year contracts, there's still no reason to lock customers in for more than a month. As jmjames says, "With an in-house IT department, consistent failure equals (or should equal) termination of employment." Why should it be any different for on-demand providers? 

Customers can forgive imperfect performance, says jmjames, provided they get proper accountability. That's why they prefer in-house services, with all their imperfections, to third-party providers. The code of practice I've outlined above may seem extreme or idealistic, but it's necessary because on-demand providers have to go to extraordinary lengths to build equivalent customer confidence and trust.

Topic: Outage

Phil Wainewright

About Phil Wainewright

Since 1998, Phil Wainewright has been a thought leader in cloud computing as a blogger, analyst and consultant.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Speaking from Experience

    With 5+ years working in On Demand Services and most recently contract negotations, I think you're 5 points are good. Bottom line is your pro or you aren't. If you're an ASP that read to many blogs and thought wow, I'll publish a Windows Small Biz Server and become an ASP, then you are in for a tough road.

    Whether customer or vendor, the 5 points should already be covered in your SLA. If you don't have an SLA with valid metrics, then the solution in question should not even be grouped in with reputable on-demand providers.

    It's pretty easy to tell who's who. Go ask their customers. All the language in the world is for naught the day you can't get to your data. The best measure is customers. They don't lie. And if there are no customers yet, then you might want to head the other direction.
  • I'd add another

    Given the kinds of outtage we've recently seen repeatedly at Six Apart, how about committing the skills to providing an appropriate level of service and not fall foul of Scalability 101 issues?
  • Excellent article! But (as always), I have a few points of my own...

    Mr. Wainewright describes in his article the basic skeleton of the only type of thid party vendor (TPV) contract that I would ever sign. As Mr. Wainewright rightfully points out: "This kind of duplicity and deception has been rife among conventional managed service providers, with the result that the new generation of on-demand providers face an uphill battle in convincing customers that they're any different." My experiences with TPVs, both as an employee and as a customer have been so consistently negative, that I am turned off to the field as a whole. It doesn't matter that I was burning customers in a TPV NOC, and now I am evaluating SaaS providers; I am quite afraid of the "shortcuts" that TPV providers tend to take.

    To evaluate Mr. Wainewright's five points to accountability on a step-by-step basis:

    "Say exactly what the contract does and doesn't deliver."

    I think this is reasonable. My experience in the industry is that even a TPV with the best intentions initially will end up being forced to choose between losing money, making a customer mad by saying "no", or taking shortcuts unless the contract is extremely clear. Not only does the contract itself need to be clear, but the personell in both organizations need to be well educated with precisely what that means, from the people who signed the contract, to the people who interface with the partnership on a daily basis. Otherwise, the customer begins to expect (or demand) what they thought the contract delivers. TPVs aren't wholly to blame, many customers are either very naive, or have intentions to low-ball the vendor when signing a contract. For example, when I was handling tech dispatches, there was a customer of ours that insisted that since the contract did not state that our technician had to install the parts himself, they were entitled to have our technician simply drop off a fresh part on demand, essentially using our techs as highly paid couriers (it cost us about $150/hour to have a tech on a call). Since the tech wasn't doing the installation, it was often difficult for us to get the part back, if at all, and we would never get credit from the manufacturer, forcing us to eat the cost of the part. We often suspected that the customer would do this deliberately, and that these parts-only calls were not replacing dead parts, but actually a trick to get us to give them extra parts. The end result? We had to find "creative" ways to make that contract profitable, it was too important in terms of revenue and prestige to lose. Thus, we took underhanded shortcuts.

    I really like this item, because it is in the TPV's best interest to have a clear contract, because without it, they will not be able to make a bid that is fair to both sides. Sadly, this is likely a pipe dream, as customers so rarely know what they really need and want, until they get what they asked for. That's why so many contracts have an initial pilot phase before they get finalised. Even then, a frequent course that these things follow is that during the pilot, the customer suddenly wants a lot more, and then the vendor is forced to raise their bid by a large amount, and the customer has to decide between being very unhappy, or restarting the bidding process.

    "Spell out what to do if something does go wrong."

    I have to agree 100% with this one as well. More to the point, it is relatively simple and inexpensive for either side to implement, particularly if it takes the form of an online update system.

    Unfortunately, anything that involves mass amounts of human interaction, such as having telephone contact (inbound or outbound) for more than a small number of customers (maybe premier customers with a premium SLA) is unrealistic. The whole point of outsourcing your business process to a TPV is that they are specialised and will have much less downtime. Can a TPV save you money when they have a whole call center staffed, sitting around twiddling their thumbs waiting for one or two major outtages per year? That's a call center that needs to be ready to suddenly be taking calls from hundreds, if not thousands (or tens of thousands!) of customers simultaneously when something goes wrong. But the rest of the time they are only handling a small amount of silly little calls or traditional help desk type calls. The only work around is to simply not guarantee any type of ASA (average speed of answer).

    "Report live service level metrics."

    Sadly, this is nearly impossible. It's significantly easier with a SaaS system, since that could be 100% automagically monitored. It's just that building in all of those monitoring hooks into the software, then writing a monitoring system, then writing a reporting system is a monstrously difficult task. Basically, you'd need the application to either do incredibly in-depth event logging, or trigger SNMP traps, then use something like HP OpenView or SMARTS to unify not just the SNMP messages from the application itself, but from the servers, the back-end apps like Oracle, and the hardware like routers/switches. Then you would need to tie that all into a reporting tool (while we're at it, let's auto generate trouble tickets as well, and give them to the customer to let them know that we're on the case before they call, and to reduce the time needed for them to open a ticket in the first place) that the customer can view. This is a multi-million dollar system I just described that involes months, if not a year (or more) of custom coding to make it happen. My previous TPV vendor attempted this, and for the most part it was horribly kludged together, and its failure for it to work properly or even reliably aggravated the employees and the customers more than the actual problem itself.

    Even if we take all of this into account, who's to say that the TPV is actually accurately reporting these metrics? It wouldn't be too hard to throw together a quickie web app that knows the SLA and reports metrics that meet it unless there's a problem that the customer cannot help but notice. It's altogether to easy to blame a slow system response on "gee, there must be some network latency between my end and yours" when the reality is "a UPS failure just took out two-thirds of our database servers, and the backup servers are currently at 200% capacity."

    "Let customers download their data whenever they like."

    This is all too unlikely, and even if it were likely, there isn't too much that a customer couple probably do with it. One suggestion, made by Mr. Berlind (, is that TPVs/SaaS providers should use open standards for data storage. In my response (, I agreed that while open standards are nice and helpful, it won't do you much good unless a significant portion of the companies selling that particular service are all able to import that format. Note that there is one TPV that lets you do this: web hosts. As a result of this very feature, it is extremely easy to move from host-to-host. Sadly, most hosts are still pretty crummy. Cell phone companies are getting better about it too, thanks to number portability, but again, all cell providers are about equally lousy, so it doesn't matter who you use.

    "Accept 30 days' notice of termination at any time, no questions asked."

    Again, I agree with you 100% on this. I like the way my current ISP handles this. I may leave with no fee at any time without notice. The period of the contract merely guarantees me a certain rate. When the contract is up, they may change the rates, but not before. When the vendor knows that I can walk at any time, my satisfaction is important to them on Day 10 of the contract as it is on Day 1, and Day 100. Without this type of guarantee, the vendor only needs to make you happy at the beginning during the pilot phase, and near the end of the contract. As I outlined some time ago (, TPVs love to play games with those long contracts to keep your business while cutting corners. The best remedy to this is exactly what Mr. Wainewright suggests, which keeps the TPV honest all of the time, not just during contract negotiation time.

    At the end of the day, I continue to beleive (quoting myself from

    "I don't trust a third party to manage my network. I don't trust a third party to store my data. I don't trust a third party to maintain anything. Third parties will lie cheat and steal the moment you turn your back. They talk about how they have all of this experience and this and that, but at the end of the day I guarantee that you are being lied to. Their "Cisco certified network engineers" are high school grads halfway through junior college making $15 an hour. Their "MCSE"'s list "Geek Squad" as their most recent resume experience (no dis to Geek Sqaud, but re-installing XP 10 times a day is a heck of a lot less intense than what MCSE's supposedly do). Their "Unix gurus" are a couple of crusty old-timers who used SunOS 2.6 back in 1995. The third-party vendor is ALWAYS a black box, where you don't know what's happening inside of it. All you know is that you put your dollars in and (hopefully) get service back. If there's a foulup there is no accountability. You rely upon them to proactively maintain and prevent problems. When you ask them if they are being "proactive", they always say they are. At worst, they are lying to you, they screw up and go under, and you lose everything. At best, you end up saving some bucks and some headaches, but get to stay awake each night wondering what is really happening with your data."

    But what Mr. Wainewright outlines is transparency, accountability, and truly useful penalities (such as the customer cancelling the contract) as opposed to the traditional SLA penalties (a small refund or discount of the customer can definitely prove that SLA was missed) that keeps the TPV honest, despite their worst intentions. Mr. Wainewright states "The code of practice I've outlined above may seem extreme or idealistic, but it's necessary because on-demand providers have to go to extraordinary lengths to build equivalent customer confidence and trust." I do not think that his suggestions are "extreme" or "idealistic". I think that they are "needed" and "ideal". If more TPVs lived by this code of conduct, and instead of simply writing it into their mission statement or "shared values" or whatever, but baked it right into their contracts, I would feel differently about TPVs. Because even if I get a whiff of a bad feeling about them, I can leave immediately.

    The only thing that I think Mr. Wainewrights suggestion lacks, is a business environment in which the TPVs get motivated to follow it. In the free market environment, it is very easy to take a personal or company profit at the industry's loss, just like it is hard for someone to give up their polluting SUV when everyone else has one too. As Mr. Wainewright so correctly points out, "But if providers get this wrong ? if they allow themselves to take the kind of short cuts with customer trust that jmjames describes ? then they will consign their entire industry to the status of also-rans." That is important. Not just their company, but the ENTIRE INDUSTRY. Even if a few companies sign on to these ideas, if the entire industry doesn't get on board, or at least a critical mass of it doesn't, the whole industry will fall.

    What I propose to help with this, are the following:

    * SaaS providers need to group themselves by function (all the CRM folks here, all of the office suite guys there, etc.) and decide on a common format that all of them will import/export too. It doesn't even have to be open, but they need to make it easy to switch providers. Cell phone providers do this, in that it is pretty irrelevant to how you use the system which provider you use. You may need to get a different phone, but outside of that, transitioning is easy, even without number portability.

    * Each market has to have enough competition to make switching potentially beneicial. Again, to compare to the cell phone market, a few years ago I could credibly threaten my provider with a switch to another provider. Now that the market has consolidated so much, it only takes a few switches to have been with every provider out there, making the threat of leaving less important. As the consumer's choices between providers become limited, the quicker the providers trend towards a common level of mediocrity, knowing that you won't leave because it won't be any better with any of their competitors.

    * The service needs to be enough of a commodity that transferring between vendors is relatively painless to the customer, but not so commoditized that there is little difference between vendors. Again, cell phones. Now that most providers have the basics (getting decent coverage around most areas) down pat, there isn't enough of a difference between providers, other than pricing, to make a switch sorthwhile. As a result, providers stopped bombarding us with incentives to renew our contracts, and stopped working hard to keep our business, knowing that the customers knows that the experience will be the same with anyone else. On the other hand, it needs to be enough of a commodity that it is actually possible to switch providers. Vendor lock in is an easy trap to fall into, where it be the Black Iron Prison type via contract, or the Golden Chains kind where even though you hate the vendor, no one else offers nearly the same level of features. Gyms hit you with rediculous contracts (Black Iron Prison). Windows gets you with NTFS (Golden Chains); Windows XP loses large amount of security and functionality on a FAT partition, yet no other OS can write to NTFS because Microsoft doesn't like to liscense the format out to many companies.

    Overall, I really like what Mr. Wainewright has to say in this piece. I just hope that the business environment is such that we will see enough vendors doing things this way to save the industry before too many people become as cynical about it as I am.

    Justin James
  • Service levels - what really matters

    This may be somewhat off-topic but I wonder if at the end of the day the simplest way to make managed services agreements meaningful would be to give customers an independent way to track in real-time application availability, and automate, giving customers direct access, the processes described in the proposed five-point code of conduct.

    I am not suggesting that this would replace the proposed five-point code of conduct. It would complement it, and would help managed services providers actually deliver on what they promise.