Sun–Thu team, Mon–Fri vendors: setting SLA targets

If your service desk sits in Riyadh, Doha, Kuwait City, Muscat or Manama, your week runs Sunday to Thursday. Your cloud provider, your ERP partner and your hardware maintainer almost certainly run Monday to Friday.

On paper both sides work a five-day week. In practice you share four days, and fewer hours than you think on each of them. Most SLA documents in the region are written as if that gap doesn't exist. Then a vendor-dependent incident logged on a Thursday afternoon breaches on Monday, and nobody can explain why.

This isn't a scheduling curiosity. It decides whether the targets you promise the business can be met at all.

The week you actually have

Lay the two calendars side by side and there are four kinds of day:

That's two days a week where only one side is at work. And the hours shrink further once time zones come in.

A worked example (illustrative, not a benchmark). Your desk works 08:00–17:00 Riyadh time (UTC+3). A UK vendor works 09:00–17:30 London time, which is 12:00–20:30 in Riyadh in winter. The overlap is 12:00–17:00: five hours a day, four days a week. That's 20 hours of genuinely joint time in a week where your desk is open for 45. In British summer time the overlap grows by an hour. With a vendor in India (UTC+5:30), the overlap moves to your morning instead.

Now run a Thursday incident through it. A P3 that needs the vendor is logged at 15:00 on Thursday. Your desk has two hours left before the weekend. The vendor works Friday, but nobody on your side is there to test a fix or answer a question. Sunday the vendor is off. Joint time starts again at 12:00 on Monday. By then your business-hours clock has run for 15 hours (two on Thursday, nine on Sunday and four on Monday morning) and the two sides have spent just two of those hours working together.

If your P3 resolution target is two business days (18 hours on this calendar), it breaches at 15:00 on Monday, three hours after both sides are next at work together. The target was realistically gone at 17:00 on Thursday.

Why the usual fixes make it worse

Measuring the SLA on the vendor's calendar. Some teams quietly set the service desk clock to Monday–Friday so it matches the supplier. Now your Sunday doesn't count, and your users, who work on Sunday, get a target that ignores a day they're working. The SLA exists for the customer, so it runs on the customer's calendar.

Pausing the clock for "awaiting supplier". Most ITSM tools let you pause an SLA while an incident waits on a third party. Used by default, it makes your compliance figure look fine while the user waits four days. A pause is fair when you're waiting on the user, because they control that time. Waiting on your own supplier is your problem, not theirs. If you do pause for suppliers, report the paused hours next to the compliance figure, or the figure is fiction.

Copying "next business day" into the underpinning contract. For a vendor, next business day from Thursday is Friday, when your desk is closed. The contract is met, and for the business nothing has happened.

Rules that hold up

From leading IT operations across the Middle East and Africa, and holding SLA compliance at 98–99% across five regulated sectors, these are the rules I'd put in any SLA and OLA set where the working weeks don't match.

1. One customer clock, on your calendar. Measure every service desk SLA in your own working week, public holidays and Ramadan hours. Don't bend it to the vendor.

2. Split targets by dependency, not just priority. An incident your team can resolve alone and one that needs a supplier are different promises. Give vendor-dependent P3 and P4 incidents their own resolution target, and set it from the joint hours in your week, not the calendar hours.

3. Write the vendor's obligations in your time. Every underpinning contract states response and resolution targets in your working hours and time zone, or states plainly which of your days it doesn't cover. If Sunday matters to you, pay for Sunday cover, or accept that Sunday is a dead day for vendor-dependent work and set your targets to match.

4. Make Friday useful. Anything vendor-dependent that's still open at midday on Thursday goes to the vendor before your desk closes, with everything they need to work alone: logs, screenshots, reproduction steps, a named contact, and what they're allowed to do without asking. A vendor with a complete handover pack can use Friday. A vendor waiting for an answer can't.

5. P1 runs 24 × 7 on both sides, and check it really does. Confirm the vendor's critical support covers their weekend, and that your on-call rota covers Friday and Saturday. A P1 during the window where one side is asleep is exactly where major incidents lose the business's trust (see why a P1 is a trust event).

6. Put both holiday calendars in. Eid al-Fitr, Eid al-Adha and National Day don't line up with Christmas, Easter or Diwali. Each is a day when one side is out. Load your holidays into your SLA schedule and the vendor's into your OLA review, then plan cover for both in the same place.

7. Review the overlap in every service review. Report vendor-dependent incidents separately: how many, how long they waited, and how many were logged on a Thursday. If Thursday incidents breach far more often than the rest, your handover pack or your contract needs fixing, not your engineers.

A note for the UAE: most private-sector teams there now work a Monday–Friday week, so they line up with European vendors. The gap moves inside the organisation instead. A Dubai hub supporting users in Saudi Arabia or Qatar has the same four-day overlap with its own customers.

Before you sign the SLA: a checklist

• The SLA clock runs on the customer's working week, holidays and Ramadan hours.
• Vendor-dependent incidents have their own resolution target, set from joint hours.
• Every underpinning contract states its targets in your time zone and working week.
• Sunday cover is either in the contract or excluded from your targets on purpose.
• A Thursday handover pack exists, and the vendor has agreed what it can do without you.
• Vendor P1 support covers their weekend. Your on-call covers Friday and Saturday.
• Both sides' public holidays are in the calendar, reviewed each year.
• "Awaiting supplier" pauses, if you use them, are reported alongside compliance.
• Service reviews show vendor-dependent and Thursday-logged incidents separately.

Check your own numbers

Set up your team's working week in the free GCC Business Hours calendar. The Saudi, Qatar, Kuwait, Oman and Bahrain presets are already Sunday–Thursday. Then build the vendor's week as a custom calendar, with their hours converted to your time zone, and export both. Compare them day by day to count your joint hours.

Then take a vendor-dependent incident that breached and replay it in the SLA clock. Look for the moment it was really lost. With mismatched weeks, it is often a Thursday afternoon that nobody noticed until Monday. Both tools run in your browser. Nothing you enter leaves your machine.