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

To Refund or Not to Refund, that is the question.

StephenKnightStephenKnight 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.

Comments

  • ToddFToddF subscriber Posts: 3
    Well if I understand this right, he worked directly with them to develop it as in a consultant, if so it`s there`s and they bought it. They should have provided a solid document (scope doc) to describe EXACTLY what the application will do, how it will perform etc. If you didn`t meet that scopes requirements then you should fix it until all the requirements are completed and those extra costs hould be on your dime. You should also have agreed to those exact terms in the scope document and also document all items out of scope. Now if you promised a bunch of features and didn`t deliver, that might warrant a refund but not nearly a 100% one. You really should be offering a demo or something that they can mess with, then once they purchase the deal is done. I know most software companies DO NOT offer a refund after purchase, they may if you purchased it and it simply doesnt work at all on your platform, but thats not the case here.
    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
  • bertbert subscriber Posts: 12
    Like an attorney never asks a question that they don`t know the answer to first. 
    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
  • StephenKnightStephenKnight subscriber Posts: 1
    Thank you everyone for your great responses!
    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.
  • ModJulieModJulie subscriber Posts: 1
    I spent several years as a product manager for a software company.  I would have to know what documents, payment plan, timeline, etc. were decided upon at the project onset.
    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
  • JDawgJDawg subscriber Posts: 4
    This is a good read. As a designer for print and web, I`ve had to tweak my contract over the years based on the outcome of client interaction. I now offer a propsal that is fair to the client and meets my compensation needs. The notion of adding a "no refund policy" never crossed my mind, and frankly I think I should add it after reading this scenario.
    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.
  • StephenKnightStephenKnight subscriber Posts: 1
    Wow, fantastic posts!This definitely shows the neccessity of having a well defined contract and proposal.  I can see some changes that I need to make immediately.  Our company writes software for other companies mainly FileMaker http://www.filemaker.com</A> database driven websites.  Usually a potential client will call and say, "I have a database that I would like to make accessible via the web", or they will say "I need you to build a website with a backend database system."At that time most of them want to just tell me what they want over the phone, or they want to send me to websites that they have seen and they would like their website to incorporate a similar look and features.Immediately I ask them for a detailed write-up of exactly what they want, as well as a detailed write-up as to what they feel the customer experience should be.  I do this as a simple exercise to try and engage them and to get them to think all the way through the process.Once I receive their project description, I type up a detailed proposal - with a time and cost estimate based on the information they have given me.  I also inform them that we work on an hourly basis, not a "project" basis and that we will do everything in our power to stay within the quote.  But, I have never had a client that new exactly what they wanted on the onset of the project development.  Many had wonderful ideas, but it was my job as a consultant to forumlize a system that would bring their ideas to fruition and perhaps even enhance their original ideas without adding additional time an cost.Once the client and I agreed that we both had an understanding of what was to be done.  We would both sign off on the proposal.  The proposal contains, project description, cost, and timelines, milestones and payment time-tables.Usually, we charge 50% up front, then 50% once the project is completed.  We host the clients datbase and website on a computer so they can see our progress.  Once the customer is satisfied and agrees that we have completed everything in the proposal, then we ask for the last payment.  Once we receive the final payment, we deliver the files.I believe that hosting the solution (making it available during the entire development process) helps to take away any questions as to the functionality of the program as they take an active role in testing.We also protect both our interest and our clients interest during the development process by engaging in a series of emails - asking for confirmation as to the completion of different parts of the project.If there are other feautures that are wanted or needed, we will write a "change order" which is only implemented after the payment and completion of the first proposal.  I`ve found that if you continually let clients add feature request during development, you run a chance of having the project go on forever.  This can put you in conflict with scheduling if you have other clients as well as delay your payment.
    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  
  • ModJulieModJulie subscriber Posts: 1
    I think one of the biggest challenges is who your are dealing with.  Some clients that have little or no design experience have a hard time understanding exactly what a change or enhancement entails.  Some changes that seem minor on the surface may take hours or days to complete.  Other changes that appear major, might actually be small in terms of labor. 
    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
Sign In or Register to comment.