What Can Go Wrong After a Sound System Handover

Why it is not enough that the system simply “works”

A source is the input from which the system plays audio. A zone is a part of the space with its own settings. Saying that “the system works” only confirms that audio was produced from the selected source at that particular moment. It does not confirm that all agreed zones, sources, microphones, controls and connections to other parts of the audiovisual (AV) solution work correctly. Nor does it prove that the system performs the function for which it was designed.

The handover process should therefore begin with the project documentation, ordered scope or another approved specification. At MediaTech, we use the ANSI/AVIXA D402.02:2013 (R2024) standard, which describes system performance verification as a process that defines what will be verified, at which stage of the project, against which criterion and how the result will be recorded. For the customer, this leads to a simple rule: every test needs a predefined requirement against which the result can be compared.

Anything that is not part of the agreed scope cannot simply be added retrospectively during handover. And anything that is part of the scope should not merely be mentioned during the demonstration. You need a result that can be traced later.

Three possible outcomes of an acceptance test

Three possible outcomes are sufficient for the working record. They do not determine the legal effect of signing the handover protocol. Their purpose is simply to establish what happens next with each item.

The agreed result has been demonstrated. The test was carried out according to the agreed procedure, the result met the criterion and evidence was retained. Mark the item in the checklist as completed.

The agreed result has not been demonstrated. The requirement forms part of the scope, but the test revealed a deviation, unfinished work or a result that cannot yet be evaluated. Record what was observed without guessing the cause. Then assign who is responsible for the item, what will happen next and when the test will be repeated.

A new requirement has emerged. During testing, a useful function or use case may appear that was not part of the original scope. Record it separately as a new requirement so that it is not confused with something that remains unfulfilled from the original agreement. Its implementation, scope and price are assessed separately.

This distinction protects both parties from an imprecise list of comments. The customer can see which items relate to the ordered result, while the supplier receives a specific record instead of a general statement such as “the sound isn’t good”.

Testing based on real-world scenarios

Test the sound system in the situations for which it was designed. A restaurant, meeting room, lecture hall and retail space all use audio differently. A single universal test would therefore overlook part of the requirements. Base the test scenarios on the agreed purpose of the space and the functions defined in the project.

Follow the same process for each scenario:

• Define who uses the system and what they need to do.
• If a specific source, zone, microphone or saved preset forms part of the agreed scope, define it as the starting state.
• Perform the complete task in the same way the operator will perform it during normal use.
• Compare the result with the agreed criterion. Do not introduce values that were not defined by the project.
• Record the result and attach appropriate evidence.

One test may verify playback to selected zones. Another may test speech from a specified microphone or switching the source from the normal control position. If the sound system forms part of a wider AV solution, the test may also include agreed integration with video conferencing, displays, control systems or the corporate network.

Do not invent new criteria during the test itself. If the project does not define what should be achieved for a particular characteristic, record that the information required for evaluation is missing. One listener’s impression may be useful feedback, but it does not replace an agreed criterion.

What must remain in the record

The record should allow somebody who was not present during the test to understand the result. A statement such as “the microphone does not work” is too general. The record should identify which microphone, during which step, in which zone and what happened differently from what was expected.

Every open item needs seven pieces of information:

• Agreed result. The requirement in the approved scope to which the item relates.
• Test. What was done and under which conditions.
• Result. What actually happened during the test.
• Deviation. How the observed result differs from the agreed state.
• Evidence. Depending on the item, this may be a photograph, screenshot, measurement result or link to the test record.
• Owner. Who is responsible for the next step.
• Deadline. When the item will be checked again or closed.

For a completed item, a short record is enough. A deviation needs to be recorded precisely because the later correction will be verified against that record. Only record the cause once it has been confirmed. What you observed and what you believe caused it are two different pieces of information.

What to receive together with the system

The documentation delivered with the system depends on the scope of the individual project. The ANSI/AVIXA D401.01:2023 standard describes how documentation requirements are defined, who is responsible for creating the documentation and how its delivery is tracked. Before the acceptance process begins, therefore, identify which documents and deliverables were agreed.

