[nycbug-talk] FreeBSD (and Linux) Support Contracts
ericshane at eradman.com
Tue Nov 27 22:27:23 EST 2012
On Sun, Nov 25, 2012 at 12:01:47AM +0000, Matt Juszczak wrote:
> Many of our clients have requested support contracts lately (as in,
> a flat monthly fee for a certain level of offering and retainer).
> In the past, I've just done an hourly minimum per month to cover the
> retainer portion (minimum: 10 hours per month), but many of my
> clients aren't liking this option. They'd prefer a flat monthly fee
> and a few different levels of support.
While larger corporations tend to offer flat support contracts, I think
charging strait up time and materials is the only approach that does not
put you at odds with the customer. Your clients needs to know what's
happening, and charging by the hour gives you much needed leverage in
keeping them involved in what's happening on a daily and weekly basis.
Do you know why they're asking for a flat monthly fee? I'm not in a
position to make specific recommendations, but my intuition is that
they're asking for this because of some other discomfort that they're
> I'm trying to price out some contracts. I know I have some add-ons
> I'd like to include (such as monthly reports on infrastructure,
> recommendations, etc.) that make the support contract more
> worth-while than just hourly consulting. However, some clients want
> 9 - 5 support, while others want 24x7, and others want quick
> turn-around, while others don't mind waiting a day or two.
Are you servicing multiple timezones? This could be tricky, unless your
team is also distributed. I worked for 7 years at a small shop, I'd say
that true 24x7 support generally isn't necessary if you can keep the
lines of communication open. At this point it's more about fit between
what you and potential clients.
> What are other small businesses doing? I know many of you own
> consulting shops. I'd be curious to know what's working for others.
These are not easy things to solve, so I'm likewise interested in what
others might have to say.
Eric Radman | http://eradman.com
More information about the talk