What an automation support and SLA contract covers (and the 5 lines that are almost never in it)

"Technical support: response within 4 business hours." That line is in almost every automation proposal in circulation and it cannot be enforced. It does not say when the four hours start counting — from the moment the workflow went down or from the moment you wrote in? —, it does not clarify what a business hour is for someone working in another time zone, and it does not say what happens if six go by. Three holes in a single line.

An automation support and SLA contract covers six things: monitoring and failure detection, incident fixing, adaptation when third-party platforms change, a stated number of hours of minor tweaks per month, backups with a restore test, and continuity of access if the person who built it is not around. It does not cover new development, integrations that did not exist before, or what you pay Meta or the AI provider directly. And all six are worth less than the three definitions that are almost never written down: from what moment the clock starts, in what unit that hour is counted, and what happens on its own, without you having to claim anything, when the deadline is missed. Almost every contract in circulation has the six coverages and none of the three definitions, so they get argued over exactly as if they did not exist.

This piece is about the wording, not the engineering. What has to exist on the technical side for a deadline to be met at all — absence alerts, retries, an error queue — is in if the automation breaks, who fixes it; here is what gets signed.

The six coverages, with the line that defines each one

The discussion with a provider is not whether there is support: it is who absorbs each situation when it shows up, and where on paper that ended up written. This is what usually happens between month 4 and month 12 of a WhatsApp and appointment-booking automation.

The two middle rows are the ones almost no contract has. The fourth defines the only case in which the provider is in breach of nothing: if the one that is down is Meta, there is no deadline to hold them to, but there is still an obligation to tell you, because the one answering the customer who asks is you. The fifth closes off the most convenient exit a provider has when they lose someone from their team, which is stretching the deadlines without saying so.

Rows 2 and 3 are the ones that move the most money, and the discussion is not whether the shutdown is going to happen: it has a date published months in advance, and how that cycle works is told in if the automation breaks, who fixes it. Here the only thing that matters is whether that row says support fee or says quote. What was deliberately left out of the table: how many hours of minor tweaks are included per month and what gets quoted separately. It is the same negotiation as question 10 in the 12 questions to ask a provider and it does not change for being written in a contract instead of in a proposal.

The 5 lines you have to demand in writing

They are written to copy and paste. The values in brackets are the ones you negotiate; the rest is the structure that makes the clause enforceable. You do not need a lawyer to ask for them, and adding them to a proposal takes less than ten minutes.

1. Define down by the effect on the customer, and with a denominator

The hole: the contract defines availability over what the provider controls, which is the infrastructure, and you are buying a result. Those are two different objects and only one of them can be enforced. Why a healthy server does not guarantee a live process is developed in if the automation breaks, who fixes it; here is the text that closes it.

An incident shall mean any interruption of the contracted function as experienced by the end user — messages that go unanswered, appointments that are not booked, notifications that are not sent —, regardless of whether the Provider's own infrastructure and the third-party platforms show as operational. The committed monthly availability is calculated as completed executions over expected executions for the period, and not as server uptime.

The second sentence is what turns the percentage into something auditable, and it is the one that is almost never there. A process checked every 15 minutes is 2,880 runs in a 30-day month: 99.9 percent is around 3 failed runs in the whole month — the 43 minutes that sound like nothing — and 99 percent is 29 runs, 7.2 hours. With the denominator written down, either of the two numbers works and can be verified at month end against the execution history. Without a denominator, 99.9 percent is a brochure figure: nobody knows what it is calculated on, so nobody can say it was missed.

2. The clock starts when it breaks and runs in the unit you chose

These are two definitions in a single line. An eight-hour SLA sounds excellent until you ask two things: eight hours from what, and eight hours on which clock. The first is the one everybody argues about; the second is the one that changes the result.

The Provider shall verify automatically, at intervals no longer than [15] minutes, that the contracted processes are running correctly. In the event of a critical-severity incident the response time shall be [2] hours and the restoration time [8] consecutive hours, counted within a coverage window of [8:00 to 22:00, every day], suspended outside that window and resumed at the start of the following window. For the remaining severities the times are counted in business hours, understood as those between [9:00] and [18:00] on working days. All times are counted from the moment the incident occurs and not from the moment the Client reports it: detection is the responsibility of the Provider, who shall notify the Client of any critical-severity incident within [30] minutes of detection, even where it has already been resolved at the time of the notification.

