The Unique Challenges of CMS Support, Part II

By Deane Barker • Posted on August 22, 2012

Some time ago, I wrote a post optimistically called The Unique Challenges of CMS Support, Part I. In it, I explained that content management usually requires integration, so when there’s a problem, it’s sometimes difficult to figure out if it’s a problem with the product or the implementation.

I ended that post with:

Coming in Part II – how all support issues are not created equally and why this matters.

A year later, here we are.

I’m going to explain that there are four major types of services when describing “support,” and sometimes it’s tough to figure out what type a certain request belongs to, and how that request is paid for.

If you have or support a CMS (any software really – but my experience is with CMS), here are the four major support requests you get:

So, which of these is covered by a standard CMS purchase? This obviously depends on the vendor, but here are the general trends and things to think about –

Clearly downtime support should be covered initially, though it’s often not a vendor problem. Acute downtime is usually always caused by server or network issues, so the person you call at the vendor is really just going to verify their software is not the problem and tell you to call your system administrator. (And this is why people want SaaS CMS, so they have one neck to choke…)

Another question you have to answer: does the vendor have 24/7 support? In my experience, most do not. If they do, it’s an extra agreement that is prohibitively expensive. As I mentioned, acute downtime is usually not a CMS vendor problem, so in off hours, these questions will end up with your system administrator or hosting company, who usually always have 24/7 coverage.

Error support would definitely be covered. If the user cannot get past an error, they really have no choice but to get you on the phone. In the case of an error within the CMS, it’s tough to say that’s anyone’s fault but the vendor’s. If the error was due to a condition the user introduced, then it should have been caught and explained in the UI.

User support is a toss-up. A lot of the problems here should be covered by documentation, and in many instances, users haven’t bothered to look and are just calling to avoid finding the answer. This is usually covered too, but I have heard of vendors tracking this to curb against abuse, or giving a specific number of instances to avoid having customers on the phone all the time. (I also have no doubt that hold times “due to an unusual volume of calls” are designed to make calling less attractive.)

User support is also something well-handled with a good support community. Vendors, if you give you customers a good discussion system, they will use it and you’ll be better off for it.

In the end, consulting support is the tricky one and where a lot of problems and misunderstandings come up.

This particularly happens at the beginning of an implementation which the client is doing themselves (or which an inexperienced integrator is attempting), because this is when the big architectural problems need to get solved, and when the user just doesn’t have The Big Picture™ yet. They haven’t figured out the software from the 50,000-foot view, so they don’t know how all the pieces fit together.

Consulting support should always be paid support. A vendor may toss in some “professional services hours” with the purchase, but to provide this for free is to need to have some very expensive people on-call to plan customer implementations, which is a money-loser in the end. Implementations cost money, and the large architectural questions are often where that money goes. Answers to these questions don’t come free.

What makes this very hard is that because user support can segue into consulting support very easily. Drawing the line between the two is tricky.

For example, say a customer calls up and says, “I can’t add a description to a link in a menu. How do I do that?” Sounds like simple user support. However, the vendor is mystified by what the customer is attempting to do. The customer is trying to explain it, but it’s just not getting any clearer.

So, to try and get at the source of the problem, the vendor asks the customer to explain their end goal – what are they trying to accomplish? With this explanation, everything suddenly becomes crystal clear to the vendor, but it turns out that the customer isn’t even close to the right solution. In fact, they’re never going to be able to do what they want, or a more optimal solution is down a completely different path. Worse, the correct path would require backing up and re-architecting a lot of the implementation at a base level.

What does the vendor do here? Do they explain to the customer the right way to do it? If so, at what point do they cross the line from user support into consulting support? At what point does the vendor have a right to cut the customer off and tell them they need to book a slot with the professional services group? If the customer refuses to pay for that, does the vendor simply tell them that there’s a better solution out there, and to keep looking?

Worse: at what point can the vendor say, “Look, you have no idea what you’re doing. You should have worked with an experienced integrator on this project.”

There are few cut-and-dried answers here. Different vendors will handle it differently, and I have no doubt that your ability to get answers at least partially depends on subjective factors like how much you spent on your license, what contacts you made during the sales process, and how important your implementation is to the vendor in terms of future references.

(And of course, all of this responsibility is also split between vendor and integrator. The vendor may shrug off error and user support by referring you to your integrator. See Part I of this post for more on that.)

The best you can do is ask each vendor about these four types of support before you guy. In fact, send them to this blog post, and ask them, “How is each of these support types covered?”

Also, expect to pay for consulting support, or negotiate a set number of professional services hours into the deal.. Even if the vendor throws in downtime, error, and user support, you’re going to run into a problem that doesn’t fit, and the vendor is going to want to get paid to handle it.

This is item #0 in a sequence of 294 items.

You can use your left/right arrow keys or swipe left/right to navigate