.comment-link {margin-left:.6em;}

Terpstravaganza

A Periodic (P)review Of Leaping Forward

By: Johan

Saturday, January 28

E-Commerce Methodology Shifts & Brain Storming

It's been just over a year since I started tailoring osCommerce to our specific needs. It has been quite a journey and it's nearly finished; for as far as code can be finished, that is. One thing is for sure, having in-house control over your software has major advantages over relying on 3d party applications.

The version of osCommcerce I started modifying dated from around November 2003. E-commerce has developed a lot as an industry since then and recently, during a big code update, I've come across more and more assumptions or ways to do certain things in the code that is far from how reality is. I doubt this is unique to osCommerce - recent developments and hypercompetition have caused quite a few shifts in the way online retailers go about thier business.

One problem I faced is UK specific. Delivery companies like ParcelForce (Royal Mail), CityLink, Parcelline etc. don't offer Web Service based delivery tracking. I couldn't find the exact date when US based colleagues of theirs like UPS introduced their XML based parcel tracking but it was as early as 2001 as indicated by this press release. That's 5 years ago. 5 Internet years is like a 100 years in analogue terms. Whenever I asked key people from their IT departments they either didn't know what I was on about or they had a negative answer to whether it was coming or not. Disgraceful in my opinion. With US couriers you can even Google their tracking numbers! What's wrong with the British couriers? So for the time being I'm scraping the tracking details with advanced HTTP crawler classes but it's FAR from ideal.

Recently I had the joy of rethinking the way Order Statusses work. It was one of the foremost reasons for me to ask my friends in the DP Forums how they visualize complex ideas. It seems easy enough. An order is created when it is placed, then it's fulfilled by the merchant. But I came to the conclusion it's more complex than entry level or even high end e-commerce systems and software would have you believe. I came to the conclusion you can't slap one label on an order and just call it "Sent" or whatever.

"Order Status", the status of an order. What is the answer to the question "Can you give me an update on the status of my order?". One label doesn't work. An order consists of too many elements to use just one catchy phrase to identify an order's status. Has it been paid? Are all the products in stock? Will a product be sent from stock or from a drop-shipper? Was a product cancelled? Was the chosen delivery option changed? Did all products go in the same consignment or were they split up?

So many questions and even more possible answers here.

One label doesn't suffice. A typical answer to the status question would consist of a description of a couple of things. Product A is in stock but we're waiting on product B. Your billing address failed the fraud checks. Product X has been sent from warehouse 1, product Y is being prepared for despatch from warehouse 2. The consignment containing product 1 and 2 was delivered this morning but you weren't in. And so on...

Different labels are needed for different parts of that what makes up an order.

There's another angle we can take to look at what an order is and how we can label them. This requires identifying the parties involved in an order. It all starts off with the customer who creates the order by adding stuff to their basket, choosing payment and delivery options and confirming the order. It's only at that stage that some e-commerce systems slap a status label on it. "Order Received". I disagree. An order is already an order before it was received. There's too many things that can go wrong with either your website, a customer's browser or perhaps your 3d party payment processor to only record and label an order when it's in the bag.

Why not record it at the stage where it seems like they are really going for it. When they start filling out details like delivery or billing details. This is the stage where the customer controls the order's status. It's 'awaiting payment', it becomes 'awaiting card transaction' it could go to 'payment declined' from where they might try again and it becomes 'payment authorised'. Those labels are fairly simple; they describe simple events that happened to the order in its entirety.

But this is where things get complicated. To now speak about the order as a whole doesn't allow for enough granularity, for a small enough scale to see what happens inside the order. This is where in my opinion it's all about the products chosen and the services selected to get those products. And all of those could have different status labels at different times.

From here an order is passed from the customer to the merchant. Now it's the people who process an order who can change the order and push it on down the virtual conveyor belt. (Some systems allow customers to still amend their order up to the point where it was processed in terms of debiting money and preparing it for despatch.) First off, the merchant would typically check everything is in order. Are the details complete and was the transaction trouble-free? Should the status become 'Pending Fraud Review' perhaps or is more information required hence a status "Require Billing/Shipping Info"? Those still apply to the order in general. But from here on we can inspect the status at product and service level. Maybe one product out of the 4 they ordered was discontinued. Do you now apply one label to the entire order to reflect this or do you amend the status at product level so you, your staff and the customer via their account can see what's the matter?

