'Maintenance Blocks' - Managing Change Requests

An equitable system for maintaining and upgrading client work after launch.

What Are ‘Maintenance Blocks’? It’s an idea I developed which is meant to provide a fair system for undertaking bug fixes or upgrades on client work. In simple terms; they are pre-paid units of maintenance.

It never felt quite right to round-up 15 minutes of work to one hour (for the purpose of creating an invoice). However, I wasn’t happy about doing work for free for a client just because it was a small task (e.g. creating a new email account, adding Google Analytics to a website, etc).

One of the major advantages of maintenance blocks for clients is that a lower rate is locked-in for future work. There is also a degree of convenience since invoices aren’t being sent out for small pieces of work. In addition, maintenance blocks are very flexible since they can be used for either bug fixes or upgrades to a client’s existing project.

Maintenance blocks are also about mutual obligation. Having a client pre-pay for maintenance work ahead of time is a sign of good faith. In return, I give a guarantee on turn-around time (generally 48 hours from the time the request is acknowledged). If I don’t respond within the agreed amount of time, the client gets their work done for free.

I designed maintenance blocks to be purchased in ‘packs’, generally eight or sixteen blocks, with each block being equivalent to 15 minutes of work. Depending on the complexity of the task (be it an upgrade or bug fix), varying amounts of blocks are consumed. Generally speaking, a minor change would use 1 block, an intermediate change would consume 2-3 blocks, and a major change will use 4 or more blocks (nb. minor or intermediate changes are most common).



I generally have it so blocks do expire, but the amount of time they stay valid is quite long (e.g. 6 months for eight blocks).

The way a client uses maintenance blocks is quite simple. They would email a request for change via email, I then let the client know how many blocks need to be used for the change and how many maintenance blocks they will have left after the change (e.g. “you have 3 maintenance blocks remaining, the change you are requesting will use 2 of those blocks - leaving you with 1 block”). The client then confirms their agreement or raises any questions they may have.

The system is squarely aimed at small bug fixes or changes. For example; “the positioning of the logo on my website looks funny in Google’s new browser, can you fix it?” or “please add a new menu item and page to my website called 'Customer Feedback'.” The system is not meant to cover major changes (e.g. adding online shopping facilities, re-vamping the layout of a website, etc). Generally, if a change is more then 16 blocks in size (i.e. more then 4 hours), I consider it to be beyond the scope of the maintenance blocks system, and therefore would require a separate contract to be negotiated.



Why do maintenance blocks get used for bug fixes you may ask? When a project is still under ‘software warranty’ (typically, for a period of 6 months after completion), blocks don’t get consumed for bug fixes. But after the warranty period has expired, I do charge clients for fixes on their projects even if they are my fault. With the work I do, most bugs are found during the QA cycle, with few emerging past the 6 month point (but it still can happen).

Lastly, I don’t ‘force’ clients to use the maintenance block system if they don’t want to. The alternative is to negotiate a charge-out-rate and turn-around time whenever work needs to be done. At it’s core, the system was created to make everyones' life easier. Costs are settled before-hand, thus allowing us to get on with what’s important; the work.