“Omni” is the Greek prefix used to indicate the 'whole' of something. For example, for those who believe in God, he is ‘omni’-scient (which means that he possesses "complete or unlimited conscience or understanding, being able to perceive everything that happens").
‘Omnichannel’ derives from the same linguistic root, and the usage of this term (to speak of companies making various different channels available for their customers to get in touch with them) is currently increasing. Consider, for example, a company that owns a website, has developed a mobile app for smartphone users, and provides phone-based service through a call center and physical stores or branches. This could be a commercial bank, a network of retail stores, a manufacturer with its own consumer stores, a telecommunications company, among many others.
As long as each customer uses a single channel to interact with this company, we say his user experience is ‘monochannel’. However, when customers use various or all of the available channels, maybe over time or even simultaneously, the sum of ‘monochannel’ user experiences results in a frustrating user experience we prefer to call ‘multichannel’.
Users expect that their interaction through each channel, represented as information he is providing to the company, should be used in his favor on all other channels. For example, if a customer starts buying something through a mobile app on his smartphone, and suddenly the app gets stuck or the smartphone’s battery runs out of energy, he expects the information he already provided through the app to be available to the customer agent that will respond to his call to the company’s call center.
Frustratingly, the absolute majority of companies are not ready to handle this kind of situations satisfactorily, because each channel is implemented and managed as an independent process inside the company.
This analysis shows us the need to share information among the various channels in order to honor the ‘omnichannel’ title. The kind of information to be shared is not limited to incomplete transactions, but should include information about the usage and customization of channels by users (which impacts user experience much more significantly when shared among channels).
For example, if you have customized your mobile banking app to display some specific banking operations (that you use the most) on its starting screen, these same operations should be available on the starting screen of the web banking machine, as well as on the banks ATMs. Hence, it makes no sense that the mobile banking app saves the users’ preferences only on the smartphone, if we want them to be available on all other channels.
Another common situation related to user interface customization happens when the battery of your smartphone runs out of energy, and your friend borrows his phone to you, to continue using the same app (which maybe needs to be installed on this second device). Once you login with your username and password, you certainly expect the app to operate with your personal preferences (which cannot be stored only on your powered off smartphone), and not with your friends personal preferences.
Hence, we conclude that it is necessary that the values for configuration options available on each channel must be shared among all available (and even future) channels, instead of being managed separately by each channel only for its own purposes. Only through such a sharing strategy we can manage the user experience so that he feels as a SINGLE customer of an ‘omnichannel’ company, and not as a different user on each channel.
Seen from the other end of the computing ‘chain’, we know that incorporating this kind of information (related to the users’ experience) into server-based mission-critical systems would result in even more complex and difficult to maintain back-end systems.
That is the reason we prefer to implement the user’s omnichannel experience through the introduction of a third, autonomous software tier, operating as a middleware amidst the path from devices the users interacts with (smartphones, websites, call centers, stores, automatic machines) and the company’s mission-critical systems operating on back-end servers.
By using a third software tier, we gain the additional advantage that the company’s mission-critical systems operating on back-end servers will never be accessed by end-user software directly. This enhances both security and scalability, as well as assures us that the introduction of new channels will run smoothly. New channels will be introduced in the future, when users adopt new technologies: at this moment in time, these new technologies will be integrated into the middle tier, without requiring any changes to the mission-critical systems.
When incomplete transactions are also stored on this intermediate software tier (while users provide needed data step by step), we also obtain the possibility that a single transaction starts and ends on different devices or channels, freeing the user from the burden of restarting his transaction from start.
Finally, all functionality made available to users through the omnichannel user experience must be available in various human languages. This holds true both for huge multinational companies operating in various countries, as well as for smaller companies who want to sell their products or services into other countries (using, for example, e-commerce). This need alerts that the ‘omnichannel’ subject is intimately related to the ‘globalization of innovation’, a subject we already handled in the article available here.