|
|
|
www.ASPonline.com
|
ASP Forum
Code Maintenance vs. Support
"We have a customer who just bought several bundled modules from us but
doesn't plan to deploy them until next year. They're willing to pay a
maintenance fee for upgrades and patches until then but don't want to
pay for support until the software is actually in use. How should we
price this deal?"
—Peter from Provo
Peter,
I've actually encountered this problem repeatedly in my support manager
career (and again just last month). I haven't come up with a good
solution so I'm really interested in input from others. I agree that
splitting maintenance (upgrades) and support are not a wise move but I
have been put in that position several times because a customer will
purchase our software and not deploy for a year or two (playing a
hardline can obviously be difficult when you are trying to sell more
software to that same customer). What I'm curious about is where the 65%
for maintenance (upgrades) came from? Does that mean that 35% of the
support and maintenance price is "traditionally" for support? I've never
been able to find general software or industry specific numbers on this.
I've assumed that the ease and frequency of upgrades plays a major role
in the value of the maintenance and this is very different across
industries.
—[Anonymous]
One perspective on this subject is that the customer shouldn't pay for
maintenance on software until it's installed and operational... what
would you be supporting? You would be receiving dollars for something
that is not being used. I would price the maintenance to include
upgrades, patches, and software support (24x7) and have the maintenance
begin once the software has been installed. Maintenance should be
simple to the end customer and all inclusive.
—Brenda L. Scott-Fong brenda.scott-fong@3pardata.com
Director, Business Services
3PARdata, Fremont, CA
510/668-9217
After have completed this experience twice, I have learned many
beneficial things that I would do:
One option, although I'd only use it as a last resort, is to differentiate
the pricing of support vs. upgrades. It could set a precedent but I know
of some companies that do that for specific product lines, etc., because it
becomes a sales barrier if companies looking to buy your software won't
implement until well into the future. Traditionally updates are priced at
65% of the total cost for some companies. Other companies take the hard
stance that maintenance (support and upgraded) is required and you can't
break them out.
—[Anonymous]
[Any other advice on this question? Please send an email to
membership director Jane Farber at jfarber@asponline.com, and we'll
post your feedback.]
|
|
|
