I’ve spoken with many auctioneers recently who are at the beginning stages of a new technology project, usually a website redesign or new build of some kind. The questions everyone asks mostly revolve around the expectations they should have of the person or company being hired to build the website.
I’ve put together some content that I consider important to include in an RFP – request for proposal. It’s by no means exhaustive, and at least some parts of it will have to be changed for every application, but it’s a start to a baseline set of what I believe to be good standard practices when entering into a relationship with a service provider. For the purposes of this post, buyer is auctioneer, seller is service provider, employee is a backend user and user is frontend user. We’re going to assume that the buyer will provide a mock-up created by a designer. This mock-up would show exactly the layout and presentation requested by the buyer so that all the seller has to do is build the site using web standards. This draft assumes that your provider will install the website on a purchased or rented server controlled by the buyer. It assumes that the buyer has an email list system – I recommend phpList – and wants ownership of the auction calendar as opposed to using a third party’s auction calendar like that from Auction Services or AuctionZIP. I’m neither endorsing nor recommending against either of those popular auction website providers, I’m merely giving an example of a possible permutation. Perhaps a third party calendar is desired, as well as housing the site on the seller’s servers. Each auctioneer’s needs and desires are different. I’ve intentionally tried to stay away from most functional pieces of a good website and focus instead on the deliverables and legal requirements that should set the ground rules of a work for hire.
Website must include a calendar system that will facilitate easy creation and display of auction title, date, time, location and thumbnail images. Frontend layout is provided by attached mock-up. Backend must allow upload of images, auction event creation and modification and be available only over secure connection. Seller must install security certificate on buyer’s environment if it doesn’t already exist. Backend login must be employee-specific with ability to grant access to various resources to various employees.
Email subscription form must allow direct subscription ability and integration with a bulk email list management system such as phpList or Intersend.
Sales lead generation form must email leads to email address or addresses as specified by buyer or employees in the backend.
In order to anticipate future browser compatibility we require conformance to the following W3C standards.
- Markup must validate to the W3C’s XHTML 1.1 doctype at http://www.w3.org/TR/xhtml11/
- Style sheets must validate to the W3C’s CSS 2.1 format at http://www.w3.org/TR/CSS21/
- Site must not use tables for layout purposes. Tables will only be used for tabular data.
- Website must be tested to display similarly in current and the last major release of Internet Explorer, Mozilla Firefox, Apple Safari, Opera, Konqurer, and Google Chrome on stock installations of Microsoft Windows XP and Vista, Apple OS X and Ubuntu Linux where each browser is available on each operating system, as well as Internet Explorer 5 and 6.
- All deliverables must be installed by seller on buyer’s environment.
- All deliverables will be considered “work made for hire” under U.S. Copyright law. Buyer will receive exclusive and complete copyrights to all work purchased. Any use of open-source content must be expressly defined and agreed to by buyer before implementation.
- No dependence on outside services is allowed. The website must function completely and independently of any third party site, service or server, unless expressly permitted by buyer.
- Seller will have no rights to use, reproduce or access any content, materials or other information stored on the website, including but not limited to form submission, customer information, email addresses, sales data and account records.
- Work must be original and not based on existing templates or previously-constructed components used by other customers of the seller.
Successful proposal will include the following components.
- Bid for construction of website using web standards with layout defined by provided mock-up and functionality defined above. This construction must include documentation and training sufficient for buyer to understand and operate site completely and effectively.
- Estimate of time to completion as well as financial implications of delays should they occur due to additional requests made by buyer or developmental hardships experienced by seller.
- Bid for continued ad-hoc support and maintenance on an hourly basis. Support must be provided by website creator if that person is different from seller.
- List of hours with guaranteed availability for support.
- List of five websites created by seller and contact information of website owners to serve as list of references.
Now, I realize that this draft is very strict. Some providers may balk completely, and some that don’t balk may intentionally price themselves out of the competition because, like using perfect English, using web standards is hard for some. Hopefully, however, this example may serve as a valuable starting point for someone looking to start from scratch. Compromises may be desired on certain parts, like XHTML validation, but an auctioneer should always retain the rights to your data (deliverable 4) and be sure that the provider will support the product after it’s built. Above all, be sure to have a very clearly-defined, counsel-approved contract that you can use to hold the service provider accountable should you believe that the work is incomplete or incorrect. Writing an example RFP was requested by many. These are some of my ideas. Do you have a must-have condition for the work that you hire done? Leave a comment so we can build on this document and add it to the resources page.