Business Models and Best Practices Best Practices I) Company Organisation Managing warranties, support and main...Managing warranties, support and maintenance programs
Most sustainable programs are delivered on an "as-is" basis without any particular software warranties. Certain editors provide some code warranties but for example only for those that accept a payment in cash. This allows them to finance certain software insurance against risk of lost of customers data,....
Ideally, and always to protect your software asset, any sort of warranties or support agreement shall be always delivered by the services company and not directly signed by your product company (cf: first best practice).
Another option would be to provide a separate support agreement (for example based on a number of incidents per year) that customers may acquire in order to get their problems fixed more rapidly than just being able to enter their issue in a bug tracking system and to wait until someone in the community decides to try to correct it (if anyone tries...).
Finally you will have to decide your maintenance program and how existing customers will be able to upgrade to your new minor and major releases. Of course, your customers should always get the choice to pay their "upgrades" in cash or in kind as this paradigm is valid for all license royalties, upgrades included.
Best practice:
Clearly separate, and especially if your program requires quite a lot of customization, license, upgrade and optionally support agreements (= product oriented) and integration services, maintenance of custom work and other installation, local assistance or hosting tasks (services oriented).
Comments:
There are several aspects that are often mixed up by customers but that shall be clearly separated especially in the case of a sustainable program where roles of actors are assigned form a different manner than traditional software programs:
Proposed by the product company
- License Agreement: Acquisition of a version of your program in cash or in kind
- Upgrade Agreement: Payment of a yearly or extra fee in cash or in kind in order to get new minor or major releases
Proposed by partners and resellers
- Support Agreement: Usually sustainable software are delivered on an "as-is" basis as this is the result of work of a community. However software partners may decide to offer some level of support on the program to their customers (ex: based on a number of possible incidents per year).
- Service Level Agreement: the partner proposes not only to offer support on the program but for example to manage your whole server with specific conditions (bandwith; downtime; 24/24 support;...)
- Technological Consulting and Assistance Agreement: This is a pure IT services contract to offer a wide possible range of value added such as training, custom development, consulting, integration services, etc...
Always try to clearly separate these various agreements as they are clearly associated with different tasks and responsibilities.
Otherwise, as a software editor, you can propose a cash only yearly upgrade fee (e.g. ~20% of the customer overall license value per year) if you provide additional value added services such as some level of free support or assistance. Of course, active contributors in the community shall always have the choice of continuing to "buy" their upgrades in kind and perhaps, if they also need it, to acquire a separated professional support agreement.
Another point to mention is that you shall clearly avoid letting your customers pay upfront a certain number of future upgrades. You can only buy what is available now. So contributors will have to spend some time each year if they want to get some free upgrade ticket. The goal is really to incentive contributions on a long term basis and not to be able to cumulate future free upgrades.
Ideally, and always to protect your software asset, any sort of warranties or support agreement shall be always delivered by the services company and not directly signed by your product company (cf: first best practice).
Another option would be to provide a separate support agreement (for example based on a number of incidents per year) that customers may acquire in order to get their problems fixed more rapidly than just being able to enter their issue in a bug tracking system and to wait until someone in the community decides to try to correct it (if anyone tries...).
Finally you will have to decide your maintenance program and how existing customers will be able to upgrade to your new minor and major releases. Of course, your customers should always get the choice to pay their "upgrades" in cash or in kind as this paradigm is valid for all license royalties, upgrades included.
Best practice:
Clearly separate, and especially if your program requires quite a lot of customization, license, upgrade and optionally support agreements (= product oriented) and integration services, maintenance of custom work and other installation, local assistance or hosting tasks (services oriented).
Comments:
There are several aspects that are often mixed up by customers but that shall be clearly separated especially in the case of a sustainable program where roles of actors are assigned form a different manner than traditional software programs:
Proposed by the product company
- License Agreement: Acquisition of a version of your program in cash or in kind
- Upgrade Agreement: Payment of a yearly or extra fee in cash or in kind in order to get new minor or major releases
Proposed by partners and resellers
- Support Agreement: Usually sustainable software are delivered on an "as-is" basis as this is the result of work of a community. However software partners may decide to offer some level of support on the program to their customers (ex: based on a number of possible incidents per year).
- Service Level Agreement: the partner proposes not only to offer support on the program but for example to manage your whole server with specific conditions (bandwith; downtime; 24/24 support;...)
- Technological Consulting and Assistance Agreement: This is a pure IT services contract to offer a wide possible range of value added such as training, custom development, consulting, integration services, etc...
Always try to clearly separate these various agreements as they are clearly associated with different tasks and responsibilities.
Otherwise, as a software editor, you can propose a cash only yearly upgrade fee (e.g. ~20% of the customer overall license value per year) if you provide additional value added services such as some level of free support or assistance. Of course, active contributors in the community shall always have the choice of continuing to "buy" their upgrades in kind and perhaps, if they also need it, to acquire a separated professional support agreement.
Another point to mention is that you shall clearly avoid letting your customers pay upfront a certain number of future upgrades. You can only buy what is available now. So contributors will have to spend some time each year if they want to get some free upgrade ticket. The goal is really to incentive contributions on a long term basis and not to be able to cumulate future free upgrades.
The contents of this website are licensed under the Open Software License 2.0 or Academic Free License 2.0
 Top |
 |
