Maintenance Contracts

[cswebgrl]

Hi,

I’ve recently deployed a Rails web site and need to figure out the
role of maintaining it. Things that this would cover include simple
user questions, server updates, reviewing logs, etc. If they request
new features, we’ll draw up a new contract or if something is broken,
I’ll fix it.

Does anyone here have any guidelines for tasks that fall more under
maintenance? Also, I know that some advocate taking a flat fee for
“X” hours of work whereas others just bill per time used. Any
thoughts there?

Thanks for your time and help,
Cindy

[Greg Pederson]

We sell maintenance contracts that include x units per month (units don't roll over).  One unit equals one hour for regular response stuff and two units equal one hour for emergency or off hour (nights/weekends) support. 

Depending on the size of the maintenance contract you may not be able to handle 'new feature' requests, but may have to just quote and bill out extra for new features.  Other than that the client is free to request what ever (within reason) for use of their units.

Greg

--

You received this message because you are subscribed to the Google Groups "Ruby on Rails meets the business world" group.
To post to this group, send email to rails-b...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rails-business?hl=.

--
Greg Pederson
Founder and Technical Director

407.385.0098 office
888.308.9695 toll free

@gregpederson twitter
Nsight Development, LLC.
www.NsightDevelopment.com

Quis custodiet ipsos custodes

[Matthew Palmer]

On Tue, Nov 17, 2009 at 04:22:44PM -0500, Greg Pederson wrote:
> We sell maintenance contracts that include x units per month (units don't
> roll over). One unit equals one hour for regular response stuff and two
> units equal one hour for emergency or off hour (nights/weekends) support.
>
> Depending on the size of the maintenance contract you may not be able to
> handle 'new feature' requests, but may have to just quote and bill out extra
> for new features. Other than that the client is free to request what ever
> (within reason) for use of their units.

More important (IMHO) than exactly how it's structured is how you sell it to
customers. A simple "you get N hours/units/bogomips per month, use it or
lose it", unless it's *very* heavily discounted off your regular rates
(which you don't want to do) isn't very attractive -- why wouldn't the
customer just call you and get you to do the work ad-hoc?

The most effective way I've seen these marketed, at or about regular rates,
is to give an SLA as part of the contract -- not so much even in terms of
defect resolution times and those sorts of things, but even small(ish)
feature requests and such. You tell the customer "if you want to come back
to us in a month and ask us to do a bunch of stuff, we may not be able to
help you immediately, because we'll have taken on a pile of new work. You
may have to wait a few weeks before we can spare the manpower. But, if you
sign up for one of our Maintenance Contracts (flourish!), we'll guarantee
that we'll have someone working on it within N hours / days /
whatever-as-appropriate. Yes, your hours/units/bogomips don't roll over
from month to month, but that's because you're paying someone here to be
available to you at very short notice, and that's money that we have to pay
regardless of whether you use our services or not that month".

Given that way, it's a far better value proposition. You, me, and everyone
else here knows that you won't *actually* have someone sitting by the phone
reading a book, but it's compensation for maybe having to slip a project by
a day for another client when something comes up to be dealt with "under the
SLA". Anything that is likely to exceed the number of hours under the
maintenance contract goes into the "when we're ready" pile, which is another
way to upsell to bigger monthlies -- "well, at 10 hours per month we're not
really going to be able to do anything except a few small bugfixes, but if
you take our 30 hour per month contract we can do a couple of small features
for you at a rush".

- Matt

[cswebgrl]

Matt,

Thanks so much for those really great points. I definitely want this
to be a win-win situation for both of us and the points you bring up
would frame a good working relationship with clarity for expectations.

Thanks!
Cindy

[cswebgrl]

Greg,

Thanks for your reply.

You indicated that you sell contracts with x units per month and they
don't roll over. What happens when a client purchases 10 hours of
regular maintenance, uses those 10 hours before month's end and has an
"emergency" request. How do you handle those?

Thanks again,
Cindy

[will jessup]

The way we've been doing it is simply:

You're paying maintenance to keep the site up and running, fix things we didn't find initially and minor tweaks. We're doing this at a flat rate and we're both participating in a bet - that is, we're betting we wrote this great and it will only take us a few hours here and there and you're betting that the rate you'll get in terms of hourly will be less on an annual or monthly agreement than it would be to fix these issues as they come up.

Of course, you can not have maintenance and we can fix things on an hourly rate as they come up - but not only will you be paying a higher hourly rate for 'immediate need' work, you'll be at the end of the line behind clients who do have an agreement which allows us to accurately staff resources for these sporadic needs.

Will

Will Jessup
Managing Member
760 807 0850

Citrusbyte | Modern Web Development
www.citrusbyte.com

[Ryan L. Cross]

Cindy,

To start off, that 'flat fee' that you're referring to is often called
a retainer. That's a GREAT way to keep a client happy and yourself
paid IF you do it right. A new contract is critical if a retainer is
to work. You would basically go into it saying:

I'll stand by between the hours of 8a-8p for up to 10 hours of
maintenance a month for $500 per month. You will be required to
submit a ticket to me using [whatever ticketing system you choose]. I
will respond within 12 hours unless something is urgent at which point
I require a phone call in addition to the ticket. Anything over the
agreed upon 10 hours will be billed at my normal rate.

That sorta thing really works well since the client feels good about
having someone standing by and you get paid whether you do anything or
not. This sorta thing often has a few tasks built into them every
month, such as regular upgrades to a CMS you might have used or other
sorts of updates.

As for the alternate methods, once I finish a project, I hand over the
keys. Its not that I don't love my clients, there just has to be a
handing off point so you - the developer - are not obligated to
constantly to return to do free work, even if it *fixing* something
that you did previously. If you've already handed the app off to the
client, the understanding should be that you are no longer responsible
for what might happen to the app. Someone might ask, well what if the
developer put bad code in that breaks the app later. That's the
developer's reputation. If that gets tarnished, that developer won't
be in business for much longer, so it takes care of itself. You may
give them a discount if the problem was caused by something you did,
but you still need to get paid for your time. Now if you did
something that was just dumb that broke the app, such as "misplacing
the decimal point in an account system" then yes, you'd probably be
better served going in and fixing it for free. But that's going to be
the exception if you're worth your salt.

I hope that helps!
Ryan

[Matthew Palmer]

On Wed, Nov 18, 2009 at 09:48:20AM -0800, Ryan L. Cross wrote:
> Someone might ask, well what if the developer put bad code in that breaks
> the app later. That's the developer's reputation. If that gets
> tarnished, that developer won't be in business for much longer, so it
> takes care of itself.

Oh, if only t'were true...

- Matt

[Eric Davis]

Matthew Palmer wrote:
> You tell the customer "if you want to come back to us in a month and
> ask us to do a bunch of stuff, we may not be able to help you
> immediately, because we'll have taken on a pile of new work. You may
> have to wait a few weeks before we can spare the manpower. But, if
> you sign up for one of our Maintenance Contracts (flourish!), we'll
> guarantee that we'll have someone working on it within N hours /
> days / whatever-as-appropriate.

What Matt is describing is how I've been working for several months.
I'm regularly booking work out 1-2 months in advance and a few of my
regular clients have all signed up for long term retainers, just to
reserve some of my time in case they need to make some changes quickly.

I've also had to turn away some potential clients because they didn't
give me enough notice before their deadlines in order to get scheduled.
They've since came back and are giving me 2-3 months notice on new
projects just to make sure I have time (I have one client give me about
9 months notice on a new project).

It's all about where you are providing value to the client. Is the
value a quick guaranteed response to a bug? Guaranteeing that you'll
be able to help them adapt to a change market? Or just the piece of
mind that they have some who can "handle anything that comes up"?

And don't overthink it. My first retainer was basically "I'll provide X
hours at $Y per hour each month for 12 months. Either side can cancel
anytime with 7 days notice". They've used this time for fixing bugs,
adding new features, server upgrades, and even user support.

--
Eric Davis
Little Stream Software
http://www.LittleStreamSoftware.com

[Kapil]

hi,

You might find this maintenance contract template useful

http://www.myintervals.com/blog/wp-content/uploads/2009/01/Maint_Cont_V4.1.pdf

Regards

Kapil

www.vinsol.com
www.railsbizcast.com

On Nov 19, 10:23 am, Eric Davis <eda...@littlestreamsoftware.com>
wrote: