Support SLA's explained
We’re often asked: “what service commitments can you make?” Agency Service Level Agreements (SLA’s) are those baseline commitments. For us, often an agency for Drupal agencies, the Service Level Agreement is a partner promise that comes with defined consequences if broken.
“Change is the only constant”. We have heard this time and again and of course agile, its principles help provide a management framework(s) to manage change for customer or ensure partner success. In general whichever business value chain a company is working on and with any dynamical model to support its execution, customers want and like (sometimes prescriptive as should!!) to be involved, updated timely in the product journey. This requires systems and structures to aid collaboration, coordination (with or without cadence per customer needs). Besides an internal agency system which is working in architecting and building a product solution, a complete support team is engaged and involved in architecting and building an operational system to ensure healthy, efficient and effective collaboration (doing the right things at the right time!!).
For support services, customer requests could vary in urgency, complexity and risk levels. The collaborative play generally involves reducing resolution and communication time while ensuring an effective solution.
These when converted to measurable metrics and success criterias , define Service Level Agreements. SLA’s help us set clear and measurable guidelines, eliminates confusion while defining what is and what is not acceptable, eventually establishes clarity in terms of our commitment to our clients.
Tailoring Service Level Agreements: The Basics
The success of a support engagement is entirely determined by how much an agency is able to reduce response and resolution time for the customer depending on the complexity, the scope of work, and the velocity of work coming in by re-architecting relevant operational ecosystem (if the needs are accepted as a service strategy) to support velocity and capability needs. For example, an agency may taget to create an offshore team for a strategic partner to accommodate their time zone , essentially ensuring availability for efficient resolution and response times.
What does this depend on?
Tailoring is most often not dependent on the actual process of ticket closure, ticket collection, or ticket response (for which agencies normally have established baselines and frameworks) but rather on
- how the subunits in an agency are structured (to aid efficiency)
- the capability tiers within an agency (to manage complexity and delegation)
- and the engineers managing the service requests (value system including softer skills such as communication).
For instance, a certain type of ticket created for an incident that occurred at the backend server may need to be pushed to a particular kind of functional crew (Centers of Excellence) or a different capability tier. The complexity and risk level of the ticket determines the capability tier to which the ticket should be delegated. The more tiers there are available, the more advanced the SLA definitions, giving clients complete coverage across a range of issues with varying complexity.
With geographically distributed teams, SLA definitions could get another degree of flexibility (to aid efficiency) particularly if the company allows its team members to work for a certain number of planned and proactively communicated hours. We can have team members working within clients’ time zone, as required (for people can work from home and in out of office hours). The model is surely scalable for it provides a feasibility to build pods (fully functional in capability) covering more geographies, ultimately speeding up resolution times for our clients with strategic geopositioning.
Designing More Holistic SLA’s: Key Considerations
While support SLA’s will, first and foremost, deal in aspects revolving around defect resolution, a holistic SLA must cover more than just reactive maintenance needs. Maintenance partners also need to consider their partners’ longer term needs along with short term return on investments.
What about “preventive” maintenance?
Once support teams begin working on tickets, they’ll often find that there are other problems that run deeper on the end-client’s site, for example. The site may not adhere to prescribed standards, which could mean that further down the line it will not be scalable and the code will not be optimized for performance. Hence proactive, corrective, adaptive maintenance as separate streams demanding separate centers of excellence!! as we scale.
At this point, support agencies can either resolve the superficial issue and close the ticket, or they can view this as an opportunity to consult with the client about considerations that will prove valuable in the long term. Mature agencies will take the opportunity to offer consultative value to their clients, helping them move closer to their long-term vision.
SLA’s should therefore be designed to include implicit, non-functional expectations which are also part of maintenance. These can be based around security requirements, performance optimization, scalability (in terms of number of users or adding more functions, etc.). Through experience we have generally observed, maintenance services generally are supported in parallel with managed end-to-end projects (solving a bigger problem).
It’s important to address “technical debt” before anything else..
Another important consideration for support agencies to keep in mind at the start of the engagement is that end-clients’ websites may be burdened with some degree of technical debt, that is: the implied cost of additional rework caused by choosing an easy solution in the past instead of using a better approach.
Once it is clear that there is technical debt associated with a project, the first “obvious” priority should be to address it. The very first milestone should be focused on resolving technical debt, so that SLA’s can be be reliably defined and adhered to.
If this is not done at the start of the project, any effort expended on fixing bugs, making enhancements or tailoring SLA’s is likely to be non-impactful (per expectations) effort, as unresolved technical debt is likely to create complications further down the line. Engineers may find themselves fixing some aspects, but in the process unearthing several other issues with the end-client’s website.
At later stages in the project, agencies may find that clients do not wish to pay for the cost of fixing new bugs as well as all the hidden issues that are revealed in the process (which may be rooted in unaddressed technical debt).
This might seem basic, but it’s important for support partners to bring any kind of technical debt to the attention of clients for a collaborative, consultative and a symbiotic relationship.
Agencies that are looking to enhance any partnership and progress towards shared value creation will want to raise such issues early and address them proactively. Doing so may offer no immediate returns, but it does increase the probability of having a successful long - term relationship.
Driving SLA Success: Preventing Breach
For service requests, the most important consideration usually is how quickly communication can be established with the end-client to update them on the expected time to resolution (depending on the severity and risk level of the service request: urgent, critical, normal or low priority and on the complexity of the solution) and floor developments. This is determined by how fast the ticket can be recorded, and the support team’s time to first response. System cycle time and Ticket cycle time being equally important to consider. SLA’s can we tweaked to include the above drivers after identification of what works with the customer and the servicing organization collaboratively.
Effective Discovery : If an issue needs more research, causes a risk spike, doesn’t have a direct solution, or is a known issue, usually the best that support partners can do is to provide a workaround. In such a case, it becomes imperative to provide clients about the time needed to build a patch, for instance. Success is determined by how quickly support staff are able to establish effective communication with the end-client to source solutions to their challenge or opportunity.
Capability tiers and value system: For urgent or critical requests, which may cause website downtime and possible business losses for the clients success usually depends on two factors: 1. whether agencies have engineers available on the floor to solve that particular query, and 2. whether engineers with the right capability are available (already pointed in earlier sections). Careful consideration and planning going into weaving 1 and 2 effectively in the operational execution adding to customer success. It is imperative for support agencies to ensure that service requests are assigned to engineers at the appropriate capability level who can think a little beyond than just providing a quick-fix.
Empathy: Any effective partnership has to be grounded in a thorough understanding of the client’s vision (long term goals!!) as well as a sense of ownership. Challenges exist but customer success entails how well they are actively listened to, acknowledged, understood and supported with a mutually agreeable and a co-architected solution.
Communication: Communication with the client is a key factor in determining successful outcomes. There are two broad types of communication failures:
- Lack of timely reply to clients: The team may already be working on the issue, but if the client has not been kept informed, their experience is likely to be negative.
- Failure to provide a satisfactory explanation (i.e. communicating) with clients: Even when an issue could not be effectively resolved in time, this should be conveyed to clients in such a way that they are able to understand reasoning, efforts made, and what comes next.
All things considered, nobody really benefits from a quick or “hot” fix; they benefit from partners’ efforts towards genuine, consultative value creation—reducing these problems, and proactively evolving.
SLA Breaches: Broken Promises
An SLA breach is unacceptable. It can result in lost revenues and end-clients, as well as seriously damaging PR for the partner agency. In all such cases, it is vital for support staff to act prudently and methodically to restore service at the earliest. It’s important to understand what led to the breach, and promptly resolve any internal challenges through a joint retrospective. Transparency, ownership and effective communication with end-clients can help to restore broken trust and create positive outcomes.
Any service provider has to be sensitive to the serious repercussions of SLA breaches for partners and end-clients and hence the need for measures to protect our partners in the event of an SLA breach. Depending on whether there is work left incomplete, work that is found to be sub-quality, or work that is delayed, some companies refund varying percentages of the project budget to partners.
Ultimately, the goal of an SLA is to foster accountability and a sense of trust in the partner agency. Well-designed SLA’s protect the interests of both parties and ensure that any issues can be quickly and fairly resolved. When SLA’s are meticulously detailed and effectively used, they help create successful engagements and better outcomes for end-clients as well as partner agencies.