Support

Managed Support

A standing arrangement with people who know your system

How this is usually engaged

A rolling agreement with an agreed volume of work per period and a defined scope, reviewed quarterly. Cover hours, response commitments and escalation routes are specific to your engagement and set out in the support agreement. Substantial new development sits outside the agreement and is scoped separately, so improvement time is not quietly consumed by feature work.

Start a project brief

Practice: Support & Maintenance
Sectors: 5 served
Process: 5 stages
Standard: Built and tested to WCAG 2.2 AA

An ongoing agreement covering monitoring, incident response, user support and a share of continuous improvement, with named engineers and an escalation route agreed in advance.

01What this solves

The problem this addresses

When something breaks, the expensive part is rarely the fix. It is the hour spent finding someone available, the further hours they spend working out how the system is built, and the decisions made under pressure by people without context. Ad hoc support also means nobody is watching between incidents, so problems are reported by customers rather than caught by monitoring. What organisations actually want is not a faster reaction but a shorter distance between the problem and someone who already understands the system.

02Capabilities

What is included

Monitoring and alerting

Availability, error rate, performance and job failure monitored with alerts routed to people rather than to a dashboard nobody watches. Alert thresholds tuned so that an alert continues to mean something.

Incident response

A defined escalation route, named responders and an agreed process for diagnosis, communication and recovery, followed by a written review of anything significant.

User support

A route for your team to report problems and ask questions, with triage that distinguishes a fault from a training need from a genuine change request.

Change and release management

Changes applied through the pipeline with review, staging verification and a rollback path, in agreed windows. No direct edits to production.

Continuous improvement allowance

A reserved portion of each period spent on the causes behind recurring tickets — the small fixes that never make a roadmap but generate most of the support volume.

Service reporting and review

Regular reporting on incidents, ticket themes, performance trends and infrastructure cost, with a review conversation about what the pattern suggests doing next.

03Use cases

Where this work usually starts

An operational system the business depends on

Scheduling, dispatch or case management where an outage stops work immediately and there is no manual fallback that scales.

Logistics & Transport

A small internal team that needs depth behind it

One or two developers who cannot provide cover for holidays, illness or an incident that outlasts a working day.

Professional Services

A customer-facing platform outside office hours

Bookings or orders taken in the evening and at weekends, where the cost of an unnoticed failure accrues while nobody is watching.

Hospitality

04Approach

How we approach it

A managed arrangement puts named engineers on your system with a standing understanding of how it is built. We take on monitoring and alerting, respond to incidents through an agreed escalation route, handle user-reported issues, and reserve a portion of each period for improvement work directed by what the tickets and the metrics are telling us. Response times, availability expectations, cover hours and escalation contacts are agreed with you and written into the support agreement rather than assumed.

05Process

How the work runs

The order matters more than the ceremony. Stages overlap in practice, but none of them is skipped.

01
Onboarding
Reading the system, testing the deployment and rollback path, documenting what we find, and confirming we can operate it before the agreement begins.
02
Agreement definition
Scope, cover hours, response commitments, escalation contacts and exclusions written down together. This is where the numbers everyone else publishes actually get set.
03
Instrumentation
Monitoring, alerting and log retention brought to the level the agreed commitments require. You cannot respond to what you cannot see.
04
Steady state
Ongoing monitoring, incident handling, user support and improvement work, with every change traceable to a ticket.
05
Quarterly review
What broke, what recurred, what the trends show, and whether the scope and commitments still match what the business needs.

06Deliverables

What you receive

Everything below is handed over as part of the engagement. If you take the work elsewhere afterwards, the next team has what it needs.

Support agreementScope, cover hours, response commitments, escalation contacts and exclusions, agreed with you in writing.
Monitoring and alerting configurationWhat is watched, what triggers an alert and who it reaches.
Incident response planRoles, escalation route, communication templates and decision thresholds.
Ticket system and reporting access
Periodic service reportIncidents, ticket themes, trends and improvement work completed.
Maintained runbook and system documentation

07Technologies

What we use on this work

These entries are drawn from our managed technology directory, which records why each one is in our stack and what we reach for it for. Nothing outside this list is claimed for this service.

Languages & Runtimes

TypeScript
Node.js

Data & Storage

PostgreSQL
Redis

DevOps & Operations

Docker
Kubernetes
Grafana
Sentry

The full technology directory

Highlighted entries are used routinely on delivery work

08Security

How this is kept secure

Access is granted to named individuals under least privilege, reviewed at agreed intervals and revoked promptly when someone leaves either organisation. Privileged actions are logged and attributable. Incident handling follows an agreed plan with defined roles and communication routes, including who decides whether an event needs to be reported onward — that decision is yours, taken on your own legal advice, and we supply the technical facts it rests on.

Our full security and quality approach

09Questions

Asked before we start

What uptime do you guarantee?

We do not publish a figure, because a meaningful availability commitment depends on your architecture, your hosting and what you are willing to spend on redundancy. We agree a target with you during onboarding, based on what the system can actually support, and write it into the support agreement along with how it is measured and what happens if it is missed.

Do you provide cover outside business hours?

Where the engagement warrants it and you are willing to fund it. Out-of-hours cover requires a rota, which has a real cost, so it is worth it when downtime overnight or at weekends has a measurable consequence. Cover hours are agreed and written into the support agreement rather than left as an assumption.

What is excluded from the agreement?

Substantial new development, and faults originating in third-party systems beyond our control — though we will diagnose those and give you the evidence to take to the supplier. Exclusions are listed explicitly in the agreement, because an argument about scope during an incident helps nobody.

Would we be better off hiring someone in-house?

Frequently, yes. If your systems need attention most days, an employee is usually better value and better for continuity than an agreement with us. Managed support makes sense when the load is real but intermittent, when you need cover across more skills than one person has, or as a bridge while you recruit — and we are happy to help you write the job description.

START HERE

Talk to us about Managed Support

The project brief takes about five minutes and gives us enough to have a useful first conversation about Managed Support rather than a generic one. If you would rather just ask a question, the short form is there for that.

Start a project Send a short message

We read every enquiry ourselves. If we are not the right fit, we will say so and tell you what to look for instead.