ShopSite Tip: Using Customer Registration Effectively in Your Ecommerce Store

Customer Registration, when setup properly, can be an effective tool for any ecommerce store. However, there are a few pitfalls to avoid to make sure this enhances your online store as opposed to it driving sales away. These tips will have some ShopSite ® specific examples, but could apply to any shopping cart solution.

Don’t make it required

In 99% of all cases, it’s never a good idea to make customer registration a requirement in order to complete a purchase.

You know how you’re annoyed when the cashier at a store asks for phone number, zip code, blood type, etc…? It’s twice as bad online when a customer just wants to buy your merchandise as quickly and easily as possible, and is confronted with your roadblock.

Unless you have a very good reason to require a customer to login / register to complete a purchase (and I mean a valid business based reason), you want to avoid forcing the customer to register/login in order to pay.

In today’s competitive online world, one time purchases by people who found your website on Google in a complicated search may make up a large percentage of your orders. They do not plan on a repeat purchase at your store, so why would they register before checking out?

Not knowing it’s optional is just as bad

ok, so you set your store to not require customer registration. Hooray! (sort of). However, this is what is displayed on your shopping cart page:

Is it required? Nobody knows…

There is no indication that customer registration is *COMPLETELY* optional in order to checkout! The customer does not know they can skip registering to continue.

The default text in ShopSite does not make this clear. It’s up to you to make it clear to your customers. Like Hanks Clothing does:

Crystal Clear it’s not required

To store or not to store…

In ShopSite, you can offer to store payment information for registered customers. This means their credit card numbers will be saved in the software.

Although this data is encrypted per credit card regulations (PCI Compliance), you have to weigh the added risk on your end of your website storing all of this card information. Unless you know your bottom line will be affected by repeat customers not wanting to shop with you because they have to type their card info in each time, I’d recommend disabling this feature.

The less sensitive data you have to manage, the better.

Bad links for sign-in / register

Many websites like to have simple links in their site’s navigation for signing in to customer registration or registering. This is a good thing.

Rexart.com sign-in / register header

One mistake we see a number of merchants make is they create these links by going to the sign-in page or register page in their store and copying the URL in their browser.

Unfortunately, what this does is create a link to a *specific user’s* cart / registration, as it copies a unique session ID in the URL. You do not want this, as everyone will be sharing a session (sort of), which results in confusing data in the cart and registration panel.

Here is the format to follow:
sign-in:
http://xyz.com/cgi-xyz/sb/order.cgi?func=2&html_reg=html&storeid=XXXX

register:
http://xyz.com/cgi-xyz/sb/order.cgi?func=1&html_reg=html&storeid=XXXX

Replacing “xyz” with your domain name and XXXX with your store’s id code.

Do NOT link to the secure URL with registration.cgi in the path. The “order.cgi” shown above is correct.

What do you think? Anything else merchants should be doing with regards to customer registration?

photo credit
roadblock photo credit

Looking for a web host that understands ecommerce and business hosting?
Check us out today!

3 Comments

  1. Daniel Keane says:

    Customers can place an order on our site without creating an acount.

    We offer the customer a second chance to register an account from the order confirmation page. We already have all their details, they just need to create a password.

    Only thing is the initial order is not related to the account, only future orders.

Leave a Reply to Daniel Keane