“Important” Section For a Call Manager in CRM For Sales

Overview

My main project at Action is an internal CRM for telephone sales. It is a large system which I have been working on for the fourth year with a large team. The system includes many modules, among them

sales;
sales management and configuration;
supervising salespeople;
customer support;
financial management;
and many others.

The case I will talk about below is a block update for sales managers. Our CRM is called ERM (Edinoe Rabochee Mesto or Unified Workspace), which is the name I will use from now on.

Problem

Some groups of sales managers show poor sales results compared to other groups in similar conditions.

Goal

Understand the cause or causes of low efficiency.
Increase sales in underperforming groups.

Analysis

I started by analysing the data. The PM prepared a table in which data on the manager's activities during the day were collected. This table covered 19 groups, totalling about 220 managers.

To make it easier for me to work, I converted the data into a graph:

The most important part of a manager's job is talking to the client (the green part). The schedule shows that, on average, managers talk for 1.5 hours a day, while the daily goal is 3 hours. On average, managers talk exactly half as much in a day!

It is also clear from the graph that it takes the most time for managers to prepare the call and the operation afterwards. So these are the first candidates for detailed analysis and improvement.

Assumption. Low sales may be the result of a short conversation time with customers. If we’ll free managers from the manual routine, it will increase the time for conversations and sales will rise.

Process

Structure of a call

Before we continue, we need to tell you how a call works. By a call within a company we mean contact with a customer via telephone call. The life cycle of a call consists of the following parts:

A new client is loaded into the ERM interface. The call card with the loaded client data is opened and the script for the call is opened.
Preparing for call. Manager studies client's communication history, who called last time, how the conversation ended. What is the reason for the call - a new sale or re-subscription. What product we are selling or re-subscribing, for how long do we need to re-subscribe. Or what kind of debt the client has, when was the last payment, etc. Depending on the purpose of the call, different information is required.
Manager calls the client, conducts conversation according to the script, reacts to the client's comments, looks through detailed information of the client, presents the product, convinces to buy.
Making an order. If the client agrees to buy, the manager places the order and sends the client an invoice for payment.
Call completion. Depending on how the call ended, the manager displays the result of the call and sets a date for the next one. When the call is over, a new call is dropped.

All these stages merge into three group:

I decided to concentrate my work on preparation for the call. Preparation is the most important part. The better the manager prepares, the better the call will go. At the time of the redesign, managers from all sales areas were already working in ERM, and we knew all the basic scenarios. Preparing for a call can be divided into three stages:

Study of communication history. How often the client was called. What was the conversation about and how did the previous call end. What number was called. How to contact the client.
Understand the purpose of the call. Selling a new product? Renewing a subscription? Offer great deals? Invite them to an online conference? Calling outstanding invoices? Calling accounts receivable? And so on.
Find out detailed information on the purpose of the call. Which products do we extend? How many days left until the end of the subscription? Exactly which orders are outstanding? What is the overdue period? What is the amount owed? And so on.

To answer these questions we need to know the client well. The data on the history of communication has already been displayed on the first screen. The rest of the data was hidden in the depths of the client's card in various sections. For example, if you call about unpaid invoices you need to go to the section with orders, filter the table by orders and find the unpaid ones. If the client has money on their account, go to the payment tab.

Current implementation

In current implementation this process looks like this. The first screen looks like this:

The left half is the call card. It shows the client, his position, contacts, what company he works for, his communication history. On the right side is a script. It tells us why we are calling and what to say during the call.

If you need other information before the call, you have to open the customer card and go through the tabs in search of the right information. The opening of each tab is accompanied by a small download of data, which adds up to a noticeable delay.

To understand the call preparation process in detail, I did two things:

Conducted interviews with managers, asking them how the preparation goes.
Observed the users on Skype through a screencast or watched broadcast videos.

As a result, I had scenarios for the preparation of the call.

Try 1. Ideation

The first idea was simple — to simplify the search for information. I wanted to do this in two ways. The first was to remove the duplication of information. In the current implementation, some of the information about the user is in the Call Card. And the same information is in the client card.

My idea was to get rid of the calling card altogether, and regroup the information in the client card by combining some groups and bringing the more important information to the forefront.

I started with pencil sketches in a notebook.

After the layouts, started to draw something. Sticking to the idea that a callout card was unnecessary. The very first sketch came out like this.

