How to Decide Which SLA is Right For You

Which SLA

What is an SLA?

SLAs (Service Level Agreements) are the governing force in the relationship between the consumer and an enterprise support provider. SLAs clearly define what is expected by both parties with measurable objectives. An example is a signed agreement between an IT department and a support provider. The SLA spells out when and how the support service will be conducted. An OLA (Operating Level Agreement) is another name for SLAs but is for agreements within an organization without an established provider-customer relationship. Now, let’s dive into the three different types of SLAs.

Service Based SLAs                              

A Service-Based SLA is one identical service pack for all customers. This type of agreement is essentially “one size fits all;” it does not provide additional options or the ability to flex with individual IT environments. The advantage of this type, however, is that it simplifies the process for the various maintenance providers who utilize this type of SLA.

There are three categories a client will fit into when using a Service-Based SLA. These categories are divided by how efficiently they meet the needs of the customer. The first category contains those whose IT infrastructure requirements perfectly match the tenets of the agreement, while the second category contains clients who are paying for services that they are never able to fully utilize. In the third category, clients find the Service-Based SLA inadequate to meet all their needs as their IT environments exceed the specified services. Two examples of how an SLA may not reach the needs of an IT department would be faster response time and a readily available hardware inventory for break-fix scenarios. For many companies looking for third party enterprise support options, Service-Based SLAs may not be the best option if they do not efficiently and effectively meet their needs. Customers who commonly prefer this agreement are IT service providers, corporate IT, and IT service management.

Customer Based SLAs

Customer-Based SLAs are designed to contain all the possible services needed by an organization or department. This SLA is a general overview of all the services contained within a single agreement that is structured around each customer’s needs. The focus on each customer individually is what sets a Customer-Based SLA apart from a Service-Based SLA. An example would be an IT service provider offering several services packaged together within on SLA in order to meet all the needs of a client.

Multi-Level SLAs

The final type of SLA is a Multi-Level SLA. This SLA is customized based on the needs of the end-user client/company. The SLA is divided into three levels and allows the user/client to integrate multiple conditions into the agreement to provide a more suitable service to the client’s needs.

The Multi-Level SLA’s three levels are the corporate, customer, and service levels. The corporate level covers basic service level management (SLM) issues and does not require constant updating. It contains an in-depth discussion of all the necessary parts of the agreement and applies to all customers. The customer level of a Multi-Level SLA focuses on a singular customer group and covers all relevant SLM issues regardless of services used. The Service-Level SLA has a distinct focus on the the individual services and defining the service for the individual client.   

Mathing Needs to SLAs

Many organizations need enterprise system support and maintenance. The support and maintenance process is defined by SLAs. At thomastech, we believe that IT managers need to be given a choice of SLAs and the ability to customize them. After all, IT managers know their own enviroment’s needs, and thus they are the best equipped to make the right choice.

thomastech provides a selection of SLAs that are centered around the core concept of empowering you, the IT professional. The goal of thomastech is to empower you through hardware and enterprise maintenance so you can keep your systems running and your data moving. Going beyond many other third party maintenance providers for enterprise systems, thomastech provides you the freedom to custom-tailor the support process and SLAs to best fit your IT environment. To learn more about our SLAs, visit our support page at https://thomastechllc.com/third-party-tech-support/ or call (330) 225-3117 to speak with a real person to find a personalized solution to your enterprise support needs.

The facts behind new vs. old enterprise IT models that OEMs don’t want you to know

Is the newest model the best choice? The answer would be yes, right? Unfortunately, the answer is not that simple. There are many factors that influence the answer.

OEMs are constantly releasing new models. With each new model, the OEM proclaims it as an upgrade that it solves many IT problems. Not only are IT managers flooded with this information in OEM ads, they experience additional pressure while attending IT conferences and shows from both the OEM and other attendees. All this pressure pushes for a spontaneous purchasing decision versus a planned transition. When an impromptu purchasing decision is made, many IT managers overlook their multi-year plans and stabilization exercises. Is the offer provided by the OEM along with the outside pressure to buy worth discarding all the careful planning that has been put into place?

