The Unique Challenges of CMS Support, Part I

Content management systems are a little different from most enterprise software because they’re almost always heavily configured and customized. I know other software packages are too – CRM, for instance – but a lot of CMS installations are little more than API platforms, and they’re heavily coded against, so the customer has (or hires) developers that are integrating their code into the CMS code, and the two have to work together to produce a decent result.

This makes CMS support a bit of an odd bird. When something goes wrong, whose fault is it?

Assume you purchased Episerver to run your website, and you hired an implementation firm (like Blend) to integrate it. This is a common pattern, and I’d venture that external integrators are used for content management implementations more often than most other types of software.

To implement Episerver, we usually have to write code. We can do a lot at the server control level, but that’s still templating code. If you want more heavy customization, we write event handlers, plugins, full-blown modules, etc. We’ve done some semi-insane customization of Episerver installs.

Later, say you find an error – when you do Actions A, B, and C, in that order, you get an exception. Who do you contact about this – Episerver (the vendor) or Blend (the integrator)?

In my experience, you need to contact Blend. We implement several different systems, and – with some exceptions – the problem is usually always with something we did. Episerver is heavily QA’ed before release (I know this because I’ve seen their unit tests), and their code has the benefit of thousands of installations. However, the code we wrote for your website might just have been written for you specifically, so it’s much more likely that the problem lies here.

What this means, in a lot of cases, is that direct vendor support for CMS is pointless. You will call the vendor and explain the problem, and they will say “That’s not a problem with the software, that’s something your integrator did.” More likely, they’ll use the time-honored phrase “that’s an implementation issue.”

(Even if you implemented yourself, it doesn’t help. It just becomes something you did, rather than something your integrator did.)

We’ve had experience with companies that offer direct vendor support, and they often use it as a selling point. “We have a 1-800 number you can call whenever you have a problem…” This is a seductive pitch. What they don’t tell you is “…but 90% of the time we’re going to tell you it’s an implementation issue and you have to call your integrator.”

Are they being disingenuous? Perhaps, if they push direct support heavily during sales, knowing that most issues will be pushed off to the integrator. However, when the support call actually comes, that response is probably completely appropriate. The fact is, most problems are with the implementation, so when Vendor X tells you to call your integrator, they’re doing the only thing they really can do. They can’t be expected to debug the integrator’s code, so what other option do they have?

Episerver has an interesting sales and support model. They only sell through partners, so you don’t buy from Episerver, you buy from Blend – we resell their software. This means we also support it. If you buy Episerver from Blend, we are your first line of support. If something goes wrong, you call us, which is appropriate in most cases because (1) we can resolve most issues for you, and (2) we probably integrated for you, and the error is likely in the implementation, not the software.

Now, if we have an issue, then we can turn around to Episerver and get support. So if I don’t know what’s wrong, we can get support as a partner. This support tends to be super-effective, because the issue has already been triaged by Blend, so if I have to go to Episerver it’s probably an actual problem, and given my experience with the CMS (not to mention the implementation), I can have a much more effective conversation with Episerver about the problem.

I think this is an intelligent model and fits how CMS is integrated and how it needs to be supported.

It perhaps gets a little odd when the customer implements themselves, because, in that case, they have more experience with the implementation, and you have a developer (the customer) talking to a developer (me). However, I still maintain there’s considerable value here because I have more experience with Episerver than they do, so even for our developer customers, I can resolve most of their issues without involving Episerver.

What this model also means is that customers have another dependency in the support chain. If Blend integrates, but the customer hates us and severs the relationship, where do they go for support? We would still be the selling partner, so we are between them and Episerver and they still have to come to Blend for first-line support. In these cases, they would need to go to Episerver and request to be matched to another partner.

Episerver has followed this model for years and it’s been adopted well in Europe, but it’s faced some pushback in North America, which we’re working to resolve. North American customers tend to want guaranteed vendor support, which is not offered. We’re finding customers on this side of the Atlantic that look past the integrator and want to cement the relationship at the vendor level.

I can understand this. Accurate or not, there’s a tendency to consider the integrator as an interchangeable commodity, whereas the CMS vendor relationship is more permanent. Integrators come and go, but the vendor is eternal.

In practice, I still have relationships with all my Episerver customers, and we still do primary support, so the model clearly works fine. The problem is that it’s tough to get this message across in the sales process when you have other vendors dangling 1-800 numbers, no matter how ineffective they might be.

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