CMS support models: Is your implementation partner really committed?

There are some inconvenient truths about support that not all partners like to speak openly about - like support availability, the experience level of the offered resources, and their ability to fix issues the right way for your project.

Sure, when the questions about support inevitably come up in RFPs, they promise the world - but there's always some fine print between the lines. Often, support and maintenance becomes just an afterthought, as both parties are eager to get on with the "real" fun project work.

Every EPiServer implementation partner claims they do support and maintenance - the tricky part for the customer is finding out exactly what kind of support they mean. Preferably, BEFORE sealing the partnership and embarking on a project together.

The 4 common support models

1. The just-in-time support

The partner doesn't have a dedicated support department/team. Instead, developers have to be yanked out of whatever task they're currently on, to handle your support issue.

For customers:

• Expect to be caught up in a resource planning tug-of-war. Your issue will only be dealt with if it's urgent enough and the partner has developer resources available.
• If your issue is urgent but development resources are scarce, expect to pay a premium for expedited support.

For partners:

• Developers can be used for project work instead of wasting time going idle when there's no pressing support needs.
• However, whenever an urgent support issue does arise, developers will lose progress on their current project, they may be frustrated having to jump into unfamiliar projects, and may be unhappy with the spike in workload.

2. The remote outsourced support

The partner doesn't do their own support, opting instead to have a remote third party perform this service. 

For customers:

• Expect to spend extra time explaining the problem and its context to the support team. They most likely have a good grasp of EPiServer in general, but no prior knowledge about your specific implementation.
• Furthermore, most EPiServer implementation partners use a custom tailored project framework for their implementations. If the remote third party handles support for multiple partners, don't expect the support team to know their way around the specific project framework that your site is built upon. 
• For support outsourced to other parts of the world than your own, there may even be a timezone and/or language barrier to cope with. 

For partners:

• While in-house developers aren't being drowned in first-line support, the original project members may still have to pitch in when support is stuck on complex issues in legacy projects, disrupting their workflow.

3. The local outsourced support

The partner has a third party performing support services on their behalf, but they are either co-located, in close proximity of each other, or very familiar with each other's methodologies. 

For customers:

• Expect that the support team has a good grasp of EPiServer, but not necessarily prior knowledge about your specific site.
• However, local outsourced support rarely service more than one implementation partner, and should be very familiar with your partner's project framework and their preferred methodologies, making it easier for them to find their way around the code even if they haven't worked on your specific site before.

For partners:

• Having development and support separated means both departments will work as efficiently as possible on their tasks.
• The separation also means that developers miss out on being exposed to a variety of implementations, which would otherwise have been a good opportunity for learning and distribution of knowledge.

4. The in-house dedicated support

The partner has a dedicated team exclusively doing support, handling issues immediately as they arise.

For customers:

• Expect to be serviced by experienced developers, who know the project framework and methodologies like the back of their hand, and likely have previous experience with the customer's specific site.
• The collective experience of the development team is available to the support team if they should need it. It' s just a matter of walking over to a colleague to get a direct answer.

For partners:

• Separate development and support teams ensures efficient working conditions for both teams.
• In agile organizations, development and support resources may be equally experienced and virtually interchangeable, allowing teams to scale up or down as needed, and providing a great environment for learning experiences.

Confirm the commitment

How committed is your implementation partner to supporting you? It often comes down to this:

• Does your partner have dedicated support resources (either in-house or outsourced) - or do they frantically scramble to allocate support resources when issues arise?
• Do they fix issues in a hit-n-run, patchwork manner ("just make it work") - or do they make sure their fixes are consistent with the overall architecture of the project?
• Do they work reactively, i.e. just handle support on a case-by-case basis - orproactively, i.e. spot recurring patterns and improvement potential before it gets critical?
• Do they even want to keep supporting you after The Big Launch - or will they drop you like a hot potato to move on to the next exciting new project?

These are questions your (potential) implementation partner should be able to answer without hesitation - preferably backed up by other customer references.

Get a support & maintenance contract

Even the best business relationships can turn sour if there are mismatched expectations about support.

A support & maintenance contract will help both parties understand the WHAT, WHEN and HOW of your relationship post-launch.

As a minimum, the contract should have details about:

• Which support channels are available to the customer (email, issue tracking system, phone etc)
• At which hours the partner's support resources are on duty 
• How the customer can reach support outside office hours
• What kind of response times are expected for different urgency levels (be sure to have your partner explain their urgency scale - wrong color on a button is seldom a CRITICAL issue).
• Pricing for support both inside and outside office hours

Committed partners will also likely have a proactive maintenance program in the contract, which may include:

• Regular "health checks" of the site configuration and server environment
• Review of relevant logs to detect recurring patterns and take appropriate action
• Suggesting updates, new features or other improvements to keep the site from becoming stale - these may range from technical improvements to content changes to conversion tweaks, depending on the partner's areas of expertise.

How we do support at Epinova

When we tick the box that says "we provide support", we mean it. 

Throughout the project development phase, we assign a lead developer to be the customer's main point of contact. After launch, that same lead developer will very likely stay with the project for a while to handle immediate support issues and features that just didn't make it into the initial launch. 

When the post-launch dust settles and the site is in normal operation, we formally transfer support duties over to our dedicated in-house support team. During the transfer, developers and support go through the site's architecture, integrations and documentation to ensure support have all the info they need. 

What's special about our support team is that they are all senior level, EPiServer certified developers. We see support duties as a great way for developers to expand their horizons, so we all take turns serving on the support team. Customers benefit from the experience level they encounter, and a fresh pair of eyes may uncover even more improvement potential for their site.

We do regular health checks of customer sites, and frequently turn findings into mini-projects to ensure we apply the required attention to detail.

We don't believe in dumping support over to a remote third party - if the quality of the project deteriorates from patchwork bug squashing, and we both miss out on improvement potential, where's the value in that?