There’s a great usability book out there by a fellow named Steve Krug, called “Don’t Make Me Think” That book title couldn’t be more apt for the checkout process in a shopping cart. When your shoppers commit enough to hit the checkout button, don’t present them with a new decision to have to make before they can get started.

As one person put it, your shoppers aren’t looking to develop a relationship with you. You have something they want, and they want to give you their money so you can send it to them. Since you want to get their money and send them things, it seems you have a common goal. So why not make it easier to achieve that goal? Get the sale, and then offer them the opportunity to create an account if they think they’d like to come back and shop again. But don’t clutter the checkout process with an unnecessary decision.

So, to the meat of the matter. How does one go about creating an account for a customer using the information available on the INVC page? Since they’ve already provided their shipping and billing information, there are only two additional bits you need from them: a user name, and a password. The rest you can feed to the form from what they’ve already told you.

In your INVC page template, decide where you want to present the account creation option, and add the following code. The hidden input for PrevPage isn’t required, but it gives you a global variable to test against if you want to customize the ACED page to display a “Thank you for creating your account” message instead of the account edit form.

You’ll have to do your own form styling, but this should give you the bare bones you need to get started.

<form method="post" action="&mvt:global:secure_sessionurl;">
<input type="hidden" name="Store_Code" value="&mvte:global:Store_Code;">
<input type="hidden" name="Action" value="ICST">
<input type="hidden" name="Screen" value="ACED">
<input type="hidden" name="PrevPage" value="INVC">
<label for="login">User Name</label>
<input type="text" id="login" name="Customer_Login" value="&mvte:global:Customer_Login;">
<label for="pass">Password</label>
<input type="password" id="pass" name="Customer_Password" size="25" value="&mvte:global:Customer_Password;">
<label for="verifypass">Confirm Password</label>
<input type="password" id="verifypass" name="Customer_VerifyPassword" size="25" value="&mvte:global:Customer_VerifyPassword;">
<input type="hidden" name="Customer_PasswordEmail" value="&mvte:order:bill_email;">
<input type="hidden" name="Customer_ShipFirstName" value="&mvte:order:ship_fname;">
<input type="hidden" name="Customer_ShipLastName" value="&mvte:order:ship_lname;">
<input type="hidden" name="Customer_ShipEmail" value="&mvte:order:ship_email;">
<input type="hidden" name="Customer_ShipPhone" value="&mvte:order:ship_phone;">
<input type="hidden" name="Customer_ShipFax" value="&mvte:order:ship_fax;">
<input type="hidden" name="Customer_ShipAddress" value="&mvte:order:bill_addr;">
<input type="hidden" name="Customer_ShipCompany" value="&mvte:order:ship_comp;">
<input type="hidden" name="Customer_ShipCity" value="&mvte:order:ship_city;">
<input type="hidden" name="Customer_ShipState" value="&mvte:order:ship_state;">
<input type="hidden" name="Customer_ShipZip" value="&mvte:order:ship_zip;">
<input type="hidden" name="Customer_ShipCountry" value="&mvte:order:ship_cntry;">
<input type="hidden" name="Customer_BillFirstName" value="&mvte:order:bill_fname;">
<input type="hidden" name="Customer_BillLastName" value="&mvte:order:bill_lname;">
<input type="hidden" name="Customer_BillEmail" value="&mvte:order:bill_email;">
<input type="hidden" name="Customer_BillPhone" value="&mvte:order:bill_phone;">
<input type="hidden" name="Customer_BillFax" value="&mvte:order:bill_fax;">
<input type="hidden" name="Customer_BillAddress" value="&mvte:order:bill_addr;">
<input type="hidden" name="Customer_BillCompany" value="&mvte:order:bill_comp;">
<input type="hidden" name="Customer_BillCity" value="&mvte:order:bill_city;">
<input type="hidden" name="Customer_BillState" value="&mvte:order:bill_state;">
<input type="hidden" name="Customer_BillZip" value="&mvte:order:bill_zip;">
<input type="hidden" name="Customer_BillCountry" value="&mvte:order:bill_cntry;">
<mvt:item name="buttons" param="Save" />
</form>

