PLAN
Map the auction workflow, venue constraints, system dependencies and people responsible for each critical task.
Reference connects the individual systems on this site into repeatable auction-day procedures. It is where sound, connectivity, lighting, security and equipment become one tested operating plan rather than five separate technical areas.
Use these materials to define requirements, record a known-good configuration, test the complete path under realistic load and give staff a recovery sequence they can follow while the sale is live.
The system pages explain individual technical areas. Reference is different: it organizes the decisions that sit between them. A streaming failure may involve WAN service, LAN switching, device power, software credentials and the person responsible for failover. A checkout delay may begin with a printer, but the real dependency may be a shared USB hub, an overloaded workstation or a network path used by several stations.
A useful reference therefore describes the task, the full dependency path, the condition that counts as a pass and the fallback staff will use if the primary path fails. The goal is not more paperwork. The goal is a short operating record that makes setup faster, troubleshooting calmer and equipment changes easier to evaluate.
Map the auction workflow, venue constraints, system dependencies and people responsible for each critical task.
Run the complete signal, data, power and operator path under conditions that resemble the live sale.
Keep the working settings, connections, device roles and measured results as the known-good baseline.
Define the trigger, backup path and person authorized to switch to it without stopping the room.
Reference is not a collection of generic definitions. Each entry should lead to a measurable requirement, a practical test, a record worth keeping or a clearer recovery action.
Power and core networking are checked before software, audio is tested at bidder positions rather than beside the console, and checkout is tested as a complete transaction rather than as an isolated printer test.
Record sustained upload, UPS runtime at real load, audio coverage, camera retention, cable distance, operator count and the time required to move to a backup path.
Document device roles, connections, software versions, critical settings and the physical layout that worked. A baseline makes later changes easier to isolate and reverse.
A backup is operational only when staff know when to use it, where it is, what it depends on and how to confirm that the handoff succeeded.
The first Reference article provides one practical sequence for proving the complete auction operation before bidders depend on it.

One sequence covering power, network, sound, lighting, security, clerking, checkout and recovery.
The checklist starts with shared dependencies, then moves through bidder-facing systems and finishes with deliberate failure tests. It separates “the device turns on” from “the task can be completed and recovered by the assigned operator.”
A short checklist, a measured baseline and a rehearsed recovery path usually create more sale-day value than another feature added without a clear owner or test. Begin with the first cross-system checklist, then use each result to improve the relevant system file.