Author's note: We've certainly covered a lot of material so far. Before wrapping up, it's important to keep in mind that a shareware company is just a small, self-contained software company. Shareware authors, just like the big guns of software, face a lot of the same issues we've discussed. Issues like sales strategy, writing the software, testing, shipping, ReadMe files, marketing, and distribution. The model for shareware is the same as it is for larger companies, just miniaturized.
Today we conclude the series with a discussion about press releases, payment processing, user support, a launch checklist, localization, and working from the road.
There are so many facets of press releases that we don't have the time to do anything but provide a quick overview. If you're looking for a detailed description of press releases, be sure to read Hacking the Press, by Adam Engst of TidBits. Adam's article covers the topic of press releases better than just about anybody.
As explained in our previous discussion in this series about the shareware life cycle, press releases should be distributed with each new release of your software. Press releases should be sent not only to the public press venues, but also to all users who have registered your software, as well as to all users who have asked to be informed about any changes to your products.
Don't send press releases for Mac OS software to your Windows users.
Do create a Web form where users can request information when it becomes available.
Do send new product announcements to all of your users. (This shouldn't happen with any great frequency.)
Don't over do it.
Below are the sections you should consider including in your press release:
By the time you have a few hundred users, you may find that sending out the release and update emails is too unwieldy with a simple email client. If you don't have access to a Unix server and enterprise level mailing list software, you may think you're out of luck. No worries! There's a wonderful piece of software called eMerge. eMerge, by Galleon Software, can import tab delimited text files with user information (like their registration numbers) and send form-merged emails. Even better, eMerge makes a direct connection from your computer to the recipient's POP server, so no intermediate SMTP server is necessary! eMerge also stores addresses that no longer work, enabling you to remove them easily from future mailings. It's a wonderful package. Unfortunately it's only available for Mac OS 9, although it runs great in the Classic Environment of Mac OS X.
The Do's and Don'ts of Shareware, Part 2
The Do's and Don'ts of Shareware, Part 1
No matter how hard you try to write perfect software, a release will invariably have a bug. Depending on the severity of the problem (crashing the user's machine comes to mind) you may want to release an immediate update. On the other hand, if the problem isn't too severe, you may not want to send out any emails at all and just silently post your update. It's reasonable to send some updates to the public press venues only and not your users, or vice-versa. (I've always wanted to use the term "vice-versa" in an article. :-)
If you have a staff of 200 people, a clean room full of computers, and your own T3 link out onto the Internet, you'll probably create your own payment processing solution. As with so many other facets of the software industry described by this series, most shareware authors have no such luxury. To the rescue are third party companies who have created entire businesses around processing payments for shareware authors. We'll call these companies Payment Processing Providers.
Payment Processing Providers basically take care of the headache of charging a user's credit card in a secure fashion, processing the sale, sending the goods to the user, and sending the payment to the author. This basic functionality is common to all Payment Processing Providers. How each provider allows authors to configure this functionality, and how functionality is provided to the customer are completely different. In addition, each of the three Payment Processing Providers described below is a "Work in Progress". Their systems are constantly evolving to keep up with industry trends and the demands of authors and users alike.
Below is a discussion that compares and contrasts three different Payment Processing Providers. All three providers are run by very honest people. All three providers are intent on providing excellent service to their authors and their authors' customers. Intertwined with the descriptions are my own experiences with each of these three Payment Processing Providers because there's nothing like the personal touch!
Kagi Software. To understand Kagi Software it's important to understand how they got their start. Way back before the Internet became popular, shareware companies distributed their software through America Online's software forums, Info-Mac FTP archives, Dial-up boards, or on shareware distribution disks. To facilitate the collection of funds from users, Kagi provided a special piece of software called "Register". Authors configured "Register" (using a rather obtuse mechanism by today's standards) with their product information and price. Authors would send a "test" payment to Kagi either by fax, email, or postal mail, and Kagi would plop all of the product information into its database. The user uses the same "Register" application to pay for the software. (The "Register" application does not make any kind of connection to the Internet. It's only used for creating paper or email payment messages that are encrypted weakly. "Register" is also not available for Mac OS X natively.)
When the Internet became popular, Kagi basically output its database to a series of Web pages to collect sales from users. Today, the required use of the "Register" application is only optional, but it's still the primary way to add a product to Kagi's system. (As per the first paragraph of Kagi's own FAQ to do just this: "Kagi processes payments for products based upon the product name. The best way for us to add your product name into the database is for you to send us the first test payment so that we can see exactly how the program name is spelled when output from the register program.") In the end, this translates to a complicated mechanism that's wired together in a rather unintuitive fashion and is poorly documented. Kagi has improved its system over the years, however. These days authors can generate sales reports via Kagi's online server, and customize their Web pages. It's Kagi's mix of old and new technologies that leaves many authors very frustrated with Kagi's system. But many authors also swear by Kagi's system, never giving a competitor a second look.
Some cases in point: Most of Kagi's support mechanisms are provided through special email addresses that are handled manually by different Kagi employees. One such email address allows authors to set up Kagi to generate customized registration codes. An email I sent to this Kagi address wasn't answered for 7 months. (Yes, 7 months.) Kagi has also been known to accidentally email viruses to all of its authors. Although no provider is immune from such problems, no other provider in my experience has ever had this problem. A recent email to firstname.lastname@example.org wasn't responded to for 24 hours, and only then the response was an automated message directing me to a different email address! The redirection was fine, but 24 hours? That's a long time for an author who's running an entire shareware company as a part time job! Also, an inordinate number of my users have complained that fax orders can sometimes take over a week for Kagi to process. An email to Kagi about this was answered within five days, and the faxes were processed soon thereafter. Turnaround time on mail orders is even worse, usually resulting in unanswered emails from the Kagi support staff and very frustrated paying customers.
Do remember that it's a really bad idea to frustrate paying customers. Especially before they get their registration numbers!
There are a number of things Kagi does right, however. Without a doubt, Kagi is the King of international sales. At the very core of their service is unending respect for the fact that most of the world does not speak English. And interestingly enough, most of the world does not use credit cards. Kagi handles this quite gracefully by providing all authors with a default sales experience in many different languages and accepts payment from European banks and debit cards not found in the United States. As a shareware author, you should not underestimate the International Marketplace. But don't overestimate it either. (Confusing, isn't it? How you handle this really just depends on your particular product.)
Kagi offers many services. Unfortunately its services are strewn about on their Web site detailed in endless FAQ pages. Just combing through those pages alone can take a half of a life time, and their support staff is slow to respond. But if you look hard enough, the features you may want are probably available, sometimes at a price, in some form or another. And the features will be located for you upon request by Kagi's support staff, hopefully before you die.
DigiBuy. Close your eyes and envision the perfect Web-based sales solution and you're probably seeing DigiBuy. DigiBuy is the shareware subsidiary of the major e-commerce player Digital River. DigiBuy is a ground-up rewrite of a payment processing provider dedicated to shareware. Authors open a DigiBuy account with their own private username and password. Once DigiBuy's setup is complete (setup takes about five minutes and is available 24 hours a day) authors can add products through DigiBuy's Web interface (this takes another five minutes per product). Once finished, you're presented with a URL that you link from your Web site, and you're done. If you don't like DigiBuy's default ordering Web pages (they're about a 6 out of 10 on the universal hideousness scale) you can completely customize the entire ordering experience with DigiBuy's advanced template mechanism. If you can handle writing HTML, you can handle writing Web pages with DigiBuy's template mechanism. There are also loads of features that allow you to have DigiBuy generate registration codes for your products on the fly, and insert them directly into customer receipts. And authors can configure all of this with no human intervention on the part of DigiBuy. For the author, DigiBuy is the most intuitive and automated engine available. Everything is right where you'd expect to find it, and its interwoven documentation helps you every step of the way. DigiBuy's knowledgeable support staff will answer your emails expeditiously too, usually before the end of the current business day.
From the customer's point of view, DigiBuy has a load of features. Using DigiBuy, customers can place their orders via your customized Web pages instantly. Or for added security, DigiBuy can accept orders by fax, phone, mail, and even Purchase Orders. (To handle purchase orders yourself, here's what you'd have to do: customer postal-mails the author a purchase order, author sends customer the product, customer sends author the money, author sends the customer a receipt (optional). It's a four-way handshake.) Unique to DigiBuy, phone orders are handled 24 hours per day by their specialized automated touch-tone system.
Cases in point: DigiBuy's customer support is fast and courteous. DigiBuy's uptime is excellent. Features are added to their Web site on a regular basis, and their programmers respond to bugs very quickly. When I signed up with DigiBuy I asked their programmers to add Macintosh line delimiters (carriage returns) to their machine-readable reporting options. This feature was made available to all of its authors within 18 hours. Now if that's not service, I don't know what is.
But there's a catch. DigiBuy, for all it does right, is very expensive. DigiBuy also lacks fundamental features like the ability to split sales between authors and DigiBuy lacks an International sales experience, so your users will be stuck ordering in English. DigiBuy also has no software-integrated solution.
In the end, DigiBuy takes a hefty percentage of the cost of inexpensive products, and for shareware authors, that's a really big problem: most shareware products are inexpensive. Too bad too, because DigiBuy's Web-based ordering system is superb.
eSellerate. eSellerate is a relative newcomer to the payment processing game, opening its doors about two years ago. eSellerate, although lacking in a few basic features, has some serious power behind it. It also has one of the best deals in the industry for low cost products. Knowing this, let's begin.
eSellerate offers authors three separate options for accepting payments from users. (1) The first option accepts payments via a traditional Web interface. Although not totally configurable, the eSellerate Web interface offers Web based shopping cart technology. Authors can place "buy buttons" on their product pages or use a single page for all "buy buttons" (the default). (2) eSellerate's second option to accept payments is completely unique: an integrated eSeller. An integrated eSeller can actually accept a user's payment right from within your software. That's right, no Web browser necessary. As the shareware author, you'll make a function call to an eSellerate library. This magical library will present windows and fields to collect the user's credit card information and verify the credit card on-the-fly. Here's the best part: if the user's credit card information is valid, the eSellerate servers will return a new registration code right to your software. This is great because this avoids the extra step of instructing the user to enter the registration code which is a relatively large source of customer support emails. (3) For the third option, because eSellerate is made by the same folks that make Installer Vise, it's easy to embed payment technology right into your installers.
eSellerate's back-end is very powerful. Its databases are relational. This allows authors to define a product once, and then reference those products from multiple price points (SKUs). In turn, these SKUs can be referenced from multiple eSeller configurations: either integrated, installer, or Web site. It's a little unwieldy at first, but well worth the configuration effort. What a great idea: only enter your product's information once! This saves a lot of typing and time in the end. And if you get stuck, eSellerate's courteous support staff has the patience of Job. They'll usually respond to emails within hours, and if you get really stuck, they'll talk you through problems on the phone. Expect more support calls with eSellerate than DigiBuy because eSellerate's system simply does more. (eSellerate's integrated technology is Windows and Mac OS compatible (CFM+InterfaceLib, CFM+CarbonLib, or Mach-O compatible). See, I told you you'd need a little support!)
Cases in point: eSellerate's support staff will answer all of your questions expeditiously and thoughtfully. A while back when eSellerate's integrated solution was still in the 1.x stage, there was a slight incompatibility with my software. Their developers were quick to respond and steadfastly worked through the problem until it was solved. Writing a Web interface for sales is hard to get right. But writing an integrated solution that's compatible with so many operating systems and versions is nearly impossible. And eSellerate's actually pulled it off with flying colors.
Although eSellerate doesn't offer simple splits of sales between authors, and lacks total configurability of the Web-based sales experience (its template choices are a five out of ten on the universal hideousness scale, especially with multiple products), they do many things right. Its author back-end for running reports of sales is the most configurable in the business. And the best part: its rates are the lowest in the industry, even for inexpensive products. Percentages of gross product price do add up and you should take percentages seriously. eSellerate's 10 percent fee for low cost products is much lower than their competitors. Be sure to keep in mind that eSellerate's rates will jump up to 15 percent if you make more than $15,000 in any 12 month period.
Below is a comparison table of the three Payment Processing Providers described previously. As stated above, these providers are always evolving their services, so it's important to check with them when you're ready to sign up.
(1) Refunds are initiated between the user, the payment processing provider and the author. Charge-backs are initiated by customers via their credit card company and result in much higher fees.
(2) eSellerate's fee is dependent upon volume. Lowest fee shown.
(3) Business hours, provider's local time only.
(4) Encrypted weakly.
(5) Cart not available with "old" store, only "new" store.
(6) Contract must be signed and faxed.
(7) Some international banks cost extra to transfer funds to. eSellerate doesn't penalize users whose banks support lower cost transfers.
(8) eSellerate keeps payment fee only if customer disputes charge directly with eSellerate. Author-initiated refunds are free.
(9) Non-objective comparison.
Although this article only discusses three Payment Processing Providers in detail, there are many others. Authors should look for themselves and compare services and percentages to find the best match for their products. A few other providers that come to mind are RegNow (20 percent commissions) and new player Plimus (10 percent commissions, see its "BuyNow" solution). PayPal's merchant solution is also an option, although your customers may not want to become PayPal members. PayPal's support is also difficult to get ahold of and its system can arbitrarily lock out accounts with no recourse. In any event, it wouldn't hurt to send an email to the tech support folks at all of these companies to see how quickly they'll respond to your questions. Such response time is usually indicative of how seriously they take their responsibility.
There is one other option we haven't discussed: setting the whole thing up yourself. There are a number of articles and books detailing e-commerce implementations. Below is just an overview of what you'll need to process sales from your very own server:
Now all of that sounds like a lot to keep wired together. But there is a simpler solution: Amerimerchant.com is both a payment gateway and merchant account with fees as low as 2.4 percent + $0.31/transaction. All that's needed is the server, scripts and secure certificate. Amerimerchant can also wire your payments directly to your bank account every day. In the spirit of Tim O'Reilly's penchant for Open Source, there's a real opportunity here to create a shareware payment processing system for use by the entire shareware community.
Do consider all options before signing up for a provider.
Do remember that approximately 40 percent of your sales could come from integrated eSellers.
Don't tolerate bad service. There are too many companies who want your business.
Do be sure to give these companies feedback! The good ones will be glad to get it, and hopefully add features to their package.
Do remember that 15 percent of $30,000 in annual sales is $4,500, and that's a lot of money!
Do make a spreadsheet and calculate your payments for a month. Looking at fees one sale at a time can be very deceiving.
We've all been there as users... working under a deadline... stuck on a problem... the software isn't quite working right... and you need help. Enter the world of technical support.
The first rule of providing support is to always be nice to your customers. No matter what profanity they send you. No matter how rude they are. No matter how demanding they are. Rise above it, and be nice. The one problem with email is it's very difficult for both the writer to relay tone and the reader to interpret tone. And words translated from other languages to English don't always express feelings and characterizations fairly. So have patience, and err on the proper side of being courteous.
If you don't stay on top of it, support can really get overwhelming at times. Don't Panic! There are lots of things you can do to seriously reduce your support load. My own general rule is that if I receive the same question more than twice, I add the answer to my shareware Web site in one form or another. This serves one great purpose: to lower my support load. And it works. Users, for the most part, are ready and willing to read your Web site to find answers to their questions. The challenge is making it easy for them to find the answers. Here's where FAQs are so important. (Oh, don't call them FAQs. Very few users know what that those three letters mean! Spell it out: "Frequently Asked and Answered Questions".) You may want to keep your FAQs in a database so they can be exported to static web pages. A little scripting will save a lot of time here.
In addition to FAQs, an "Important Notices" section on your support pages can call attention to pressing issues. Important notices are a great way to handle problems with your software that will impact all of its users. If you release a corrupted archive accidentally (and you will, at least once) you'll definitely hear about it. So an important notice is warranted to reduce that support load. Position the "Important Notices" section on the page so the users see it before they get to your support email address. If you have too many Important Notices, they will probably be ignored. Use them sparingly.
One more thing: there's a fairly common rule of thumb that says that only 1 out of 10 users actually complain about a problem. So if you're getting 10 emails on a problem, 90 others have had the same problem and didn't bother telling you about it. Keep this in mind when supporting any and all problems with your web site and software. All support issues should be taken very seriously.
There are two kinds of support: Technical Support and Sales Support. Technical Support involves questions about the installation and use of your product. Sales Support involves any questions about registration and payment. It's good to keep them separate, as users will want to help direct their questions to the correct "department". It's also easier for you, the author, to filter the questions into the appropriate box.
The #1 sales support question, without a doubt, is "I lost my registration code, can you send it to me please?" This is the most difficult kind of question to answer automatically because if the user lost his or her code, they also lost his or her order number. And chances are the user has either moved or changed email addresses since purchasing the software. So there's no easy solution. One thing that can help is a database that allows free text searches through any field. Searching for users' names along with their cities is a good way to narrow the search. Executing such a search right from your email client is a great idea that can save you serious amounts of time (see next paragraph).
My own registration code lookup works like this: (1) I select hopefully unique and descriptive text in the user's email. (2) I click a button that executes an AppleScript. My AppleScript opens my FileMaker registrations database, searches for the text in every field, and presents me with a list of possible matches. (3) I click a checkbox next to each match for all orders the user has ever made (there may be more than one!). (4) I then execute another script that creates the registration message. This script also pastes the text back into a reply to the user. The whole process takes about 10 seconds. If you have about 10,000 customers, you can expect 1-6 of these requests per day. Not too bad. But these requests will usually spike when you release an update. This is why many shareware authors will send users their registration codes at the end of their press releases. (See eMerge above.)
The above example describes why keeping a copy of your sales database on your local machine is so important. Be sure to get details on how to mirror a sales database on your machine when you sign up with a payment processing provider. (As for the Payment Processing Providers described above, eSellerate handles mirroring to your local machine by emailing authors a tab delimited text file with the previous day's sales. Kagi, DigiBuy, and eSellerate send authors an easily parseable email with every purchase.)
Do have patience for all of your users!
Do create FAQs for frequently asked (and answered) questions.
Don't assume your users know what "FAQ" means!
Do remember that it's really hard to relay tone via email. Try to avoid misunderstandings!
Do create an "Important Notices" section for items that affect all users of a product.
Do leverage your Web content against support emails.
Do create a database of sales so you can send your users any lost registration codes.
Localization is the process of translating your software to another language. Case in point: 15 percent of my sales come from a Japan. So Localization is something that should be taken very seriously.
Software named PowerGlot will make it easy for your translators to translate your software to their native language. PowerGlot is able to parse and change resources of all types (including PowerPlant), and apply translations from previous versions of the software to the latest release. It's an excellent time saver.
So you've done all of this work and you're ready for the release. Below is a checklist that you can use before you upload your updated Web site to make sure many of the necessary pieces are in place. (Included are all of the items I personally have forgotten over the years at one time or another.)
One quick note: never make a release the day before you go on vacation. If you do, it is inevitable that your release will contain a bug that will take two days to fix!
Now you're ready to upload your Web site, send out your press releases, and go to bed! If all went well, you'll wake up the next day to a few dozen sales and a bunch of happy customers. :-)
Do verify every item on the checklist before you release your software!
Do be sure your product's Web page has a version number on it so it will be found by version-tracking web crawlers. (Like VersionTracker.com)
Let's face it. We don't all sit in the house all day and wait for support emails to arrive. We take vacations or go on business trips. Working from the road is easy. Just dial up once per day and answer your emails. Users who expect support will be very patient with you if you're on vacation. Users understand that even shareware developers need some time off too. :-)
Find yourself an ISP that has dialup numbers around the World. America Online comes to mind. Here's where a portable computer really comes in handy too.
If you don't want to lug around a laptop, be sure your ISP supports a Web-Mail interface so you can check your mail and respond to questions from CyberCafes. In Europe, CyberCafes appear around every corner.
I think we've covered just about everything... from conception, creation, testing, sales, Web sites, ISPs, downloads, mirrors, sales, support, you name it. There's nothing I've described that's revolutionary. I just tried to bring all of these little facts together into one place.
Keep your goals realistic, listen to your users, and shareware can be a really fun hobby for any programmer. And that's really the bottom line... having fun with what you do.
Do have fun writing and selling shareware!!
Although it's nice to close my eyes and dream that I'm the shareware king of the world, when my eyes reopen I am always reassured that it really was only a dream. Nobody works in a vacuum. There are references throughout this series to articles, utilities, and other works that take different tacks on the shareware industry. A few references I couldn't squeeze into the content of this series are below.
Rick Holzgrafe wrote an article entitled Successful Shareware. This article was reprinted by the good folks at TidBits back in 1997. Rick's shareware was so good that I snapped up a copy for myself.
Although a few years old, Colin Messitt wrote an article that details cost figures for his software as well as insights into why people register. The article is reprinted here.
MacTech ran an article a while back by Tonya Engst on How to Write a ReadMe.
Chris Smolinski over at Black Cat Systems is maintaining a list of Payment Processing Providers. It's a hard list to keep up to date, so be sure to verify all values with the Payment Processing Providers themselves.
Let's not forget all of the shareware developers who blazed the trail in an industry trend that grew incredibly fast. Just about all shareware developers will give you hints and tips. All you have to do is ask. We're all part of a community here, and working for yourself is no easy task.
And a special thanks to the O'Reilly editors!
Sanford Selznick is the owner of Selznick Scientific Software, LLC, a programming, consulting, and shareware company based in Tucson, Arizona.
Read more Developing for Mac OS X columns.
Return to the Mac DevCenter.
Copyright © 2009 O'Reilly Media, Inc.