1. Ask people whether or not they want to create an account. If they have an account, make them log in.
2. Ask for shipping and billing information.
3. Throw some upsales at them and hope they’ll bite.
4. Find out how they want to pay and what method of shipping they’d like.
5. Get their payment details from them.
6. At long last, give them an invoice.

Those who criticized Miva’s checkout process held up the concept of “one page checkout” as somewhat of a Holy Grail. And over time, I admit, I began to subscribe to the idea that a single page checkout process was not only to be admired, but to be aimed for even when it meant cramming the page with decisions for the shopper to make.

Recently, however, Bruce Golub of Phosphor Media, a respected member of the Miva Merchant community, made a comment about one page checkouts that made me sit up and take notice.

According to Bruce, it’s not the number of steps in the process, but how understandable the checkout process is that matters. Remove distractions. Remove advertising. Tell the shopper what to expect. Focus the shopper on what to do next and how to do it.

Wow. Such simple advice, and yet it just makes so much sense. We think that by not making our customers click “continue” a few times, we’re making it easier on them. In fact, we may just be doing the opposite. By trying to do too much on a single page, we risk distracting the customer from the checkout process entirely, or simply overwhelming the customer with information and tasks. The likelihood that they will overlook inputting some detail of the checkout process goes up, increasing the checkout error rate, and increasing customer frustration — and frustrated customers are bad for business.

Thanks, Bruce, for putting the checkout process back in perspective.

Well, let’s start by taking a look at what we mean by a Search Friendly Link.

A regular Miva Merchant link to a product page for a product named widget that has a product sku of SQK-233 looks like this:
<a href=”http://www.domain.com/mm5/merchant.mvc?Screen=PROD&Store_Code=StoreName&Product_Code=SQK-233″>

Kinda long and klunky, isn’t it? The items after the question mark in the standard Miva link (Screen=PROD, for example) are called parameters. Parameters are common in links for dynamic websites where data is stored in a database; parameters determine what content will be pulled from the database to be displayed on the page. There’s lots of debate in the SEO community about parameters in URLs, and what effect, if any, they have on indexing and ranking of pages

There are numerous ways to write Search Friendly Links, and Pete McNamara (an internet marketing and Miva Merchant specialist for whom I have a great deal of respect) has written an excellent tutorial on creating Search Friendly links for Miva 5. Following Pete’s tutorial, one version of a Search Friendly link for our widget might be:
<a href=”http://www.domain.com/p/widget.html”>

Ahhhh….short and sweet!

Putting aside the seo debate of whether or not search engines can or do easily index links containing multiple parameters, the fact is that so-called “search friendly” links are also people friendly. A short link like the one in the second example above is easier to type, easier to remember, and easier to copy and paste into an email without the link breaking.

Some schools of thought in the SEO community hold that search engines take the presence of kewyords in the URL into account when ranking pages, while others claim it makes no difference. (In case you haven’t noticed, the SEO community loves to argue!) But, regardless of whether search engines give weight to the use of keywords in URLs, the fact is that in many search queries those keywords will appear bolded in the search results. This helps those links to visually stand out, and people may be more likely to notice and click those links because of the highlighted keywords. And nobody would argue that an increase in targeted website traffic is a bad thing.

All of which adds up to Search Friendly Links being better for people. Better for people means better for your customers, and the more you do to make you website accessible and friendly to your customers, the more likely it is that your site will bring you those precious sales.

So, if Search Friendly Links are also more user friendly, shouldn’t everyone use them? Not necessarily. If you have a new site, by all means you should embrace search friendly links. On the other hand, if your site is already indexed by the search engines, and ranking well, it’s not a good idea to just up and change the links to your pages. You need to think long and hard about your reasons for wanting to change your links, and what you hope to gain by doing do. Then weigh those gains carefully against the risks of losing your search positioning, even temporarily.

If you decide that the risks are worth it, be certain that you implement proper 301 redirects for any pages for which the URL has changed. (A 301 redirect is a server-level directive to search engines and browsers that basically says, “Hey, the stuff you’re looking for has moved permanently to this new place over here.”) 301 redirects aren’t guaranteed to protect your rankings, but they will definitely help to minimize any damage done.