Omni-channel, Schmomni-channel

The buzzword in Customer Service and Contact Centers over the past few years has been omni-channel. Omni-channel supposedly stands for a singular, high-quality personalized experience that a customer has with a brand that occurs regardless of where or what device the customer is using to get service. But in speaking with several industry analysts over the past week, we heard “omni-channel, schmomni-channel,” meaning the term isn’t as broadly understood as many would think. There is confusion and a very different definition by businesses around the world that use the term vs. how vendors use it!

Let’s think a little bit about the history of customer service. It started with phone calls. Then service evolved to “multi-channel,” which really ended up to be 1 or 2 channels, like email and chat, that a business would implement. These channels acted independently, and for 90% of businesses today, still do. The channels, organizations, and data are captured nicely and neatly, but IN SILOS! This is bad. Silos mean a disjointed experience for the customer, a critical asset to any company.

This reminds me of a personal experience I had with a financial services institution (not an Avaya customer by the way) after they changed a recurring payment without any notification, nor my approval. I only discovered what happened when I was notified of a late payment because the full amount had not been submitted. I called and they can’t tell me how or why this change was made because “only customer service, not billing, has access to that information.”

What I experienced happens all too often, and represents a major problem in customer service today. Customers have one experience on the web, a different one on the phone or in-person, and yet another on their mobile device. Ultimately this reflects poorly on the brand.

Almost every vendor of customer service technology has declared that their solution delivers an open, flexible, omni-channel experience, but in reality, it’s been a bit of a stretch. We haven’t connected all the piece parts to make it possible—all data sources (from all vendors) to one repository, in one view, with an agent and customer experience that provides the full perspective. Perhaps the obvious question is: why has it been a stretch? I think the answer has to do with square pegs and round holes.

So I hereby proclaim a better term: multi-touch, meaning multiple touch points. It’s a unified operation where data is shared, delivering a consistent brand experience across all touch points—phone, mobile web page, mobile app, desktop, social media, and in the branch. Multi-touch is all about differentiation in a highly competitive market.

Multi-touch also delivers a new frame of reference: for the customer, for the agent and for the business. But it’s a frame of reference that needs to build on our existing investments and knowledge—customers aren’t going to replace their devices, and businesses aren’t going to throw out their tested solutions. That means any solutions must be:

  • Bulletproof. Businesses will not put their critical customer contact capabilities in jeopardy—there is far too much at stake. So a multi-touch architecture needs to be proven reliable—if the foundation can’t handle voice at five 9s, the move to multi-touch is unlikely to be a smooth one.
  • Flexible. Multi-touch is a journey for most enterprises. They want to build, learn and grow, not take a swan dive off the high board. So a platform that allows migration at the enterprise’s pace with no disruption is essential.
  • Complete. Enterprises won’t turn to multi-touch on a dime, but they do need to know that they have a solution that will get them to the promised land: a solution that will truly change the way they offer customer service, not just at a surface level, but at a level that make that service a bona fide part of their brand.

Multi-touch delivers the same brand experience across all channels, consistently. A consistent experience is accomplished when different groups share information and data freely and in real time throughout the entire organization. It is no longer about taking information and building a routing rule, it is about taking the information and leveraging it to engage the best resources and up-to-date information to ensure the best customer experience—implement strategies not rules! In doing so, businesses are better able to adjust and make decisions faster, ultimately leading to a better customer experience.

At the upcoming IAUG, I’m excited about the announcements that will continue the conversation Avaya started at Enterprise Connect in March on how our solutions can help companies win the customer experience battle. I look forward to spending several days with our customers, listening to their needs, and getting their opinions on multi-touch solutions and the differences they can make for their businesses and the experiences they deliver to their customers.

Related Articles:

Avaya and IAUG: Coming Together for a Better User Group Experience

Marilyn ShuckMarilyn Shuck serves as a Director on the IAUG Board, president of the Puget Sound Avaya Users Group, and as a UC Engineer at the University of Washington.



The combination of the Avaya Technology Forum (ATF) and the International Avaya Users Group (IAUG) flagship event, Avaya ENGAGE, is generating a lot of buzz. As IAUG members, it’s exciting for us because we’ll be there as Avaya is announcing new products and have better access to Avaya. We’re also looking forward to bringing in more technical expertise, session choice, and potential new members to IAUG.

In the past, ATF was held in February or March, and Avaya ENGAGE was in June. By the time we assembled for Avaya ENGAGE, new product lines would have been out for several months. Now, we’ll get to hear the latest announcements. Since we’re partnering with Avaya, we’ll have much more access to them, getting our questions answered, getting trained, and seeing the new products in action.

We’re also able to offer so many more sessions, some with more technical expertise. ATF has historically been a technical conference, and our IAUG attendees will have a choice of breakout sessions that will add a new dimension to the education they’ll already be receiving.

It also makes sense to hold both of these events under one umbrella. There’s some overlap between ATF attendees and Avaya ENGAGE attendees, and in organizations where travel budgets are tight or where the same person is a technical support specialist and a user, you no longer have to choose which event to attend.

Additionally, we’re excited about the possibility of introducing new members to IAUG. Some ATF attendees may not have known about our existence, but now not only will they have the chance to learn more about us but they can network with us. We can continue to share learning opportunities and even bring a whole new quality of technical users to IAUG.

