Over the years, my background in IT marketing and product management has brought me close to the subject of how a software should be extended to new channels. I can recall at least five occasions on which I’ve been involved with spec’cing channel support in the past 15-odd years:
- ERP in Branch Office in the mid ’90s
- Internet ERP in the late ’90s
- Electronic Bill Payment in the mid ’00s
- Mobile Banking in the late ’00s, and
- Social Media Sales and Customer Support in the last one year.
On each occasion, the initial expectation of the market was identical: The software must do everything on the new channel that it did on all the old channels. Attribute it to hype or consultants sitting in ivory towers, but a software gained legitimacy to its claim of supporting a new channel only when it permitted every step of every business process to happen on the new channel. Let me call this the “multichannel support” mindset.
In each instance, it took a few years for the market to appreciate that each channel had its own strengths and accept that there was nothing wrong if the software only supported those features that played up to the strength of the respective channel.
Since Internet was a great way to extend an ERP to customers, suppliers and partners without requiring specialized hardware or leased lines, it became okay for ERPs to only support marketing, sales and channel processes via the web to begin with.
Soon thereafter, the market recognized that there was no point in making the software support a certain feature on a certain channel when the corresponding business process wasn’t likely to happen on that channel. Out went “web-enabled MRP” from an ERP’s production module.
It took a little while longer for companies to understand that their internal and external stakeholders didn’t think channels as much as overall user experience.
At this stage, vendors responded by splitting a single business process across multiple channels in such a way that it leveraged the respective strengths of each channel, delivered the best possible UX, and all channel hops were natural. I call this “omnichannel support”.
This is similar to “interconnected retail”, which is the term used by Home Depot’s CEO Frank Blake in Fortune to describe “as seamless an experience as possible for you as a consumer, whether you’re interacting online or in the store.”
To take “buy mortgage product” as an indicative business process in the context of a retail bank, omnichannel would translate to the following steps on different channels:
- Mobile: Get tipped off to a new low-interest mortgage product from a friend on social media
- Desktop: Search online for this product and visit the bank’s website to find out more about it
- Branch: Learn about the nuances of this product from a branch executive, fill up forms to apply for it, and submit the required documents.
As I’d highlighted in Jumping On The Omnichannel Banking Bandwagon, multichannel banking is neither necessary nor feasible in most cases and omnichannel banking is the practical way forward for most banks. I recently noticed that omnichannel commerce also fits in nicely with the new buyer journey postulated by McKinsey.
The 3 phases of the new consumer journey per @McKinsey happen on 3 different channels. Ergo #OmnichannelCommerce. http://t.co/ZYKfanLoHj
— Ketharaman Swaminathan (@s_ketharaman) November 11, 2013
Then, in the final stage, take exclusive features that are available only on one channel and not on the others. Once all key processes are omnichannel-enabled, I envisage the next phase to cover functionality that leverages the exclusive features of a given channel e.g. Mobile Remote Deposit Capture and ATM Driving Directions. These two features rely on camera, GPS, accelerometer and other features available on a smartphone but not on a desktop. For the lack of a better expression, I’m calling this the “omniplus channel commerce” phase for now.