WE'VE MOVED!
We are proud to announce our NEW community destination. Engage with resident experts and fellow entrepreneurs, and learn everything you need to start your business. Check out the new home of StartupNation Community at startupnation.mn.co
We are proud to announce our NEW community destination. Engage with resident experts and fellow entrepreneurs, and learn everything you need to start your business. Check out the new home of StartupNation Community at startupnation.mn.co
Options
To Refund or Not to Refund, that is the question.
StephenKnight
subscriber Posts: 1
Hi everyone, this is my first post of what I hope to be many!
I own an online software development company and usually do not ever come into contact with my clients. I do however participate on numerous mailing list where I am very active. Last night, there was a great question posted about when to offer a refund.In the world of software development, when you are delivering an intangible, things are a little different. Here is the developers scenario and the crux of his problem.
He is a software developer that has worked with the client for quite some time. He has worked with the client to develop a system that they requested. The system is fully functional and the company has been using the software since November. Now the company says that the software is not what they wanted and it does not perfrom up to expectations. (5 months later) and they are asking for a complete refund.
What would you do in this situation?
Refund the customer?
Try to work with the customer to identify the sudden change, identify the problem?
Tell the customer "No way, you`ve had months"
Set up a guideline that says you have "x" number of days to test this solution, after this you own it?
Many customers are very weary of contracts as they usually do more to protect the consultant thant themselves. I realize this is a multi-part post, but I do think that it has a lot of value as it covers a unique service industry where there is no actual tangible product, and it is usually just a representation of the clients wishes.
I own an online software development company and usually do not ever come into contact with my clients. I do however participate on numerous mailing list where I am very active. Last night, there was a great question posted about when to offer a refund.In the world of software development, when you are delivering an intangible, things are a little different. Here is the developers scenario and the crux of his problem.
He is a software developer that has worked with the client for quite some time. He has worked with the client to develop a system that they requested. The system is fully functional and the company has been using the software since November. Now the company says that the software is not what they wanted and it does not perfrom up to expectations. (5 months later) and they are asking for a complete refund.
What would you do in this situation?
Refund the customer?
Try to work with the customer to identify the sudden change, identify the problem?
Tell the customer "No way, you`ve had months"
Set up a guideline that says you have "x" number of days to test this solution, after this you own it?
Many customers are very weary of contracts as they usually do more to protect the consultant thant themselves. I realize this is a multi-part post, but I do think that it has a lot of value as it covers a unique service industry where there is no actual tangible product, and it is usually just a representation of the clients wishes.
Sign In or Register to comment.
Comments
I guess i would try to work with them and find out whats going on because clearly there is a problem. I would also suggest you develop some type of contingency plan for issues just like this. It`s a common problem between consultants and companies and both parties need to have protection. ToddF2007-4-18 15:15:18
One should not go into a custom programming project without clearly defined results and goals. If you take on a project you need to complete it as defined. Refunds are for over-the-counter products and not custom software. Custom software jobs should be paid in payments as each defined goal is reached. Payment of each goal should be understood to not be refundable from the beginning of the project. Payment should only be done as each goal is completed. This will mean that the only things paid for are those that everyone agrees to be complete. This will avoid this problem all together. If you are not willing to put this in writing from the beginning you should not do the project. These are some of the guide lines we have used over the past 23 years and they still seem to work today.
I hope that helps...bert2007-4-18 16:9:30
I truly believe that the procedure policy is key. I`ve been involved in the software business for about 15 years, and it never fails to amaze me as to "value" that is applied to intangibles.Customer`s do not seem to understand the amount of time, research and de-bugging that goes into software solutions.So, I think the key is this. Talking with the customer, finding out exactly what it is that they want. (Even though most of the time they will not be able to tell you exactly what they want.) Then, have the client sign off on an agreement stating that the schematics are what they want. Once this is complete, you work on the projects, I would have the client sign off as each stage of the project is complete and that it meets with their required specs. Once the project is complete, have the client sign off saying that this is indeed what they requested.
Should the client decide that they want to add more features, you can present them with a change order, which they can agree to. You decide if the change order is something that will be provided with additional cost, or that you will provide as part as your service.
After "X" amount of days, (which should be in your contract) if the client does not contact you with technical issues relating to your project, then you should consider that part of your project complete and "accepted" as a deliverable product.
I do think that the most difficult part lies in the ability for the client to actually be able to articulate their actual needs. Most of the time when I work with a client, it is a slow process as they have not actually taken the time to work through the entire solution.
I do think, that if they do sign off on the project, that there should be no refund. They are paying for the time spent...if they sign off on the completion of the project, then there should be no arguing in the future as to payment or non-payment of work performed.
I am very interested in hearing the thoughts of others.
We had what we believed to be good documents that clearly identified what services we would provide and how much they cost, etc. After several clients coming back wanting and expecting more, we had to seriously evaluate our contracts and payment terms. We sold "out of the box" software along with custom services. The services were the sticky part. We had customers come back months even a year later asking for free services, changes, etc. One of our biggest challenges is that we would deliver a project and the customer wasn`t ready to use it right away. They would sit on our project and then once they implemented (sometimes months later), they would come back and ask for changes. That is why we put a time limit on the evaluation period. The customer knew from day one how long they had once the project was delivered to evaluate, and it was their responsibility to have their piece complete.
Because of these situations, we ended up revising our entire consulting work process. We idientified the services we would perform upfront, required payment once certain milestones were met, and gave the customer a period of 60 or 90 days to evaluate the project. Once the 60 days were up, the contract clearly stated that acceptance was assumed if we were not contacted and the maintenance contract would then be in effect. Once on maintenance, all changes were billed at our hourly rate.
I do think that after 5 months of use, there should be no refund. I do believe the consultant should meet with the client to determine where the dissatisfaction lies. There could be something gained for the future by understanding the problem, and trying to avoid this in the future. Unfortunately, the consultant would also need to gauge the "power" of this customer to possibly threaten future work with them and other companies. How angry will the customer be, and could it damage the consultant`s reputation. I don`t think this is right, but unfortunately might have to be taken into account when determining the "solution."
I know we did things for customers we never should have done. However, it made good business sense in the long run. If the customer was completely ridiculous in their demands, however, you have to draw the line somewhere.
ModJulie
It`s rare but when it happens, I will work with a client to solve an issue without compensation. But if it goes way beyond the scope of the proposal, sorry I gotta charge for my time. (Way beyond=design a new concept for a brochure, for example.)
And I agree with Nikole... 5 months? Forget it. The client had ample time to correct issues. That may sound harsh but there are some clients who will take advatage of you.
These are just some of my insights, I`ve been in the software development business for about 15 years. The amazing thing is how incredibly complex the relationship between client and consultant can be. Once I think I know all of the nuances of my clients, one will throw a curve ball and I`m struck out at home once again
While I have product management experience and experience working with developers, I don`t have experience in knowing what types of things are "easy" fixes and others which are not.
I found myself in this situation with my recent web design. I hesitated asking for a change that I thought would be major from a design standpoint, but found out was a simple fix. Another change I requested was going to be very involved and cost a lot of money. It was described to me as "trying to unbake a cake." Lucky for me the change that I thought was most crucial ended up being the least expensive to fix!
ModJulie