Equipment after-sales for a defence service branch — fault tracking, problem closure and MTBF

The situation

A defence service branch runs equipment whose after-sales support is itself a controlled activity. Repairs happen on an isolated intranet, technical documents are graded, and the people who need the information are spread across units with different clearances. The branch needed a service system: report a fault, dispatch a repair, record the repair, accept the result — plus a front-end surface for announcements and a document area for material that is cleared for a given reader.

The default build for that brief is a work-order system. It is also the wrong shape, because closing a ticket answers only “is this item fixed”. The questions the branch actually has to answer are different ones: which failure modes recur across the fleet, what the failure rate is for a given equipment type, what the MTBF looks like, and whether a problem that has appeared before has been genuinely closed or merely patched.

The call we made

The ticket is evidence, not the product. We designed the system around two analytical obligations and let the repair workflow feed them.

Problem closure as a workflow, not a checkbox. When a fault recurs, or is serious enough to escalate, it stops being an individual repair and becomes a problem: the cause has to be established, the fix has to be recorded as a known remedy, and the item cannot simply be marked repaired and filed. This matters because in equipment support the expensive failure is the repeat failure. A ticketing system will record the same fault in unit after unit and call every instance resolved, which is exactly the outcome the branch was trying to avoid.
MTBF analysis is only possible if the data is captured at repair time. MTBF is not a report added later; it needs the installed base, the operating time and the failure events with their timestamps. If the repair form does not capture equipment identity, fault category and time, no later analysis can reconstruct them. So the repair form was designed backwards from the analysis, and the analysis was treated as a deliverable rather than a nice-to-have.

The environment dictated the rest. There is no external network, so no cloud services, no remote updates, no downloadable fonts or map tiles: deployment is a media transfer and the system has to be complete offline. Technical documents are graded, so access is by role and by classification level, and the document module is a controlled store with an audit trail rather than a shared folder. Classified data does not leave the environment, which is also why so little of this project can be described here.

We kept the front end and the admin console as separate surfaces. The service portal is where unit users read announcements, raise a request and find documents they are cleared for; the admin console is where the support organisation tracks faults, manages problems and controls documentation. Merging them would have meant one permission model trying to serve two populations with different clearances and different jobs.

What we built

Repair workflow — report, dispatch, repair and acceptance — with the state of each item traceable through every step.
Fault registration classified by hardware and software, because the two fail for different reasons and are fixed by different people.
Escalation and problem closure, so that a repeated or difficult fault becomes a problem with a cause and a recorded remedy instead of another closed ticket.
Failure-rate and MTBF analysis over the repair history captured at the point of repair.
News and significant-event management for the service organisation, kept on the same platform as the support data.
Technical documentation with graded authorisation, including the audit record of who accessed what.
Offline installation and role-based access suited to a classified intranet.

Result

The branch ended up with two things a work-order system would not have given it: a measurable reliability picture per equipment type, and a record of which problems were actually solved rather than deferred. Repair throughput remains the day-to-day use of the system; the analysis is what changes maintenance planning, because it moves a decision from “this unit reports a lot of faults” to “this failure mode accounts for a defined share of the fleet’s events”.

Since deployment it has run inside the classified environment with no external dependency, which is the property that matters most for this class of customer: nothing in the service workflow requires a connection to the outside world.

If you are being asked to build support software for equipment that cannot be discussed, the design question is the same one. Decide early what has to be measurable — then make the workflow capture it, because that is the only moment it can be captured.

Screens from this system are not published. It runs on client infrastructure with client data, so we show it live instead: a short screen-share walkthrough under NDA, on a system we demonstrate rather than a screenshot we sanitised. Ask for it in the first call.

Technology

Stack	Vue 3 · Spring Boot · Offline intranet deployment · Classified environment adaptation
Delivery model	Classified on-premise delivery
Client	A defence service branch (name withheld)
Status	Internal / under NDA

What we cannot show

This project falls within the classified domain. Unit designations, failure statistics, MTBF figures, user identities and the interface itself cannot be published. What is described here is the system structure and the reasoning behind it.