When this fits
Issues are currently resolved by whoever remembers how.
Vendor support answers for its own product and nobody answers for the system.
You need a defined response commitment for something the business depends on.
How we work within it
Context kept between tickets
Your architecture, history and known quirks stay on record, so a recurring issue is recognised rather than re-diagnosed.
Severity defined by business impact
Priority set by what it stops, not by how loudly it was reported. Agreed in advance so it is not argued during an outage.
Root cause, not just restoration
Restoring service is the first job; the second is the change that stops it happening again. A ticket closed without that is a ticket that will reopen.
What you get it on
Support, across these domains
A delivery model is not a product. These are the technology domains we work in through it — start from the one your problem sits in.
Engagement and pricing model
A subscription against defined systems and response levels, or a block of hours for lighter needs. Sized by what is covered, not by how many tickets you raise — charging per incident rewards the wrong outcome.
What we commit to, and what we measure
Response and resolution against the levels agreed for your systems.
Repeat incidents, tracked because a recurring issue is an unfixed cause.
Proportion of issues resolved without escalation to a vendor.
Targets are set per engagement and written into the agreement. We do not publish a number here, because a service level that is not attached to a specific scope is not a commitment.
Questions we are asked
What response times do you commit to?
Those agreed for your engagement and written into the contract. A response time published on a website is attached to no particular scope and therefore commits to nothing.
Does this replace our vendor support contracts?
No — it sits above them. Vendor support answers for its own product; this answers for your system, including the part where two products disagree and each blames the other.
Can you support systems built by someone else?
After an assessment. Where something is not safely supportable as it stands we say what would have to change, rather than accepting the scope and carrying the risk silently.
What is out of scope?
Written down at the start, in the agreement. Undefined scope is where support relationships fail, and it fails in the direction of whoever is more confident during the argument.
How is this different from managed services?
Support responds when something is wrong. Managed services operates the estate day to day, including everything that stops things going wrong. Many organisations start with support and move across.
Start with an assessment
The fastest way to a useful answer is a short, scoped look at what you already have.