How do I reduce cart abandonment? How do I convince people to buy rather than walk away? How do I build trust before they become my customers?
E-commerce is full of such evergreen questions. As a software house that has been working with Komplett, one of Norway’s largest e-commerce companies, for 10 years, we hear them regularly and tackle them every day. As always, when you take a deep dive into a topic, there are no easy answers. But there is a fair amount of knowledge you can build into your customer journey to improve in the areas that matter most.
Today, I’d like to focus on a topic that may seem inconspicuous but is hugely important when it comes to growing a mature e-shop: the delivery statement.
What is the delivery statement?
Going by the looks it’s not a frontliner of your PDP – it’s this small font caption that appears somewhere around the big & bold customer price and informs the customer when to expect the product to be delivered. But how it is being said and with what certainty, that’s something that has a huge impact (one of the biggest of all PDP features) on the final buying decision.
Let’s look into the certain ways of providing the information.
Estimated Time of Delivery (ETD) vs. The Delivery Promise
Let’s take few examples into consideration:
- Standard shipping in 10-15 business days
- To be sent 28 May – 10 June
- Est. Dec 15 in your location
Those are typical examples of Estimated Time of Shipping/Delivery. The customer is informed about how the regular business process is shaped and on what date can he/she expect the package to arrive. It doesn’t though promise anything. The shipping/delivery will or will not happen (although it is likely to happen) within the given time and the customer cannot rely on such a statement. It’s good enough, if the customer orders something as a bargain, an extra that isn’t needed immediately and waiting for it is morelessly acceptable. How often do we buy something we don’t need here & now though? Let’s then have a look on different approach to delivery statements:
- Buy until midnight and have it delivered tomorrow
- Delivered to Chicago, IL by Wednesday, Feb 29
- Guaranteed delivery in 2 days
Over here you can see that the seller promises the delivery date. The semantic differences might seem quite small, but it carries a huge difference to the whole collaboration model between the shop and the customer, as the shop actually guarantees that the delivery will happen within the given date. The shop ultimately takes the responsibility for the delivery within the particular timeframe. The customer can be sure that the parcel will arrive on time (which is guaranteed by the reputation of the shop and hopefully terms & conditions).
This allows the customer to plan his/her time and product usage around the delivery. It provides much better experience and, looking from the e-commerce perspective, assures smaller cart abandonment, higher certainty of buying decision and a boost in conversion. So, in short words – lots of advantages, no flaws. Why isn’t it then a global standard? Of course, because of money.
Implementing a bulletproof delivery promise that will encounter many possible delays but not overinflate the guaranteed delivery time (it would be super safe to assume that all deliveries will happen within half a year, wouldn’t it?) is a very costly and time-consuming activity. Why? It’s all about the complexity of processes and integration of the data standing behind it. Scaled businesses always have tangled processes and combining them into one reliable machine is quite a mountain to climb. Let me explain the complexities in next paragraph.
What drives complexity of the delivery promise?
On first look it seems easy, you keep products on stock, you calculate the delivery time and you display this to customer. Real business is just never as easy. Scaled e-shops always have to fork the processes and customer expectations force us to propose different features in delivery. And not to forget, many businesses have some special conditions that need to be taken under consideration. I will try to summarize the factors that influence the complexity of the Delivery Promise.
Courier services
Customers demand various couriers to be available, as they might have preferences on the brand, the quality and timeliness might differ geographically (we all know the situations where you hate a particular delivery person from your area). Moreover, they may expect parcel locker deliveries and usually it is quite handy, you connect via API and that’s it. But what if you are selling some particularly big products (like i.e. fridges, dishwashers)? You have to assure on the data level, that the customer doesn’t order an oven to a 20x30x40cm locker in his/her neighbourhood. To assure that, you need to fetch the dimensions and weight data from PIM. But that’s not all. What if the order includes a microwave, an ice cube machine and a water purifier? All of them separately fit the locker, but as a separate parcel and the customer won’t be interested in paying 3 times for the delivery. You then need a tool to sum up the parcel measurements and collective weight. Going further, if you integrate cargo deliveries, you need to enable additional options like carrying the parcel to a particular floor. Some of the cargo couriers (i.e. furniture carriers) require integration with their online delivery calendars. In such cases the number of edge cases, the features to integrate and thus the time of implementation can skyrocket.
Warehouse availability
Seems easy, doesn’t it? You have a warehouse, what’s in it, you send the same day, what needs to be ordered takes longer.
The reality is a lot different. First of all, most nation- or region-wide companies have multiple warehouses for the proximity of delivery from suppliers. You have to integrate availabilities in them. Moreover, if the company runs also a physical business, each of the shops has to have a small scale warehouse on the side to operate. Additionally, to show the full availability, you must constantly monitor what’s on the shopfloor and on the shelves. In the end the global warehouse availability becomes an integration of tens of small warehouses, where except for availability checks, you also have to implement special rules for order collecting. If the customer orders a bike, a helmet and a baby biking seat and you have them in 3 different locations, do you want to send them asap in 3 deliveries (accepting the additional cost) or do you prefer to delay the parcel delivery by one day to gather them in one warehouse first?
Those are the issues that require a deep business process analysis and we only assumed here that all the products are immediately available. Next point is deeply connected, but brings the complexity to a whole new level.
Product sourcing
The reseller companies always have multiple product sources that need to be aligned with their SLAs, real time of deliveries, absence/bank holiday calendars etc. Defining the delivery promise with the usage of vendor’s SLA means you can delay it to the point that never happens (if the SLA is really safe for the vendor). Basing on the standard delivery time of your vendor, you basically know some of the parcels are not going to be delivered correctly.
Going further, if your e-shop offers the goods directly from the producer, the availability estimation becomes even more crazy. In case your products are MTO (made to order), the production process starts when the order is actually made (it relies to expensive, small-scale products, mostly in B2B e-shops). It is nearly impossible though to determine, If the production line is going to be available at the time, as there is always a risk that someone will place a far larger order just before and the production line will be busy for few weeks. Integration of a live production plan calendar is another brick in the wall, especially if the products are highly costumizable and hard to predict in assembly time (just to give golf course lawn mowers as an example from my experience).
Untypical products
The product itself can be also quite a problem in the determination of delivery promise. Especially in B2B market, but not only, if the products are hard to quantify or are shipped in special conditions, the process of providing the valuable delivery promise can be complicated.
Let’s consider materials that are delivered by meter (i.e. cables in the construction material business). The cables are cut from a huge roll and in small amounts are sent on its own. In larger amounts, they are wound on a spool of certain size. The calculator that allows to transform meters to parcel size is needed, as it doesn’t grow gradually. The size/weight of the parcel determines the shipping method and hence the delivery time, which becomes a resultant of many factors that need to be sourced in different databases, hence the complexity yet again grows.
Additionally, many materials can require special shipping conditions – like bioscience / pharmaceutical products. Cool storage, HazMat (hazardous materials), dry ice parcels – possibilities are endless and they all raise the complexity of delivery planning. In edge cases, you need to plan each delivery with the assessment of the failure risk (i.e. flight cancellations, delays due to public holidays on one of the delivery chain points). In such case providing a fully reliable delivery promise requires a big buffer that harms your value proposal (and due to that it may not make sense to promise anything).
At Komplett, we wanted to give customers in Norway a clearer picture of when their order could arrive and more choice at checkout. We tested express delivery options, including the price point for each one, and compared different ways of presenting standard delivery times. Adding an extra day was one option, but the approach we’re now implementing is a range of estimated delivery days, expressed in working days and excluding weekends. The experiments showed that delivery information can influence both the delivery method customers choose and conversion.
How to build your delivery promise?
Coming to conclusions – if it is so tough, why would we even struggle? Well, in the end, of course, for money. The reports disclosed by companies indicate, that providing an exact delivery date is nowadays more important to over 60% of customers than the actual speed of delivery. It also allows around 10% of drop in the cart abandonment and in the end, which probably is the ultimate goal, it drives to around 13% of the conversion lift. For any shop out there in the market, those numbers will be significant.
To the contrary, introducing the delivery promise that will be reliable and not overly defensive is of course a costly feature to enable. Is it worth it though? Well it’s something you have to calculate.
To do that, you need to gather the available numbers and assess your expected gains and, this not being easy, is an easier part of the job. In step two you need to assess how much time & money you will need to introduce a comprehensive delivery promise solution. Understanding the quirks of your business and the data that you need to integrate & use is an absolute 101 here. My experience shows that in scaled e-commerce business using an off-the-shelf SaaS is not an option, it has to be carefully planned and tailored to the actual case.
Finally, having the estimated cost of time & money investment, you can assess whether in your case reaching out for this additional revenue justifies the investment.
Conclusions
The delivery promise is one of the most expensive features to be introduced in the e-commerce world. It requires both time & money and its complexity is nearly overwhelming. But if you implement it, the conversion raise is double-digit and that’s an opportunity nobody wants to miss. My advice would be: team up with experienced people, who know how to build it, assess your gain to cost ratio and go for it, before your competitors will.
Want to read our Case Study for Komplett? Click here!
Want to discuss with our Strategic Partnership Manager about increasing your business?
Contact Wojtek, author of this article!
