A CRM is the acronym for Customer Relationship Management, a product for managing a sales wallet. It is a very popular tool, used by sales managers and salespeople, and it works for both B2C and B2B.
People usually use a CRM to organize the sales process, centralize the company's sales data and consequently use the functionalities so that they can sell more.
This project was led by me and another senior designer, we collaborated heavily in every single part of this process.
People usually use a CRM to organize the sales process, centralize the company's sales data and consequently use the functionalities so that they can sell more.
The responsible feature for that are the data reports, that gather together all the numbers of all users in one account. As the RD Station CRM was growing, so was the users maturity in sales. The current reports were not enough for the customer maturity.
People usually use a CRM to organize the sales process, centralize the company's sales data and consequently use the functionalities so that they can sell more.
The responsible feature for that are the data reports, that gather together all the numbers of all users in one account. As the RD Station CRM was growing, so was the users maturity in sales. The current reports were not enough for the customer maturity.
We started the discovery first understanding where we wanted to go with the project, defining our goals and setting the expectations.
We had a lot of information and requests that came from customer support (it was always at the top requests and problems), NPS, SUS (UX metrics) and a lot of infos from previous interviews we did with clients, but we also needed to align with business requirements and expectations.
With that in mind, we started our own research to validate who was going to use this new reports and how they could use that in its full potential (and also, I mean, better deliver value).
As we were talking about creating something for high maturity in sales users, we decided to go through with the Jobs to Be Done framework, where we could understand what each maturity level wanted to accomplish and which numbers they were needing.
But we first had to define what maturity meat for us, what is a low, medium and high maturity users, which involved talking to a lot of people and grabbing a lot of numbers from different variants of usage of the CRM. We spent a lot of time in Google Analytics, Hotjar, Amplitude and Mixpanel finding out how many opportunities an average account created per level, if the user had a sales process created, how many pipelines there were and so on.
With those numbers, we set a quantitative (again: with a LOT of people) where we could then separated what data and reports each of this maturity levels were looking for, how they were actually using it and why they wanted this numbers for.
Then we did a qualitative research so we could find out our final jobs to be done for each maturity level and how to place this numbers we find out people wanted in actual goals. This all guided us to know what information we needed to put in each new report to solve each job. If there were a job, there were a number that could solve that goal.
For this new reports we only used the high maturity level users’s jobs, so we stated to look around the other products how they were displaying data, how depth the numbers went and how they explained each concept of the reports.
We already knew what informations needed to appear in each report and we draw a few models of reports but we faced a lot of problems making other people understand how to read the numbers.
We went back and fourth a lot of times between drawing, validating and testing this reports concepts (we conducted over 40 user tests just at this point and had almost daily meetings with developers to understand what could be done or not) until we reached a data visualisation that worked great for everybody.
Only when we reached the sweet spot between what could work for developers, users needs and business goals in a scalable model, we stated to develop in the product.
As one of the main findings in our research the main difficulty of growing the maturity of the users of the CRM was to make them understand how to read a data report. It doesn’t really matter how good are your data if people can’t read it.
So after testing a few models of reports, we reached to a pattern that could be shared between both products of the company (so it was scalable) and easy to set and read.
The first line is where you make the first setting.
1. Pipeline: decide which sales funnel you want to collect data from.
2. Responsible: decide which sales person you want data from, or if you want data from a specific sales team or all the salesperson.
3. Creation date: the date when the opportunities where created.
4. Closing date: when the opportunities where closed. Both closing and creation are used to set a vision of the past, in any time the user wanted.
The second line then were for the big data blocks: easy and important numbers, with a small comparison from the same last period.
1. Each report have it own, also showing if your numbers are growing or not, performing as expected or not.
The third row then were for the graphics: with the details of the numbers.
1. Group type: there were a few variants for the numbers, like the responsibles, products etc.
2. Data type: if you wanted volume (quantity, #), or percentage (%).
3. Data visualisation: if you wanted graphics or tables.
Also, after a lot of tests, and having in mind that some users have a lot of data, the labels were positioned BEFORE the graphic, at the top.
And finally, at the end, the detailed information of each item that counted on the report.
In a table, for cases where you want to see from where the information came from and take actions after reading the numbers.
This type of report was the one that we choose that better suited the quantity of informations that we wanted to display at the time, also suiting the quantity of variations that we could display.
The results were used to conceptualise 2 big groups of reports that covered all of the jobs to be done.
The first group of reports were called Perfomance em vendas (Sales perfomance), with:
1. Conversion: how many opportunities became sales, separated for each sales person, shown in percentage and quantity.
2. Reasons of loss: with how many loses and the most common reasons why opportunities were not closing as sales, separated for each sales person, shown in percentage and quantity.
And the second Atividades de vendas (Sales activities), to report:
1. The time of first contact to a client: time between receiving a sales opportunity to the moment the sales person calls or interact with this person, separated for each sales person, shown in percentage and quantity.
2. Tasks: number of tasks that each sales person was creating and finalising with each opportunity, separated for each sales person, shown in percentage and quantity.
3. Interaction: different from tasks, interactions counts the notes, calls and other activities that were done with the opportunities, separated for each sales person, shown in percentage and quantity.
Since it was a huge project, the strategy for this project followed a plan of delivering each report with progressive incrementation (total of 16 small releases) in controlled rollouts to a beta program, to validate solutions while the rest was being build.
After the first report was made, It was launched in Alpha for testing and after to clients, then in Beta for a few more people. This repeated until we had all 2 big reports done to then be fully rollouted for all the PRO plan users.
These new reports were part of group of new features that were used in the a new plan for the product, so it directly increased the number of people interested in the new plan.
It was also a new competitive feature that helped more mature user to make decisions and sales teams to perform better sales.
debsperandio@hotmail.com