Thank you for all of your responses…so the takeaway for me is
- have great documentation, post it online and give customers links to the section that answers their questions
- release updates in response to common customer issues
- expect up to 2 hours per day on support requests
I think it boils down to how much your time is worth. In the early days with not many clients competing for your time you could have afforded spending extra time. Now that your clientele has increased, a flat rate should at least account for a maximum number of hours beyond which clients needing updates would pay your hourly rate.I believe the rule of thumb should always be a cost per hour maybe broken down into increments. I haven’t reached 70 clients yet but I already see the potential for such a dilemma.
Yep, you’re absolutely right. I guess I’ve always felt the sale is easier if the client knows there’s one set price and no surprises…but that can’t work forever like you say.
@Fillerspace – I think that’s a pretty fair takeaway from the discussion
This month I have had 676 sales so far and have received only 29 help requests – that’s less then 4% which I think it is pretty good.
I have kept records of the percent of help requests and it was close to 15% when I started out.
There are a lot of factors involved in this reduction of help requests but the most important ones are:
- designing an item:
I feel it is important to only use things that are properly tested and supported. I’m referring to third party scripts and effects. If what you use is popular enough you get the advantage of an already existing knowledge base with bugs and solutions that can really cut down on support time when trying to find a solution for a problem.
- the source code:
The code must be very intuitive, properly formatted and commented.
On a few occasions I have completely rewrite the code for a template making it more intuitive and simplifying it.
- the documentation:
It must be as detailed as possible.
Write it for beginners but structure it in a way that advanced users can skim read it and get to the parts they might have trouble with.
I even go so far as to explain some simple concepts ( example: Applying multiple classes to a html element) before getting into presenting the actual template code.
Also when you present a concept that you feel might be unknown to beginners besides the presentation of it that has got to do with your template link to an more advanced tutorial on trusted websites like w3cschools etc.
- how you put the item together:
Pack the item content in subfolders whose names are self explaining to as what they contain and also include a readme-first.txt file where you provide an overview of the folders and their content and also ask people to read the documentation first.
These are just some ideas off the top of my head but at as a rule of thumb remember that it is always simpler ( or at least more efficient ) to avoid a problem then to fix it.