With the unit in place, the same number changes size. A workflow that goes down on a Friday at 19:10, with eight business hours on a 9:00 to 18:00 Monday-to-Friday calendar, has a restoration deadline of Monday at 17:00: almost 70 hours of service down without anyone having breached anything. The same eight consecutive hours with an 8:00 to 22:00 window run out on Saturday at 13:10, eighteen hours after the outage. One text tolerates almost four times more downtime than the other, and both of them say eight hours.

After that, any number works as long as it is written down: a stated 24-hour restoration is worth more than a 4-hour commitment that starts counting when you call. And the last sentence — notify even if it is already resolved — gives you something almost nobody has: knowing how many times a month your system breaks. Without it, your only source of information about the health of the service is the absence of complaints.

3. Third-party changes are included in the support fee, and done in advance

The hole: the provider bills as new development something that adds no functionality at all, it just keeps alive the functionality you already paid for.

The adaptations required by version changes, updates or discontinuation of third-party services on which the system depends — including the WhatsApp and Meta APIs, the models of the artificial intelligence providers, Google and the payment gateways — are included in the monthly fee and shall not be billed as new development, provided that the contracted functionality remains unchanged. Where the third party publishes a discontinuation date, the Provider shall inform the Client within [15] days of becoming aware of it and shall carry out the adaptation no less than [30] days before that date.

The second sentence is the half that never gets written. Without it the clause is complied with just the same if the migration is done the day after the shutdown, with the workflow dead in between and, on top of that, without charging you anything: the money argument is won and the service one is lost. The unchanged-functionality phrase, on the other hand, is what makes the clause fair in both directions: if you take advantage of the migration to ask for three new features, that does get quoted, and rightly so.

4. Do not let the provider's calendar move your deadlines

The hole: the deadlines in line 2 are signed against a company and met against one person's calendar. If the contract does not say what happens when that calendar is unavailable, the deadline is suspended in practice and there is nothing to claim, because the contract did not say otherwise either.

The Provider shall maintain, for the entire term of the contract, at least two people with access to and operational knowledge of the system, and shall deliver to the Client every [90] days an updated inventory of the accounts, services and credentials on which the service depends, indicating the holder of each one. Leave, holidays or departures of the Provider's staff shall neither suspend nor extend the committed deadlines.

Two details make this line enforceable. The first is the closing sentence: without it, the coverage you bought in line 2 has holes the size of one person's holidays, and legitimate ones at that. The second is that the inventory has a date and a consequence: ask for the first delivery to be a condition of the first invoice of the support fee. An inventory promised and never delivered is the earliest sign that this line is not being complied with, and it arrives months before the incident does. Incidentally, it is the first thing the next provider will ask you for if you ever switch.

5. Make the breach have a consequence, and make the consequence apply by itself

The hole: almost all penalties require a formal claim from the client. Nobody sends a legal notice over a bot that was down for six hours, so the penalty is never applied and works as if it did not exist.

Failure to meet a committed deadline shall generate in favor of the Client a credit equal to [15] percent of the monthly fee per incident, applied automatically on the following invoice and with no need for a prior claim. Once three critical-severity breaches have accumulated within a period of 90 consecutive days, the Client may terminate with no notice period, with no penalty and with immediate delivery of the materials provided for in the exit clause.

What the credit buys is not money: it is a place in the queue

The credit is not there to compensate you, and it is worth being clear about that before negotiating it: 15 percent of a USD 250 monthly fee is USD 37, and a two-day outage in an appointment book costs a good deal more. What it buys is priority, and that does not depend on the percentage you start from: it depends on a ratio between two numbers you already know.

1. What your contract is worth to the provider, per year: monthly fee × 12.
2. What it costs them to attend to you in an incident: around 3 hours at their rate. If you do not know what range that moves in, the reference figure is in the 12 questions to ask a provider; for this calculation let us take USD 60 an hour, USD 180 per incident.

Divide one by the other. With a USD 250 monthly fee the contract is worth USD 3,000 a year and attending to you costs USD 180: a ratio of 16 to 1, so losing you is far worse than interrupting whatever they are doing. With a USD 60 monthly fee the contract is worth USD 720 and the ratio falls to 4 to 1: two incidents in the same month turn you into a client they lose money on, and no wording is going to bend that arithmetic.

