Snag lists are useful when they are clear.

They become frustrating when everything is treated as the same kind of issue. A true defect, a client preference, a missed training point, a late design change and an added feature request should not all sit in one vague list.

AV and smart home projects need better structure than that.

A defect is not the same as a preference

If a speaker is not working, that is a defect.

If the client wants a different volume level for a room, that may be a preference adjustment. If a button works but the label does not match how the family speaks, that is a refinement. If the client now wants another source added, that may be new scope.

These items can all matter, but they should not be handled the same way.

Clear categories reduce tension

Projects near completion can be stressful.

The builder wants to finish. The client wants to move in. The interior designer wants the room clean. The AV team needs time to test. If the snag list is unclear, every item feels like a dispute.

Categories help everyone see what needs repair, what needs explanation, what needs approval and what needs pricing.

Training issues should be captured honestly

Sometimes the system is working, but the user has not yet learned how to operate it.

That is not the client’s fault. It is part of handover. The snag list should be allowed to record training items without pretending the system is broken.

For example, a client may not know how to change sources, find playback, adjust a scene or use a specific room mode.

That should lead to better handover, not unnecessary fault finding.

Added scope should be protected

Late requests happen naturally.

Once a client starts using a system, they may realise they want something extra. That can be a good sign. But added scope should be documented clearly so it does not become confused with unfinished original work.

This protects the client and the contractor.

DG Technologies’ view

DG Technologies believes snag lists should help finish the project cleanly.

The goal is not to argue about wording.

The goal is to separate defects, preferences, training and new requests so each one can be handled properly.