AV Control Support SLA: Separate Response from Restoration

An AV control support SLA should distinguish acknowledgement, active investigation, workaround and restoration. Define severity by operational impact and state exactly when each clock runs. A promise to “respond within four hours” does not mean the venue will be working within four hours, particularly when access, spare parts or a third-party content system determines the recovery path.

Define the supported service boundary

List the installed control version, covered rooms and interfaces. Explain whether the service includes operating-system maintenance, device firmware, content playback and network troubleshooting. Where another supplier owns an interface, describe the coordination responsibility and information exchange. Avoid offering a single restoration guarantee for systems over which the support provider has no practical control.

Name the accepted reporting route and required ticket information. An operator should be able to provide venue, zone, symptom, current visitor impact and last known working time without understanding protocols. Establish how urgent incidents are escalated outside normal hours and whether the contract includes that coverage.

Write useful severity examples

The table is a drafting example, not a market-standard service commitment. Choose numerical targets only after checking staffing, geography, access windows and equipment replacement arrangements. Have the actual contracting parties review the final wording through their normal commercial process.

Define the clocks and evidence

State when a ticket is received, what constitutes a qualified acknowledgement and when active investigation begins. Record pauses caused by denied site access or waiting for a customer-approved action, with timestamps and an owner. A pause should be visible and justified rather than a way to conceal inactivity.

Define restoration in operational terms. A gallery may resume with one screen unavailable under an agreed workaround, while the permanent repair remains open. Record both states. Distinguish “control command sent,” “device replied” and “visitor service restored”; these are different observations and may occur at different times.

Make remote support a controlled dependency

CISA's remote-access guidance is relevant because support tooling itself needs governance. Agree which remote tool is authorized, who grants a session, how authentication works and what evidence is retained. Avoid assuming permanent unattended access is acceptable simply because it would make support faster.

NIST's contingency-planning reference provides context for prioritizing recovery. Translate that into room-specific operating alternatives: an operator-led presentation, an isolated zone or a postponed special event. These are proposed operational choices, not a claim that a given tool automatically delivers resilience.

Exercise a support ticket before go-live

Run a sample incident with an operator and the service desk. Verify the reporting route works, the asset can be identified and the support engineer can locate the correct configuration baseline. Test access authorization without changing production behavior unnecessarily. Record how long each agreed stage took, but do not extrapolate one exercise into a guaranteed future response time.

Review incident patterns periodically within the contracted service process. Repeated standby failures may indicate a configuration defect that deserves a planned fix, while repeated requests for new content are a different service need. Keep the record factual and avoid inventing availability percentages from incomplete ticket data.

Use the AV commissioning checklist to establish the initial operating baseline. Ask SoftControl partners about the specific support arrangement available for your region, devices and deployment; the example SLA here makes no promise about SoftControl staffing, coverage or restoration times.