Support plans and SLA

The first clock stops once an engineer is actually on your case and has told you what they found. Since that depends on nobody but us, it belongs in the contract: 15 minutes, one hour or four, according to plan. The second clock stops when your colleagues can work again, a workaround being perfectly acceptable. That one is shared with your telecoms operator, a software publisher or a hardware vendor, so we commit to targets per priority and break out in the report every waiting period that was never ours to shorten.

The ticket system calculates, priority by priority, how many requests were answered inside the agreed limit, using the very timestamps you can read in the history yourself. Anything that ran over is listed by name, together with why it happened and what we changed so it does not happen twice. The contractual consequence of an overrun is a subject for the signing table, not for the middle of an incident.

The clock only turns during covered hours. Fifteen minutes elapse on the Friday evening, then it picks up again at 8:00 on Monday, so the response is due at 11:45. If a weekend of silence costs you too much, the answer is not to argue about the arithmetic but to pick a plan whose hours match how your business actually trades, and to write those arrangements into the contract.

The engineer proposes a priority using the rules above, but the final word is yours. If you judge the consequences heavier, the priority is raised without debate and the history records who changed it and when. In practice it pays to name, at contract time, the two or three applications whose failure automatically counts as critical in your company.

Yes, by amendment, effective on a date we agree together. A retailer facing the Christmas peak may want Premium from November and Business again once January arrives. The move works in both directions, and we are the ones who raise it when a year of reports shows you have been buying speed that no incident ever called for.