How we work, from first call to handover.
You get senior engineers who learn your business properly, then write down what the work is before they touch it. Whether you are fixing a problem or improving a setup that already runs, the standard is the same.
We map the business, not run a checklist.
Most firms run you through the same onboarding form they run everyone through. We do the opposite. Before we recommend anything, we learn how your business actually runs: where permissions have crept, what your IT spend is buying, and how the departments lean on each other. The plan comes out of your business, not a template someone reuses.
Our clients run from family firms where one person holds every IT decision to large, regulated organisations with a long list of people who have to agree. The platforms differ, the pressures differ, the right route differs. What stays the same is that the work is agreed and priced in writing before it starts, and our own engineers carry it out.
You'll see it work before you have to rely on it.
Before anything is built.
Nothing gets designed until we know how your business runs. The plan follows that, in an order you sign off, not a template we reach for on every job.
Not promise.
Backups restored. Failover tested. Controls written down. You get the evidence handed over, not a reassurance.
Five ways to bring us in.
Fully managed.
We run the platform for you against terms agreed up front, with our own engineers on the account. You get the firm's full bench, not one pair of hands, and the work is never handed to a third party.
Named engineer.
An engineer who knows your environment and is yours to call, backed by the rest of the team behind them. The same person who learned your setup is the one who picks up when something does not add up.
Fixed-fee project.
A defined piece of work for an agreed figure, settled before anything starts. It has a defined start, end and handover. Plenty of clients start here and then keep us on a named engineer or fully managed once they see how we work.
Migrations and business events.
Cloud and server migrations, tenant-to-tenant moves, mergers, relocations. We have moved an entire data centre to another country. Closed properly, with the old environment switched off and the new one trusted.
Focused review.
An engineer works through part of the environment, writes up what they find, and tells you what to fix and in what order. You get a clear read and the evidence behind it, with no obligation to take the next step with us.
An engagement, first call to handover.
It starts with a call to a senior engineer and ends with a handover your team can run from. The stages below are what sits between.
A first call with an engineer.
No account manager reading off a discovery script. You describe what you run and what prompted the call, and we tell you how we would approach it.
We read the platform as it runs.
We take the platform as it runs in production, alongside the people who own it day to day. We read the configuration in front of us, set what is documented against what is actually on the box, and learn where the business is exposed. Not an automated tool sweep filed by someone who never returns to the system.
A written read, backed by evidence.
You get the findings in writing, what matters most, and the order we would fix it in. Written so an engineer can act on it and a board can follow it, with the evidence behind each call rather than an assertion. The pace is set with you, not assumed.
The fixes, by the engineers who scoped them.
What we will do, the timing and the figure are agreed in writing before the next piece of work begins. The engineers who already know your environment carry out the fixes, so you are not paying a second team to learn it from scratch.
Handover your team can actually run.
A walkthrough with whoever needs to be in the room, documentation an incoming engineer can act from, and the decisions logged against the reasoning behind them. Where the business is continuity-sensitive, every change is traceable and signed off. From there we stay on where you want us, and step back where you do not.
Talk to an engineer who can assess your environment in detail.
You leave the call with a direction and the sensible routes. A written quote follows, scoped to your environment rather than a standard package.
Four things we commit to.
In-house engineers, start to finish.
No sales tier to clear before you reach someone technical, and no work quietly subcontracted out. The people who hear your setup described are the ones who carry it through to delivery. Where a physical site visit is needed, they are vetted hard, fully insured, and supervised.
Scope and figure written down before work starts.
On a fixed-fee project the figure is agreed up front. On a named engineer or fully managed, the terms are written down. No open-ended billing, no contingency line standing in for a number we would not commit to. If something needs to change, we name it on paper before the engineering changes with it.
Evidence, not a tool export reformatted as a deck.
You get a real record: diagrams that match production, decisions logged against the reasoning behind them, runbooks down to the credentials and the people who hold them. For regulated work, every requirement is met with proof rather than a tick in a box, and it is handed over in a form your team can keep current.
We own our part and work alongside the rest.
We take the Microsoft and infrastructure side cleanly and work alongside your other suppliers on the rest. On a marketing campaign, for example, we handle email deliverability (SPF, DKIM and DMARC) and leave the campaign itself to your marketing firm. Where it crosses into cybersecurity, Factor1, our cybersecurity subsidiary, picks up that side.
What an experienced engineer catches before it bites.
Three problems that a summary screen reports as healthy, which our engineers check in full before acting.
The FSMO role still living on the server marked for retirement.
Five domain controllers, one of them quietly holding the PDC emulator, all slated for refresh in the same window. No health dashboard flags it. We checked role placement before scheduling a single reboot.
An account sitting outside MFA on an exclusion nobody remembered.
A temporary carve-out from two years back, still on the conditional access policy, still applied to an account whose owner left long ago. We read the exclusion list against current owners, not just the rule that is switched on, because stale exclusions are typically found there rather than in the active rule.
A compliance policy whose exemption group had swallowed half the business.
The summary view said the device compliance policy was targeted correctly. The exemption group, meant for a handful of users, had grown to cover far more than it should. We found it by opening the policy in full, where the summary view does not surface it.
Speak to a senior engineer who would run it.
The introduction call is the quickest route to a useful answer, but the lines below all reach a senior engineer. Tell us what you run, including anything you are unsure about, and you will get a clear read on what we would tackle first.