That is why line 5 has two parts, and each one serves a different moment. The credit orders the queue while the provider can still attend to you. The exit is the only thing that helps you when they no longer can. The credit is the thermometer, the exit is the lever.

What it means if they refuse to sign each one, and what the paper does not fix even if they sign all five

• They refuse line 1: they have no way of knowing whether your process ran. They are selling hosting under the name of support.
• They refuse line 2: there is no monitoring. Without detection of their own, the clock cannot start anywhere other than your phone call.
• They refuse line 3: migrations are the business model. Every API shutdown becomes an invoice, and between WhatsApp, the AI models and the payment gateways there are usually several a year.
• They refuse line 4: it is one person on their own, and their calendar is your SLA. They may be an excellent person; it is a risk you have to know you are taking.
• They refuse the whole of line 5, credit and exit: the only cost of failing you is an awkward conversation.

No refusal is disqualifying on its own in a small project. A "we do not monitor every 15 minutes because your workflow runs twice a day, we check it after each run" is a better answer than the clause. What has no fix is them saying yes to all five without being able to explain how they do any of them.

The reverse is worth being just as clear about before sitting down to negotiate, because a signature is easily confused with a guarantee. A contract distributes responsibilities between two parties: it does not manufacture technical capabilities the provider does not have, nor does it restore revenue that never came in. With the five clauses signed you have covered the arguments that show up first, and these four things are left out:

• A contract does not create the monitoring that line 2 takes for granted. Signing that detection is the provider's responsibility does not make the alert appear. That gets verified once and only once, by breaking the workflow on purpose and timing it; it is explained in if the automation breaks, who fixes it.
• No credit pays for the real loss. Three days without reminders in an appointment book of 40 slots a day are felt in the month's revenue, not in 15 percent of a monthly fee. The contract distributes responsibilities, it does not restore sales.
• Someone on your side has to notice the breach. An automatic credit needs a record of when it broke and when it was restored to exist. If that log is kept solely by the provider, the clause is applied by the same one who breached it. It is fixed with one more line: that the month's incident report — occurrence, detection, notification, restoration and severity — is attached to the invoice.
• Above five or six workflows that touch money or scheduling, it no longer fits in a contract. The quarterly inventory in line 4 is enough for a list of ten accounts. When the system has dependencies that overlap with each other, what you need is someone holding that map every week, and that is operational work, not a clause.

When none of the five is worth negotiating

There are three cases where this text is not the tool, and the first one comes out of the calculation above.

• A ratio below 5 to 1. With the cost structure in the example, that means monthly fees of less than USD 100 a month. There the problem is not the wording: you are buying support at a price that makes giving it to you irrational, and the five signed lines do not change that arithmetic; they just give you a piece of paper to wave when the provider has already decided to attend to someone else first. The honest conversation is to raise the fee or lower the expectation, and both are valid answers.
• One-off payment, with no monthly fee. If you bought the development and there is no monthly charge, there is no SLA to negotiate because there is nothing to breach: every fix is going to be a new quote. What takes the place of these five lines is the exit plan — exports, ownership of the accounts and who you ask six months from now, even if it is by the hour — and it is worth closing on the same day the project is delivered.
• Workflows that simply do not need paid support. There are more of them than it seems, and the criteria for ruling them out are in if the automation breaks, who fixes it. If your workflow falls into that list, these five clauses are an argument you have no reason to have.

The sixth line, the one that is not among the five

If you take a single sentence away from all this to paste into the proposal before signing it, let it be the one that appears further up on the side and did not make the list: that the month's incident report — occurrence, detection, notification, restoration and severity — is attached to the invoice.

It is one line, it costs no money and it makes the other five verifiable. Without it, the five clauses are measured by the same person who has to comply with them, and the automatic credit in line 5 depends on the provider incriminating themselves. With it, in month 4 you have twelve rows telling you something no clause can promise: whether what breaks is always the same workflow, whether you found out yourself or you were told, and how long the detection you signed for really takes.

There is also a second-order effect worth taking advantage of. A provider who signs that line without arguing has already answered, without meaning to, the question you did not know how to ask: they have the log. The one who asks to take it out has answered you too.

If you have an unsigned proposal, send it to info@striqtech.com: we will point out which of the five lines is missing and which one is not worth fighting for in your case. Fairly often the reading is that the workflow does not need paid support and the whole discussion is unnecessary. For what is worth closing before signing, there are the 12 questions to ask a provider.