IT buyer: the five commandments to negotiate with a Software vendor

April 7, 2022
min

If you are negociating a contract with a Software vendor for your organisation, here are our five basic recommendations you can't forget.

Tell me more
Scott graham OQM Zw Nd3 Th U unsplash | Capyx

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.

Capture décran 2022 04 07 à 15 11 54 | Capyx

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

Capture décran 2022 04 07 à 15 18 50 | Capyx

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)

Capture décran 2022 04 07 à 15 22 10 | Capyx

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

Capture décran 2022 04 07 à 15 29 10 | Capyx

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

Share

Keep me posted

Do you want to stay tuned ? Subscribe to our newsletter !