>Hi all,
>
>I'm developing a system for 3 remote clients...it is basically the same system, with some differences built in for each client. It will most likely NOT be sold to additional clients (it's a social security system). I'll be traveling to each site to do installation, conversion and training.
>
>I'm trying to figure out how to go about setting up some kind of maintenance agreement, and am having trouble deciding what is fair to the client, but offers them some basic level of support (say, priority over my other clients for responding to problems/questions, etc.).
>
>It's clear that I will fix any bugs that I caused, or if something in the system doesn't live up to the original design/agreement. It's also clear that if they request a change, they will be charged for it (and we'll work out something so that if it's a major change and all three want the change, they can share the cost, etc.).
>
>I see that many companies charge an annual fee that covers upgrades, etc. But i am not going to be independently making improvements to the system, i.e., all the changes will be initiated by the clients and paid for.
>
>But, there will probably be a great deal of support required - especially over the first few months, and I want to be compensated in some way. Charging by the hour for e-mail/telephone support seems too complicated.
>
>I'm wondering what consultants do in cases like this...any ideas are welcome. Thanks! J

You're right, you need to address this if it hasn't been already in your original development contract.

Basically, as a consultant, time you spend in telephone support or e-mail support is time out of your life, that you could have been spending doing other things. You need to be compensated for that, anything else is not sustainable. Business people understand this; if you charge fairly for your time they will respect that, and will use your time judiciously. If you don't charge for it they will perceive your support time as being of no value, so they will abuse it with petty things, things that aren't even related to your application etc. The idea is to encourage them to be as self-sufficient as possible, while reassuring them that professional-grade help is available if they do get into a jam.

Because level of support needed is likely to be unpredictable, I think the fairest way is to charge by the hour. You'll need to get used to billing by time; then invoice them at an interval that's comfortable for both of you e.g. monthly, bimonthly etc.

If you anticipate a lot of time in the near future, and you'd like to give them an initial break, you could offer a discount:

- a rate discount off your entire support bill for, say, the next 3 months
- a "volume discount" e.g. first 25 hours @ $nn/hour, 2nd 25 hours @ 0.8*$nn/hour, anything over that at 0.6*$nn/hour

For real-time support (telephone, remote-control such as VNC, pcAnyWhere etc.) you charge full fare hourly rate. E-mail support can be difficult to charge for. For you, it's easier because it's asynchronous, you can deal with it when it's convenient for you rather than for the client. OTOH a lot of times it's quicker to pick up the phone and walk someone through a fix than to try to type up clear, concise instructions in an e-mail. Also, with e-mail you tend to back-and-forth a lot getting background information about the problem, so it can take a lot longer to fix than with a real-time phone call.

So, it can easily take longer (more of YOUR time) to process an e-mail reply than to phone an answer back. I also find it hard to track how much time I've spent on an e-mail; in contrast, phone calls are easy to time, some phones have built-in call duration displays to help with this. Personally, I tend to guesstimate time spent processing support e-mails, and effectively apply a moderate discount over my standard rate.

There are advantages to e-mail support: if the same problem recurs, the client already has the solution, or you can easily forward it to them again if they've lost it. If another client encounters the same problem you can forward the solution to them as well. Also, they can form the content of a troubleshooting or FAQ section on your web site if you have one.

Some large companies charge a flat rate per support "incident". They can do this because they have a good handle on what their average costs are. I'd suggest you're not in that position (at least not yet). If you do go this route you need to carefully specify "what is an incident" - an e-mail or phone call can easily involve 2 or more separate "incidents".

When do you charge or not charge?

- If your app doesn't meet contracted or agreed specs, you fix it no-charge. Make sure your specs are well laid out, or that the client has signed-off on the app as delivered, or this can be a slippery slope ("moving goalposts" or "specification creep").

- Bug fixes: it's tempting to offer "free bug fixes forever" but that's not realistic. Clients must realize (be told if necessary) that all software has bugs; they may find obscure ones literally years later; or that something doesn't work properly now that they're running it on Windows 2008. I don't offer free bug fixes in writing beyond 1 year, and in most cases 3 months. However, if they hit a significant, reproducible bug beyond that period I'll typically still fix it for free, to build goodwill and improve the product.

- Enhancements: you charge full fare for these. What you need to be careful of is when something doesn't work exactly as the client wants it to, or they've subsequently thought of another way they'd rather see it done - sometimes they'll try to call it a "bug". You need to be sensitive but firm about these.

- Operational problems: suppose a client calls up and says the app doesn't work. You talk them through a few checks over the phone and determine you've got a corrupted table.

a) it could have been a power outage, computer crash, virus infestation etc. These are not your fault; you charge for them. It can be helpful for the client if you can recommend hardware repair people, network admins etc. to fix low-level problems before they get you involved to get their app back up running.

b) maybe a bug in your program caused it. In that case you have to fix it at your own expense, and pronto - often the client's downtime is worth a lot more than your hourly support rate, you can't leave them hanging any longer than absolutely necessary. You also need to be upfront that a bug caused it, not something they did. Hopefully this type of problem will be rare :)

c) For your own safety (and ultimately the client's as well) you should not offer or guarantee data recovery of anything entered since their last verified backup. This forces the client to be religious about backups, and rightfully so since it's the only true security they have. By all means, if a bug caused the loss of today's data try your best to recover it but make it clear that won't always be possible and at any time they may have to revert to their latest backup, and to be prepared for that eventuality.

If you have to go on-site for support, you will need to charge realistically for your time and expenses. Depending on how far away they are you may need to charge a half-day or full-day minimum. Find out what the expenses are likely to be and give them an idea up-front so it's not a shock if they have to have you on-site. Encourage them to set up a PC with VNC or pcAnyWhere - it can be a lot cheaper than a site visit.

If you haven't got it already a good general resource is http://www.hentzenwerke.com/catalog/sdg3.htm