MULTI & OMNI CHANNEL

NICE InContact

the problem

OMNI was being considered a must have feature in the contact center space despite there being no clear definition of what OMNI was. Some were calling OMNI the ability to turn a phone call into a video chat while others said it was the ability to handle multiple contacts at once, and others still just renamed an existing product as OMNI. But what is OMNI to inContact, and how does it fill our customers needs? Is OMNI more than a buzzword?

Playing Leap Frog not Catch up

Our customer research showed one portion of the industry wanted the to give better customer service, or to have a first call resolution. The others wanted to move through as many customers as quickly as possible, more of a churn and burn mentality. We decided that we needed more than what anyone was calling OMNI. More importantly we needed another and all together different thing that we later would call MULTI.

My Role

I was the lead UX Designer on this project. I did user research, analysis, testing, wire-framing, prototyping, and generated the final designs and requirements. Thought-out this project, I also collaborated with project managers, developers and data analysts.

Key Results

6 months

of research & design

25 +

end user tests

1

major release

< 1,000

sticky notes used

Agent Personas

We preformed market and competitive research to investigate OMNI, what others were doing, where it was successful and where it wasn’t. Utilizing this data with the learnings from the market appetite we defined MULTI and OMNI and added them to our agent personas to better communicate out and up how this change would affect agents.

MULTI: One agent can handle more than one customer at the same time across any channel (voice, text, chat, social, video, etc.).

ONMI: One agent can handle any customer channel agnostically (one customer across any channel, simultaneously).

As I developed the interactions and designs I continually used these personas and definitions as guid posts.

Early Sketches & White Boarding

Working with our Directors of UX and Product Management, we did a lot of ideation sessions around what we wanted the functionality to be and how it might work. We did multiple white boarding and sketching sessions.

Workshops

At the beginning of the project I ran a series of ideation workshops with the UX team as well as other key stakeholders across the company. 

Running these workshops early on in the process was integral to getting a jump start on the project as it would be a large overhaul not only to our agent application but also to the backend services. Throughout these workshops we relied on our initial research and our definitions for MULTI & OMNI Channel to keep us on track.

These workshops primarily took the form a 10x10 exercise where all participants would sketch as many ideas as they could in 10 min. Then after sharing your ideas with the group there would be another 10 min of sketching, repeating as many times as necessary/useful.

Early Design Exploration

There were some early design explorations for the VP heading up this project to help him put his ideas down on paper.

This exercise also helped to pinpoint some early usability issues that happen when there is on overabundance of cognitive load on users.

Wireframes

After gathering and reviewing all the workshop materials I started making wireframes. These wireframes were used in internal testing to help validate findings from the workshop and to test different interaction patters to accomplish out Multi and Omni contact handling vision.

We went through many iterations to find the best way to help agents to not loose track of how many contacts and what type of contacts while also not overwhelming cognitive load.

User Journey FLOW

During early wireframe testing I mapped out a journey that included all of the main interaction needs of the agents. This journey incorporated both OMNI and MULTI contact handling and was my guide for building out the interactive prototype that was used for user testing. This also helped us tell the story and communicate changes and milestones to the executive team and other stake holders.

UI DESIGNS

After testing for interaction fluidity in the wireframes I started to build out the main screens needed for building the journey as a prototype in Adobe XD. I then created screens that showed the limits of what the app needed to handle for the largest amounts of contacts possible.

Prototype

Just before moving into development I took the designs and made a functioning prototype. I took this prototype to our yearly users conference to test the flow we created. This allowed us to find any problems we missed and resolve them before development.

USABILITY TESTING

At the conferance I did moderated, in person testing. I tested the prototype against a scripted flow and tracked where success was and was not as well as any feedback during the test. I also recorded the tests so that I could verify all findings from my notes against the recording for confirming any issues found.

We did uncover 1 usability issue with how switching from phone to messaging was initiated. This issue was indicated by a majority of the users tested. Because this was found I was able to get the changes made to the designs and requirements before development started.

FINAL DESIGNS

Examples of the final designs for the feature showcasing both the Omni-Channel and the Multi-Channel.

DOCUMENTATION

Examples of the Documentation that was delivered to R&D.

RESULTS &
TAKEAWAYS

the problem we had

OMNI was being considered a must have feature in the contact center space despite there being no clear definition of what OMNI was. Some were calling OMNI the ability to turn a phone call into a video chat while others said it was the ability to handle multiple contacts at once, and others still just renamed an existing product as OMNI. But what is OMNI to inContact, and how does it fill our customers needs? Is OMNI more than a buzzword?

Playing Leap Frog not Catch up

Our customer research showed one portion of the industry wanted the to give better customer service, or to have a first call resolution. The others wanted to move through as many customers as quickly as possible, more of a churn and burn mentality. We decided that we needed more than what anyone was calling OMNI. More importantly we needed another and all together different thing that we later would call MULTI.

Takeaways

By not just closing the gap but actually leapfrogging the competition we found ourselves securely in the top spot in our magic quadrant. This project also contributed to the successful merger/ sale to NICE.

It was sot an easy project. From inception to release it was about 1 whole year. At the time we were doing 3 major releases a year, and this project took 2 releases to do right. We found items that could be put into the first release and focussed on those first. But in the end going in for the long game paid off.

Key Results

6 months

of research & design

25 +

end user tests

1

major release

< 1,000

sticky notes used

All Content © Copyright 2012-2025 Steven Jeppesen