01
The situation
Keep it running
The software is built. Someone has to answer for it.
Patching, backups, renewals, monitoring, the certificate that expires at the worst possible moment, and the question of who picks up the phone when something breaks during month-end close. None of it is glamorous, and all of it is the difference between software that runs and software that quietly stops.
02
Recognition
What this usually looks like.
No in-house team and no support arrangement
The system runs because nothing has gone wrong yet.
A support provider who has stopped responding
Tickets go in. Nothing comes out. You have no idea whether anyone is even looking.
Nobody owns hosting, backups, or renewals
They are on someone’s personal card, or a former employee’s account, and you find out when something lapses.
Nobody accountable when it breaks at month-end
You have a list of people to try rather than a person whose job it is.
03
Approach
What we do about it.
We take ownership of the running system, which is a narrower and more useful promise than it sounds.
Every issue becomes a ticket, logged with the description and the time it arrived, rather than a message that gets fixed quietly and forgotten. That gives you something to hold us to, and it makes recurrence visible as a pattern instead of five separate inconveniences spread across a quarter. Anything that keeps coming back gets referred to engineering for a root cause rather than patched a fourth time.
A ticket is somebody telling us that a thing they rely on is broken and asking us to show we have seen it and own it. So being heard is instant and automatic. The decision about what happens next is a separate thing, made by a person, and it takes as long as it honestly takes.
A closed ticket is not the same as a solved problem. Nothing gets marked done because we think it is done: it closes where it opened, with you looking at the place the problem happened and confirming it is resolved. You verify once, and we do not ask you to test the same thing twice.
Underneath the ticket queue sits the work you never see. Scheduled backups that are restore-tested rather than merely configured, dependency and security patching, access reviewed on a schedule so it does not accumulate, and deployment through a pipeline with a rollback plan written before it is needed.
04
Commitments
What we commit to.
A named owner
One person accountable for your systems, and you know who it is.
A ticket for every issue
Logged, triaged, acknowledged, and closed with a resolution note.
Targets in writing
Resolution targets agreed with you per engagement and written down, set against capacity that actually exists.
Escalation before the deadline
You hear about a ticket heading for its threshold while there is still time to decide something, with a recovery plan attached.
A monthly account
What came in, what went out, what recurred, and what we recommend doing about the recurrence.
Restore-tested backups
Recovery time is a number somebody measured rather than a policy somebody wrote.
Support hours
08:00 to 20:00 SAST, Monday to Friday. Cover for defined critical incidents outside those hours is agreed per engagement.
Acknowledged within an hour
Inside support hours, every ticket is acknowledged by a person within one hour. Time to repair depends on what broke, and that target is agreed with you per engagement.
We do not advertise a blanket resolution time across all clients, because a number that applies to everyone regardless of what they pay is either meaningless or untrue. We also do not publish a support telephone number until a named person has committed to answering it.
06
What you get
What you get.
A ticket queue you can see into
Every issue, its owner, its status, and how it was resolved.
Patching and access review
Dependencies and security updates applied, and access revoked on the day someone leaves.
A current runbook
How the system is deployed, monitored, and recovered, updated whenever any of that changes.
A monthly summary
Volume, resolution, recurrence, and a recommendation for anything that keeps coming back.
07
Commercially
How it works commercially.
Either a monthly retainer under Embedded Function, sized against the support load rather than guessed at, or a standalone support agreement covering a defined system.
Where the system is one we did not build, the first step is a short piece of paid work to inherit it properly. Supporting a system nobody has documented is how support arrangements fail in month three, usually during the first real incident. If you are not sure which arrangement you need, the health check will tell us enough to recommend one.
08
Objections
The questions people ask us here.
We did not build it with you. Will you still support it?
Yes, once we have inherited it properly, which means documenting what it does, how to run it, how to deploy it, and what breaks. We will not agree to support a system we have not looked inside.
What happens when our usage grows?
The retainer is reviewed against actual hours rather than left to drift. If the load changes we tell you and we re-baseline, in both directions.
Are we paying you to do nothing in a quiet month?
Partly, and that is what the arrangement is for. Availability, patching, backups, and monitoring cost something whether or not anything breaks. What you should not accept is being unable to see it, which is why there is a monthly summary.
What if we want to move to someone else?
Documentation, credentials, and runbooks are handed over, and they were yours throughout. Notice period is one calendar month. See how we work.
Claer & Volker
453 Winifred Yell St, Garsfontein
Pretoria, South Africa
info@claervolker.com
© 2026 Claer & Volker
·
·