Will pay for help

[Richard Gaskin]

Lars Brehmer wrote:
> I think the KRM process of buying and unlocking with a click without  
> navigating a store, shopping carts, checkouts etc. would be the  
> perfect way to go, at least for me with this particular project, and  
> worth every penny of the fees thay charge for using this service.

It certainly seems convenient, but unless you have an uncommonly strong 
brand association and trust level with your audience you may want to 
also maintain a shopping cart on the web.

While no financial transaction is entirely hack-proof, customers are 
used to buying on the web, and as long as they see the "locked" icon in 
their browser they feel reasonably assured that their sensitive credit 
card data is secure.

When building a custom purchasing solution into your software, you not 
only have the technical challenge of implementing it but also take on 
the risk that your conversion rate may be lower because customers have 
no idea what your software is doing under the hood.

This perceived risk issue is exacerbated by an ever-growing number of 
malware programs floating around, contributing to an erosion of trust 
throughout the environment.

The degree to which this trust factor will affect conversion will of 
course depend on a great many factors, and for some audiences the 
convenience might just outweigh the perceived risk.

Just the same, you may want to play it safe and offer an option to buy 
on the web.


I haven't seen specific studies of conversion rates for software sold on 
the web vs. with a built-in shopping system, and if anyone has one I'd 
be very interested in reading it.

But as a general rule, when it comes to generic business questions 
common throughout the industry, I tend to follow trends established by 
the most successful companies, not reinventing those wheels and instead 
devoting any resources I might spend on innovation to crafting the 
differentiators in our products.

Adobe, Microsoft, Apple, and pretty much every other major player I can 
think of sells software through their web site, and do not include a 
payment system in the software itself.

An exception to this is iTunes, but that package has a very different 
business model based around frequent low-cost purchases of individual 
songs and albums, rather than a one-time purchase for the software 
itself.  That said, it should also be noted that Apple has an unusually 
strong brand recognition and trust factor which raises consumer 
confidence to levels most of us can't hope to match.

If, like iTunes, you sell a wide range of low-cost content, making a 
built-in shopping system may prove worth the expense.

But in reviewing this option with clients, we decided that the cost of 
adding this feature provided a low ROI in even the best case, since it's 
a feature that if used at all will be used only once.  So instead we put 
that development expense toward features that are used in the daily 
workflow, the things that make our product worth buying.


Tip:  provide a PayPal option for your customers.  Mine kept asking for 
me PayPal for years before I finally got around the spending the five 
minutes it takes to set it up, and boy did I feel dumb for not doing so 
sooner - conversion rates bumped noticeably.

Using PayPal has two attractions:

- It's ultra-convenient to make a payment; just enter your address and 
password and you're done.

- Because it's in a separate account from one's normal banking and 
credit cards, it doesn't feel like spending real money; it feels like 
play money, making impulse buys much more frequent.


--
  Richard Gaskin
  Fourth World
  Revolution training and consulting: http://www.fourthworld.com
  Webzine for Rev developers: http://www.revjournal.com