What do you think is a good structure for an ongoing support agreement with a client for their website?
Here’s another LinkedIn question and my response, this time on best practices for client / vendor agreements for web services. Whether you’re a web developer or a business owner who is using (or about to use) a web vendor, read on, my suggestions below help protect both the client and the web developer.
This isn’t the final word or an encyclopedic review of the subject, but it’s a solid start. Comments and contributions are welcome as always.
The Question
What do you consider a fair agreement for an ongoing support structure for a website, including bug fixes, phone/email support etc from a web development agency.
What should be complementary/included and how long would that be reasonable?
Do you factor the likely cost of that support into your projects or would you absorb the cost? e.g. Quoting 15 hours to do a website you would agree to 12 hours of support a year at no extra cost?
My Answer
As a few people here have pointed out on this thread already, there are different types of support to consider. Here’s one way you can create an arrangement to cover three key types (bugs, enhancement requests, training and staff support), and to protect against scope creep and cost overruns.
In your agreement:
1. To address the “feature vs. bug” issue and scope creep, make sure the requirements are as detailed as possible, and that the spec documentation (including wireframes) is signed off on by the client when a price is agreed to. This way the client can’t come back later and say “There’s a ‘bug’ because the system doesn’t have an export feature.”
2. Build training and documentation into the initial project bid. Base it on how long it will take to write a user manual and do a half-day or day of user training. This is best because then you’ve done your part in terms of supporting the client users, and they can train new and future users. If the client doesn’t want to pay for documentation and training up front, tell them you’re happy to support them whenever they need, but you’re going to have to charge them hourly for phone, online and in-person training and support.
3. Make sure that you involve the client in final testing and QA so they can give system approval and “acceptance” before you go live. Build time in for client testing and acceptance into your project plan. It’s amazing how many projects skip this step and then go into crisis mode when the client starts finding issues two days before scheduled site launch.
4. Set a time period for free bug fixes, which depending on the scope of the job can be 30 days, a year, or whatever both parties feel is appropriate. If you don’t do that, in two years when the new version of PHP (or whatever language the site uses) comes out and a feature breaks, you’re going to be on the hook for rewriting code for free.
5. Offer a maintenance program up front with a discount rate for committing to monthly hours. Give them a small (2-5%?) bonus discount if they pay for a bucket of hours in advance. The scope of this program depends on the size of the client and project. Work with the client to figure out what they’re realistically going to need. Don’t try to sell a bunch of hours they don’t need. If they don’t plan on adding features, just do a few hours for minor tweaks like updating pages, adding options to forms, etc. If they plan on ongoing development, figure out what they’re willing to pay and then agree on that many hours.
Good luck!
