I redesigned the Cogito calls interface to allow Supervisors to more easily filter the calls their agents were taking. As part of this redesign, I drew on patterns and examples from commercial sites to specifically leverage conventions that would be familiar to the end users.
The design can also be narrowed down to a subset of functionality that is applicable to only agents.
Understand
USERS
Supervisors are typically looking at call lists to:
- Evaluate the quality of the calls and monitor what is happening at the moment
- To identify calls to use during coaching sessions with agents
Both of these tasks are hit or miss with the current filtering functionality.
In addition, these are repetitive tasks that a supervisor will want to perform more than once.
User stories included (but were not limited to):
- As a supervisor, I want to be able to identify agents who are having difficult calls while that are occurring so I can intervene and assist the agent.
- As a supervisor, I want to identify calls that have certain behaviors so I can use them as examples when coaching my team or specific agents.
- As a supervisor, I want to be able to save my filters so I can use them over and over again.
AS IS
The existing Cogito filter capability consisted of a dialog that returns results in a thin, navigation pane. This experience does not allow for dynamic filtering.
COMPARISONS
As part of the research for the To Be experience, I looked at common examples of filtering. While there are examples of integrating into tables, the most common filters are dynamic filters found on commercial sites, particularly travel and eCommerce sites.
There are certain standard conventions to be found on Amazon, BestBuy, Travelocity, and Kayak. I drew on these as inspirations for the new design.
Iterate and Design
The To Be design quickly adopted an approach of having the Calls list appear on a full page with plenty of space to indicate which behaviors were associated with each call as well as other important information.I wireframed and then prototyped several design iterations.
In addition the design introduced conventions, such as:
- A left hand expanding/collapsing filter panel
- A clear indication of which filters were selected which also allowed the user to easily clear them
- Additional filters, such as by team, quality score, and behavior
DURATION
In call centers, call length (often referred to as Handle Time) is a major focus. While call centers want agents to be friendly and treat their customers well, they also are expected to complete calls in a certain amount of time. On the flip side, agents should not rush or be rude to customers.
As a result, filtering calls to find exceptionally long calls, or exceptionally short calls, is a common desire of Supervisors.
In the As Is experience, selecting a range of duration is a clunky From and To field configuration where the user selects the number of minutes and seconds.
In the new design, I use a range selector component. At first, it looked as if this component would not be viable, because while the average call center call was approximately 8 minutes long, there are always outliers such as a 2 hour call, which would make the range component difficult to use. The solution I arrived at was to assert that the top portion of the range would represent 20min+ calls.
BEHAVIORS
Filtering behaviors was tricky. A supervisor doesn’t just want to know if an agent had a particular behavior on a call, but how bad the behavior was. For example, if an agent got notified they were speaking too quickly, but quickly corrected themselves, that was a good result. If an agent repeatedly got the notification, or received the notification and did not correct the problem, then the supervisor wants to be aware of that.
As a result, after some iteration and experimentation, I adopted a range selector component for the behavior filters as well.
