Introduction
A paragraph about services and deliverables usually comes at the top of the agreement. Here you’ll see provisions describing the engagement, setting rules about personnel, establishing an SOW process, defining work is accepted, and the like. Keep this book handy to navigate those initial provisions with confidence.
The Engagement
A typical engagement paragraph looks something like this:
You’ll often see a lot of things jammed into these initial paragraphs, but there are a couple things to keep in mind:
- Form of SOW. Even if the Service Agreement specifies a form of SOW, an Agency often will have much more luck customizing that than editing the agreement. So, if the Service Agreement doesn’t specify a form of SOW, use yours. If the Service Agreement does specify a form of SOW, you may still be able to use yours. The argument you can make is that it is already customized to the types of work that you perform (whereas the Client’s form of SOW will likely be generic). The SOW often gets less legal attention than the body of the Service Agreement. So, use the SOW to customize your deal instead of negotiating boilerplate terms.
- Staff Management. The provision giving Client the power to remove staff from a project is typical in larger Service Agreements and generally isn’t worth fighting. Be sure that Client is subject to some reasonableness requirement. Or better yet, a requirement that Client notify Agency of staff problems and provide a period to fix problems before the Client can require removal. A clause reflecting these recommendations might read:
- Exclusivity. Very likely an Agency’s engagement will be non-exclusive. That is preferred except in rare cases (e.g., agency-of-record status). If the agreement is silent on exclusivity, then the default is non-exclusive. And that is OK.
- Compliance with SOW. The example above requires that Agency’s work be “in accordance with the schedule, specifications, and requirements set forth in the applicable SOW”. The problem here is that only vary rarely does a project exactly comply with schedule, specifications, and requirements in the applicable SOW. The simple edit here is just to qualify compliance as “material” compliance or “reasonable” compliance. This ensures that small or technical departures for the SOW won’t be used as grounds for termination or withholding payment.
SOW Conflicts
An agreement should contain a provision resolving conflicts between the body of the agreement and the terms of the SOW. This is often in the engagement paragraph or nearby (though can also be buried elsewhere). A typical provision might read as follows:
The situation this comes up most typically involves payment terms. For example, the body of the agreement will likely say that the Client pays net 30 on monthly invoicing. If your project calls for an advance deposit and monthly advance retainer payments, those specifics will be included in the SOW for the project.
A couple things to keep in mind about how to reconcile conflicts between the Agreement and the SOW:
- Which to Control? As a general matter, I recommend that the SOW control if there are conflicts between it and the Agreement. The reason is that the whole point of the SOW is to have a deal-specific set of terms. Allowing the SOW to control gives you the flexibility to adjust to project needs without amending the main agreement. If your agreement does not contain a provision resolving conflicts between the SOW and the body of the agreement, you should include one that reads something like the following:
- Except as Provided in the SOW. If the Client insists that the body of the agreement overrides the SOW, your focus then should be on adding the words “except as provided in the SOW…” as qualifiers to key agreement provisions. The most common provision to qualify is the paragraph stating payment terms of net 60. You add “Except as provided in the SOW…” as a qualifier to that paragraph, and then you have the flexibility to customize payment terms in the SOW. Another common clause to consider qualifying is the paragraph defining acceptance procedures.
Acceptance of Work
Many Service Agreements contain a provision specifying a mechanism for how services and deliverables are to be approved by the Client. A typical provision might read as follows:
I don’t like these provisions for the simple reason is that they require formality that is rarely, if ever, followed. Nevertheless, it is difficult to get these provisions removed from the Service Agreement. While it is fair for the Client to not have to pay for things fairly rejected for not materially meeting specifications, to minimize risk, your goal should be to limit the scope of what Client can reject. Consider the following next time you face a provision like this:
- Defer to the SOW. If your project requires a specific approval process or phases, detail that in the SOW. As we discussed above, just make sure that the agreement appropriately defers to the SOW (e.g., “Unless otherwise provided in the SOW…”) or the SOW specifically overrides the agreement’s default approval process (e.g., “The following approval process replaces the provisions of Section X in the agreement.”)
- Be Objective. In determining when work is “done”, avoid specifications such as “to Client’s satisfaction” or other subjective phrasing. If possible, use your SOW to document objective specifications for determining when work is complete. This is especially important for development projects. You may also want to specify tests that indicate when functionality is complete (e.g. “a user submitted form generates an e-mail with form contents to contact@example.com, incomplete forms prompt user for missing information”).
- Limit to Material Problems. Rare is the creative services project that is delivered flawlessly. Deal with this by including a qualifier on the compliance requirement such as “substantial” or “material”. In the above example, you’d add the word “substantially” before each occurrence of the word “comply”. The need to qualify performance standards can come up in other contexts. For example, see the discussion above about The Engagement.
- Require Specifics. If something isn’t up to snuff, you’ll want the Client to give specifics about how a deliverable fails to meet specifications. This helps avoid the “We don’t like it” rejections. Avoid language that allows the Client to simply specify “any other objections, corrections, changes, or amendments Client wishes made to the deliverable.” Language like this is a round-about way for Client to expand scope under the guise of rejecting work.
- Be Realistic and Flexible. Consider adjusting the acceptance period on work to something appropriate for the project and type of work. 30 days to approve when you are against a deadline is an eternity. Five business days is more practical (though still can be slow for certain projects). Or better yet, specify the approval period as “such time as is reasonably specified by Agency.” If the client insists on a longer time frame, then be sure to account for that in your project calendar and fee. You can also specifically define the things in the SOW that are (and are not) subject to approval.
- Silence is Acceptance. Try and set clauses like this so that the default for silence is acceptance. You can accomplish this with a sentence to the effect:
- No Turning Back. Finally, be sure to specify that accepted work cannot be later rejected. This is a straightforward edit:
Conclusion
Many Service Agreements begin with provisions describing the relationship between the SOW and the body of the agreement as well as the process for acceptance and rejection. An Agency should keep an eye on these provisions to ensure the specialized terms of the SOW are given effect over any general terms of the contract. The Agency should also be wary of acceptance provisions that might delay a project or give Clients a back-door way of expanding scope.