Prepare my site brief: worksheet and printable PDF
01
Handover begins before the final day.
At the start, agree expected functions, tests, observers and handover documents. Use the same identifiers on drawings, equipment and test records. A photograph of a finished cabinet proves its appearance, not every circuit’s function. For each use, describe an action, expected result and observation; keep “untested” separate from “passed” and “out of scope”.
A configuration file supports continuity, but its name proves little. KNX recommends backing up after changes and checking import. Ubiquiti distinguishes complete backups from network-only backups. These examples raise a concrete question: exactly what does the supplied file contain, and for which version?
02
What the pack must make traceable.
Scroll the table horizontally to compare all three columns.
| Record | Useful content | Handover check |
|---|---|---|
| Installed inventory | Identifier, reference, variant, location, version and serial where needed. | Compare with actual equipment, not only the ordered list. |
| Drawings and diagrams | Locations, connections, zones and final site changes. | Tie each identifier to a revision and date. |
| Tests and outstanding issues | Expected, observed, result, evidence, owner and next action. | Do not turn an empty field into a pass. |
| Configuration and recovery | File, scope, version, date, custodian and documented test. | Check access and planned recovery, not just file presence. |
| Operation and support | Normal operations, limits, contacts and genuinely agreed terms. | Separate training, product warranty and any maintenance arrangement. |
03
Prepare a useful acceptance session.
Define representative cases
Prepare a record for each important function: normal command, result in the right zone, feedback and planned recovery. For a meeting, also observe the remote participant; for a network, check the intended service from the relevant endpoint. Agree states with the owner. An improvised test must not interrupt a service, open access or trigger a real alert.
Record what actually happened
Record date, tested version, operator, starting condition, observed result and relevant evidence. Use authorised captures or measurements without unnecessary personal data. If results differ, open a specific issue with an owner and planned retest. Severity and any temporary-use conditions are decided with competent people, not an automatic colour.
Demonstrate everyday operations
Let the person operating the system practise authorised tasks: selecting a zone, finding a state, recognising unavailability and asking for help. Supply a role-appropriate quick reference. Showing administration menus to an end user is neither useful training nor a reason to grant every permission.
04
The screen works. Three issues remain open.
ILLUSTRATIVE EXAMPLE
Fictional case: room R1 displays a local presentation correctly on configuration version 3. The pack contains a version 2 backup with no verified import. The owner has not confirmed access, and remotely received audio is untested. No real device or account is used.
Keep the pass within its scope
The local picture passes under the recorded conditions. Remote audio stays untested, not passed by inference. The record separates both functions and schedules a test with an authorised remote participant. It avoids a blanket “room accepted” while the agreed scope remains unchecked.
Reconcile the backup
A version 2 backup does not prove recovery of installed version 3. Identify the file matching the final configuration and have reading or import checked in a suitable environment. If complete restoration is untested, state exactly what was tested. Do not overwrite the active installation to obtain a green tick.
Verify the recipient
Sending a link proves neither access nor the owner’s permissions. Have the recipient confirm agreed access through the official workflow without collecting their password. The record retains three issues: backup/version, owner access and remote audio. Each gets its own owner and closure evidence.
Illustrative document review, not contractual acceptance or a statutory inspection. Closure requires real observations and the approvals defined for the project.
05
Enable recovery without exposing secrets.
Assign responsibilities
Identify operator, authorised administrator, integrator and supplier contact. UniFi ownership mechanisms differ between supported UniFi OS consoles and self-hosted servers; check the exact case in its documentation. Delivering hardware does not automatically transfer accounts. Record required rights and those that remain restricted.
Separate reading material from sensitive assets
The everyday pack contains authorised drawings, references, versions and contacts. Secrets, keys and sensitive exports use a protected channel agreed with authorised people. Record their custodian and access procedure, not their values in a widely shared PDF. Check that required files are available and understandable to the authorised recipient.
Date the recovery evidence
For each backup, record covered system, version, date, agreed storage and latest check. Distinguish opening a file, importing it and recovering the service: these are not equivalent evidence. A later change requires reviewing the affected pack. Recovery planning names the decision-maker, prerequisites and rollback without promising an unmeasured duration.
06
A good pack makes support more precise.
When requesting help from Inovexia, provide the available project or purchase reference, equipment and version, expected result, observed symptom and what changed. Supply relevant documents through the intended workflow without unnecessary confidential data. Separate a product question, integration work and any RMA request. Document handover adds no warranty, maintenance or permanent assistance beyond genuinely agreed terms.
07
Questions before closing the pack.
Is a successful demonstration enough?
It proves only functions actually observed under the recorded conditions. Compare results with the agreed scope. Untested functions and outstanding issues remain visible with their owner and next planned check.
What if documentation is missing?
Identify the missing document, affected system and person responsible for supplying it. Record how the absence affects operation or recovery. Do not replace an exact document with a neighbouring model’s without verification.
Does a delivered backup prove restoration?
No. Existence, readability, import and service recovery are separate steps. Document what was checked, with which version and in which environment. Intrusive tests require planned authorisation, not ad hoc use during normal operation.
Should passwords be placed in the pack?
Not in widely distributed documents. Arrange secure handover appropriate to roles and system procedures. The pack can identify the responsible person and recovery workflow without containing the secrets themselves.
Who closes an issue after correction?
Define responsibility and required approval for the project. Keep the old observation, change, retested version and result observed by the designated person. A “fixed” notification alone is not evidence of success.
08
Close an issue with evidence, not intention.
Keep a register separate from the general acceptance record. For each line, retain the relevant version, owner, planned action, evidence and authorised recipient’s decision. The example below is not an actual acceptance.
Scroll the table horizontally to compare all three columns.
| Issue | Action and expected evidence | Closure criterion |
|---|---|---|
| R-01 · V2 backup for V3 installation | The integrator supplies the identified V3 export and verifies reading or import in an agreed environment. | Date, file, version and result recorded; test limits explicit. The active service is not overwritten for the demonstration. |
| R-02 · owner access unverified | The recipient signs in normally and opens the agreed documents using their own account. | Access observed with the appropriate role; no shared secrets. Sending a link alone does not close the issue. |
| R-03 · remote audio untested | An authorised remote participant joins a test under agreed conditions; record both endpoints and the version. | Result heard and confirmed at both ends, or issue retained with next action. A successful local picture is insufficient. |
Technical sources
External reading references. These documents explain principles; they do not certify catalogue products or their combination.
- Support partenaireInovexia · Sources consulted on
- Project backup — Preserve and verify project exportsKNX Association · Sources consulted on
- Backups and Migration in UniFi — Backup scope and recoveryUbiquiti · Sources consulted on
- UniFi Password Recovery and Ownership Transfer — Ownership boundariesUbiquiti · Sources consulted on