What support and SLA questions should you ask before signing?

Establish four things: what support covers, how fast somebody responds and to what, what happens when the included period ends, and who is on the other side of the request. Most support disputes are not about response times. They are about whether the thing being reported is a bug the vendor fixes or a change the vendor bills for — and that boundary is almost never defined in advance.

Ask for the definition of a defect in writing, ask what the target response is and whether it is a target or a commitment, and ask what support costs the day after the included period expires. A vendor who answers those three precisely is telling you something useful about how they operate, whatever the answers turn out to be.

A platform launched with "three months of support included". In month two the payment provider changed an API and the integration broke. The vendor classified it as a change, not a defect, because the original code had worked. Both readings were defensible. Nobody had written down which one applied.

What counts as a defect

A definition, in writing. Does behaviour that no longer matches the specification count? Does an external provider changing their API count? This single boundary decides most future arguments.

Response versus resolution

A response time is an acknowledgement. A resolution time is a fix. Vendors quote the first; you need the second, at least for the severities that stop the business.

Severity levels, defined by impact

Three or four levels, each defined by what a user cannot do, not by how urgent it feels. "Nobody can complete an investment" and "a label is wrong" should not enter the same queue.

Hours, timezone, and out of hours

What "business hours" means and where. If money moves at the weekend, ask what happens at the weekend, and what it costs.

The channel and the named path

How a request is raised, whether it is tracked somewhere you can see, and how something is escalated when the first answer does not resolve it. A private chat with one engineer is not a support process.

What happens when the included period ends

The price, the scope and the notice period of whatever replaces it — agreed now. A support quote negotiated after you are dependent is not a negotiation.

Who actually does the work

Whether the people who built it are the people who support it, and what happens when the individual who knows the system is unavailable. Continuity of knowledge is the part no SLA covers.

Updates, patches and dependencies

Whether keeping libraries current, applying security patches and following provider API changes is support or a separate engagement. On a long-lived product this is most of the ongoing work.

• An SLA is a commercial remedy, not an availability guarantee. A credit for downtime does not restore a trading day.
• Small vendors frequently cannot offer a genuine round-the-clock commitment. An honest "no" is better information than a clause nobody can staff.
• This is about what to establish, not about what any particular vendor offers. FinMV's own support terms are part of its published commercial model and are quoted per project.
• Regulated products may have their own incident, reporting and continuity obligations that sit above anything a vendor contract says.