Omnichannel - Asset or Liability?

People tend to treat omnichannel as an asset and the next big thing. There is also an admission that omnichannel is somewhat an enigma. If it is an asset, it is still so much a "diamond in the rough" that retail companies, software providers, solution providers and system integrators - all are struggling hard to figure omnichannel and nail it.

Truth be told, I feel that omnichannel is not an OPPORTUNITY, it is a LIABILITY. Until someone builds a product that can provide the seamless experience that omnichannel purports to provide, I will like to plead that it is just a hype. 

I like to use a short story to explain this. A man had one watch, he was very happy looking at the shiny thing that told him time, every now and then. His experience was fantastic - all was well.

Then, we give him another watch. Now his focus moved away from using it to get time. He started focusing on why there was discrepancy between the two watches. However much we tried, even the seconds discrepancy looked egregious and nagging to him. His whole customer experience turned tardy and he wanted us to sort it out. So now instead of thanking us for giving him two watches, he was pissed that there is a few seconds' discrepancy between them. So much so that we was ready to throw both watches that we gave them and move to another guy who promised him just a single watch.

So, we now had a new challenge - how could we make both the watches so good, their alignment so smooth, their time so much in sync that the man would have a very seamless experience. 

Omnichannel is much like that - in the beginning of time, companies had retail brick and mortar stores and everyone was happy. Then this thing called "internet" showed up. There were some who said "we will sell things only through internet". Great - they were lucky. People called them Ecommerce guys, online retailers and so on. 

The original brick and mortar guys got greedy - they said "why can't we get on to internet?". Companies like Infosys, TCS, HCL jumped at this and assured the brick and mortar retailer that they could definitely help it get on internet. The retailer got on to internet thinking that he would start eating the ecommerce guy's lunch. 

The technology provider created another channel for retailer to make money. Everyone was happy. Then customer - let us call her Mary - who suddenly got exposed to the second channel started getting frustrated when the online channel of the retailer didn't recognize her despite the fact that she was spending so much in its stores. She understandably was just asking them to identify her as Mary whether she went online or she went in the store to do shopping. She started expecting world of the retailer but the experience was nowhere near that. In fact, most of the time, it seemed as if she was dealing with two different companies when in reality she was simply dealing with the two channels of retailer.

The retailer went to the technology vendor again. Vendor was lost, scratching their heads they decided to go to Guru of Gurus - Mckinsey. After much pensive introspection, Mckinsey came out with the term "multi-channel" that morphed itself into "omnichannel" with the passage of time.

Omnichannel was carved out as a huge opportunity. People created picture perfect view of omnichannel, but just on paper. There were questions on how to translate the paper view into practical technology.

At a high level, Omnichannel is merely three things:-

1) Profile persistence (of the customer)
2) Shopping cart persistence (of the customer)
3) Transaction persistence (of the customer)

If any technology vendor can make a tool or product that allows these three things to come together, we will immediately have omnichannel experience. It could be next big idea for a startup. However, it is easier said than done. Persistence means that data has to synced between different systems in almost real time manner. That means there has to be real time data integration between systems. In the absence of that, the persistence becomes batched and delayed updates to the backend system and therefore loses its meaning.

 In the absence of such tool or product, omnichannel remains as much a pipe dream for retailers, as it is a massive liability for them. Customers are unhappy that retailers don't recognize them well enough when they move from channel to channel in the realm of the same retailer.

Meanwhile, the original ecommerce guys like Amazon, Wayfair and eBay are having time of their lives - enjoying the sunshine since all they need to do is - worry and focus on one channel and make it the best.

The Three Sciences of Ecommerce

Ecommerce and Retail are exploding. In 2016, ecommerce and retail has been projected to be well over $ 1.6 trillion dollar industry. Intersection of Ecommerce and Retail and Big Data is the most happening intersection. People who are showing up at this intersection may not perhaps be fully aware but they would be considered pioneers many years from now.

Big data can make special play for many areas of the ecommerce and retail domain but there are three areas that are emerging as separate fields of full blown sciences in this space. They are Customer Science, Logistic Science and Pricing Science.

Customer science is likely to manifest itself in such huge dimensions that it is likely to touch almost every aspect of the business. One way to measure the success of this science would be to relate this science to best customer experience. The science will be all inclusive, in that, it will be super set of intriguing sciences like personalization, targeting, loyalty indices, Omni Channel experience, micro-segmentation, data driven experiences customization. All these sciences will be brought to give every customer a feeling of the store or online website created and tailored specifically for that customer. What can be better than that experience and walk away with a feeling that the specific store was opened and merchandized only for me? Nothing can top this. In essence, all these component sciences are becoming “need to have” as opposed to “nice to have” component sciences for Customer Experience. 

Since the start of the commerce in history, price has played - whether it was barter based as in the medieval times or currency based as in the modern world -  a very significant role in purchasing decisions in buying and selling trade. Therefore, it is natural that pricing science is assuming prominent and almost keystone attention. Pricing science is likely to include but not necessarily limited to price optimization, price modeling, location based pricing, “cheap NOT EQUALS good” strategy. MBA courses devote special focus on pricing. Big data analytics and predictive modeling are likely to give this special impetus.

Logistic science is again an all-encompassing term that includes Predictive Inventory provisioning, real time inventory and supply chain visibility, optimized shipping, supply chain analytics, feedback loop, cost optimization, demand prediction modeling and single view of demand. For those who live and breathe logistics in retail and ecommerce world, it is always clear that this is the space where we can get maximum cost optimization. This “taking out the cost” from operational expenses is the best optimization that a Etailer can do. It is also cheapest amongst all other ways of bringing down Operational expenses.

