Howdy, Partner!
One thing we always tell our clients to look for when they are considering an eCommerce provider is partner support. If a company is open, willing and able to bring partners to the table with additional value and tools for their clients, they have a better chance of survival and a greater offering to their customers. When a company is "closed", not only with their code but with the customers data, and external relationships, it usually is a bad sign.
Over the past 5 years of my experience, I have seen meteoric growth of open access to web based applications with API's, Web Services, Mash Ups and more. It was one of the reasons we wrote our Store API in tandem with its feature set - so it was always open for partners to use, clients to use, and more importantly - other systems to use. It troubles me in this day and age when a company still traps you into a proprietary system, in my opionion it means they are getting lazy and rather than compete on a level playing field with further innovation they prefer to trap customers. We have now seen this on both the smaller point of sale company level, and the large scale ERP management systems.
Businesses have to stay flexible, and provide the best value to their customers to make sure that the relationship is mutual, and not one sided.
Image is Everything, Size Matters.
You can spend countless hours and capital to to create your on-line eCommerce store front, you can hire the top designers and architecture specialists to make your users experience perfect, but if you miss one crucial element it won't perform. The single element is possibly the most important and overlooked piece of the eCommerce puzzle: product photography.
I am sure most of you are reading this post because of the image, and its the same reason that you need to show not only your product, but I highly recommended that you show your product in use. Now this can differ greatly from site to site and product to product, but there are some basic fundamentals that I can share with you based on our clients and my experience. Taking 5 sites from my past that I and my team have worked on, I analyzed their content and product photography and came to some startling results. Each one of these companies had pretty similar product bases, similar market size and budgets and shared common design and navigational elements.
| Site #1 | Site #2 | Site #3 | Site #4 | Site #5 | |
| Average Photo Size | 140 px | 256 px | 300 px | 400 px | 500 px |
| Average Number of Photos | 1 |
1 | 2 | 4 | 4 |
| Option Photos for Colors / Sizes |
no | no | yes | yes | no |
| Speciality Photo (Use or Location) | no | no | yes | yes | no |
| Average Product Traffic (Views Per Week) | 2,300 | 4,000 | 7,000 | 7,300 | 6,000 |
| Average Sales Per Week | $600.00 | $720.00 | $1,200.00 | $800.00 | $540.00 |
Now there is no magic combination, but any data cruncher can see there is something to be said about larger photos, photo options and specialty photos and their use within specific product views. There is also always a balance between page load times, graphic sizes and ease of use - but with some great tools like Zoom and Thickbox you can engage your customers with smaller versions of images and then leave it up to them to discover the details. The closer you can get your customer to experiencing the product in a real bricks and mortar store, or even in their own home half your work is done (the remaining half needs to go to your eCommerce software and its ease of use).
When I put the stats together for this post, I wanted to get 5 sites that are as close as possible (all sites above actually sell some of the same products and brands). I even started to look at how other eCommerce software handled photo sizes on-line and I came up with some interesting results. Some software actually downsizes your images without giving you a choice in the matter, namely to make serving the images faster. I have seen this now on several software packages in the open source and commercial markets and although a good idea to save on bandwidth costs; a bad idea according to the table above.
In Closing...
Pay close attention to your product photos, and how they convey not only the product but its use and position in your customers lives. Make sure your eCommerce software can handle larger images and have specialized tools and features to allow your visitors to explore individual photos with ease.
Why you should pay for eCommerce Software
Don't get me wrong, Software of any kind takes months if not years to create and deploy. Testing software and its use cases can be such a burden on a company that there are companies that just do testing for other companies... Over the past few decades a tidal wave of sorts washed over the software industry: Open Source. I love Open Source applications, I have worked on a few and use many every day. I feel that the Open Source movement was not only needed but beneficial in many areas that required a challenge - namely Operating Systems but also office productivity applications (in my opinion).
My company uses many Open Source solutions to not only create our software (Aptana) but also deploy and deliver our software for all our clients (LAMP). For me however, Open Source eCommerce poses a problem. I might really upset many with this post, and by no means do I want to create enemies - but I want to get my point across as clearly as possible...
Open Source eCommerce Solutions are more expensive than their commercial counterparts!
Open Source eCommerce Solutions are less secure than their commercial counterparts!
Okay, that's two points, so I have some explaining to do (if you haven't already closed your browser window).
First, Expense: When looking at an Open Source eCommerce Solution like osCommerce or Magento (there are many) you have to look at their Total Cost of Ownership (TCO) compared to a managed or software as a service solution like Cularis | Store and others. I have spent days on end comparing TCO when coming up with our pricing structure, so I think I know a little bit about this, but let me show you what I came up with...
Example One: TCO of Magento vs. Commercial eCommerce Solution ($199 base monthly fee)
Don't always compare free to commercial by its base price alone.
| Magento | Commercial App | |
| Software | Free | $199 / mnth |
| Support (Monthly - Avg 2 Hours) | $200.00 / mnth - Limited |
Included - Unlimited |
| Installation and Set Up (Hosting + Software) |
$249.00 / one time | Included |
| Hosting | $49.95 / mnth | Included |
| Security (SSL) | $149.00 / year | Included |
| Updates and Upgrades |
$149 / Each |
Included |
| One Time Fees | $647.00 | $499 Set Up |
| Monthly Fees | $249.00 | $199.00 |
| TCO Over One Year | $3,635.00 | $2,887.00 |
What's really amazing isn't just the cost difference, but also the time it takes to find individual vendors for your hosting, setup, support, installation and more. The largest cost difference also comes by way of support. If you require more than Magento or an independent partner has limited you to, you pay more - a lot more: up to $400 per month according to Magento themselves. An easy comparison if you already have unlimited support included with your commercial product, but let's keep digging:
Example Two: Security, Bug Fixes, Patches and more... oh my.
If you have your own IT staff or strong Kung Fu in the command line you can stop reading this part... but if you are a business owner that just wants to get to work this is very important. A managed solution and / or a software as a service solution provides everything you need to keep selling. They are responsible for your software, infrastructure, hosting, upgrades, bug fixes, patches and more. Open Source software is developed by hundreds, if not thousands of developers and is either your responsibility or your IT staff's to keep up to date. Because Open Source eCommerce software is Open, its readable by anyone, anywhere, at anytime. Any talented coder can find exploits in any code, no matter how secure or what framework a system was built on and if that coder is nefarious, rather than report the bug or exploit to the community - they use it for financial gain. I have personally seen several Open Source eCommerce systems that we moved over to our solution that were not just patches behind, but full version releases - meaning there were several major exploits still in the code. In one particular case, an exploit was even compromised and the customer had exposed credit card information, unknown to him and his customers. Not good.
Now I am not saying Commercial Software is perfect, nor am I saying that is is not a target of the same nefarious individuals, but based on its track record alone you can see its worth its weight compared to the solutions I mention here. Don't believe me? There is an easy test:
Step 1) Pick your commerce software of choice that is available as open source.
Step 2) Download a copy.
Step 3) Open It. You now have all the code.
Step 4) Return to the software vendors web site and visit their support areas, paying special attention to available upgrades and patches.
Step 5) Compare your downloaded release with those patches (you should be current since you just downloaded it).
Step 6) Look at the date of the last major patch.
If you did this test correctly, you will see that if you were a user of this software, and didn't upgrade it since the last release patch that was major - you could of had problems. If you pay someone an hour here and there to do your upgrades for you, please refer to Example One above.
In Closing...
Don't always compare free to commercial by its base price alone. You should always weigh your Total Cost of Ownership for any software you buy and make sure its as accurate as possible before making a decision. You should also include your time in that calculation, as you know how valuable that can be. If you chose an Open Source solution, make sure you have the abilities (or the staff) to stay on top of the updates that will always be required to keep it in shape.
Hello MOTO... Why you need a card not present account.
When doing business on-line, there are many things you need to take into consideration before you are ready to unleash your products on the world. One of the largest items to consider are payment methods, particularly Credit Cards. In the United States, Canada and much of Europe both Visa and Mastercard require any online merchant to have a MOTO account. A MOTO account is actually an outdated acronym for Mail Order Telephone Order and simply means that you are performing transactions for your clients where their credit card is not present but you can confirm the customers identity through other means.
When the MOTO account type was invented in the early 70's, it was mainly to help catalog based companies to accept the new credit cards that started to proliferate through their customer base, mainly in the United States. Presently, some merchant providers have started to use more up-to-date lingo to describe these account types but in principle there are only two you need to be aware of:
Card Present: When you physically handle and swipe your customers card while verifying their identity.
Card Not Present: When the card is accepted without it physically being present.
If you are just selling online, all you need is a Card Not Present account and many companies can easily set you up with one, sometimes without a start up fee and monthly fees under $25. To process a Card Not Present transaction you need a corresponding merchant account and also what is called a gateway, or card processor. One of the most widely used Card Not Present processors in the United States is Authorize.net, mainly because of their ease of integration into software and web applications. Although there are well over 100 individual gateway providers, I want to cover Authorize.net is my examples as they have, in my opinion, established a well deserved leadership role in their industry.
Now that you understand the types of processing accounts and what is needed to actually accept a payment via credit card through your eCommerce software, I want to address some very common problems we are seeing in the industry and the ramifications that will start to crop up if they are not addressed:
Problem 1: Processing a Card Present Charge as a Card Not Present Charge
When you accept a credit card at your retail store for an order that is physically being carried out in person, but use a merchant gateway or virtual terminal like Authorize.net that is linked to a Card Not Present merchant account you are increasing your processing fees, and potentially losing money on each transaction. We had a client that was losing almost 3% over their normal credit card fees because their merchant account was set up incorrectly.
Problem 2: Processing a Card Not Present Charge as a Card Present
If you thought Problem 1 wasn't that bad and could live with losing a few more percentage points, I bet you can't live with Problem 2. Many people don't understand this before its too late and we have seen many companies lose their merchant accounts because of this simple mistake. The sole purpose of a Card Not Present account is to better manage fraud protection, address verification, and credit card validation before a charge is processed. These extra steps require additional technology, time and cost the merchant gateway and your merchant account provider extra over a normal account. When you process charges that came in through your on-line store, mail order or telephone using a Card Present Account you are violation your merchant agreement.
We have seen high level point of sale systems that have this functionality built right into their software, using Authorize.net. Coupled with integrated eCommerce / Shopping Cart software, these systems simply save time and pass the "heavy lifting" of credit card processing back to the point of sale system (POS). Since the POS uses the Card Present account type to process the actual charge, it violates almost all merchant agreements for internet based transactins. To the customer and merchant everything looks like it works and no one is the wiser... until your merchant acount provider finds out.
In Closing...
When setting up an Point of Sale System, eCommerce system, merchant account or all three make sure you know how your credit cards are getting processed, and who is doing the processing. It means more than you think and can save you time, money and frustration in the long run.
You might also want to make sure no one else is taking a cut from your merchant fees... more on that later.
The Overly Branded Checkout...
I understand the importance of putting your brand in front of as many people as possible, but sometimes companies get carried away:
I am in favor of adding a meta tag, sure - it's hidden and if someone wants to see what a company is using then by all means do a little digging. I fully support what my company does by adding a tiny branded link at the very bottom of each page, "Powered by Cularis" (in 6px type). It's subtle and can be wiped out with a simple CSS change. But to force feed a graphical button, with a large branded logo on every store is...well, it's not nice. Customers that go through the hours of research to choose an eCommerce platform should feel that they are getting a "custom" solution, one tailored for them but upgraded and maintained by the provider they've selected. If a customer is spending more than $50 a month they shouldn't have to deal with any branding other than their own.
In Closing...
There are many reasons for why Volusion and other companies do this, but it should be an option, and if a customer wants it (read: doesn't mind the advertisment) they should get a discount off the product price. I might be wrong or out of line but I think you will agree.
