SMARTLINK INDUSTRY STANDARDS · STANDARD 22
Published 1 June 2026
Changes to repair workflow rules, integrations and permissions should be visible, tested and attributable to an accountable owner. This standard sets out a practical baseline for a connected New Zealand collision repair industry.
The issue in the repair workflow
Changes to repair workflow rules, integrations and permissions should be visible, tested and attributable to an accountable owner. In collision repair, the issue usually appears at a handover: a quote is submitted, an image is reviewed, an approval is sought, a supplier responds, or a customer asks what happens next. The relevant controls are release management, API changes, templates, routing rules and role permissions. When those controls are clear, people can spend their time repairing vehicles and resolving exceptions rather than chasing unexplained system behaviour. When they are unclear, ordinary operational friction can become delay, dispute or unnecessary exposure of information.
Who is affected
Repairers need a workflow that lets them prepare a complete repair file without guessing who can see it. Insurers and assessors need timely, reliable information to make accountable decisions. Suppliers and platform providers need clear technical and governance expectations so that a connection remains useful when people, systems or circumstances change. Change control and version accountability is therefore not an abstract technology preference: it is an operating expectation for the moments where a collision repair job moves between organisations.
Repairer perspective
From a repairer perspective, the practical question is whether the workflow supports accountable work at the point of repair. A repairer should be able to identify the current status, understand what action is required, and retain evidence of material exchanges. The repairer should not have to rely on personal inboxes, informal screenshots or a single staff member’s memory to explain a job. A documented process also helps a repairer train new staff and keep service stable during absences or business change.
Insurer, assessor and platform perspective
For insurers, assessors, suppliers and platforms, good practice means making the legitimate path easier than the workaround. Participants should know who owns a rule, what evidence is retained and how an exception is raised. Technical providers should design for useful logs, safe permissions and recoverable errors; operational owners should explain the purpose of a control and review whether it is still proportionate. This approach supports efficient coordination without treating any participant as a passive recipient of a black-box decision.
What good practice looks like
Use versioning, impact assessment, approval records, stakeholder notice and a tested rollback plan.
- Name an accountable owner for release management, API changes, templates, routing rules and role permissions and publish a clear contact route for exceptions.
- Record the purpose, approval and effective date of material workflow settings that affect change control and version accountability.
- Use named roles and retain enough evidence to reconstruct a material decision or handover.
- Test the workflow with ordinary and exception cases, including a staff change, a system interruption and an incorrect request.
- Review complaints, near misses and recurrent manual workarounds for a control or design issue.
Warning signs
- a material change appears in production with no approval record, test evidence or rollback path
- A participant must ask several people for a basic explanation or correction.
- A workaround becomes the normal path because the approved path is unreliable or unclear.
- A material decision cannot be traced to a named owner, timestamp and stated reason.
- A policy promises a safeguard that the day-to-day workflow does not actually provide.
Practical safeguards
Start with a small, observable improvement. Agree the workflow owner, document the control, tell affected people how it works and use evidence from real jobs to refine it. The aim is dependable practice that works on a busy repair day, not a policy that only reads well on paper.
- Name an accountable owner for release management, API changes, templates, routing rules and role permissions and publish a clear contact route for exceptions.
- Record the purpose, approval and effective date of material workflow settings that affect change control and version accountability.
- Use named roles and retain enough evidence to reconstruct a material decision or handover.
- Test the workflow with ordinary and exception cases, including a staff change, a system interruption and an incorrect request.
- Review complaints, near misses and recurrent manual workarounds for a control or design issue.
Role-specific guidance
Repairer
Keep job records accurate; use the approved route; question unexplained changes; and raise a practical exception early.
Insurer or assessor
Apply criteria consistently; explain material requests or outcomes; and keep the decision record connected to the claim workflow.
Supplier or platform
Make permissions, interface limits and escalation paths understandable; protect logs; and communicate material changes before they surprise users.
Implementation checklist
Use this checklist to turn the standard into a local operating conversation.
- Identify the current process for release management, API changes, templates, routing rules and role permissions.
- Confirm the decision owner and escalation route.
- Check the evidence retained for a material handover.
- Brief affected staff and participating organisations.
- Set a review date and record any improvement actions.
Self-check
Discuss these questions with the people who use the workflow, then record practical actions rather than scores.
- Can our team explain how change control and version accountability applies to a current repair job?
- Is the accountable owner known, available and able to correct an error?
- Do our access, records and escalation steps match what the written process says?
- Have we tested the workflow from the perspective of an ordinary user and an exception case?
- Would a reasonable reviewer be able to understand the evidence without relying on memory?
SmartLink’s position
SmartLink supports neutral, governed digital connections that help collision repairers and their partners exchange the right information with clarity and traceability. Change control and version accountability should be applied proportionately, transparently and with respect for each participant’s legitimate operational role.
Frequently asked questions
Who should use this standard?
Any repairer, insurer, assessor, supplier or platform participant whose work affects the relevant handover should use it as a practical discussion and improvement guide.
Does this require a new platform?
No. The standard is technology-neutral. It asks organisations to make the existing workflow more explainable, secure and workable before adding unnecessary tools.
What should happen when the process does not fit a job?
Use the documented exception route, record the reason and outcome, and review recurring exceptions for a design or policy improvement.
How often should controls be reviewed?
Review them after a material change, incident or recurring complaint, and at a regular interval suited to the risk and volume of the workflow.
Is this legal or contractual advice?
No. It is an industry good-practice standard. Each organisation remains responsible for its own legal, privacy, contractual and operational decisions.
Put this standard into practice
Talk with the SmartLink team about a safer, clearer workflow for your organisation and the people you connect with.