Authorize.net, the leading payment provider for ecommerce and online payments, removed their setup fee ($49) on April 19.  This is great news, since the fee was much higher than competitors, and was a barrier for entry level ventures, or hobby websites.

Without the setup fee, merchants can start taking online payments with a minimum committment of $25 / month.  Each transaction is then subject to a 2.9% + $0.30 charge, which is in line with the industry standard.  For someone looking to enter the ecommerce world, authorize.net is now a more affordable option to consider.  Merchants looking to change payment providers will also benefit from this change.  They can now effectively trial another payment provider without a setup penalty, as it were.

Amazon.com has been an ecommerce giant since the late 90’s.  It now sells almost everything you can imagine, and most people would think that’s also where it makes it’s money.

Wrong – mostly.  Outside of techies, most people don’t know that Amazon owns one of the biggest “cloud computing platforms,” known as AWS (Amazon Web Services).  This is a platform where companies essentially “rent” computing power, storage, and many other digital services.  In 2016, AWS contributed $3.1 billion in operating income to Amazon.  Retail contributed about $1.1 billion.  Surprised?

So, what is AWS?  It’s a massive set of cloud services, allowing companies to build and host web-services, databases, rent computing power, storage, and much more.  Companies that used to rent physical servers, or co-location space in data centers are moving their infrastructure to cloud based services.  An analogy might be moving from digging and maintaining your own well for freshwater, to a municipal water service that provides fresh water at a low cost.

What’s interesting to me is that these services are charging based on usage, rather than a “flat fee” per month.  On the surface, this might sound expensive, but in my experience, it’s actually cheaper.  Companies only pay for what they use, be it computing power, database transactions, etc.  Amazon has also opened up API’s to it’s natural language processing (build your own Alexa!), and much more.

From a technical perspective, this shift means that people in IT should start learning more about cloud architecture and terminology.  That’s what I’ve been doing, and starting to advise for my clients.

On ecommerce sites especially, “Live help” or “Chat now” features are ubiquitous these days.  Does your site have one?

You have seen them, perhaps even used them.  The button that offers instant access to someone who can answer your questions.  What you may not realize, is that you can close more sales by having one.  I know this mostly from client anecdotes, and also from personal experience.  Sometimes a 1-2 minute chat is all it takes to answer the last questions a customer has before a purchase.  This is especially true if you sell expensive or hard-to-return items.

So, how do you implement this feature on your site?  Here are 3 options, that might work for you:

PHP Live Helper – this is a local solution – meaning, you install it and run it on your server, next to your existing shopping cart, etc.  The code is embedded in your site wherever you need it.  You pay a 1 time license fee (I’m a reseller here so if you want to save a little money, contact me before buying), with no monthly costs.  It requires php and mysql, as the name implies.

Zopim – This is a hosted solution, with a Free level, but a monthly recurring price that many sites would need.  It’s super easy to install and configure; you can be up and running quickly.

Ogg Chat – Another hosted chat – this one integrates to google talk, but has no free option.

There are more solutions out there, if you do some searching.  The prices and features vary widely, but all will help you connect with prospects at the exact time they would like some help.  Most have “push” request ability, which allows you to proactively ask a visitor if they need help.

Also, at least php Live Helper gives you realtime stats on users as they peruse your site – what page they are on, where they go next, and how long they stay there.  This can help you determine with visitors may need help.

Keep in mind, all these solutions require someone to be available to “man the phones” – at least a few hours a day.  If you are already at the computer most of the day, it’s an easy feature to keep in the background until someone requests help.

To clarify, I don’t run any ecommerce sites myself, this is just what I see from working with ecommerce clients daily.  The bar is being raised for ecommerce success.  You may not have to do all these listed above, but you will have to do most of them, and do them well to succeed.

By now, we all know that the website for the “Affordable Care Act” (aka Obamacare) is a mess.  Not “was a mess”, but still is, 3 weeks after it launched.  Here’s an article with screenshots, and comments on various errors encountered.

As programmer, a major lessons can be learned from this failed rollout:

1. Make it work – even though the initial failures were blamed on the high volume of users, it’s become clear that there are functional problems with the code and databases.  If it were purely a capacity issue, after a few days that would have subsided as the volume decreased.  Instead, problems have persisted.  Now we are hearing that the whole thing might have to be rewritten and insurers are complaining about getting mangled data from the system.  Luckily, the government has a monopoly here, and “customers” have no where else to go.  If you launched your website in this way, you’d be finished.  If the site isn’t ready, delay the launch until it is!
2. Make it simple – in order to see any pricing for the various plans, you need to give pretty much all your personal and family information.  That means many screens of data entry to get to the pricing.  Any e-tailer will tell you this is a kiss-of-death.  You need to show customers the pricing up front, including shipping, return policies, etc.  Nobody wants to go through a lot of hoops only to find out they don’t want to buy.  Again, in this case consumers don’t have a choice, but in the real world you can’t operate that way.
3. Settle on the design early – one complaint I heard (and I believe it) is that the programmers on this project were dealing with constant changes to the requirements – requiring whole sections of code to be rewritten or discarded.  While it’s important to be flexible on functionality, at some point (long before the launch date), you need to make solid decisions and stick with them.   Better to launch with an imperfect user interface, than to launch with something that is buggy or doesn’t work at all.
4. Beta test – big companies like google and facebook routinely “roll out” new features to a select group of users, usually by invitation only.  Then after a few weeks, they expand the rollout to everyone.  I didn’t hear about any such rollout plan for healthcare.gov.  Instead, they chose the “Big Bang” approach – and when the big day finally came, we got a big “thud” instead.
5. Don’t forget Security – I’m not sure the healthcare.gov site is “insecure”, but I worry that it is.  Why?  Because all the errors suggest that the programmers were scrambling to fix basic bugs, and functionality errors.  That means that any “security testing” that was done was incomplete.  It had to be, because the site was changing up until the last minute.  It’s like inspecting the wiring in a building while the electrician is still there working.  You can see what’s been done, but you can’t vouch for what is not complete or needs to be changed.

Many of these may seem like common sense, but it’s easy to lose sight of these when you are working on an exciting new opportunity.  It comes down to simple execution of the fundamentals.  The internet has matured to a point where user expectations are very high – so make sure your site meets them.