During the review, ask the following questions:

• Was as-built documentation agreed, meaning documentation that records what was actually installed? Does it match the handed-over system?
• Are the system configurations and final settings included in the agreed scope and properly recorded?
• Can the results of functional tests and open items be traced?
• Was operator training agreed? If so, was it completed for everyone for whom it was intended?
• Does every deliverable that has not yet been provided have an assigned owner and deadline?

Documents, passwords, backups or training form part of the project only if they are included in the approved scope. If the project was simple and separate documentation was never agreed, there is no reason to artificially expand the handover requirements.

Acceptance checklist

The checklist can be prepared before testing begins. Each row should represent one requirement that can be verified independently. If several functions are combined into one row and the result is recorded as “partially completed”, it becomes much harder to determine later what was actually verified.

Before testing, complete the first two columns using the agreed scope. During the test, add the result, deviation and evidence. An owner and deadline are only required for items that remain open or require a further step.

The checklist is a working tool. It connects each requirement with its test and result. It does not replace the project documentation or provide a legal interpretation of the handover protocol. Its value lies in making the result traceable later.

Questions before signing the handover protocol

Before signing, return to the open items in the checklist. Each answer to the questions below should lead to a specific row.

• Which agreed scenarios have been tested and which remain untested?
• For which items is the criterion missing, meaning the result cannot yet be evaluated?
• Which findings are deviations from the agreed scope and which are new requirements?
• Does every open item have evidence, an owner and a date for the next review?
• Which agreed documents, test results or training deliverables have not yet been provided?
• Does the protocol clearly identify which part of the system each item relates to and what will be tested again?

If all agreed items have been demonstrated and the outputs are traceable, additional administration does not add technical certainty. If an item remains open, an accurate record is more useful than rejecting the entire system. The legal effect of signing the protocol and whether a particular part of the system should be accepted are determined by the contract and authorised project representatives. This checklist does not determine that.

Frequently asked questions

What should be checked during sound system handover? Verify that the system performs the agreed functions in real-world situations. The fact that sound comes out of the equipment does not prove this. Every requirement therefore needs its own test, result and evidence. For an open item, add the responsible party and deadline. What needs to be checked is determined by the project, purchase order or other approved specification.

How do I distinguish a deviation from a new requirement? First find the required result in the agreed scope. If it is included and the test does not demonstrate it, record it as a deviation in the working list. If it is not included in the scope, record it separately as a new requirement for assessment. This classification is used to organise the work and does not determine legal responsibility.

Does every test need a numerical limit? A numerical limit is only required where the project or chosen verification method defines one. Other functions can be assessed simply, for example whether the selected source plays in the agreed zone or whether the control system triggers the correct function. The criterion must nevertheless be known before the result is evaluated. Adding a universal number only during handover would effectively change the specification.

What if the system works but the operators do not know how to use it? First verify whether training and its scope formed part of the agreement. If so, record which role, situation or step was not handed over as agreed. If training was not included in the scope, it becomes a new requirement. To verify whether the system can actually be operated, have the operator perform their normal task. A technical demonstration does not prove this.

Which documents should be delivered with a sound system? Those defined by the project scope. They may include as-built documentation, configuration records, test results or training materials if these were agreed. Check that they correspond to the system as actually handed over. Without an agreed scope, there is no universal documentation package that applies to every system.

Can I accept a system with open items? The checklist shows exactly which items have been completed and which remain open. A decision about acceptance can then be made using the specific scope, evidence and deadlines. The legal effect of signing, however, is determined by the contract and authorised project representatives. This article does not replace that process.

Next step

If you are preparing to accept a sound system, send MediaTech the floor plan or project documentation you have available, the purpose of the space and a short description of the decision you need to close. These materials make it possible to separate questions about system design from questions about acceptance testing.

Send us the purpose of the space, the available documentation and the decision you need to make.