Managing Client Expectations: User Acceptance Documentation

Share this article

A common question on Sitepoint’s Business & Legal forum is, “I’ve delivered what I promised but my client keeps asking for small tweaks, support, and advice. How do I determine when a project is over, and how do I communicate this to my client?

Most web developers have experienced the ‘never-ending project’ and can sympathize with a developer in that predicament. It’s not easy to balance great service with the need to put some boundaries and limits on what you are willing to do for your client, and it’s especially tough when you are just starting out and you need to have 100% client retention!

The good news is that there’s an easy and simple way to prevent this problem: the User Acceptance document.

User Acceptance is just what it sounds like – an acknowledgement from your client that you’ve fulfilled your part of the deal (as set out in the original contract) and the project can end. User Acceptance is commonplace in the software industry and usually consists of a User Acceptance (UA) document which the client signs and returns once the work has been completed
to their satisfaction. In addition to putting some legal structure and accountability around the completion of the project, the UA document also serves as a crystal clear message to the client that you’ve come through on your end of the deal. It also makes the client explicitly accept the work, which will make them think twice about asking for ongoing free changes. The UA document also serves as a clear starting point for a warranty period or the beginning of a next phase.

An effective UA document can be just one page long, and have a single paragraph containing language like,

‘The undersigned agrees that ABC WebDev, Inc. has fulfilled the requirements
set forth in the agreement signed on Jan 1, 2006 and that the project is complete.”

You can expand the UA document to explain the billable rate (or other terms) for ongoing work or the length of the warranty period, which would ideally begin when the UA document is signed. Any other points that you want to make clear should also be included in the UA document.

For a UA document to be effective, the following elements must be taken into consideration:

  • The client needs to understand what the UA document means. The UA concept should be introduced in your original contract, and the client should know how it fits into the overall project flow. Make it clear that when you’ve completed the work, you’ll send the UA document for them to sign.
  • There has to be some motivation for the client to sign the document, and some clarity about what happens if they don’t. A good way to address this is to add language to the original contract and the UA document which dictates fair terms for the end of the project, such as:

    1. Starting on the day the client receives the UA document, they have 30 days to report any functionality gaps or other deficiencies in the delivered product (things that you promised to do but did not). Make it clear that you will fix any such deficiencies as quickly as possible, free of charge.

    2. The warranty period of xxx days will begin once the UA document is signed. Bugs (but not substantial changes that deviate from the original agreement!) will be fixed for free during this time.

    3. If the UA document isn’t signed within 30 days, the contract will automatically end and the warranty will be terminated. Any enhancements, bugs, or changes found after the project termination or beyond the warranty period will incur a new bill.

Using the above simple terms, the average client will want to sign the document to ensure that they don’t void their warranty period. You benefit by having a clearly signed UA document because you don’t have to worry about never-ending change requests – if the client asks for changes following UA, they’ll understand that they will be charged.

Obviously, each developer will need to customize the UA concept to fit their individual project’s needs. In some cases, a developer may not deliver a finished website until the UA document is signed. In other situations, the signed UA document must be accompanied by a full payment. Regardless of how you apply the UA concept, you’ll do both yourself and your client a big favor by having formal, signed documentation at the end of the project instead of just at the beginning!

Dave HeckerDave Hecker
View Author
Share this article
Read Next
Get the freshest news and resources for developers, designers and digital creators in your inbox each week