The customer is evolving. Mobile has trained us to expect seamless digital experiences, even as the number of channels continues to grow. The result is that we now expect organizations of all types and sizes to communicate on the channels and at the times we prefer – and those preferences might vary, depending on whether it’s our bank or an airline we’re traveling with and the urgency of the message.
The answer, or at least part of it, is multichannel failover. This means that if a customer does not respond on the channel you’ve used to reach them – because they don’t currently have a data connection, because their favorite social media or chat app is down at that moment, or simply because they don’t want to be reached that way – it will move through the various channels, in that individual’s order of preference, to make sure any important message is received and consumed.
Finding the right use cases for failover
A key word here is “important.” Automated failover is best deployed for critical or high-priority messages, such as sending one-time passwords or notifying a bank customer about suspicious activity on their account.
Failover is a powerful tool, but don’t be tempted to overuse it. Not all communications need to go through this process: a marketing message or coupon, for example, doesn’t need to be escalated and rerouted through multiple channels.
If the enterprise does apply failover to every message, reaching unresponsive users on every available channel, this can result in users feeling like they’re being spammed and potentially even opting out or complaining.
Of course, all the usual rules of messaging apply when using multichannel failover. Make sure anything sent is relevant information – just because you can access a consumer via three or four different channels, you shouldn’t be using those to send them information that they have not asked for or do not need.
Ensuring best practice with failover
Because it’s API-driven, automated failover is customizable to the particular needs of any use case. Rules can be set on what causes failover to trigger: for example, whether it’s based on the recipient reading or responding, and how long before moving onto the next most-appropriate channel.
The hierarchy of channels can be decided entirely by user preference – set up at the front-end to let them choose their preferences – or enterprises can prioritize certain channels, based on message urgency, historical user response patterns, or availability of a data connection.
It’s up to the enterprise to decide how exactly they want to set up the failover scenario, but there are best practices. When it comes to the time threshold, for example, before failing over to the next channel, enterprises should wait at least 10-15 seconds for a user to respond. Thinking more long-term, it might be worth setting a limit of unsuccessful attempts on a particular channel so that if a customer doesn’t respond multiple times, they’re not contacted through that channel in the future.
As digital communications become more complex and interconnected, random and uncoordinated engagement tactics will no longer be effective. Developers and the intelligent enterprises that they serve will need automated failover capability that can orchestrate and optimize message delivery across a growing range of channels.
Want to learn how you can meet demand for intelligent, responsive communications that streamline customer support, boost satisfaction, and honor user preferences? Read The Critical Role of CPaaS in Reaching Customers on Their Channels of Choice; Understanding the Complexity of Messaging Channels and Digital Engagement; and join our Community.