Forums: Discussions for entrepreneurs and small business.

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.

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.

I think Todd hit the nail right on the head.  I think that creating any policy or procedure to help avoid such dillema`s in the future is more than appropriate here.

I`ve worked in Project Management fro years now and have lead software projects, web projects, contruction projects and engineering projects.  It all comes down to "scope".  That will determine the actual list of deliverables, and the deliverables are in fact what the client is paying for.

I think he needs to find out from the clients perspective what doesn`t work, or what hasn`t been provided.  I imagine there would be some sort of scope document, whether formal or informal, as there must have been meeting with them to determine their needs.  Legally, it`s all about the documents!

If it were me, I would see the client, determine what is missing, develop procedures or policies to reduce the risk similar problems, with other clients in the future.  If I missed something or from the cusotmers perspective missed something, I may give some of the payment back, but defintely not all.  I imagine a custom solution would have involved alot of work for both parties.

While the legal perspective is important, I always try to run a "high-road" business.  Sometimes I have taken a hit, to ensure that our reputation fairs well long term.  It doesn`t happen too often and so we improve our position ove rthe long term.  Many times I have been into a debate with other contractors on sites about who was suppoed to "run that wire".  If it comes to a finger pointing match, I have said, "that`s no problem then, I`ll get a wire put in".  The other contractor is happy that he doesn;t have to arrange anything, and the client views US not THEM as the contractor who "made it work".

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

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.

This particular part is key. They`re paying you for your expertise and most likely need advisement on that particular solution and best practices and you should be offering up solutions that work for both parties. I know it`s not easy but someone has to sit down and go through it all with a fine tooth comb....

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