Order Process Still Not Making Sense

[TDub]

I'm wondering why there's a need to log in the user before an order is complete. I think it only serves to confuse the end user, myself included.

 

For example, I just did some testing of a domain registration because a user was having issues. Well, after I fill in my registration details pretending as if I were a new user and clicked submit, I got a MAXMIND Error message that free e-mails weren't allowed (I configured it that way and that's fine), so naturally I hit the back button (there was nothing else telling me what to do to correct the error). Well, upon clicking the back button I see an empty shopping cart, my user details listed but not editable, and absolutely no idea what happened. But suddenly I see more info across the top of the page as if I had ordered and I'm now logged in. But I haven't even finished ordering. Arrrgh! Talk about scaring the customer away or generating the perfect situation for duplicate orders/entries/etc. I hope you see my point.

 

A user should never be logged in until the order is completed. That is, UNLESS they already have an account and need to log in to add the order to their existing account.

[crombiecrunch]

ya I agree I am having a issue where I get a blank page when I click on complete order. When I click the back button I find myself logged in. Very frustrating

[TDub]

Yeah, maybe I'm missing the reason why a user needs to be logged in after an unsuccessful order, or even at all before the user completes the order.

 

I think the shopping cart idea is great and a big improvement over the previous version, but there's lots of room for improvement. Things like putting in the wrong credit card number, bad expiration date, wrong domain name, mistakes on contact form, duplicate items in the cart, changing minds about what you want to order, hitting the back and forward buttons, etc, etc. They all happen all the time, so the user should be able to go back and forth through the entire order process without breaking it OR how the process flows.

 

How many of you here have actually gone through the order forms yourselves and made some mistakes on purpose to see how the order form handles it, then try to recover from that mistake as if you were a customer and see what happens. Or talked to your customers about problems they had during the signup? I'd be interested to hear how others have fared.

[Matt]

Well, after I fill in my registration details pretending as if I were a new user and clicked submit, I got a MAXMIND Error message that free e-mails weren't allowed (I configured it that way and that's fine), so naturally I hit the back button (there was nothing else telling me what to do to correct the error).

You've asked the MaxMind module in your WHMCS to block orders submitted using a free email address. The user has checked out, the order is complete, and based on your rules the order has been rated as fraudulent. When you complete the order and it fails a fraud check, you can't just go back and edit that order. Otherwise what would be the point of it? A fraudulent user would just edit their order until it passes - the user is fraudulent so that order is now set as such.

 

A user should never be logged in until the order is completed. That is, UNLESS they already have an account and need to log in to add the order to their existing account.

As above, checkout was completed, and the order failed the fraud check. As you wanted to do, the user might then want to go on and place another order. They are logged in so they can do that, or if it's succeeded, pay for the order, access the client area, view details, etc...

 

but there's lots of room for improvement

Let's see...

 

Things like putting in the wrong credit card number

Wrong credit card number will fail the verification or charge and then be asked to re-enter

 

bad expiration date

Will fail the charge and display a message saying the card details were declined

 

wrong domain name

Can remove items from the cart and add other ones as required

 

mistakes on contact form

Can edit right up until the final checkout button is clicked

 

changing minds about what you want to order

Can add/remove items as you wish - that's what a cart allows!

[TDub]

Ok, but wait. If the order was fraudulent, why was the user allowed to complete the order process and be logged in? Wouldn't you want to either block a fraudulent users IP or prevent them from gaining any access to the system at all if it was fraudulent? Instead, I would think it would be preferential to tell them "Hey, your IP has been blocked due to suspected fraud. If this is in error, contact us directly" But in this case, the suspected fraudulent user was logged in and allowed to order again?

 

So, now, let's say it was a legit order and for some reason they weren't allowed to finish the order, then wanted to go back and reorder...how would they go about doing that? Hit the back button? Or are they supposed to know to click a link at the top of the page (which they may or may not notice or understand)? And which link should they hit?

 

My point is, the functions may all be there, but in many cases they're not presented clearly enough (in my opinion) to make the transaction "feel" smooth. Again, if it's not intuitive enough to the user to figure out what's going on by just looking at it, then they're going to get frustrated and leave. A lot of it has to do with wording, I think, and some of that I can change.

 

If you think I'm off my rocker (which it sounds like you might) I'd suggest you take some people who know very little about hosting or even shopping carts and give them some tasks, both good tasks (like here's a domain name...go ahead an order it) and those that will generate errors during the checkout (like a bad credit card number or, in my case, a possibly fraudulent order). Then see what they do. You might be surprised. Usability testing is critical in checkout processes if you want to ensure the highest percentage of completed sales. If you prove me wrong, then that's good news.

[chickendippers]

I fail to see how being "logged in" is a problem. Once an order has failed the verification it is marked as fraudulent and the invoice cancelled - it's not a security risk.

 

Perhaps you're just used to how other billing systems do it? I.e. Only create the user account after they have passed fraud check.

[TDub]

Yes, I AM used to how other billing systems do it. That's my point. Why are we changing something that works and everybody is used to?

 

It doesn't matter. I'm clearly in the minority and I'm growing weary of fighting a lost cause.

[chickendippers]

I must admit I was rather confused by that at first, but it means you have the customer's details on file to chase up any incomplete orders (fraudulent or otherwise). We definately lost custom due to that shortcoming in MB4.