Week one
Access and documentation
Monitoring agents installed, the environment documented asset by asset, and administrative access handed over with proper controls and a named owner.
Install process & service commitments
What working with us looks like
Onboarding, response targets, out-of-hours cover and escalation — written down before support begins, not after.
Service levels · onboarding · out-of-hours · escalation
Read the agreement termsNo adjectives, just mechanics
Most IT providers describe the service and leave the mechanics vague
This page exists because the details matter more than the adjectives. Below is how onboarding runs, what the service level agreement commits us to, how out-of-hours cover is arranged, and what happens when something goes wrong and needs escalation.
The first conversation
Before any paperwork, we ask a set of questions: what your business does, how many staff and sites, what systems you depend on, what broke recently, and what you would change if you could. This usually takes forty-five minutes and involves whoever owns IT decisions on your side, which is often not an IT person.
We do not use the call to quote. Its purpose is to establish whether the fit is right — and if your situation calls for something we do not do well, we say that during this stage rather than after a contract is signed.
The technical review
We look at what is actually there
With your permission, we review the Microsoft 365 tenant, licence allocation, endpoint estate, backup configuration, network equipment and any documentation you hold. This is where surprises surface.
-
Expired licences
Subscriptions quietly lapsed, seats assigned to people who left, and Microsoft 365 features paid for and never switched on.
-
Backups that never restore
Jobs that have been reporting success for months but have never been restored to a real machine. We test the restore, not the report.
-
Shared admin accounts
Accounts everyone uses and no one owns — no audit trail, no permission limits, and no way to remove access when someone leaves.
The review stands on its own
You receive a written summary of findings and recommendations, including items you could address yourself without us. Some businesses take the findings and act on them internally, and that is a legitimate outcome. We would rather hand you a useful document than a sales proposal.
Scoping and the service level agreement
The agreement is written before we take over support, not after. It sets out response targets by priority, the hours we cover, what counts as critical, how escalations work, and the boundaries of what is included.
Included in the agreement
Documented separately
- Response targets by priority — P1 through P4, agreed against what we can realistically staff
- Coverage hours for the standard UK working day, with bank holidays named individually
- Which systems we manage, and which stay with an internal team or a third party
- Named contacts on both sides, and the written escalation path for severity one incidents
- Tighter targets than the standard menu — a conversation and a priced option, never a quiet upgrade.
- Extended or overnight coverage — scoped separately, with the on-call rota written down.
- Project work: migrations, hardware rollouts and firewall changes that sit outside the retainer.
- Third-party supplier coordination, where a supplier will not take our instruction without your approval.
Response targets are agreed against what we can realistically staff, so the document means something. Ambiguity about who owns what is the source of most disputes in this industry, and it is the cheapest thing to remove at the start.
Onboarding, week by week
Two to four weeks, in four movements
The order is deliberate: access controls and documentation first, then the settings and security gaps, then the transition, then the review. Larger estates take longer, and we would rather extend the timeline than rush the access controls.
Week two
Settings and security gaps
Microsoft 365 settings aligned with how your team actually works, the most urgent security gaps closed, and backup confirmed by a real restore test.
Week three
Working alongside
We handle support alongside whatever arrangement you had before, so staff get a transition rather than a switch. Calls route the new way before the old one is retired.
Week four
Review and handover
Documentation handed over, open items closed out, and a written confirmation that the service level agreement is being met in practice — not on paper.
Support hours & out-of-hours cover
A failed backup at 9pm is not critical. A payment system that will not process orders is
Standard helpdesk coverage runs through the UK working day, Monday to Friday. Critical incident cover operates outside those hours on a defined basis, with a clear definition of critical written into the agreement: outages preventing work, security incidents, or failures in systems the business trades on.
For organisations that genuinely run around the clock, extended coverage is scoped separately, including how the on-call rota is staffed. We will not sell overnight coverage to a business that closes at 5:30, and we will not pretend that a shared overnight desk is the same as dedicated staffing.
Coverage bands
What counts
-
Working-day helpdesk
Everyday requests, new starters, software changes and general questions, handled during standard UK business hours.
-
Critical cover, outside hours
Security incidents, outages that stop work, and failures in systems the business trades on — routed to an on-call engineer.
-
Extended, round-the-clock
Scoped separately for organisations that genuinely trade overnight, with the rota staffing written into the agreement.
-
Not on the critical list
A failed overnight backup job waits for the morning working window. We log it, and it is resolved at the start of the day.
If you are unsure which band a situation falls into, call us and we will tell you honestly rather than route you into a tracking bucket.
Escalation & named contacts
The path is documented, not improvised
Every client has named contacts on our side: a primary engineer who knows the environment and an account contact for commercial matters. Severity one incidents go straight to a senior engineer, and the account contact is notified without you needing to chase.
If a third-party supplier is involved, we coordinate with them and keep you informed — in practice, one of the most valued parts of the service. You should never have to explain your own infrastructure twice, to two different people, on the same incident.
Named on every account
- Primary engineer
- Knows your environment, your documentation and your staff by name.
- Account contact
- Your route for commercial matters, reporting questions and contract changes.
-
1
First-line helpdesk
Your first call. Triage, fixes where the answer is known, and everything logged as a ticket with a named owner and a running clock.
-
2
Senior engineer
Tickets this side of the line move up without you asking. Severity one incidents go to a senior engineer immediately, with the account contact notified in parallel.
-
3
Third-party coordination
Where the fault sits with a supplier — a line, a hosting platform, a software vendor — we take the calls and chase them, and update you on a regular interval you agreed to.
-
4
Root cause & review
A recurring problem stops being a queue item. It moves to a root-cause exercise, and the finding comes back to you in the next review rather than in another closed ticket.
Response targets are written for each of these tiers against the priorities agreed in the service level agreement, so "escalated" means a named engineer with a clock, not a louder request.
Reporting, change control and honesty
You are entitled to see how we are performing
The reporting exists so you can check, rather than trust.
Monthly report
Tickets raised and resolved, response times against target, patch compliance, backup status, and any security alerts worth noting. Reports are for reading, not filing, so we keep them short enough that you will actually open them.
Quarterly review
We meet to look at the wider picture: capacity, licensing, risks, and anything on the horizon that affects your plans. Annual planning tends to cover budget, hardware refresh and security posture.
Change control
Request, assessment, schedule, implementation, record. The purpose is not bureaucracy; it is to make sure changes are reversible and documented, which matters enormously during an incident.
When something goes wrong
We will make mistakes, and so will your other suppliers. What matters is the response. Incidents are logged, communicated and reviewed, and a response target that gets missed is told to you before you notice it — with the reason.
For anything touching security controls or core infrastructure, we ask for written approval before we touch it. For routine changes — a new starter, a software deployment, a firewall rule — the process is deliberately light.
Businesses that engage with the review cycle get more out of the agreement than those that only call when something breaks. A managed service that resolves the same issue every month is not managing anything.
Where to go next
Start with an honest read of what you have
The first conversation costs you forty-five minutes and no commitment. The technical review that follows is written so that it stands on its own, whether or not you go on to work with us. Call +442074093251 during working hours, or email our team and we will come back to you the same working day.
The White Chapel Building, 10 Whitechapel Road, London, E1 1EW · Monday to Friday, 9:00 AM – 6:00 PM