Make no mistake, the foundation of the event has not changed. This is still planned with the Avaya customer in mind. However, it signals our deepening relationship by aligning all customer events.

This is going to be one of those cases where what happens in Las Vegas won’t stay in Vegas. Avaya and IAUG are aligning, and it’s going to provide valuable education and opportunities for customers, IAUG members, partners, and Avaya. The benefits of attending will resonate throughout your organization, so plan to join us in February to learn, network, and return full of ways to make the most of your Avaya implementations. You can learn more at


Advanced Techniques for Writing Avaya Breeze Snap-ins Using Engagement Designer—Part Four

Welcome to the fourth in my series of videos addressing some of the more advanced Avaya Breeze™ techniques. In Part One I showed you how to catch and process errors inside a Breeze Snap-in. In Part Two I addressed Breeze Connectors. In Part Three I added multimodal communications and parallel gateways. Here in Part four, I show you how to add JavaScript functions to Breeze expressions and data processing.

To start viewing my videos from the beginning watch the introductory series.

Continue with the advanced series:

Part 1: Error Processing and Boundary Events
Part 2: Breeze Connectors
Part 3: SMS Text, Email, and Parallel Gateways
Part 4: Adding JavaScript Functions to Snap-ins

Andrew Prokop is the Director of Vertical Industries at Arrow Systems Integration. Andrew is an active blogger and his widely-read blog, SIP Adventures, discusses every imaginable topic in the world of unified communications. Follow Andrew on Twitter at @ajprokop, and read his blog, SIP Adventures.

An Exploration of End-to-End Network Segmentation Part III: Automatic Elasticity

Imagine for a moment: you’re connected to a network via a piece of string. You perform your work, you wind down for the day and you disconnect from the network. When you leave the office, that piece of string stays behind, lying exactly where you last connected—exposed. Wouldn’t you know … the very next person to walk past your office after you leave is a hacker or a malicious employee (remember many attacks start from inside your network) who can now gain access to your open, vulnerable network via your left behind string (for techies, the static VLAN port configuration exposes that service). We all know what happens with the pull of just one thread … things unravel.

Now imagine this same scenario, but instead of your network core being connected by a string, it looks like a ball of rubber bands. When you connect to your network, a rubber band attaches to you, establishing your connection. Same as before, you disconnect when you finish your work day. The difference here is that your rubber band automatically recoils back to the network core (the rubber ball), where it safely rests until you or another user/device reconnects. If a hacker walks by where you’ve just been working, your node (or network connection) is no longer accessible. Similar to native stealth, this automatic elasticity means attackers can’t hack what they can’t connect to—therefore they can’t penetrate your network without the necessary level of authentication (certificates highly recommended).

This is the premise of automatic elasticity—the third core component of end-to-end segmentation (if you missed parts I and II of this series, be sure to catch up).

The Necessity of Elasticity

So, would you rather your network be a bundle of static, inflexible and unsecure strings that anyone can pull at? Or a dynamic, agile and secure elastic that extends to deliver services and retracts to prevent hackers from seeing and touching it?

Automatic elasticity enables businesses to stretch their network services (contained in hyper-segments) to the edge of the network, only as required and only for the duration of a specific application session. As applications terminate (or end-point devices close down or disconnect), those networking services retract from the edge. It’s as simple as that.

Stretching and retracting virtual services in this manner, however, becomes exceedingly difficult for companies operating in a static configuration environment. This is what ultimately led to Target’s massive data breach in 2013. A port had been statically configured to the company’s HVAC system—it did not retract—allowing a hacker to physically gain access to the entire network through that segment. From there, the hacker was able to conduct IP topology and trace IP routes to find the server they wanted and get the information they were after.

In this case, the mistake Target made was that it had no sophisticated methodologies in place to authenticate an end user or device before extending its HVAC port. It remained static, exposed and vulnerable to an attack, which eventually happened.

Without end-to-end segmentation, the only way businesses can truly extend their virtual services is to manually configure each node to simulate their desired level of elasticity. In this case, each node would have to be manually configured to stretch, and then that configuration would have to be removed as soon as the service was finished being used. Just imagine how time-consuming and painstaking this process would be on a large scale. This is illogical.

The bottom line is that automatic elasticity drastically reduces network exposure, and also transforms internal productivity and collaboration. A network access port is no longer statically mapped to a given service or user. Today it can be you, tomorrow a video surveillance camera, the next day a contractor. Agility, flexibility, security all delivered! With the ability to expedite provisioning and dynamically extend services to authenticated end-users or devices, an employee working across the country can quickly gain access to a system to complete a task. If you’re running late to a meeting, you can be authorized to temporarily gain access to a printer in-office to ensure you stay on schedule. The use cases for automatic elasticity are infinite and truly game-changing for businesses today.

In the End

While some still feel comfortable operating within legacy limitations, what’s important is that you now understand current industry standards have evolved to meet today’s next-generation network demands and security needs—something that end-to-end segmentation does flawlessly.

We’re excited to be able to help companies finally deploy end-to-end segmentation without resource-intensive or costly roadblocks. An end-to-end segmentation solution built on hyper-segmentation, native stealth and automatic elasticity is key. To succeed, you need all three of these complementary capabilities. All three share the common goal of maximizing network security. However, they contribute towards this goal in distinctly different yet necessary ways to substantially reduce your business risk exposure with the ever increasing cyber security threats we see and hear about globally.