Maintenance becomes difficult to manage when a fault moves between the person who spots it, the team that diagnoses it, the supplier who repairs it and the person who accepts the asset back into service. The answer is not to replace the asset register. It is to make the work around each exception visible.
Start with the asset, then define the event
The asset register remains the record of what the item is, where it is and who owns it. A maintenance event records what happened and what must happen next. Routine planned work may fit an existing maintenance order. Open a separate case when the issue crosses teams, needs a decision, creates a safety or service risk, or requires evidence before closure.
Use a clear path from report to return to service
- Capture the issue: identify the asset, location, reporter, symptoms, date and any immediate risk. Attach a useful photo or inspection result where appropriate.
- Triage: decide whether to isolate the asset, continue with restrictions, schedule planned work or escalate an urgent incident. Record who made that decision.
- Assign an owner: one person owns the next action even if several teams or suppliers contribute. Give the handoff a due date and a clear acceptance condition.
- Execute and track: connect the case to the maintenance order, purchase order or supplier reference held in the system of record. Keep status updates and blockers visible.
- Verify closure: record the repair performed, test or inspection result, approver and return-to-service decision. Close only when the agreed evidence is present.
Keep systems in their proper roles
Your ERP or maintenance application should remain authoritative for asset details, inventory, purchase orders and financial transactions. A process layer can coordinate owners, decisions, reminders and evidence across those records. Avoid copying master data into a second register; use stable references and check who may view sensitive attachments.
Make exceptions explicit
A supplier delay, repeat fault or rejected repair needs a named owner and a new next step. A reopened incident should preserve the earlier history rather than overwrite it. For a critical asset, define an escalation route and a substitute or contingency plan before the deadline passes.
What to measure
- Time from fault report to triage and to return to service.
- Open events by owner, age, location and risk level.
- Repeat faults on the same asset and repairs rejected at verification.
- Events closed without the required inspection or acceptance evidence.
Example: a failed delivery vehicle
A driver reports a brake warning and uploads a photo. The dispatcher marks the vehicle unavailable; the fleet owner assigns an inspection. The workshop's job reference stays in the maintenance system, while the case tracks the supplier handoff and promised completion. The vehicle returns to service only after the inspection result and release decision are recorded. The precise steps and mobile capture options must be tested in the target deployment before they are promised to users.
How Intelliflow fits
Intelliflow is designed to make cross-team work visible: the next owner, outstanding decision and closure evidence are easier to follow. The practical starting point is one asset class and one exception path, connected to the records you already trust. Validate the configured workflow and permissions with a real scenario before rolling it out more widely.
Evidence to keep at each decision
At intake, retain the original report, asset reference and any photograph or sensor reading with its source and time where available. At triage, record the safety or service decision and who made it. At supplier handoff, keep the approved scope, quote or work order reference and revised dates. At closure, retain the inspection or test result, the release authority and the communication to affected users. A photograph is not proof of a successful repair by itself; it must answer the relevant question and match the asset and event.
Test a repeat fault, not only a successful repair
Suppose the same vehicle returns with a similar fault two days after release. The new report should link to the earlier event without overwriting it. The owner checks whether the asset is safe to use, whether the repair is under warranty or requires a new authorisation, and who updates the driver or customer. The previous supplier completion is evidence of work performed, not evidence that the recurrence has been resolved. Keep the new issue open until its own inspection and decision are verified.
Before putting the route into use
- Check that a field user can report the correct asset without seeing other customers' sensitive records.
- Prove that an urgent safety issue reaches the designated owner when the usual assignee is absent.
- Confirm that a supplier delay remains visible with a revised due point and customer update.
- Test a rejected repair and a missing inspection result: neither should silently become “complete”.
- Read back the linked maintenance order or purchase transaction from its authoritative system before treating the case as closed.
For more on decision-time proof, read evidence and auditability. The fleet handover guide shows a related vehicle journey.
Frequently asked questions
Does every maintenance order need a separate case?
No. Use the existing maintenance route when it already gives the right ownership and proof. A coordinating case is most useful when the outcome crosses teams, systems or customer commitments.
When is the asset ready to return to service?
When the required repair or inspection evidence is present and the person authorised by the organisation's policy has made and recorded the release decision.
To test one asset exception against your own records and controls, book a process review. Intelliflow Editorial Team. Examples are illustrative; validate field capture, integration and permissions in the target deployment.