Collect In-Store vs Delivered To Store

Just thought of bringing out the difference between these two types of delivery options. While in both cases the customer has to go to a store and pick-up the goods ordered on the website, the back end handling of the order is completely different. The details in this article might be of very little use to business users as they might be already used to the concept however this can help development teams understand the difference in both and the associated requirements. 

Deliver To Store is just like delivering to any other address. The goods ordered are delivered  from the central  warehouse to the retailer's store selected by the customer. The customer enters payment information on the website and when the goods are dispatched the OMS settles the orders for the web channel. This option is designed to offer convenient pick up for the customer from a nearby location. Providing this option might require integration with GoogleMaps / Bing Maps and the details of retailers store. Back end processing mostly remains the same unless the business team decides to ship orders alongside regular store inventory instead of the logistic network / process used for fulfilment of orders. Once the order is shipped to the store, an email / a SMS is sent to the customer and the customer can pick up the order by visiting the store. 

Pick-up In-store is also known as "Reserve N Collect". Unlike the previous option, when the customer places the order on the website, payment information is not taken and the customer is given a confirmation of reservation indicating the time before which they need top pick up the goods.. Inventory check is done against the "back inventory" of the item in the store selected by the customer and a message is sent to the in-store team to pick and reserve the item. Payment is taken by the store when the customer collects the item,  and this transaction is booked against store's PNL account. It depends on the retailer to show the order on the web under Order history. No shipping of physical codes is done. This option is one of the steps towards true multi channel implementation.    

The complex area is to figure a workable solution when the retailer has in-store system operated in-house where as the website is a SaaS offering on revenue share basis. However this problem is for the business team to solve and is mostly contractual and might have limited impact on the implementation.

-AV

Mobile Kiosk Using Tablets - Contd...

This is how I would visualize overall using a tablet. As you see its not very different than a commerce website. Also not all components are shown here. This is just a high level representation of blocks of functionality. 

Some important things to note.

1. Address validation system is required only when you are trying to ship a product to the customer.
2. Not all systems and interfaces are shown here. Only a few widely used system are shown. Reporting from OMS and Financial Reconciliation are important but mainly on OMS and hence omitted. 
3. There would normally be an ESB for handling all external interfaces which I have not shown here.  

So the things that make it different from website is the App itself and the communication with the commerce engine and payment gateway. The commerce engine needs to expose APIs, preferably rest, which the App can call to get the required information and create baskets and orders.  

In the previous article there were a few areas that were required for doing the chip & pin Integration. Below are a list of features and considerations that can be built into the App and Commerce Engine when planning for first release. These are just my views based on the use cases I have seen so far and are by no means  complete.

Registration 

For unassisted in-store the user should be able to do it himself, else for assisted version it should a simple form which does not ask to much personal information but just creates an Id and then sends and email to the customer to  where he can go home and do the rest of the job. However registration should be not in the checkout process like websites. It is also useful to capture information about the customer and hence advisable to have as an optional functionality at the end of checkout for sure. 

Scan and Search
A very frequent use case is to not find the right size, colour or variant of the product that you are looking for but find a very similar product in store. So the user picks up the product on the shelf and walks to the customer desk to show what they have got and what he wants for easy explanation. In such cases attaching a bar code reader which can scan and bring back similar results is very handy to avoid delays in front of the customer.

Reviews, Ratings and Recommendations.

Very good features to have in-store, will keep the customer engaged for a longer time and also increase the chance of the customer coming back knowing they can always make an educated decision for buying a product. If the customer's email is captured it is good to ask for review of product purchased by sending the link for writing reviews in an email. Of course this is assuming the retailer also has a transaction website. We have assumed that the reviews service provider can do a hosted review with Apps as well. However this depends on the provider and hence needs to be verified before implementation.

Product Videos
Product videos demonstrating the product features can add a great value for the in-store user. Trailers for the new film or album can also enhance the in-store experience. For audio music we already have a hot spot where the user can jack up head phones and can listen to the song before buying. On demand video trailers for films and games can be done in a similar way.  Have not shown separate content providers for MVG industry and have assumed all data coming through PIM for simplicity.

Store inventory visibility

for a full blown multi channel this feature is unavoidable. However it is more of the commerce engine capability that decides this and the ability of other systems to expose store level inventory.   

No Preorders, No digital downloads but Yes Back Orders

Pre-orders and digital downloads do make sense for a few use cases of in-store ordering but they add considerable complexity in both payments and order handling and hence should try to accommodate in a  future release. Back orders on the other hand are one of the most important uses cases for in-store ordering where the item has gone out of stock and the customer is standing ready to pay for it and hence should ideally be considered. 

Existing Customer Order Association

If a customer already has an account with the retailer and is buying / ordering in-store, it makes sense a provide the functionality to associate the new order with his existing account. However this is a good to have functionality and can wait for future releases. Apart from just making it easier for the customer this also give good data for analysis of customer behaviour.

Once you have these things in place, the next step is to get the mobile phone app out. It can be a little different which I can write about next time.


-AV