After the layouts, started to draw something. Sticking to the idea that a callout card was unnecessary. The very first sketch came out like this.

The solution isn't working, but it's what's needed to get started. Went further. Over several iterations, went back to the call card option, as I was unable to find a solution that could work without it.

Based on the last sketch, sketched out the main screens for the prototype:

It came out too colourful.

Since this interface will be in front of you for eight hours at a time, in the second approach I removed the colours and superfluous icons, made everything more relaxed and tried on the new style on the main screens.

Despite all these sketches there was still one problem. Apart from cosmetic changes, nothing had changed. It was ERM 1.0 with all the problems, only with a different skin. Same call card, same script, zero practical changes.

Nevertheless, I assembled these layouts into a prototype and tested two scenarios on five managers. I recorded all observations.

I took a break to clear my head and switched to another project. A couple of days later, in discussion with a colleague, we came up with a simple idea. What if we collected *all* the information we need in a concise form in one place? Whatever the duplication, the main thing is to have everything in one place at our fingertips. I think we're on to something important it was aha moment.

In literally 15 minutes I put together a draft of this unit. As the users of the product and I work in the same company, I had no trouble finding a manager for the test. I called the sales manager on Skype to get the end user's opinion of the new block.

The manager replied that this unit would be very useful in preparing for the call. He literally said "The idea is fire!". I went to the salesman with this sketch. The vendor also approved of the idea. I prepared a presentation of the idea and a prototype of the ERM. We had a meeting with the customers and the CEO.

With the confidence that we are doing well, I did the presentation. But the idea got screwed up. Yes, we added importance, but where did the script go? The idea was very, very raw.

Try 1. Results

As a result of the first stage, we have the concept of the Important. Even though the presentation failed, we had a good idea, which we started to develop.

Try 2. Completely abandoning the calling card and improve of Important

The main thing is that the idea of an important one was not taken away. It gave me strength - I had found something of value. I started to think further. I worked out on paper, how the page with the script might look, but without the call-card.

Since we concentrate all the important information in one block, the only thing we need from the call card is call management. I put this functionality into a small widget, winning half a screen of space for customer information.

Doing away with the call card is a bold architectural decision. It's not just a front-end design change, there's a serious change in the technical processes behind issuing a new call and tying it to the client card and script opening.

So I needed to discuss this approach with the developer. In order not to spend a lot of time working through a possibly non-working concept in detail, I sketched out warframes of the idea in 10 minutes and arranged a meeting with the development team. At the meeting, I showed a prototype of these mock-ups and talked about my idea.

The developers said that the idea worked and was a good one. Checked the idea with other designers in our department and they were supportive. This meant that it was possible to work out the details and show them to the users.

It took a couple of days to work out the important stuff.

The design resulted in two variants. The first option combined the important and the script on the same screen.

The second option suggested that the script would open on top of the important one.

There were four managers on the test. The first two managers were shown both in order 1, 2. The second group was shown in reverse order — 2, 1. It turned out that people chose different options in different groups. And it was always the option that came last. After the test, I talked to the managers about the results. They were unanimous — the script should always be on the screen, managers should not be allowed to make mistakes. That is why this variant went into the final revision:

Try 2. Results

The point of Important is as follows. We have gathered all the information you need for the call on the first screen, which is available immediately before the call. These are:

information about the last call when we spoke to the customer;
offers for the customer with individual discounts;
unpaid invoices;
products for which the subscription has not yet expired;
debts the client hasn't paid;
and so on.

The information is packaged in a drop-down list. In the headings of the items the information has already been put out. If there are offers for discounts, we write how many such offers there are. If there are unpaid invoices, we write how many of these invoices there are.

In the expanded list we already show detailed information. For example, we show a calculator that calculates the discount depending on the parameters (subscription period and tariff).

I drew all the states for each item. And put all the layouts on a separate page. Above the layouts, there is a link to the task description.

Results

After the implementation of the Important, the average talk time increased to 1 h 47 m in the observed groups. This is not as much as we expected, but it is still a positive result.
Sales in the observed groups increased by 8%. I think that our assumption was right, but it is only a part of a bigger problem.

Personal Learnings

While working on this case study, I realised the importance of being more attentive to testing. The fact that different users produced different results depending on the order in which they were shown came as a surprise.

I understood that every failure is a starting point for further development. The result is always a better solution than the previous one.