People can argue about Omni-Channel being the fourth science – however, I refuse to add that to these three majors. I had rather club omni-channel as part of customer science since, in the absence of customer experience, omni channel is just bunch of technologies designed to exist and operate in cohesive manner. It is customer science which provides the real value for omni-channel.

Though the price wars, over-store’ing in US as well as burgeoning foreign (read, Chinese) debt is going to make life brutal for retailers and ecommerce companies, it is also going to be the most happening space in coming years.  

A Centralized Team aka “The Only Grocery Store in the Town”

What are tenets of a centralized team? First off, what does that even mean? Centralized teams are those that provide “Horizontal support” - implies that the team is not providing support to one specific domain or parts of business, instead it focuses on supporting all teams in a very generic manner. The support then takes the shape of becoming a service as opposed to being a domain specialized niche service.

There are pros and cons of moving away from being a niche service provider to being a generic service provider. One obvious upside is that the team develops a “cookie-cutter” type of solution and uses the same solution to service any and every line of business. The downside is that this is detrimental to the team members themselves. They lose the touch to understand nuances of each domain. Their expertise is diluted to a point that the service would devolve into a commoditized service.   

Typically, in most companies of reasonable sizes, teams such as network operations, database administration, system and storage administration and data center have the opportunity to assume the role of central teams and provide horizontal support.

Why are such teams formed and kept as central teams? There are multiple reasons for that. For one, a central team has a critical mass so it can be administrated as a team as opposed to “onezy-twozies” who are existing as differently skilled persons in a team of largely varying skilled resources. Then there is question of performance appraisals - this becomes easier since you can compare “apples-to-apples”. The career paths are clear – you can have a clear career path within a team of 10-15 system administrators as opposed to one system administrator residing in a team of developers. This is the high order bit of why central teams are needed.

If we want to double click on details then, from logistic standpoint as well, it becomes easier – you can restrict superuser passwords, sysdba, system passwords etc within the team and don’t have to share it across multiple teams and lose the notion of password itself. Finally, best practices are very well shared, standards are set and implemented. SLAs are drawn and people have set expectations on the type of “customer experience” for a given task.

When we combined the DBA teams under one umbrella in 2009 – after trying for many years – I realized that there were more leaders, especially those whose DBAs were being “snatched away” from them, who wanted this model to fail than those who wanted to see it successful. So there was a political realm to the whole implementation. While one part of the management chain wanted this to happen, the other part was doing simply window dressing by playing along in meetings and using every miss by central team to highlight the fact that it was a failed implementation.

Then there were DBAs who were behaving as if they have been uprooted from their comfort zone and were struggling to find their roots in the new land. They were still attached with umbilical cords with their previous organizations and wanted to restore the status quo. This behavior can largely be explained as a sole fish or few fishes falling into a bigger pond and being scared, loaded with skepticism of how things will pan out.

As is fairly apparent by now, there were struggles, external as well internal, to nuke the central team even as we had just started forming up.

Most of the external fears and misconceptions were very reasonable – for example, will the service levels dip, will the team get same focused support from their earlier DBA or will that DBA’s effort spread thin across multiple other domains, will team get new DBA to interact every time so they have to end up teaching  from scratch, the idiosyncrasies of their domain to the new DBA. However, it would be naive to say all of the opposition to move towards central team was based on above reasons only - there could be the omni-present sense of "loss of territory" coming into play as well in that opposing behavior

While all this was happening, I became convinced and somewhat determined that if we have to be successful as a central team, we need to behave as follows:-

Imagine that you are the only grocery store in the town. By being the only place where people can turn to for their groceries or go hungry, it becomes important that following tenets be followed:-

• No Customer Turned back – we can’t turn back any partner team for whatever reason – least of all due to things being out of stock or not enough salesperson to provide customer the service (akin to lack of bandwidth).
• Queue system established – we will have to establish a queue system that gives a sense to the customer when will he or she gets the attention of salesperson.
• Length of queue (or wait period before service) is reasonable
• Service is provided with quality
• Service is provided with a smile (because you love to do business with friends)

Luckily, we had a very mature leadership team in place. We had discussions within leadership team that we will do our utmost to make this successful. We ensured that we would provide the best service to all our partner teams including the new teams that we absorbed into our teams. This was more of journey. Over a period of consistent engagement with us, the “noise” generated by external partner almost died down and was replaced by a sense of “we are better off now”.

There will always be people who for their personal interests will go against the grain of centralization. At some point, it is better to make the right call on those. There have also been team members who came from external teams who have turned out to be exceedingly better than our existing team members.

What happens if you fail to follow the tenets?

Most of the times, central teams walk away with the arrogance and impression that people don’t have choices and they will do whatever we tell them. When that happens, customer teams tend to behave somewhat analogous to flows of rivers. Like a river figures out path of least resistance and eventual flow, a partner team not getting required service from the central team tends to eventually figure out how to find that support. They will devise a way to get that service – in most of the cases, the solution will involve seeking help from teams outside of central team, forming their own team, engaging with an external vendor to outsource their support needs. All this leads to undermining and ultimately destroying central team, so it is always in the best interest of the central team to behave like the "only Grocery Store in the town" and follow the tenets mentioned earlier.