06 / 06
Discipline
Support & Maintenance
Keeping software alive after it is built. Answering when something breaks, patching before something breaks, backing up in a way that has been tested, and being the named person accountable for the system rather than one of several people who might know something about it.
Approach
Positions we hold
How we approach it.
Every issue becomes a ticket
The most common failure in support is not slowness, it is invisibility. Issues arrive by message, someone fixes them quietly, nothing gets logged, and at the end of the quarter neither side can say what was done or whether the same thing happened five times.
Every issue is logged with the client, the description and the time received, then triaged, prioritised, acknowledged, and closed with a resolution note. Slightly slower for the first ticket, considerably better by the tenth.
A closed ticket is not an outcome
Work closes where it opened: the client looks at the place the problem happened and confirms it is resolved, once, and is never asked to test the same thing twice.
Anything that comes back gets referred to engineering for a root cause rather than patched a fourth time. The ticket history is what makes that pattern visible in the first place.
Escalation before the deadline
When a ticket is heading for its agreed threshold you hear about it while there is still time to decide something, with a recovery plan attached. Being told after the fact that a target was missed is reporting rather than communication.
The maintenance nobody sees
Dependency and security patching. Access reviewed on a schedule and revoked on the day someone leaves. Scheduled backups, restore-tested into an isolated environment. Runbooks kept current. Certificates and renewals tracked.
This is most of the actual work and none of the visible work, which is why it is the first thing to disappear from a support arrangement priced by ticket volume.
We read the system before we support it
Where we did not build it, the first step is inheriting it properly: what it does, how to run it locally, how to deploy it, what breaks. Agreeing to support a system nobody has opened is how these arrangements fail in month three, usually during the first real incident.
What we will not publish
No blanket service level across all clients, because a number applying to everyone regardless of what they pay is either meaningless or untrue. Targets are agreed per engagement, in writing, against capacity that exists.
There is no telephone support line until a named person has committed to answering it, and we will not promise that nothing will break. What you are buying is that somebody notices, somebody owns it, and you can see what happened.
Stack
What we run support on.
Jira
Harvest
Microsoft Teams
Outlook
Runbooks
Scheduled backups
Restore tests
Deployment pipelines
Rollback
Engagements
Typical shapes this takes.
A retainer on a system we built
Straightforward, because the inheritance work is already done and the people are the same.
A retainer on a system we did not build
Preceded by a short paid inheritance piece, which produces the documentation the arrangement depends on and which you keep regardless.
Database and platform administration only
Backups, restores, patching, monitoring, and capacity, without application-level support.
Deliverables
What you get.
A named owner per system
And you know who it is.
A ticket queue you can see into
Every issue, owner, status, and resolution.
Targets in writing
Agreed with you per engagement.
Restore-tested backups
With a recorded recovery time.
A current runbook
Updated whenever the system changes.
A monthly summary
Volume, resolution, recurrence, recommendation.
Reading
Related reading.
The strongest seams here are restore testing versus backup configuration, and why a published blanket service level is usually untrue. Those pieces will be linked here as they are published.
Claer & Volker
453 Winifred Yell St, Garsfontein
Pretoria, South Africa
info@claervolker.com
© 2026 Claer & Volker
·
·