Software uptime promise: 5 terms to check before you sign

• Estimate what a lost afternoon of quoting and dispatch costs you before you judge any credit.
• Read the availability wording, including the scheduled maintenance exclusion, and ask when those windows fall.
• Confirm which phones the field-access promise names, and test a job started offline during a trial.
• Write down the outage the same day and file a claim inside the stated deadline.
• List every tool quoting and dispatch use, and mark the ones the promise does not name.

Field service software is where the day actually runs. Quotes go out from it, jobs are dispatched through it, and crews check their schedules on phones before they drive to the next site. When it stops working, the office slows down and the trucks wait. That makes the uptime promise in the contract worth more attention than the feature list on the sales page.

A better habit is to read it the way you would read an insurance policy. Ask what is promised, what is excluded, what you must do to get anything back, and how much that is worth to you.

The five terms below work as a checklist. The examples come from the published service level agreement for ServiceM8, which is a useful reference because it states its rules in fairly plain language. Your vendor's wording will differ, and some terms may be missing altogether. Whatever you find, compare it against this list.

Before you look at any contract, estimate what a bad day costs you. You do not need precise figures. Count the jobs your office quotes on a typical day, think about how many of those would be lost if quoting stopped for a few hours, and estimate the average value of a job. Add the cost of crews standing idle while dispatch is unavailable, and the cost of overtime to catch up afterward.

The vendor will never calculate this for you. Its guarantee is written with its own exposure in mind, not your losses. Once you have a rough figure, you can judge whether the remedy in the contract is in the same range as your risk. If a single lost afternoon would cost more than a month's subscription, the contract's credit is not going to make you whole, and that gap belongs in your planning.

Start with the headline promise. ServiceM8's agreement describes its own purpose this way: "This Service Level Agreement (SLA) outlines our guarantee to you as a business account holder, and what you are entitled to in the unlikely event that ServiceM8 becomes unavailable." ( ServiceM8 SLA ) The word that matters there is "entitled." A guarantee only helps you if you know exactly what you are entitled to receive.

The promise itself is more specific: "We guarantee that ServiceM8 will be available 100% of the time in a given month, excluding scheduled maintenance." ( ServiceM8 SLA )

Read that sentence twice. The first half sounds absolute, but the second half carves out scheduled maintenance, and the measurement period is a single month. Both details shape what the promise is worth. Downtime labeled as scheduled maintenance does not count against the guarantee, so a vendor can stay inside its wording while your team spends an evening unable to reach the system.

Availability is also not the same as usability. A system can respond to a ping and still be too slow to take a payment or load a job sheet at the curb. The headline number says nothing about speed, error rates, or whether a feature you rely on, such as scheduling, is working. If the sales team talks about reliability, ask what they measure and whether they publish the results. Pair this with Field service settings to verify: 8 job checks .

Ask the vendor three things about maintenance. First, what counts as scheduled maintenance, and where is that defined in writing? The wording uses the phrase without explaining it. Second, how much notice do you get before a maintenance window? Third, when do those windows fall? A window in a quiet hour on a Sunday is a different matter from one at the start of the working week, when your dispatcher is sending the first jobs of the day.

Finally, ask where availability is recorded. If the vendor cannot show you a history of past downtime, you have no independent way to check the figure the guarantee relies on. A status page that shows only the current state is not the same as a record of what happened last quarter.

Your crew is often the heaviest user of the software, and the one most affected when the signal drops.

Notice the two conditions. The first is that the promise applies only where network connectivity is available. That is a sensible limit, because no software vendor controls a phone's signal, but it means the guarantee does not cover a basement, a rural lane, or a building with poor reception. The second is the device list, which names iPhone and iPad. If your crew uses Android phones or tablets, the published wording does not name them, so ask directly whether they are supported and whether the same access promise applies to them.

Think about your real working day rather than the one in the brochure. A dispatcher in a well-served office and a plumber in a crawl space face very different connectivity. Ask the vendor what happens to a job started offline. Does it save on the device and sync when signal returns, or does it need to be entered again? Can two people edit the same job while both are offline? The contract may not answer these questions, so get the answers in writing or test them during a trial.

It also helps to ask what the crew can still do when the app is unavailable altogether. Some owners keep a short written fallback: a printed list of the day's jobs with addresses and contact numbers, a phone number that reaches a named person in the office, and a clear rule that the crew should call in a job rather than wait. None of this replaces the software, but it keeps a bad morning from turning into a lost day. Pair the fallback with Text notification setup: 8 field service steps .

ServiceM8's remedy is a bill credit, and the formula is spelled out in the agreement: "If an outage occurs, we will issue a credit to your next bill for 5% of your monthly fee for every 30-minute period of downtime, up to 100% of your fee for the month." ( ServiceM8 SLA )

In plain terms, a longer outage earns a larger credit, and the total can never exceed the full fee for that month. The arithmetic is simple, but the result is usually small compared with a day with no quoting or dispatch. That is why the cost estimate described above should come first.

The published formula leaves two questions open. It does not say how a partial 30-minute period is treated, and it does not say how the start and end of an outage are measured. Ask both before you sign. A credit that ignores a short tail of disruption is not the same as one that counts every minute your team lost, and you should know which kind you are buying.

Be realistic about what a credit is. A bill credit is a discount on your subscription. Nothing in the wording says it covers the revenue lost while your office could not quote or dispatch, or the overtime your crew worked to catch up. If your contract includes a credit and nothing else, treat that as the floor of your protection, not the ceiling.

This example uses round figures only and is not a real bill. Apply the published formula to an illustrative monthly fee of 100. The formula credits 5 percent of that fee for every 30-minute period of downtime, and the credit stops at 100 percent of the fee for the month. One 30-minute period produces a credit of 5.