Now we're ready to despatch part or all of the goods ordered. Depending on whether we indeed ship one, a subset or all of the goods, one label really becomes impossible to use for an 'order'.

Delivery tracking... Like I said at the start, UK couriers are rather incompetent at this but I didn't give up that easily. An order is made up out of one or more products. They on their turn can be split into one or more consignments. Consignments can then be split up in parcels, potentially. You can see the limitations of a single order status label here. A parcel gets prepared for despatch, collected by the courier and then via a variety of trucks, vans, hubs, depots and individuals to the customers. But parcels can be separated from other parcels from the same consignment so when we scrape the status off their website they could show individual tracking statusses.

That's why a status changes from a label on the order as a whole to an individual label on each product ordered.

Here's another outdated principle. Using just one set form to capture a customer's address is wrong. We validate postcode to ensure delivery goes well and to prevent fraud but what if the customer is from the Republic or Ireland where postcodes are not used? In the UK we'd put the postcode after the county usually, in Holland we do it the other way around. in Germany, an address is formatted differenlty again. That's why the site should first ask for the country and then apply a set of validation and formatting rules. And we could be nice and detect their country by IP in a bid to try and guess their preferred option for them. It's all about cutting hassle between finding the products they want and paying for them. After all, it's their money we want so we as a merchant should pave the way to a successful transaction smoothly.

Which brings me to another flawed principle. Why capture billing details if you are not going to use them? If we only e-mail an invoice then what good is knowing their billing address and getting them to type it out in its entirety when they chose to pay by Bank Transfer or PayPal? Do we need that in order for us to take their money? I don't think so. One catch is that I base the available payment methods in my code on their billing address. That way only people from the UK and some trusted Western European countries can pay by Card. If we were to swap this around and ask for their preferred payment method first, we'd have to allow all or use IP detection, which could prevent someone on holiday to order something he or she needs when coming back home.

One thing that hasn't changed at all is the fact that people don't read instructions. They skim text or look at pictures and make assumption based on that. I had all instructions scrutinized by a colleague who spent years in sales and is an expert at no-waffle communication. All instructions were cut down to the bare minimum and in as plain and straight-forward English as one could wish. Also placed strategically and formatted in an eye catching way. Still people don't read it. So we have to code things assuming the worst kind of customer from hell who is completely new to buying online and almost soiling their pants about keying their credit card (whilst you and I know it's actually safer than to pass it over the phone, fax or e-mail). But whilst catering for the stupid we also appreciate those who can in fact make a fast decision on a purchase; they need a fast track route to the end of the check-out.

Requiring people to sign up an account when they want stuff delivered to an address other than the delivery address is one of those things they don't get. They happily skip simple instructions and then type their preferred delivery address in the order comments section so nothing is validated and automated consignment job insertion functionality doesn't work either. Thanks for not reading that bolded red line.

The solution is to accept 'defeat' as far as doing it the way we want to do it and to find a way that suits them. In the end, it's their money we want - we're not that fussed how they hand it over. I have had some thorough looks at check-out procedures of big online merchants like Amazon etc. If I remember correctly it takes about 14 screens to complete a new order on Amazon. "Do you want gift wrapping?" takes up a whole page/stage. They have the branding to keep their customers but smaller merchants can't afford such 'mistakes' in my opinion.

So, should we ditch the requirement of an account altogether? After sales support is a lot easier if someone is logged in; order status reporting is a lot easier when you can pinpoint a visitor to an account number and hence an order number. The use of accounts and supplemental customer data also allows for interesting marketing campaigns, customer loyalty efforts etc. So ditching the need for an account is not the way forward.

What we can do here is to lift the account creation to after the buying process. Just force an account on them but after the money part was done. That way they get a quick sales route, they get an account to re-order easily, get support etc. and we get their data and an easy way of communicating. What this idea leaves me wondering though is whether they will actually sign in when they order again.

After jotting down those ideas I'd like to finish saying how cool the AdWords API is and what a nightmare it is to get similar functionality from Yahoo Overture. It requires signing an NDA to participate! Google just e-mails you a token, offers the API classes and functions code and off you go, up and running in minutes. Thanks Brin & Page!