Commandment 1 : The basic TTR you won't forget
When your internet line is down, you call your internet operator and ask for a resolution of the incident within the day?
The “time-to-repair” (TTR) is the timeframe committed by the software vendor to solve an incident, and the level of priority determines the engagement of resolution call the “Service level”
The negotiation of this software engagement is determined by the business and/or technical impact of the incident on your business. And faster the resolution expected is, bigger is the investment required in resources and cost for the vendor.
Attention point: an application used once per week per 2 persons, doesn’t request the same time-to repair than a software used by the whole company in a daily basis.
Exemple of a SLA for a Time-To-Repair
Tips: an “estimated resolution time” is an objective of resolution, not a commitment 😊
Commandment 2: the Incident Priority definition, challenge it you will
By definition, an incident on your software has an impact on the business activity. Each incident on the software will be classified according to a “priority of resolution”depending to its business or technical impact. The objective is to determine the type of incident related to the software (functionality, report, interface,….), and negotiate the highest priority for each of them
Attention point: Faster it’s solved, faster your teams can keep going on.
Tips: Don’t hesitate to add some concrete examples
Commandment 3: the availability for cloud solution, avoid it you can’t
The Software availability is the percentage of time when the application system is correctly operated and accessible by the user. The software availabliiltiy is basically calculated as: 100% - “Sum of P1 incident”
(the P1 incident definition refers to a discountinuity or unavability of services)
Tips: Try to integrate the performance incident is your Priority 1 definition for a maximum of vendor reactivity
Commandment 4: the road map and release notification process, clarify it you have to
The Saas principle is that a software vendor push product releases towards the client in order to enhance its experience. However, as client, it’s not rare to be touched by a major release that contains important changes that will directly impact the organization (data format modification, new functionality …).
In this case, it’s difficult to avoid the risk but as IT buyer you can mitigate it via a clear communication on the process.
Tips: Some software vendors are able to retain a release, an opt-out right for several months can be negotiated
Commandment 5: the reporting you can’t pass-by
“no reporting, no evidence, nothing to discuss”
Ask for the production of the incident management and availability reporting by the supplier is a best practice --- that can avoid lot of stress in case of conflict. It enables sane discussions on fact, and the application of the penalty fees (in case you would have attached this mechanism to your Service Level)
Tips: It’s always good to attach an example; its definition can lead to interesting discussion between the business and the partner