The purpose of this page is to present some things and thoughts that are often overlooked by those that are looking for a complete program solution.

I rarely use wizards when offered in a program but from experience because most of my customers are new with the computer or are busy with the rest of their lives they find it difficult to make time to learn a complex program's interface. If you are targeting your program to this majority group of computer users you might consider the ease of program use a Wizard can bring.

I have a program that has been in the market now for around five years. Because the program requires special set up before use, a wizard was the order of the day. The wizard below introduces the end user to the program, explains a few things about what to expect from the program and most importantly guides the end user with setting up the program to access the internet with its own custom dialer.

In addition to Wizards on this page I've included Help files and a small bit about Tech Support. If the goal is to make money with your program then you must eliminate the enemy, tech support and if not eliminate support, do what you can to minimize it!

What about the DO ALL program? In my major version upgrade to the above program, it DOES ALL. So.. I thought a few more Wizards were in order.

My feelings about Wizards are that most people for whatever reason do not really take the time to learn how to do something sophisticated and it seems less people take the time to thoroughly read a help file so they have a place in some programs. I think most find it is easier to fire off a tech support email for an answer to even the most simple of questions. Tech support costs time which translates to expenses at your end. When I program, I do what I can to prevent the future tech support email! Most simple of questions? To you a question may be simple and you'll often wonder how this same user figured out how to use their email program! It is not a simple question to your end users. Most of your customers actually know it is a simple question and will begin their cry for help with some kind of phrase that explains how computer stupid they are. 

Help Files

In your big commercial programs I believe Technical Writers write help files and I think in a lot of cases it shows. If I have learned anything from my customers is that your help file for those that do read them is everything. One of the things I learned is that the programmer is not always the best person to author the help file! Programmers know the ins and outs of the program and it is all too easy for them to skip small details and use terms a lot of end users do not understand. If you get an email from a customer saying something to the effect they don't know the jargon.. then you know you have probably went over the head of large segment of your users.

If your help file is not well thought out, you make for yourself more tech support emails.  For the more complex programs a good help file is not written in day, even two or three. I've come to grips understanding that I will never win with all end users in the help file department. 

How many times have I been sent a support email asking what the windows clip board is? I don't have one of those they say and some have even argued! Are you expected to write a help file that explains what you meant when you refer to a basic Operating System feature? No.. but be careful how you word things. The more you say, the more questions that can come out of what you say. The reverse is also true, the less you say can have the same effect.

I have received all three emails over the years.

1. You have the worst help file I ever had to deal with.

2. You have the best help file I ever read. Gosh you made this easy!

3. Your help file took all day to read. You explain things in way too much detail.

The above help file took about a week to write. My point is, I'd like you to remember that a good quality help file can take some serious time to write.  In my case, I tend toward making my help files extensive hoping to leave little to question. I send the help file's outline and my final draft to a few beta testers that know about the English language better then I. I have beta testers that are not real computer smart (per their own words) and in my opinion, this is the best person for the Help file job. If you let a neophyte computer user proof your help file they will point out all the places you forgot to keep it simple and clear.

There are two dominant Windows Help File formats now. 

The original  *.hlp Windows Help or Winhelp files have a contents "tree" of books, in which you can select a topic which then replaces the contents tree view. Included in a basic help file is a table of contents, an index and is searchable. Click on a Help button, or press F1, and a help file is launched which provides the Help information.  Many features can be programmed into this file format including buttons and small scripts. The advantage to this type of help file is that it is faster then the newer browser style.

The newer browser style *.chm compiled help file. It offers you a structured Contents tree, indexing of keywords and a search on the complete text of the whole Help file. The advantage is that these remain in view while you browse through the help topics.

I've begun to notice more and more web site based help files. The advantage to this style is you can update the file in one place and all end users benefit from the update. The disadvantage for modem users is that they have to log on to access your help file.

The cost of your help file will be greatly determined by how simple or complex you want it to be. Adding photos (screen shot) examples add to the cost because of the graphic work that needs to be done. Graphics also bloat the help file considerably.

Tech Support

You can sell a program for $20 and you can the next day spend $30 in your time answering questions about it. My personal record? A 55 minute call to Spain.. $153.00 US. Tech support costs you money if you do not charge for it. Tech support is your grand opportunity to also show the customer you support what you sold them. The majority of my sales are word of mouth. When something goes wrong or your customer does not understand something, they are sitting at their computer probably frustrated beyond belief and want an answer now. In reality most do not get the answer now because I believe most have come to realize that tech support can take a day or two. However, my general rule is two fold. I answer within 24 hours in 90% of the cases and two, my tech support is shoot and forget. I rarely follow up. I explain this policy on my site and in my help file. I send a solution or more questions to assist with problem. Shoot and forget means If I don't hear back from you I assume the issue is resolved.

I never, well rarely, take a support phone call. If I do it's on the customer's dime. Sometimes you need to learn a lesson more then once. I received a support email from a gal with a long string of names. It began with Maria. She really needed help and was really frustrated. She had no experience installing programs and asked if I would send her my number and she would call me. Uh.. nope.. they always call when my head is in the code and it takes me a long time to find where I was at again. I agreed to a "good will" support call and asked for her number. The name sounded very foreign but the ISP was I thought US based so... Well.. I received via email a strange series of numbers that made up her telephone number. The support call took around 50 minutes because after helping getting the program installed she wanted to know how to use it. The call was to Spain! Ok.. well.. some good will I hope will come out of this and more orders from Spain. I did end up charging for the call in the end. You could have heard the Sprint pin drop when I said after all was well, by the way this support session was not free. After a nice pregnant pause I said, "You owe me a home recipe of Spain's national dish."

Here are some interesting numbers...

Probably fifty percent of my tech support involves system specific issues. Those are issues specific to a an end users computer. I guess it's my job to help fix their computer sometimes. You know if you reinstall Windows 95 a lot of programs will not work correctly? Database backward incompatibilities that require MS Office service paks,  DCOM, MDAC? Micorosoft's DLL HELL?

I would guess forty percent of my tech support involves answering questions answered in the help file or on my support page. I have reduced this one a bit because my support policy states that if the answer to your question is in the help file, I am going to steer you there.

Maybe ten percent of my tech support involves something program specific and ninety percent of the ten percent involves a question that is not my program's fault. In my case my high selling programs interface with a web site, the website can make changes that ultimately require and update to my program and the program depends on an ISP or the website itself. Sort of like a virus programs need periodic updates.

I hope I have given you some things to think about. Help files take time to write good ones, wizards can make your end user's life easier and minimize tech support calls and tech support costs you money. A good program minimizes tech support, provides adequate help to the end user. It costs more to program this program but it costs you less in the long run when a good coder thinks ahead for you and save you tech support emails.

A tech support web page is strongly advised. Here you are able to provide up to date information about your program and create a centralized list of frequently asked questions (FAQ).

Bottom Line

Everything you do to minimize the need for a tech support email or call makes you money. Your "cheaply" coded program can cost major big down the road for this reason alone.