Engineering capacity is consumed by support
The team that should be building is absorbed by incidents, requests and interruptions, so roadmap commitments slip for reasons that never appear on the roadmap.
Managed IT services and application support
Support arrangements are usually judged on responsiveness. The better measure is whether the volume of work falls over time. We operate systems against a defined agreement and treat recurring incidents as defects to remove, not as workload to staff.
Business challenges
Managed services are commissioned when operating the estate has started to consume the capacity meant for building it.
The same incidents recur
Each is resolved competently and none is removed, so ticket volume is stable at a level nobody chose and improvement work is never scheduled.
Knowledge sits with individuals
Certain systems are understood by one person. Their absence is an operational risk, and their departure is an incident waiting for a date.
Nobody can say what the service level actually is
Response and resolution are discussed as impressions because they were never defined, measured or reported against a target.
Monitoring reports symptoms, not impact
Dashboards show resource utilisation while the question being asked is whether customers can complete a transaction.
Out-of-hours coverage is informal
Nights and weekends depend on someone answering a message. It works until the occasion it does not, which is usually the occasion that matters.
Business outcomes
What changes when operations are engineered rather than staffed.
- Engineering capacity returned to roadmap work rather than absorbed by interruptions
- Ticket volume falling over time because recurring causes are removed, not staffed
- Operational knowledge held in runbooks rather than in individuals
- Service levels defined, measured and reported against an agreed target
- Monitoring that reports business impact rather than resource utilisation
Why we measure a managed service by its shrinking workload
A support arrangement paid by volume has no incentive to reduce volume.
The conventional managed service is priced against tickets, seats or hours. That structure quietly rewards the persistence of the work: every recurring incident is billable, and the effort required to eliminate it is a cost the provider carries with no return.
We hold the opposite position. Recurring incidents are defects, and removing them is part of the service rather than a separate project. The measure of the engagement is whether the volume of unplanned work falls, which is also the measure your team would apply if they were doing it themselves.
That also shapes the exit. We document as we operate, so ending the arrangement is a handover rather than a dependency you have to unwind.
Our consulting approach
Four commitments that shape every managed engagement.
Reduction, not absorption
Recurring incidents are treated as defects with a root cause and a fix, not as a workload to be staffed indefinitely.
Runbooks over individuals
Operational knowledge is written down as it is acquired. Knowledge held only by a person is an availability risk with a name.
Service levels that are measured
Response and resolution targets are defined per severity and reported against actuals, including the months we miss them.
Exit by design
Documentation, access and automation are structured so the arrangement can end cleanly. Lock-in is not a retention strategy we use.
Defining the service
Most disputes in managed services are scope disputes that were latent from the beginning. What is covered, what is explicitly not, what constitutes a request versus a change, and who decides — all of it is cheaper to settle before the first incident than during one.
We define scope against systems and business processes rather than against a headcount, and we write down the exclusions as plainly as the inclusions.
- Covered systems named individually rather than described in general
- Exclusions written as plainly as inclusions
- Request, incident and change distinguished, with different paths for each
- Decision authority stated for each category of work
Transition and knowledge capture
Transition is where a managed arrangement is won or lost. Taking over a system that is understood only informally, without capturing that understanding, reproduces the original risk with a different party carrying it.
We run transition as a documentation exercise: architecture, dependencies, failure modes, recovery procedures and the informal knowledge that has never been written down. The artefacts belong to you from the first day.
Application support
Application support spans triage, defect resolution, configuration and the small changes that keep a system fitting the business it serves.
The distinction that matters is between fixing an instance and removing a cause. We track both, and we report the ratio, because a support function that only fixes instances is a permanent cost centre by construction.
- Triage against defined severity, not against who reported it
- Root cause pursued for recurring defects rather than instance fixes alone
- Small changes delivered under the same controls as any other change
- The ratio of causes removed to instances fixed reported openly
Infrastructure and cloud operations
Infrastructure operations covers capacity, patching, backup verification, certificate lifecycle and the configuration drift that accumulates in every estate that is changed by hand.
We prefer estates defined in code, because they can be reproduced and drift can be detected. Where the estate is not there yet, moving it in that direction is part of the improvement programme rather than a precondition for starting.
- Patch cadence agreed per class of system, with exceptions named
- Backups verified by restore rather than by job status
- Certificate and credential expiry tracked before it becomes an incident
- Drift detected between declared and actual state where the estate allows it
Monitoring and observability
Monitoring that reports resource utilisation answers a question nobody is asking during an incident. The question is whether the business process is working, which requires instrumenting the process rather than the server.
We define the small number of signals that indicate real impact, alert on those, and route everything else to a dashboard. An alert that does not warrant waking someone should not be able to.
Incident and problem management
Incident management restores service. Problem management removes the cause. Organisations that fund only the first are surprised that volume never falls.
We run both: a defined response path with severity, escalation and communication, and a review practice that examines the conditions which made the failure possible. Actions are tracked to completion, because a review nobody implements is documentation rather than a control.
- Severity defined by business impact rather than by technical component
- Escalation and communication paths agreed before they are needed
- Review focused on conditions rather than on individuals
- Remediation actions tracked to completion and reported
Service levels and reporting
A service level that is not measured is a statement of intent. We define response and resolution targets per severity, measure against them, and report actuals — including the periods we miss.
Reporting also covers what the numbers do not: ticket volume trend, recurring causes, work eliminated, and the improvement items that are queued but unfunded. Those tell you more about the direction of the service than a compliance percentage does.
Continuous improvement
Improvement is scheduled work, not spare capacity. Where it depends on quiet weeks, it does not happen, because quiet weeks are when deferred work is caught up.
We allocate a defined portion of the engagement to eliminating recurring causes, automating manual procedures and closing documentation gaps, and we report what that allocation produced.
- A defined allocation to improvement rather than whatever capacity remains
- Recurring causes prioritised by volume and business disruption
- Manual runbook steps automated in order of frequency
- The result of the allocation reported, not assumed
Security in day-to-day operations
Most security exposure in an operated estate is created by routine activity: an access grant that is never removed, a certificate that lapses, a patch deferred past the point anyone remembers deferring it.
Operations therefore carries security responsibilities: access review, patch cadence, secret rotation and audit trail. Control design is cybersecurity consulting; this is the discipline of running to it.
Backup, recovery and continuity
Backup arrangements are frequently confirmed by the presence of successful jobs. The only meaningful confirmation is a restore, performed on a schedule, timed against the recovery objective.
We verify recovery rather than backup completion, and we test whether the arrangement survives the scenarios it exists for — including those where the backup system shares a failure domain with the estate it protects.
Third-party and vendor coordination
A meaningful share of operational effort in any real estate is spent not on your systems but on the parties around them: software vendors, connectivity providers, cloud support and the integrations between them. Where nobody owns that coordination, incidents stall between organisations each waiting on the other.
We take that coordination as part of the service. That means holding the vendor case, establishing which party is accountable for a given failure, and escalating on your behalf — including when the honest answer is that the defect is not ours to fix.
- A named owner for every vendor case rather than an assumption someone is chasing it
- Accountability established early so an incident does not stall between parties
- Support entitlements and escalation routes recorded before they are needed
- Vendor-caused recurring failures reported to you rather than quietly absorbed
Bringing new systems into the service
Estates grow, and a managed service that only covers what existed at signature drifts out of usefulness. New systems need a defined route into scope rather than an informal expectation that support will absorb them.
We define acceptance criteria for that route: documentation, monitoring, runbooks and a recovery procedure must exist before a system enters the service. Applied consistently, that criterion also raises the standard of what your teams build, because it is known in advance.
Service governance
Governance keeps the arrangement honest. A regular review that examines trend rather than compliance percentage, a change advisory path proportionate to risk, and a route for raising that the service is not working — used without friction.
We also review scope periodically, because estates change and a scope agreed two years ago describes a system that no longer exists.
Commercial model and exit
Managed services are delivered through a transparent subscription. Pricing is published, includes GST, and does not vary with how much of the service you use, because volume-linked pricing rewards the persistence of the work.
Exit provisions are agreed at the start: notice period, handover artefacts and access transfer. An arrangement you cannot leave is not a service.
What you receive
A defined service, an operating baseline, and a reduction programme — not simply a queue with people attached.
- Service definition with covered systems, exclusions and decision authority
- Transition documentation: architecture, dependencies, failure modes, recovery steps
- Runbooks for every recurring operational procedure
- Monitoring and alerting design based on business impact rather than utilisation
- Incident and problem management process with severity and escalation defined
- Service level targets, measured, with actuals reported including misses
- An improvement backlog with a defined allocation and reported results
Engagement models
Initial project design
Engaged before significant code exists, when structural decisions are still cheap to change. Produces the target-state architecture, the technology selection rationale, and a sequencing plan the delivery team can execute.
Mid-project assistance
Engaged when delivery has slowed, costs are rising, or a design that fitted the original problem no longer fits the current one. Diagnostic first: we establish what is actually causing the drag before recommending change.
Ongoing support
A named architect available as the system evolves, covering design review, technology decisions and course correction. Delivered under a subscription rather than a fixed project scope.
Enterprise delivery
How a managed engagement starts and runs.
Free first consultation
Your estate, current support arrangement and the work that is consuming engineering capacity.
Assessment and baseline
Current ticket volume, recurring causes, documentation gaps and operational risk, established before targets are agreed.
Service definition
Scope, exclusions, severity model, service levels and commercial terms, including exit.
Transition
Knowledge capture, runbook authoring, access and tooling setup, with a defined point at which the service starts.
Steady state
Operations against the agreement, with a scheduled allocation to eliminating recurring causes.
Review
Regular governance examining trend, scope fit and the improvement backlog rather than a compliance percentage alone.
Technologies
The estates we operate and the tooling operations depend on.
Cloud platforms
AWS, Azure and Google Cloud estates, operated against the landing zone and guardrails already in place.
Containers and orchestration
Kubernetes and container platforms, including upgrade cadence and capacity management.
Linux and Windows server estates
Patching, hardening and configuration management across mixed estates.
Databases
PostgreSQL, MySQL and SQL Server: backup verification, performance and upgrade planning.
Infrastructure as code
Terraform and equivalent, so changes are reviewable and drift is detectable.
Monitoring and alerting
Metrics, logs and traces, with alerting tied to business impact.
Log management
Centralised logging with retention modelled against cost and investigation need.
Backup and recovery tooling
Arrangements verified by restore rather than by job status.
Service management tooling
Ticketing, on-call scheduling and the reporting the agreement requires.
Automation and scripting
Runbook steps automated in order of frequency.
Industries served
Sector determines availability expectations, change windows and the consequence of an outage.
Industry
Healthcare
Systems that cannot be taken offline for routine maintenance.
IndustryBanking & Financial Services
Change control and audit trail obligations on every operational action.
IndustryInsurance
Long-lived platforms with narrow change windows.
IndustryRetail & E-commerce
Seasonal load peaks and change freezes around trading periods.
IndustryManufacturing
Production systems where downtime has a direct output cost.
IndustryTelecommunications
Continuous operation and high-volume infrastructure.
IndustryGovernment & Public Sector
Procurement structure, residency and long support horizons.
IndustryEducation
Term-driven load patterns and constrained operational budgets.
IndustryEnergy & Utilities
Regulated availability and safety-relevant systems.
IndustryLogistics
Round-the-clock operation where an outage stops physical movement.
Why NG&NR
Paid to reduce the work
Our commercial model does not scale with ticket volume, so eliminating recurring incidents costs us effort and earns us nothing — which is exactly the incentive you want in a support arrangement.
Documentation as we operate
Runbooks and decision records are produced during the engagement and belong to you, so ending it is a handover rather than an unwinding.
Engineering-led support
The people operating your systems are engineers who can change them, not a tier structure that escalates to someone who can.
Named accountability
A named lead owns the service outcome and remains the point of contact for the engagement.
Frequently asked questions
Through a transparent subscription with published pricing that includes GST. It is not priced per ticket, per seat or per hour, because volume-linked pricing rewards the persistence of the work rather than its removal.
Both arrangements are common. Where your team keeps product development, we typically take operations and recurring support so their capacity returns to the roadmap. The split is defined explicitly rather than left to develop.
Knowledge capture, principally. We document architecture, dependencies, failure modes and recovery procedures, including the informal knowledge that has never been written down. The artefacts are yours from the first day, and the service starts at a defined point rather than drifting into effect.
Response and resolution targets defined per severity and agreed against your actual business impact rather than a standard tier. We measure and report actuals, including the periods we miss the target — a service level nobody reports against is a statement of intent.
Coverage is scoped to what the estate genuinely requires. Continuous cover is expensive and is not warranted for every system, so we agree it per system rather than applying one window across the estate. Where out-of-hours cover is in scope, it is a rota with a defined response, not an informal arrangement.
That is the objective and we report the trend, so you can see whether it is happening. Recurring incidents are treated as defects with a root cause, and a defined portion of the engagement is allocated to removing them rather than left to spare capacity — which never materialises.
Then you should be able to, which is why documentation, runbooks and automation are produced during the engagement and belong to you. Exit provisions — notice, handover artefacts and access transfer — are agreed at the start. An arrangement you cannot leave is not a service.
Through a separate path with its own controls. Conflating the two is how unreviewed changes enter production under the description of a fix. Small changes are typically in scope; substantial development is quoted separately as software development.
Yes, and that is the usual case. Transition exists precisely for it. Where we find operational risks during transition, we report them with the remediation cost rather than absorbing them silently and carrying the risk.
We carry the operational security responsibilities: access review, patch cadence, secret rotation, certificate lifecycle and audit trail. We do not operate a security monitoring centre and do not claim to. Control design is cybersecurity consulting.
Service level actuals, ticket volume trend, recurring causes, work eliminated, and the improvement backlog including items that are queued but unfunded. The trend and the backlog tell you more about the direction of the service than a compliance percentage does.
It suits organisations where operating the estate has begun to consume the capacity meant for building it. That threshold arrives at different sizes. The first consultation will tell you plainly if a managed arrangement is not yet worth its overhead for you.
Next step
Discuss a managed service
A free first consultation covering your estate, the support burden it currently creates, and whether a managed arrangement is worth its overhead at your stage.
No cost, no obligation. Pricing is transparent and includes GST.