Managed IT is the part of the relationship that starts after everyone else has gone home. A system was chosen, implemented and handed over; from that point what matters is whether it keeps running, who answers when it does not, and whether the answer arrives from someone who understands why it was built that way in the first place.
We treat managed services as the continuation of the advisory relationship rather than a separate product sold by a separate team. That has one commercial consequence worth stating up front: because we do not earn a margin on your software licences, keeping your existing platform running well is not a conflict of interest for us.
A system the business cannot operate without depends on one person's availability, and that person takes leave. Incidents are resolved but never explained, so the same one returns. Your internal team spends its week on keeping things alive rather than on the work you hired them for. A platform was implemented by one vendor, integrated by another, and neither will own a problem that sits between them. Or you have just gone live and discovered that the implementation contract ended at handover while the need for help did not.
You have an internal team with genuine depth on the platforms in question, documented runbooks, and cover for absence - in which case what you may want is escalation support for the specific systems where that depth runs out, not a full managed arrangement. Or the systems in scope are not actually critical, and an incident costs you inconvenience rather than money, in which case a managed contract is insurance against a risk you are not running. We will say so; the trade-off between managed and in-house is set out in our article on how consulting, systems integration and managed services differ.
We start with what has to keep running and what it costs you when it does not - by system, by process, by hour. That conversation, not a service catalogue, is what determines the shape of the arrangement. A system whose outage costs you a morning and one whose outage stops invoicing do not belong under the same commitment.
We assess the current estate honestly, including the parts we did not build: what is supported, what is out of support, what depends on one person, and where the real fragility sits. Where the right answer is that you should keep this in-house, or take it to the platform vendor directly, we say so - there is no licence margin behind our recommendation.
You receive a written proposal setting out which systems are covered, at what commitment, through which escalation path, and what is explicitly out of scope. The out-of-scope list is the part worth reading closely, in our proposal and in everyone else's.
Onboarding covers access, monitoring, documentation of the environment as it actually is rather than as it was designed, and an agreed incident and escalation path with named contacts on both sides before the first incident.
Managed IT is stage 5 of our consulting methodology rather than a product beside it. The same relationship covers the decisions that arrive with operation - renewals, capacity, the next system that has to talk to this one - which is the reason the arrangement is worth more than a ticket queue. Where a decision turns into a project, that is IT strategy work and is scoped separately.
A documented inventory of the systems in scope and what each is critical to. Monitoring and alerting on those systems. A single agreed intake and escalation path with named contacts on both sides. Incident response against the commitment set out in your agreement. Documented root-cause analysis on significant incidents, so a recurring problem becomes a fixed one. A regular service review against what actually happened rather than against a dashboard. And a documented exit position, so the arrangement is one you could leave.
Onboarding length depends on how many systems are in scope, what access has to be provisioned, and how much of the current environment is documented. It is scoped and dated in the proposal before you commit.
Managed IT is a continuing arrangement rather than a project fee: it is priced per period against the systems in scope and the commitment level attached to them, and it is contracted separately from any implementation work so that support is not bundled into a build you have already paid for. Adding or removing a system changes the scope and therefore the fee, in both directions. We do not earn a margin on your software licences, so a recommendation to consolidate or retire something reduces our own revenue rather than protecting it - put the same question to every other provider you are considering, because it changes what their advice is worth.
Organisations running a business-critical platform without internal depth on it. IT managers whose team is consumed by keeping the lights on. Finance and operations leaders who need a predictable operating cost in place of unpredictable incident spend. Multi-site operators whose systems are supported inconsistently across locations. And organisations that have just completed an implementation and are discovering that the implementation contract ended where their need for help began.
Where our clients have approved publication, the engagement is written up on our success stories page with the detail they approved. That page, not this one, is where the record lives, and it is deliberately not a complete record - most clients in regulated sectors do not publish. The absence of a story matching your situation is evidence about permission, not about experience. Ask in a first conversation and, where the client agrees, we will put you in touch with them directly.
Onboarding, not implementation, is the right word - the systems already exist. What drives its length is how many are in scope, how much access has to be provisioned and approved, whether the environment is documented, and whether monitoring already exists or has to be introduced. The last of those is usually the long pole, because monitoring a system properly requires understanding what normal looks like for it. We scope and date onboarding in the proposal.
For a managed arrangement the recurring fee is the visible line, and the ones that matter alongside it are: the internal time you still spend, which never falls to zero and should be estimated honestly; whatever is excluded from the agreement and therefore billed separately, which is why the out-of-scope list deserves more attention than the coverage list; the cost of the incidents the arrangement does not prevent; tooling or licences the provider requires you to hold; and the cost of exit - what it would take to move to another provider or back in-house, including whether documentation and monitoring configuration leave with you. Compare that whole set against the fully-loaded cost of the internal alternative, including cover for absence and the recruitment risk, rather than against a headline rate.
A managed arrangement creates a specific obligation that project work does not: a third party holds standing access to your systems and, through them, to your data. The instruments that most often bind that in the Kingdom are the Personal Data Protection Law, administered by the Saudi Data and Artificial Intelligence Authority (SDAIA), which governs how personal data is processed and transferred and treats a processor's access as in scope; the National Cybersecurity Authority's controls, where the organisation is a national or critical entity, which reach the third parties operating its systems; and ZATCA's requirements where the systems under management touch invoicing or tax records. The questions to settle in the agreement rather than the datasheet are: where support data and logs are held, who specifically holds standing access and how it is reviewed, what happens to that access at termination, and where any remote support session terminates.
The real alternatives to a managed arrangement are: keeping it in-house and investing in the depth and cover to do so; taking support directly from the platform vendor, which is often the better answer for a single product; a hybrid where your team holds the first line and we hold escalation on the systems where their depth runs out; and doing nothing, which is a legitimate choice for systems whose failure is merely inconvenient. We assess those against what an outage actually costs you, and we will recommend one of the first four over our own service where it fits better. The comparison is set out at more length in consulting vs systems integration vs managed services.
That is the premise rather than a caveat - a managed arrangement exists to keep what you already run running. Two practical qualifications: a system that is out of vendor support can be monitored and maintained but cannot be patched, and that limit belongs in the agreement rather than in a later conversation; and where a system exposes no usable monitoring interface, coverage on it is necessarily reactive. Both are assessed and written down before the arrangement starts, not discovered during the first incident. Where the problem is that systems do not talk to each other, that is systems integration work rather than support.
We name a client only where that client has agreed to be named for the specific purpose, and in managed services that permission is rarer than elsewhere for an obvious reason: naming who operates an organisation's critical systems is itself security-relevant information. The organisations who have agreed are on our customers page, maintained against those permissions rather than assembled for this page. If you would like a reference from an organisation of comparable size, sector or system criticality, ask during a first conversation - we will approach a suitable client and put you in touch directly if they agree.
Our published record is on the success stories page. It carries the engagements our clients approved for publication, with the detail they approved, and it contains no anonymised composites. Managed arrangements are under-represented there relative to project work, because the thing a support relationship produces is the absence of incidents, which does not photograph well and which clients rarely see a reason to publish. The constraint is publication, not disclosure to a prospective client under an appropriate agreement.
Client feedback we have permission to publish appears below this page's content and on our customers page. No quotation is written into this section, and the absence is deliberate: we do not publish a client quote until the client has reviewed and approved the exact wording attributed to them, for the specific place it will appear. For a support arrangement the useful reference is not a quotation anyway - ask for a call with the person who raised the last serious incident, and ask them how long it took and what they were told while they waited.
Our current vendor relationships, accreditations and the certifications our consultants hold are published on the partners page. We keep them there rather than restating them in service copy, because partner tiers and individual certifications change and a page asserting a status it can no longer stand behind is worse than one that does not assert it at all. For a managed arrangement the question that matters more than the firm's aggregate status is which named individuals would hold access to your systems, what they are certified on, and whether they are the same people next quarter. Ask that of us and of everyone else.
A first conversation is a review, not a pitch: which systems cannot be down, what an outage actually costs, and whether a managed arrangement, an escalation-only arrangement or an investment in your own team is the right answer. If it is one of the last two, we will say so. Book a decision session to start there.