Automation legalities: Papering the maintenance relationship
How does an automation provider put in writing the "maintenance and service" relationship?
As I see it, there are three types of maintenance and service agreements. The first is an alternate within the original design and installation agreement. Check the box, pay this amount, and the "maintenance and service" scope is added.
The second is via an independent written contract (the best choice if you were polling attorneys).
The third option—and far and away the most common—involves simply picking up the phone, listening to the immediate issue, and jumping into the fray whenever it makes sense to do so (call this a "callback" relationship). The agreement? There is not much of one to speak of—you are the customer, your satisfaction is important to us, and we will try to get the thing up and running to do what you want it to do. Never mind that there may be some muddiness as to whether this is original scope, a warranty call, a retrofit, an upgrade, or maintenance for a fee.
Each of these arrangements has its strengths and weaknesses from the perspective of the automation provider.
First-rate maintenance and service agreements are not off the shelf, but tailored to the application in question—rarely will a generic master service agreement do the job well. The must-have "legal clauses" fall into two categories: those that are specific to the maintenance relationship and those that are not.
The sections particular to maintenance contracts deal with payment, definitions, warranties, exclusions, and what I call "response boundaries." Those of a general character (call these "the usual suspects") address limitations on liability, termination, confidentiality, force majeure, disputes, and completeness. Only the former set of five legal clauses will be discussed here.
1. Payment. The payment terms available for maintenance and service agreements are superficially the same as those for automation contracts generally—lump sum, guaranteed max, and cost plus—with two important forewarnings. The first is that there is inherently an open-ended quality to the scope of these agreements that argues for time and material billing. The second is a competing dynamic—the fact that end users (like car owners) view the maintenance and service relationship as a sort of protective shield, arguing for closure (pay this fee and you do not need to worry any more). Given these opposing forces, the guaranteed max (or some variation on that theme) or lump sum with hours threshold and fixed rates are acceptable compromises.
2. Definitions. Certain contractual terms cannot be left to themselves in a successful maintenance and service relationship. Most important are defining the precise extent of the "covered system" in question, the boundaries between "customized" and "third-party" software, and the scope and nature of the services themselves.
3. Warranties. Of all the boundaries between original scope (design/installation) and maintenance, none is more fraught with difficulty than the line involving warranties. No end user wants to be invoiced for that which would be free in the absence of the extended service agreement; no integrator wants to be denied payment for additional work because the end user is unfairly raising the warranty flag.
4. Exclusions. Related to this is the need to carve out what is not covered by the maintenance agreement. Services provided to someone other than the end user certainly are not. So is migration from one platform to another. Upgrades are either in or out depending on the system (and what type of upgrade we are talking about).
It also may be wise to exclude the following:
- Services arising from an end user’s failure to maintain an installation and operating environment in accordance with the system documentation
- Service arising from damage occurring to the system or any of its parts beyond ordinary wear and tear, including accidents; unusual physical, electrical, or electromagnetic stress; neglect; misuse; failure or fluctuation of electric power, air conditioning or humidity control; excessive heating; natural disasters such as fire, flood, wind, earthquake, or lightning accident; or fire and smoke damage.
- Services that involve deviating from the best practices of the control system industry.
5. Response boundaries. A final type of boundary is the one involving responsiveness to end-user needs. Inherently the maintenance relationship has a response-reaction facet that is minimized if the integrator has a facility presence but is maximized if there is none. How quickly is a response required? It depends on the correct response. One way of structuring this aspect of the relationship is to define degrees of magnitude right there in the agreement (defining the difference between an emergency and a low-priority fix—and calibrating the sometimes considerable distance between them).
– Mark Voigtmann leads the automation practice at Faegre Baker Daniels, a law firm with offices in the U.S., the U.K., and China. Follow Mark’s regular posts on legal issues at http://twitter.com/automationlaw or reach him at Mark.Voigtmann@faegrebd.com or 317-237-1265.
Edited by Mark T. Hoske, content manager, CFE Media, Control Engineering and Plant Engineering, firstname.lastname@example.org.
See related video clip http://bit.ly/P8kmTl