With every new piece of equipment released, OEMs advertise upgrades made over the previous model. Yet these changes between models are often minor and have little real-world impact. Most of us have had a similar experience even when purchasing consumer IT products. A feature is promoted as an upgrade, but later it is discovered the change/upgrade did not help in the way expected. In some instances, the changes made between models actually decrease the usability of the product thus increasing user frustration. In order for a model change to be accurately called an upgrade, its features must have a measurable benefit to the organization and IT department rather than some extra “chrome”. They should make a noticeable and valuable contribution to mission critical operations within the system’s environment. If the benefit is not significant enough, the older model currently in use may be the better option.

A general consideration for IT departments is if the inter-model feature change is significant enough to merit the additional work and increased capital expenditures. On release, often a new model has undergone only a few slight alterations since the previous model, sometimes just two or three. If these changed features are not vital for mission-critical operations, it may be wise to wait for one or two models to be released before upgrading. This waiting allows departments to jump over intermediate models and pay the price for one system replacement while accumulating multiple features instead of just two or three. This waiting allows for budget maximization while reducing downtime associated with system migration.

As with many other forms of tech, enterprise system models are not without their defects when first released. Often IT products display a bathtub shaped curve demonstrating the failure rates of systems and hardware. When a model is first launched it experiences soaring failure rates. After a while, the failure rate drops and the issues and bugs are worked out as the innovators and early adopters experience the problems. Often it is better to be a member of the early majority, or even in the late majority, on the product adoption bell curve as many of the problems will be fixed and the systems will be more reliable. Waiting too long, on the other hand, places users in the last 16% along with significant chances of system failure rates spiking due to the age of the systems.

Some IT products do not demonstrate the traditional failure rate curve; instead they demonstrate more of a flat or a steady increase in the failure rate. This unusual behaviour results from the root cause being impractical for the OEM to resolve or additional problems becoming apparent over time. For IT departments without unlimited funding, it is safer to remain in the early or late majority when purchasing and adopting the new model of enterprise hardware. New models are especially risky to innovators and early adopters as they have no previous history to determine whether the systems have a high failure rate and are thus unreliable. On the other hand, those following early adopters will know from their experience whether the model is a wise and safe investment.  

When implementing a system swaps for new models, IT departments must determine their system swap procedure to avoid additional costs. There are usually two options when swapping a drive. The first is to maintain a redundant system for transitioning data and users to during the swap, while the second is to shut down the system and cut access to the data. Both methods for swapping systems generate additional costs either from purchasing and managing another system or costs resulting from downtime.

Choosing option two and shutting the system down results in down time. As many know within the IT field, downtime is costly. Probably the highest cost from downtime associated with a system swap is lost revenue. Following lost revenue, other costs are incurred, including those resulting from reduced productivity, lost opportunities, and decreased customer confidence. To avoid or reduce these costs, a solution must be designed around compatibility with existing infrastructure and employees’ usability to allow for a seamless transition. The lower the frequency of system swaps in an IT infrastructure the lower overall associated costs and downtime.

When considering upgrading to a new system, IT managers should consider the additional man-hours incurred as a result of the transition. Not only is work required to move the entire system that is being swapped, but work is also required to reconnect and troubleshoot potential compatibility issues. Once the system is in place, IT staff and company personnel must be retrained. Not only is this time-intensive for production and office staff, but it also requires a significant time investment from those providing the training. A major cost to organizations and their related IT departments is man-hours. As a result, efficient man-hour use is a major consideration for many IT managers so they can maintain their given IT budgets. Increasing the intervals between system swaps decreases the overall man-hour costs.

Many managers at this point are thinking about their legacy hardware and their related support and maintenance needs. The OEM places additional pressure to upgrade systems so they can sell more and increase their profit margins. They do not consider what is best for IT managers and their budgets as their goal is to increase sales. As a result, support costs skyrocket when it is time to renegotiate the SLAs. Once a system is sunsetted by the OEM, no support is provided by the OEM regardless of the price, leaving departments without support for functioning systems. Thomastech provides a solution.

With Thomastech’s support, many managers receive up to a 70% savings compared to the OEM’s SLAs. Thomastech focuses on streamlining and simplifying the support and maintenance process. Thomastech accomplishes this by providing direct access to level three engineers, extensive internal hardware inventory, support for all your OEMs in one place and a streamlined ticketing and triage process. All of these features ensure a faster resolution, lower costs, and reduced downtime.