What a Support Agreement Actually Promises

Nearly every support agreement promises a response time. Far fewer promise a fix time, and the ones that do usually hedge it heavily. That is not necessarily bad faith. How long a fix takes depends on the fault, and nobody can honestly promise to solve an unknown problem in four hours.

What it means is that a fast response tells you when somebody will say hello. It does not tell you when you will be working again. A fifteen minute response promise sits perfectly happily alongside a ticket that stays open for a week.

The useful middle ground is a promise about effort and about updates. Work continues without a break at the top severity, and you hear from them at a stated interval whether or not there is news. Silence damages the relationship faster than the fault does.

Every target in the document hangs off a severity, which makes those definitions the part to read twice. They should be written in terms of business impact, with examples, and the examples should come from your business rather than from a template.

The question that decides everything is who sets the severity. If the provider sets it alone, every target is at their discretion, because the quickest way to meet a top severity target is to log the ticket one level down.

A workable arrangement lets you set it, lets them propose a change with a stated reason, and says how a disagreement gets settled. Check whether severity can rise as a ticket ages, too. A problem affecting one person for two weeks stops being a minor issue.

An availability percentage means nothing without three details. What is being measured, from where, and what is excluded.

From where matters more than people expect. A system that answers a check inside the data centre while being unreachable for everyone in your branch office is fully available on paper and completely down in the building.

The exclusions are where the number really gets set. Planned maintenance is nearly always excluded, so check how much notice is required and whether there is any limit on it. Emergency maintenance is often excluded as well, and that phrase can swallow a great deal if nobody defines it. Add up the exclusions before admiring the percentage.

Some exclusions are entirely fair. Nobody can promise the availability of a broadband line they do not run or a software platform they do not own. A provider who does promise it is either not reading their own document or charging you for a risk they cannot manage.

What they can promise is the handling. Raising it with the third party quickly, chasing it, telling you what is happening, and switching to whatever backup route exists. Look for that, because it is the part that is genuinely theirs to give.

Watch for exclusions triggered by your own systems. Agreements commonly void the targets for anything out of vendor support, unpatched past a stated window, or changed by you without telling them. Reasonable in principle, and worth checking against reality. If a third of your systems are already out of support, the agreement covers less than it appears to.

Service credits are the usual remedy and they are usually small, worked out as a slice of the monthly fee. They are not compensation for the outage and were never meant to be. Treat them as a signal rather than as a recovery.

The clauses worth negotiating are the ones about repetition. One miss should produce an explanation. Several within a defined period should produce a written improvement plan with dates on it. Continued failure after that should let you leave without penalty.

That path is worth more than a bigger credit percentage, because it keeps everybody's attention on the cause rather than on discounting the invoice.

Performance against the agreement is normally reported by the provider, out of the provider's own ticket system. That is workable, but only if you are able to check it.

Ask for the right to receive the raw ticket data rather than a summary chart, including the timestamps used in the sums. Ask how a ticket's clock is paused while they are waiting on you, and how those pauses are recorded. That mechanism is where reported and experienced performance most often part company.

Where uptime genuinely matters, keep your own monitoring. It does not have to be clever. It has to be yours, so that a conversation about an outage starts from one record instead of two.