A credit you cannot claim is worth nothing, and this is where many owners lose it. ServiceM8's agreement says: "Failure to contact ServiceM8 within 30 days will result in a forfeiture of the the customer's right to receive the credit." ( ServiceM8 SLA )

The clock is the important part, and the wording leaves one thing open: 30 days from when? From the outage, from the moment it ended, or from the bill that shows the credit? The sentence does not say. Ask the vendor to define the start date in writing, and to confirm the exact channel you must use to make contact. A message to a sales rep, a support ticket, and a phone call may not all count the same way.

Build a simple habit around this. When an outage happens, write down the date, the start and end times as best you can, what stopped working, and who on your team noticed. Save screenshots of error messages. Note which jobs were affected. The record supports your claim if you make one, and it gives you evidence of what happened if you later need to discuss the service with the vendor or decide whether to switch.

Put the claim window in your calendar the same day you learn about the outage. Do not rely on memory, and do not assume someone else in the office will remember. A missed deadline is one of the few outcomes you can avoid entirely by planning, and the contract gives you no second chance to make it up.

It is also worth checking whether the vendor's support channel gives you a written confirmation when you file. If it does, save it. If it does not, send a short follow-up email that restates the outage details and the date you reported it. The goal is proof that you made contact inside the window.

The last term is the one that surprises people most. Here is how ServiceM8's agreement defines its reach: "This SLA applies to the primary hosting service, and excludes any services or tools not explicitly mentioned, including but not limited to deployment and integrations with third party services." ( ServiceM8 SLA )

Read that sentence as a map of gaps. The guarantee covers the primary hosting service. It excludes tools that are not explicitly named, and it names deployment and integrations with third-party services as excluded. For a field service business, integrations are often where the real work happens. A quote might pull pricing from a catalog tool, send an invoice to an accounting package, or push a booking into a shared calendar. If one of those links fails, the uptime promise, as worded here, may not reach it, even though your quoting process has stopped. See also Partial billing: 8 rules for estimate approval .

This is where many owners discover a problem too late. The headline guarantee sounds as if it covers your whole operation. The scope clause shows that it covers one part of it, and the rest is your responsibility or depends on other contracts you may have signed without reading.

Ask the vendor for a list of what is in scope. Then map your own workflow against it. Write down every system your quoting and dispatch depend on, from the core app to the accounting package, the payment terminal, the messaging tool, and the spreadsheet your manager uses for overtime. Mark which ones the contract names. Anything unmarked is a risk you carry yourself, and you should decide whether to accept it, add it to the contract, or replace it with something the vendor covers.

A contract is only part of your protection. The rest comes from how your business behaves when the software stops. Start with a simple plan that the office and the crew both understand. Decide who logs an outage, who tells the crew, and who contacts the vendor. Name a backup person for each role, because the usual person may be out sick on the day it matters.

Keep a current export of the information you need to keep working. That usually means the day's schedule, customer addresses, phone numbers, and any job notes the crew needs on site. Store it somewhere that does not depend on the software, and update it on a regular schedule your team can keep. An export that is three months old is not much use during a Monday morning outage.

Decide in advance when the office switches to phone calls. Waiting for the system to come back can cost hours. A rule such as "if the app is unavailable for a set period, we move to paper and phone" removes the debate from the moment, when people are stressed and the clock is running. Choose the trigger that fits your business, and practice the switch once so the team knows how it works.

Finally, review the plan after each outage. Note what the team did well, what slowed them down, and whether the vendor's communication was useful. Use that review to decide whether the vendor is meeting the promise in practice, not just on paper. If the record shows repeated problems, that evidence will matter more than any clause when you discuss renewal or switching.

Turn the five terms into specific questions, and bring them to your sales call. Ask for written answers, and keep them with the contract.

• How is availability measured, and where can I see a history of past downtime?
• What counts as scheduled maintenance, how much notice do I get, and when do maintenance windows usually happen?
• Does the field access guarantee cover every device my crew uses, and what happens to work done while offline?
• How is each credit calculated, including partial periods, and is there a cap on the total?
• From what date does the claim deadline run, and what exact steps do I take to file a claim?
• Which tools and integrations are covered, and which are excluded?
• How will you notify me of changes to the terms, and how much time will I have to respond?

If the answers are vague, ask again in writing. A vendor that is confident in its service should be able to explain its promise in plain words.

If you are weighing two vendors, put their terms side by side in a simple table with the five rows above. Add a row for the subscription cost, so the comparison stays grounded in what you pay. The table often shows that a higher headline percentage is less useful than a clearer definition of scheduled maintenance, a fair credit formula, or a claim window that is easy to meet.

Look for wording you would be comfortable explaining to your own team. A plain promise you can measure and claim against is worth more than a grand one with exclusions that swallow it.

Also check whether the vendor can change the terms later. Ask how notice of changes is given, through which channel, and what your options are if you disagree. Terms that look fine on the day you sign can be revised, so ask now rather than after you have built your operation around the software.

Open the agreement and highlight availability, field access, the credit formula, the claim window, and scope. Send one email that asks for the gaps in writing, and file the reply with the contract before you sign.

What are the five uptime terms to check?

The five terms are availability and scheduled maintenance, access from the field, how credits are calculated, the deadline to claim, and what the promise covers.

Does scheduled maintenance count against the guarantee?

No, scheduled maintenance is excluded from the monthly availability guarantee.

Is a bill credit the same as repayment for lost work?

No, the credit is a discount on the monthly fee and the published cap is 100 percent of that fee.