L1, L2 and L3 application support and 24x7 follow-the-sun operations across our GCC and global delivery pods. One ticket queue. Three time zones. SLA-backed, audit-ready, exit-friendly, the way we would want it run for ourselves.
Follow-the-sun coverage
Live- On call
Delivery pod A
Shift 1
--:--:--
- On call
Delivery pod B
Shift 2
--:--:--
- On call
Delivery pod C
Shift 3
--:--:--
- Production estates run
- 0+
- Incidents handled / year
- 0
- Average SLA attainment
- 99.4%
- Years running 24/7
- 0
SLA tiers
Three commercial shapes. Pick the one that matches the cost of an outage.
Every tier ships with named people, written response times and an escalation path you can read out in a board meeting. Move up or down a tier per quarter, no penalty.
Bronze
- Coverage
- 8 x 5 (local business hours)
- P1 response
- P1 within 30 min
- P2 response
- P2 within 2 hours
- Best for
- Stable platforms, internal users, predictable load
- L1 + L2 application support
- Single time-zone delivery pod
- Email + portal + voice channels
- Monthly service review
Silver
- Coverage
- 16 x 6 (two-shift coverage)
- P1 response
- P1 within 15 min
- P2 response
- P2 within 1 hour
- Best for
- Customer-facing platforms, GCC operating windows
- L1, L2 and queued L3 support
- Two shift pods (GCC + global)
- On-call rotation for after-hours P1
- Bi-weekly service review + monthly QBR
Gold
- Coverage
- 24 x 7 x 365
- P1 response
- P1 within 10 min
- P2 response
- P2 within 30 min
- Best for
- Revenue-bearing platforms, regulated workloads, global users
- L1, L2, L3 with named reservists for L4 vendor escalation
- Three follow-the-sun pods across GCC and global delivery
- Dedicated incident commander on P1 bridges
- Weekly service review, monthly QBR, quarterly DR rehearsal
Follow-the-sun model
Our early pod starts the day, hands to the GCC pod, who hand to the late pod, who hand back. No ticket sleeps in a queue. No engineer is paged at 03:00 unless the system genuinely warrants it.
24-hour coverage map (UTC)
Overlap = warm handoff
Early pod Global ops
02:30 - 14:30 UTC
GCC pod GCC ops
05:00 - 17:00 UTC
Late pod Global ops
13:00 - 01:00 UTC (next day)
What’s in scope
Five operating areas. Run as one contract.
01
Application support (L1 - L3)
- Shared service desk in your ITSM tool of record
- L1 triage, L2 functional fix, L3 development support
- Release-manage hotfixes through your change board
- Knowledge base maintained, not just inherited
- Documented run-the-bank vs change-the-bank split
- Vendor co-management (SAP MaxAttention, Oracle SR, Microsoft Premier)
02
Incident response
- Severity matrix agreed with your service owners
- P1 war-room within ten minutes, 24/7
- Hourly stakeholder updates on a single channel
- RCA published within five business days
- Problem records tracked to closure, not just opened
- Game-day rehearsals at least once a quarter
03
Capacity & cost
- Tag governance and unit-cost dashboards
- Right-sizing of compute, storage and database tiers
- Reserved-instance and savings-plan portfolio review
- License harvesting (SAP, Oracle, Microsoft, Adobe)
- Forecast vs actual review every month
- Sustainability and carbon reporting on request
04
Compliance & audit
- ISO 27001, HIPAA and PCI-DSS evidence trails
- Quarterly access recertification with sign-off
- Change advisory board minutes, archived seven years
- GDPR, PDPL, CCPA data-subject request handling
- Vendor-risk assessments on the platforms we operate
- Auditor liaison so your team isn't the buffer
05
DR & BC
- Tiered DR design (hot, warm, cold) per workload
- Backup health verified weekly, restore tested monthly
- Two live DR rehearsals per year with measured RTO / RPO
- Runbook-driven failover, no hero engineers
- Crisis comms templates pre-approved by Legal and PR
- Post-rehearsal report for the audit and the board
The runbook
Boring is the point.
Every estate we operate has a versioned runbook in your repository. Steps, thresholds, escalation owners, comms templates. Engineers don’t improvise at 03:00 — they execute, write up, and move on.
- RB-014P2
SAP S/4 - Job RWAVE_PROCESS stuck > 30 min
- 1. Confirm in SM37 that job RWAVE_PROCESS is in 'Active' state.
- 2. Check SM50 for related work process; capture stack via /SDF/MON.
- 3. If lock contention in SM12 against table EKKO, escalate to L3 with snapshot.
- 4. Otherwise, kill job, rerun with -recovery flag, monitor 15 min.
- 5. Open problem record if recurrence within 24h. Notify @ops-sap.
- RB-082P2
Maximo - Async work-order publish backlog > 500
- 1. Verify cron mxe.cron.MaxAsyncJobsCron last run < 10 min ago.
- 2. Check queue depth on ASYNC.WORKORDER queue; threshold = 500.
- 3. If JMS bridge down: restart bridge service, verify resync.
- 4. If poison messages > 10: route to DLQ, raise to integration L3.
- 5. Confirm depth back below 100 within 20 min, log in ServiceNow.
- RB-141P1
HIS - HL7 ADT inbound feed silent > 5 min
- 1. Page on-call clinical-systems engineer (PagerDuty schedule HIS-CLIN).
- 2. Check MLLP listener health on ports 6661/6662; restart only if confirmed dead.
- 3. Cross-check upstream ADT system status via vendor portal.
- 4. If gap > 15 min, declare clinical incident, notify CMIO duty officer.
- 5. Replay queued messages from store-and-forward after restoration.
Tooling bench
We operate in your stack, not ours.
These are the tools our pods are certified on and run in production today. Bring your own — we’ll skill into it inside the first takeover sprint.
- ServiceNow
- Jira Service Management
- PagerDuty
- Datadog
- ManageEngine
- IBM Maximo Real Estate & Facilities
- Azure Monitor
- Splunk
- Prometheus
- Grafana
- Dynatrace
- OpsGenie
KPIs we report on
Seven numbers your CIO actually cares about.
Reported monthly in a four-page operating review. Trend lines, not vanity charts. The numbers below are the rolling portfolio average, not a peak.
01 · MTTR
32 min
02 · MTBF
94 days
03 · Ticket volume
1,200 / wk
04 · SLA attainment
99.4%
05 · Change success
98.7%
06 · Customer CSAT
4.7 / 5
07 · Cost per ticket
-22% YoY
Live operating review
Sectors we run for
Estates that don’t allow downtime.
Hospital wards, oil fields, trading floors, retail tills, government citizen services. Pick the one closest to yours and we’ll bring the pod that has shipped it before.
Common questions
What buyers ask before they sign.
Q.01
How does handover from our incumbent provider work?
We run a 6 to 10 week shadow-and-takeover. Two weeks of read-only shadowing, two weeks of paired ticket handling, then primary with the incumbent on standby. Knowledge artefacts, ticket history and runbooks are imported into our ITSM of record on day one - no information held hostage at exit.
Q.02
Are we locked into your tooling stack?
No. We operate in your ITSM, your monitoring stack and your cloud accounts wherever possible. If you don't have one, we stand up ServiceNow or Jira Service Management under your tenancy and hand the admin keys over from day one. Every dashboard, runbook and integration is yours.
Q.03
Do you support on-prem, private cloud and hyperscaler equally?
Yes. About 38% of the estates we run today are on-prem or private-cloud, the rest are AWS, Azure or GCP. Our pods rotate across all three weekly, so the muscle memory stays sharp on both worlds.
Q.04
What's the exit clause?
Standard contract carries a 90-day termination-for-convenience clause and a 60-day reverse transition obligation, with all artefacts handed back in machine-readable form. We have run six exits in the last four years - none of them clawed back, which we take as the only honest scoreboard.
Q.05
Where does our data sit and who can touch it?
Production data stays in your tenancy. Our pods access it through your IDP (Okta, Entra ID, Ping) under named accounts with just-in-time elevation. Data residency follows your contract: GCC and other sovereign-cloud zones supported. PDPL, GDPR and HIPAA controls audited annually.
Independent assurance
ISO 27001 certified; HIPAA-ready, PDPL and GDPR compliant.
Related practices
