What should an automation maintenance contract include?

A useful maintenance contract states which systems are covered, who responds, during which hours, within what timeframe, and what happens when a fault requires a site visit or replacement parts. It should also cover updates, backups, access and documentation.

“24/7 support” is not specific enough. It may only mean that a platform can generate alerts at any time, without a technician reviewing or acting on them around the clock. A sound agreement turns broad promises into conditions both parties can verify.

Start with an accurate system inventory

“Automation” is too vague for a scope of work. Lighting, climate control, blinds, access control, CCTV, networking and energy systems may involve different manufacturers, warranties and service providers.

The technical schedule should identify the main equipment, relevant versions, locations, connections between systems, and any cloud services or licences they rely on. In an integrated installation, what looks like an automation fault may begin with a router, controller or expired account.

An inventory also distinguishes the original installation from later additions. Without that baseline, it is difficult to assign responsibility or confirm whether a proposal covers the full service ecosystem.

Separate monitoring, response and resolution

These are different commitments:

• Monitoring: the system detects and records an event.
• Response: someone reviews it and provides an initial assessment.
• Resolution: service is restored remotely or on site.

A two-hour response time does not promise a repair within two hours. Resolution may depend on access to the building, available parts, manufacturer support or another contractor.

Set priority levels according to operational impact. An unavailable app, while local controls still work, is not equivalent to a locked entrance or a failed network in a business premises. For each level, confirm coverage hours, the contact channel, the response target and when the clock starts.

Updates need a controlled process

An untested update can solve one issue and introduce another. Deferring every update indefinitely creates its own compatibility and security problems.

The agreement should say who approves and performs updates, whether a backup is taken first, and which functions are tested afterwards. Where the system allows it, changes should be logged and a rollback path retained.

Customer-requested changes matter too. Adding a camera, changing the internet provider or replacing climate equipment may affect existing integrations. Establish whether this work is covered by the recurring fee or quoted separately.

Write down the exclusions before the first fault

Proposals become comparable when they show what is excluded as clearly as what is included. Check, in particular:

• Travel, on-site labour and out-of-hours work.
• Parts, consumables and equipment outside warranty.
• Licences, cloud storage and manufacturer subscriptions.
• Building work, electrical work and additional cabling.
• Failures of the internet provider, electricity supply or third-party services.
• Changes made by other installers without coordination.

For a multi-unit development, establish whether the agreement covers shared areas, individual apartments or both. Site access and the authority to enter a unit also need an owner; without access, the service target stops at the front door.

The customer should retain control of access

Shared accounts and passwords known by several teams make interventions difficult to audit. Prefer named users, permissions limited to each role, and a process for removing access when a person changes role or provider.

The customer should know who administers each account, where backups are stored and which documents are handed over. At the end of the agreement, there should be a clear transfer of credentials, configurations, change records and manufacturer contacts. Maintenance should not create dependency through missing information.

Compare the service against four scenarios

Before signing, ask what happens when an alert arrives overnight, a fault requires a visit, a device is discontinued, or the system moves to another provider.

Those answers are more revealing than a long task list. They expose additional costs, external dependencies and the limits of remote support.

A good contract does not promise that nothing will fail. It defines how faults are detected, prioritised, communicated and resolved — and who makes each decision.

Review my maintenance scope. Include the installed systems, operating hours and the functions that cannot tolerate downtime.