How To Ensure Success With Your Drupal Maintenance Contract

Drupal maintenance contracts or Service Level Agreements (SLAs) are as old as tech support and maintenance services. With constantly evolving support needs, conventional support and maintenance SLAs are no longer adequate to meet the needs of companies and are in need of an update. Having said that, how can you ensure that your Drupal support SLA is tailored to meet your needs effectively? But before that, let’s first get into what a support SLA actually is.

What is a support SLA?

Support SLAs, sometimes also called support response SLAs, are a contract between a support vendor and the client. This states the level of service that can be expected from the support provider. The contract might include aspects such as ticket response procedures, updates, resolution times, etc.

SLAs were introduced to bring accountability into the client-vendor relationship. Through clearly laid out policies and conditions, SLAs allow support and maintenance teams to quickly identify tickets, classify their level of severity and estimate a resolution time. This ensures that accountability, role clarity, and deliverability are set from the beginning of the relationship.

Support SLAs are also important in that they help determine value and define success in the client-vendor relationship. They validate the expectations of both parties and set parameters for accurately measuring project success while discouraging potential disagreements.

When a client is considering the ROI from such a partnership, the SLA becomes a way to measure the quality and efficiency of services rendered

General Support SLA Structure

Support SLAs come in many shapes and sizes, but they usually cover the following aspects:

• Conditions that a particular ticket needs for a particular SLA policy to be applied
• Response time for each desired metric and a priority value
• A way to define how response times will be measured in business or calendar hours by priority value/support plan
• One or more ancillary metrics (response time metrics, resolution time metrics)
• SLA penalties, or compensation you will receive in the event of a breach. If your support provider fails to meet the promises within the SLA, how will you be compensated? Penalty clauses outline monetary or other benefits you might be entitled to in such a scenario.  
• Also a clause in the case of multiple breaches, allowing you to exit the partnership.

Sometimes, a support SLA gets breached. The breach could be from the client’s side or the support vendor’s side.

Whatever the case, the underlying cause of the breach is probably an issue with the SLA. Here are some factors that contribute to such breaches:

An Unhealthy Focus on Cost Reduction

While some clients realize cost reductions from cheaper IT support alternatives, often this goal is achieved at the expense of addressing long-term, strategic objectives.

For instance, within the Drupal maintenance contract, support vendors might include a clause wherein policy breaches are reciprocated with discounts for services rendered. This is good from the cost perspective as the client pays a discounted price later. But it does little to address the issue that caused the policy breach in the first place, which can lead to further cost implications. And we know Such Cost Implications Can Be Huge.

Simply measuring costs does not provide an accurate measure of IT support success. And this is where a support vendor with a good SLA becomes trustworthy.

When you review the SLAs of Drupal service providers shortlisted to support your web application requirements, be sure to consider the holistic vision it creates. Is it about cost or value? Can you find a path which balances the two optimally for your business?

Fine print creating loopholes

Drupal support vendors tend to draw up lengthy SLAs with fine print that clients are usually unable to comprehend. When issues start creeping in, clients simply want them to be resolved; they don’t want to end up in a corner where the fine print blows up in their face.

Be sure to ask for an SLA review call or meeting to go through each aspect in detail. If you come across points that seem to have different interpretations, raise them and have them reworded appropriately.

Rigidity

Rigid Drupal maintenance contracts sometimes prevent deeper discussion around perceived support quality and the time to follow up. With this in view, vendors need to incorporate more flexibility so that clients feel safe in the knowledge that they can rely on their support provider when an issue arises without worrying about whether the nature of the issue is covered in the contract or not. This approach makes sure that you don’t have to take a scrupulous and meticulous approach to navigating maintenance contracts.

Consider: how much extra work is the vendor willing to accommodate to solve an issue? Is this defined in the maintenance contract? Does it sound reasonable to you? Make your expectations clear, so the vendor can tweak the contract to suit your requirements without running up a loss.

The ‘one size fits all’ approach

Conventional practice for many Drupal support vendors is to have a common company-wide SLA, without taking into account service-level and customer-specific tailoring. With this approach, they end up missing the essential component of service design for each account.

Conventional Drupal maintenance contract structures mostly talk about core services that repeat across various customers, but what they lack is customer-specific tailoring for different services.

Before signing on with a particular Drupal support vendor, consider whether they are willing to tailor their services and SLA structure to address your needs most effectively. Are they fluid and flexible enough to be able to accommodate the needs of your business fully?

Revenue impact

Ultimately, decision makers don’t really care about SLAs; they care about revenue and profits. If they have to worry about needing a separate contract at additional cost to ensure proper troubleshooting and solution implementation every time an application breaks or a bug is found, it's just not viable to outsource support.

Do ensure that when it comes down to it, your support SLA will cover your requirements without a negative impact on revenue.

What areas do Drupal Maintenance Contracts need to address?

Drupal maintenance contracts need to be tailored towards overcoming the challenges faced by individual clients. Hence, there is a need to update support SLAs and incorporate aspects that matter to your business.

Business priorities & requirements

Drupal maintenance contracts need to take into account your specific priorities and business requirements. For instance, a set of issues might have a similar priority level for the majority of clients. But some issues will be of different priority levels and these need to be addressed clearly within the contract.

Effective communication

Drupal maintenance contracts can also be a great mechanism for expectation management. However, they need to be clear in defining the responsibilities of the support vendor and client employees. A level of upfront honesty and transparency needs to be maintained to ensure that both parties are in sync and know what's expected and what will be delivered.

Involving all relevant people

To have a well-rounded SLA, it is important to make sure that the people directly responsible for delivering SLA policies are involved in the SLA construction process. Also, from the client's side, the respective operations personnel need to be involved in the review process of vendor SLAs.

Avoiding unreasonable targets & milestones

You can expect most Drupal maintenance contracts to explicitly mention resolution times for various issues. But these can sometimes be shots in the dark, with little to no research into the issue at hand. In such a case, you might have extremely quick response times promised within the SLA, but when the issue arises, the actual response time could turn out to be much longer. Background research and proper estimation are vital in ensuring that SLA expectations can be met.

SLA’s are a continuous, living document

An SLA cannot be a document which, once signed, can be filed and forgotten by both parties. Clients and vendors need to come together at a predetermined frequency to assess service adequacy and make sure that the SLA stays updated to meet current challenges and needs.

SLAs are an important part of the vendor selection process and can be a powerful tool for establishing and measuring parameters for customer success. But it is not enough to use a cookie cutter approach to designing them.

Drupal service providers need to begin with the right questions, clearly understanding business need and establishing a meaningful vision for customer success. They need to be focused on value rather than cost, and flexible enough to accommodate changing requirements. Only then will they be able to fully leverage the SLA as a means to achieving great outcomes for their clients.