Saturday, August 18, 2007


One of the most challenging situations you will encounter as a new IT Managed Service Provider will be figuring out how to address your clients who are pushing the limits of the defined level of service you are obligated or willing to provide. I have written extensively about the level of service provided to your clients by using a tight SLA, but what isn't addressed is the ways you go about enforcing the clauses in your SLA when they are being conveniently ignored, without leaving a bad taste in your clients mouth.

It would seem that none of these operational details are included when engaging a consultant or in discussions with your "trusted advisor" or MSP Platform Vendor. The answer as to why this is not addresses properly, is most likely due to the fact the very few of the folks engaged in these discussions have any experience in running a small business, never mind a successful MSP. They talk a good game but when asked these types of 'real guidance needed" questions, the answers they provide fall way short of the mark. Another question in the same realm can include "What do I do to compensate my engineers who will lose most of their on-site revenue?". I have never received anything but lip service on that one.

Scenario:. Human nature for what it is often forces many people to have selective memory with regards to inconvenient truths. There is no better example of this when dealing with the expectations of an MSP customer where so many difficult-to- comprehend details are relevant. Most of these expectations are unintentional, and are caused by external pressures from bosses or co-workers and veiled in "favor" terms. But some are just plain manipulative.

In June this year we had a typical 6 week sale cycle will a real estate company considering our "localsourcing" option in choosing a new IT provider for their networks and systems. We had numerous discussions and provided them when in-depth documentation of what we will provide. This included marketing materials and an incredibly detailed SLA (an example is available for download here) with a detailed "in plain English section" to summarize. One important criteria in the SLA is that no phone calls to our Engineering staff are allowed even during coverage hours and all correspondence was to to be done using our easy-to-use ticketing system or by email. Another requirement was a drop dead date of 45 days as to when their network infrastructure was to be ungraded due to it's marginal state. They read and accepted the SLA and contract and each time we followed up they were happy with the service. After 45 days we started bugging them about bringing in the SonicWall TZ and migrating them to a more robust configuration. The response was we can't do that now and maybe in September/October. Effectively, we're being told to fuck off and stop harassing them.

Suddenly, after using our ticketing system for two months, we started receiving calls directly to our staff for minor and major issues which did not include the only exception to this clause, a full network outage. Our Engineering staff are not equipped to push back on these calls, for a good reason. We chose not to provide them with this option because they may not be equipped with all the details necessary to argue the point and it could cause an issue with the customer. It is my job as the Jefe to make such calls and they can be difficult and sensitive. So based on the response to the network issue, I chose to let it ride - Mistake #1 and #2.

The next day I received a call from the person in charge to say she was very upset about the delay in response to the network problem which in hindsight (so she was told by the Network provider) she determined was caused by a Spambot or a virus flooding their network. Why had we not seen this, she asked?

We had received the message the day before and had called her back two hours later, well inside of our required response times. So based on the assumption that no AV notifications had been logged, we asked her to check her T1 provider first for potential causes of the slowdown. BTW our response to a ticket would have been much faster! We never heard back from her but after an on-site visit it ended up being caused by a faulty network card and not a virus. So with an unmanaged marginal router in place with no Intrusion Prevention or SMTP filtering we had no way of picking this issue up anyway. Mistake #3 (we should have forced an upgrade in the beginning) We were now being held accountable for a shitty network we never put in, and a "slow response" to her needs which was well without the required response under the SLA which she signed.

Frustrating to say the least, but calling her up and telling her to Read Her Motherfucking SLA (RYMSLA) is not the best way to deal with this situation, although it is something you desperately want to do under the circumstances. Is the customer always right? Hell no! And are you equipped to call them on it? Hell No! In the following posts I'll give you a few pointers about some way to deal with this, now that I've had time to think about it.