Request a quoteGet a quote

    ↑ ↓ selectEnter openEsc close

    The whole guide for printing: vyvoj.solutia.cz/en/guide/print

    Part IV After launch: operations, further development, independence

    Support and SLAs, maintenance, technical debt, and how not to depend on a single vendor.

    Support and SLAs

    ~11 min readUpdated Lukáš Mikula

    An SLA is a promise in numbers: how quickly the vendor will help you when the system does not work, and what it will pay if it does not make it in time. What matters are three different time limits, the support hours during which they are counted, and a precise definition of availability. Pay for round-the-clock support only where you really need it, and ask for a report every month.

    A response is not a resolution

    The most common trick is an SLA that covers only response time. The vendor “responds” within 15 minutes, confirms that it has received the ticket, but takes a week to deal with the bug itself. And it has not breached the contract. So for each priority, ask for three separate time limits:

    • response: the vendor confirms the ticket and starts working on it,
    • restoration: the system works again, possibly with a temporary workaround,
    • resolution: the bug is fixed permanently.

    The vendor does not set the priority according to its current workload. Impact and urgency decide, based on the definitions in an annex to the contract. Any dispute is resolved by an escalation procedure agreed in advance. Also distinguish between an incident, where operation needs to be restored, a problem, where you look for the cause of repeated incidents, and a change request. Each is handled differently. New features do not belong in the fixed monthly fee for support; they go through change control and the budget for further development (chapter 22).

    Sample incident priority table (illustrative time limits)
    PriorityWhenResponseRestorationResolution
    P1 criticalthe system does not work, or most users cannot use an essential feature, such as logging inwithin 30 min, 24×7within 4 hwithin 2 business days
    P2 highan important feature does not work, but a laborious workaround existswithin 2 hwithin 1 business daywithin 5 business days
    P3 mediuma minor limitation, such as a faulty filterwithin 1 business daynot neededin the next release
    P4 lowa cosmetic defect, a questionwithin 3 business daysnot neededas agreed

    The time limits are an indicative suggestion, not a norm or a market standard. Set them according to how much an hour of outage costs you. The time limits run only within support hours.

    Time limits run only within support hours

    8×5 support covers 40 hours a week; round-the-clock 24×7 support covers all 168 hours, which is 4.2× more time. If you report an incident on Friday at 4 p.m., a 4-hour time limit under 8×5 support with business hours of 9 a.m.–5 p.m. ends at noon on Monday. The weekend does not count.

    8×5 or 24×7?
    8×524×7
    Hours covered per week40168 (4.2×)
    What it requires of the vendora regular team during business hoursseveral people on call, shifts, surcharges
    When it is enoughinternal systems used during business hoursservices for the public, online stores, shift-based production

    There is no public data on support prices in CZK. The only certainty is the arithmetic of the hours covered; have the price itemized in the proposal.

    A common compromise is 24×7 only for P1 and 8×5 for everything else. Base the support hours on when people actually use the system, and include the option of tightening them later in the contract. Needs change: the basic registers were created for the office hours of public authorities, but the digitalization of services for citizens requires round-the-clock operation, and even more than 4 years after the deadline at the end of 2019, it had still not been ensured NKÚ, audit conclusion KZ 23/05 (chapter 23).

    Convert availability percentages into hours

    99% sounds great, but it allows up to 87.6 hours of outage a year. At 99.9%, it is about 8 hours and 46 minutes. Try it yourself:

    Calculator

    How much outage time does your contract allow?

    Start with an example, or enter the availability from your contract and how it is measured. You will see how long the system may be down without the vendor breaching the SLA, and what that can cost you.

    Example systems (illustrative levels, not a recommendation or a standard)

    What the contract promises
    The percentage of time the system must work under the contract. Each additional nine cuts the permitted outage time tenfold. Without a definition of what counts as an outage, and where and how it is measured, availability cannot be enforced.

    The arrows jump between common levels (99 / 99.5 / 99.9 / 99.95 / 99.99%).

    When availability is measured24×7 = every hour counts, including nights and weekends. 8×5 and 12×5 = only workdays during 8 or 12 operating hours; an outage outside them does not count toward availability at all. You will find this in the availability definition in the contract; do not confuse it with support hours.
    Evaluation periodThe period over which the vendor calculates availability and shows it in the report. Monthly evaluation is stricter and better for you: one long outage is not averaged out over the whole year.
    What an outage costs you
    What one hour without a working system costs you: people who cannot work (headcount × hourly cost, roughly gross salary × 1.338 / 160), lost revenue, contractual penalties, and extra work after recovery. Set both the availability and the response times in the SLA based on this amount.

    A rough order of magnitude is enough. Zero = leave it out.

    Permitted outage time per month

    43 min

    99.9% = up to 8 h 46 min of outage time per year.

    Per year
    8 h 46 min
    Per month
    43 min
    Per week
    10 min

    Evaluated separately for each month: if the system is down for more than 43 min in a single month, the vendor has breached the SLA.

    Every hour counts, including nights and weekends. Ask whether planned downtime is excluded from availability.

    At CZK 200,000 per hour of outage, the permitted outage time can cost you up to CZK 1.75 million per year. That does not breach the contract; you bear the loss.

    Without JavaScript, we show the calculation with the prefilled values (CZK 200,000 per hour of outage).

    Permitted outage time per month by availability (measured 24×7)
    Chart as a table
    Permitted outage time by availability in the selected measurement mode
    Availability (24×7)Per yearPer monthPer week
    99%87 h 36 min (3.65 days)7 h 12 min1 h 41 min
    99.5%43 h 48 min (1.83 days)3 h 36 min50 min
    99.9% (entered)8 h 46 min43 min10 min
    99.95%4 h 23 min22 min5 min 2 s
    99.99%53 min4 min 19 s1 min

    How we calculate: outage time = (100% − availability) × hours in the period. A 365-day year = 8,760 h, a 30-day month = 720 h. 8×5 operating hours = 2,080 h per year (about 173 h per month), 12×5 = 3,120 h. What outages can cost you = permitted outage time per year × cost of one hour of outage.

    Check three things in the contract: whether availability is measured 24×7 or only during operating hours; whether planned downtime is excluded; and over what period it is measured. The example systems are illustrative, not recommendations: the measurement mode matches when people use the system (internal systems during working hours, public services around the clock), and the cost of an hour of outage is an estimate for illustration.

    The same percentage can mean a completely different promise. Ask:

    • What is an outage? Only a complete failure, or also a response time longer than a few seconds?
    • When is it measured? If availability is counted only within 8×5 support hours, a nighttime outage of any length does not breach the contract.
    • How often? Monthly evaluation places stricter demands on the vendor than annual evaluation. That way, one long outage does not get “diluted” in the annual average.
    • What is excluded from the measurement? Planned downtime, outages of subcontractors or the network.
    • Who measures it? Ask for the methodology in the contract and access to the monitoring data.

    Watch out for chaining, too. In the basic registers, the individual parts contractually have 99.9% or more, but taken together, the guarantee comes to only 99.68%, which means up to 28 hours a year that the contracts do not cover NKÚ, audit conclusion KZ 23/05. And availability that nobody measures is just a wish: the Ministry of Finance (MF) set it as a parameter of two projects and then was unable to evaluate it NKÚ, audit conclusion KZ 15/31.

    Penalties that hurt, and a report you read

    Token penalties and a missing report are among the most common mistakes. An SLA without them is like a car warranty that nobody enforces. The contract should include:

    • contractual penalties or discounts on the fixed monthly fee, graduated by priority and repetition, with the right to terminate the contract for repeated breaches,
    • a monthly report: incidents by priority, compliance with time limits, availability, open problems, hours used, plus a regular meeting,
    • the report as a condition for invoicing the fixed monthly fee,
    • the customer confirms the closing of an incident, and repeated P1 incidents lead to a root cause analysis.

    Whether the servers are run by the vendor, by you, or in the public cloud, admin access, monitoring, and logs should be available to you. Without your own access and data, you remain dependent on the vendor (chapter 24).

    An untested backup is not a backup

    Ask when a restore from backup was last tested and how long it took. The contract should include the RPO (how much data you can afford to lose), the RTO (how long recovery may take), and a restore test with a written report at least once a year. A proven rule for backups: 3 copies, 2 types of media, 1 off-site.

    How it goes wrongHow to do it right
    How it goes wrongThe SLA guarantees only response time.How to do it rightThree time limits for each priority: response, restoration, resolution.
    How it goes wrong“99.9% availability” without a definition.How to do it rightWhat an outage is, where and how often it is measured, exclusions, and access to the monitoring data.
    How it goes wrongThe vendor sets the incident priority.How to do it rightPriorities in an annex to the contract; disputes are resolved by the escalation procedure.
    How it goes wrongNew features get pushed through the fixed monthly fee for support.How to do it rightIncidents in support; changes through change control and the budget for further development.
    How it goes wrong24×7 for everything, “just to be safe.”How to do it right24×7 only for P1 or critical parts, 8×5 for the rest.
    How it goes wrongToken penalties, no report.How to do it rightGraduated penalties, termination for repeated breaches, a monthly report as a condition for invoicing.

    Questions

    Questions for the vendor

    1. What response, restoration, and resolution times do you guarantee for P1 to P4, and within what support hours do they run?
    2. How and where do you measure availability, what counts as an outage, and will we have access to the monitoring data?
    3. Who sets the incident priority, and what does the escalation procedure look like if we disagree?
    4. What makes up the price difference between 8×5 and 24×7?
    5. When did you last test a restore from backup, and how long did it take?
    6. How many of your people actually know the system, and who stands in for a key person on vacation?
    7. Which of your subcontractors have access to the system and the data?

    Solutia video