The Unique Challenges of CMS Support, Part II

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:

• "My site is broken!” This is pretty clearly a problem. The site might be down or significantly impaired, thus rendering the customer pretty uptight. These are not leisurely issues – time is a critical factor here. Additionally, this problem can happen at any time, 24/7. Call this downtime support.

• "I have encountered an error.” This is closely related to downtime support, but the site isn’t down or significantly impaired. There is an error when the customer tries to do something, so they have no choice but to call you. This error is often not even visible to the public – it might be internal to something an editor is trying to do in the admin interface. Call this error support.

• "How do I accomplish Task X?” The customer also has a problem here – the site isn’t broken, and there is no error, but they just can’t figure out how to do something they should be able to do. The customer is either completely in the dark and doesn’t even know how to start, or they feel like they’re doing it correctly, but not getting the result they want. Call this user support.

• "What is the best way to accomplish Goal X?” This is more long-ranging than the above. The user has a more expansive question about how to do something with the CMS. How do they ensure fault tolerance? How do they architect their site properly? How do they integrate with their CRM? Call this consulting support or best practices support.

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.