Tips & tricks to avoid disputes over availability of real-time data in a smart building

A smart building collects a lot of data via smart sensors, for example about how the building is used. That data provides insight into the current state of the building (where wear and tear might occur, where maintenance is needed) and ensures that a smart building can make (automated) decisions. For example, a smart building can automatically adjust climate control to the number of people in a room. This requires a constant (Internet) connection between the smart sensors and the smart building's digital cloud-based software platform. But to what extent can you as the buyer of the software (usually the building owner) expect 100% availability of the software and thus the proper functioning of the smart building? In this blog, I answer that question and discuss tips & tricks for the software supplier and the buyer to avoid disputes.

For a smart building to function and properly perform its task as the user's "personal assistant," a stable connection between the sensors and the software platform is essential. Of course, this can sometimes go wrong. But in that case, is the supplier liable for damages? In proceedings before the Arnhem-Leeuwarden Court of Appeal, the question arose last year as to whether a purchaser of software for a work environment may assume that it has 100% guaranteed access to this work environment.[1] The Court of Appeal ruled that it is not. In doing so, the Court of Appeal found the following circumstances relevant:

• What service/support level is agreed upon?
  Software vendors often offer different support levels at (obviously) different prices. The expectations of the service to be offered that a customer may have are related to the support level purchased.
  
• Is all or part of the software system hosted by the software vendor?
  If the entire chain of the ICT infrastructure is not managed and supported by one vendor, this increases the risk of software failure and unavailability.
  
• Has a guarantee been agreed?
  If the software license agreement (or "SLA") does not explicitly state that the agreed support level amounts to a guarantee with availability of the work environment or fault-free access to that work environment, this may not be assumed. This certainly applies if other parts of the SLA make it sufficiently clear that there may be outages, temporarily reduced or unavailable (parts of) the system and it has been agreed that the helpdesk can be called upon in that case in accordance with the agreed service level. In that case, the customer must assume that failures and other outages may occur.
  
• Duty to warn software vendor?
  If the customer is a professional counterparty, the software vendor does not have to warn again on its own accord that no (virtually) fault-free access is guaranteed. Therefore, the customer may also not rely on the software supplier to warn her about this yet again.

In short, whether a (virtually) fault-free availability of a software system can be expected depends on what the parties have agreed upon with each other.

[campaigns]

Action items software vendor

The following action points, among others, will help you as a software vendor avoid a dispute over accessibility to (often essential) software:

• In an SLA, make good and clear agreements about the percentage of availability to be offered;
• Be realistic in the guarantee regarding availability. Do not offer a percentage availability if it is unlikely to be achievable;
• Establish whether unavailability due to maintenance is deducted from the availability percentage, or whether it is separate from the guaranteed availability;
• Agree on backups and security. When a total package is delivered, it is more likely to assume that the associated security is included;
• If you do not supply or maintain the entire ICT system, it is important to include exonerations regarding those third-party systems.

Action items buyer

It is also important for the customer to clearly define agreements on availability in an SLA. Additional important agreements include:

• Warranties. A buyer could negotiate a guarantee on the availability offered. It is then important that a discount or penalty is attached to failure to meet the guarantee;
• When will (and may) maintenance take place. Consider, for example, an office building that is a smart building. In an office building people usually work during the day and maintenance in the (late) evening hours and at night will cause the least inconvenience. By agreeing on maintenance times, nuisance is kept to a minimum;
• Match the desired/necessary availability to the service package. If you find that you suffer immediate damage due to inaccessibility, you should purchase a higher service package (and thus faster action). If you can also bridge a (limited) time offline, a lower service package is sufficient;
• Think about the duration of the contract: when may the supplier terminate the contract and how will this affect you / your business? If the service is essential then a time-limited contract, for example, is not wise.
• Backups. Agree who is responsible for backups of essential data.
• Exit arrangement. What if you want to switch to another service provider? Or what if your software vendor goes out of business? Can you then easily switch to another vendor and migrate the data? What are the notice periods?

By addressing the above issues in IT contracts, future discussions about system availability and its consequences can be avoided as much as possible.

Do you have questions about smart buildings and the necessary contracts surrounding the integrated software? Please feel free to contact our specialists: Valerie Lipman (v.lipman@pvdb.nl) and Noreen Sturris (n.sturris@pvdb.nl).

[1] Arnhem-Leeuwarden Court of Appeal June 29, 2021, ECLI:NL:GHARL:2021:6380.