Multiple Sales Pipelines

Background

PipelineDeals is a sales CRM. The goal of PipelineDeals is to help businesses manage and improve their sales processes by making it easier for sales teams to manage, track and coordinate their efforts with different prospects and customers. There are many ways in which our software enables sales teams to be more efficient, thereby boosting their bottom line. One of the first ways our software makes sales teams more efficient is by creating a repeatable routine amongst all users. If everyone on the team is working within the same framework, it becomes easier to implement effective strategies, track results and report on revenue. We help our customers establish a consistent process by creating a single pipeline made up of a defined set of stages. Each ‘deal’ (this is how we define a lead or prospective sale) will pass through the same set of stages culminating in a won or lost deal.

This defined set of stages is core to the underlying model of PipelineDeals software. When internal stakeholders on the L-team and our own sales team insisted that we needed to build a feature that would allow our users to create additional pipelines, each with their own unique set of stages, it presented many challenges.

Researching & Understanding the Problem

This project ended up on our product roadmap in an unusual fashion and therefore didn’t have the typical timeline for conducting and performing research. This feature isn’t exactly revolutionary and many of our competitors already had something similar established in their software but instead of using our competitor’s solutions as a starting point, I wanted to conduct user interviews to get a deeper understanding of the problem.

To begin the research, I utilized a few different resources for finding potential interview candidates:

1. I reached out to our customer success team to see if they had any customers who had asked for this feature or were experiencing problems due to the current single pipeline model.

2. I checked our feature request form that is filled in with requests from customers that are given to the customer care team.

3. I asked our sales team if they had won or lost any recent deals where the prospect had mentioned this feature or the need for more than one pipeline. Using these three resources, I was able to set up 5 interviews with current PipelineDeals users.

In these five 1/2 hour - 1 hour interviews, I tried to get to the root of this problem by asking questions about their sales process, current PipelineDeals usage, and pain points around tracking the entire lifecycle of their deals. I gained a much deeper understanding of the problem and was able to synthesize the problem into two main categories.

Multiple Products

It is extremely common for businesses to sell more than one product, but oftentimes the products are close enough that the same sales process can be used to sell both products. It can be much more difficult to track the sales process when products are not closely related at all. This is an example I heard in one of my interviews that explains this very well. This customer sells a large range of farm and garden equipment. They sell small lawnmowers for personal, home use but they also sell large tractors for industrial farm-use. For these large tractors they also sell them outright or they have leasing programs. Either way, these products all have a different sales process and require a unique set of stages to in order to complete the sale.

Solution

After a thorough investigation of the problem, we knew we had to figure out a way for users to track different products and processes. For us, this meant altering the one pipeline model that PipelineDeals was built around. Users would need to be able to create multiple pipelines, each with a unique set of stages. This solution would allow users to create a pipeline for each process or product that they needed to track.

Our solution was not groundbreaking but implementing this solution would touch nearly every part of our application: listviews, profile pages, reporting, deals, account settings, importing, our API, our mobile app and more.

Design

Pipeline Administration

The first page I designed was account settings. Account admins needed a simple and intuitive way to perform all pipeline administration. My first decision was to combine pipeline and stage administration on the same page. Previously, all stage admin was on it’s own page that also included deal loss reason. By combining pipelines and stages I could accomplish a couple tertiary goals. The page for creating deal loss reasons was hidden on a second tab of the ‘Stages’ page and our customer care team often got calls because users could not find that page. By creating a new page for pipelines I was able to make ‘deal loss reasons’ its own page, giving it much greater visibility. The second benefit of moving deal stages to a new page was that I could redesign the entire UI. Deal stages had not been touched or updated in a very long time and there were a lot of updates I could implement in order to make deal stage administration easier to do.

Throughout the years, our account settings pages have been added to and changed at different times. This means that the UI from page to page can be different. As we add new pages we try to update the UI as much as possible. With the ‘Pipelines & Stages’ page, I was able to combine the most modern elements from various account settings page to create our most modern, intuitive account settings page to-date. This was very important since this page would be used to manage pipelines and stages.

My solution was to enhance the ‘clone’ functionality and prompt the user to copy or move their deal any time they wanted to change the pipeline. With this solution, the user would be able solve both problems discovered through my research:

1. If the account was selling multiple products, they could easily move a deal from pipeline to pipeline depending on which product their lead was interested in.

2. If the deal needed to be tracked in one pipeline and then tracked in another pipeline as it went through a different process, the user could easily create a copy of the deal with all of its pertinent information and no manual entry.

Once a decision was made as to how we were going to handle deals being moved or copied from pipeline to pipeline I focused my designs on making it as easy as possible for the user to add deals to the correct pipeline, view deals in specific pipelines, and run reports on individual pipelines.

Mobile

While this project was being worked on, our company was also building a completely new mobile application. Prior to this rebuild, our mobile application was managed by a 3rd party and new features added to the web application were not included in the mobile app. With the rebuild of our mobile application our in-house developers were going to be taking over the development of the mobile app.

This was the first web-app feature that was going have functionality available in the mobile application as well. I knew that not all functionality would be available in the mobile app so I started off the design process by deciding what core functionality must be parodied in the mobile application. Making sure that the pipeline and stage were easily visible to users was a main point of emphasis and also making sure that users could perform the same move/copy actions.

There was some important learnings that came out of designing this feature for mobile.

1. Updates to the API needed to be taken into consideration from the onset of a project. The mobile app gets all of its information from our API and in the past the API was an afterthought. Now API construction needed to be part of the initial development.

2. Since our mobile application is not a 1:1 copy of the web application, it was important to understand the core functionality of a feature that needed to be included in the mobile application.

Overall, the development of Multiple Pipelines functionality for the mobile application was very successful and I learned a lot of lessons for future mobile development.

Beta Program/Learnings

The development process of multiple pipelines was broken down into four stages. By the end of the third stage we had a viable MVP that could be tested with users. At the time, I was acting a project manager, designer, and product manager for this feature. I decided the best way to gather feedback would be to run a limited beta with a few of our key accounts that had shown interest in this feature.

To avoid any disturbances in the workflow of our beta testers, I created 5 test accounts and created a set of sample data including deal stages that matched their current workflow. My goal was to create a test account that mirrored their existing account in order promote as much engagement as possible.

After setting up calls with each beta tester, I gave them each an overview of the feature, a demo of the new functionality, and a set of common workflows/tasks to test out the new functionality. At this point, I gave them two weeks to test out the feature on their own and then set up another call to get feedback. In the follow-ups, I gained insight into a few improvements that should be implemented before the wider launch of Multiple Pipelines.

2. When a deal was copied into a different pipeline the new deal name was automatically prepended with the text, ‘Copy of’. This was to make sure the user knew which deals were a copy of another deal. From there, they could easily change the name from a variety of places in the app. Through the beta discussions, I learned that most users were copying deals from the edit deal form. When I asked why they preferred to perform this action from that particular modal (even though it required extra clicks to navigate to) they said it was because they could rename the deal at the same time they were copying it. This is just a function of the edit deal modal that the move/copy modal did not have.

Based on that feedback, I decided to add add a new field to the move/copy modal that would allow the user to change the name directly from that screen. ‘Copy of [deal name]’ was automatically added to the input so the user wasn’t required to name it at that point but they had the option to do so, if it improved their workflow.

The limited beta was very effective for catching bugs that were not caught during UAT and also making some key improvements that came out of the follow-up interviews.

Post-Launch

During the final phase of development, I coordinated with our marketing team to coordinate product marketing efforts, met with engineering to discuss the best plan for rolling out this feature, wrote documentation that could be utilized by internal teams to write help articles and help customers with issues and finally completed an internal demo of the feature.

When development was complete, we rolled this feature out over a week to ensure that no issues would occur that would disrupt the workflow of accounts. The rollout was very smooth and we’ve received great feedback since the initial launch.

Outcomes

• Our sales team has been able to attract larger clients because we can support their need to manage multiple products and/or processes.

• Current users of PipelineDeals who had created a workaround to solve the problem of having a single pipeline are now able to create additional pipelines and streamline the management of all their deals. Many of the features we built have made it simple for existing users to adjust their current workflow and seamlessly begin working with multiple pipelines. Within the first week of release our customer success team relayed a story of a 5 seat account on our lowest plan (Start) that was going to leave PipelineDeals, but after seeing the multiple pipelines feature, decided to add 5 additional users and move up to an annual contract on our highest plan (Grow).

• A goal we are always trying to accomplish is to expand the use of PipelineDeals beyond just the sales team. Multiple pipelines has allowed for other teams to use the software. Delivery teams can use PipelineDeals to manage and track the delivery of goods, account managers can use the software to manage the post-sales relationship, and project managers can use it to track the status of projects. By expanding the adoption of PipelineDeals within an organization, we are becoming a vital part of their workflow and increasing our stickiness as a tool.

Future Enhancements

In the short time that Multiple Pipelines has been released, I have already created a backlog of future enhancements that I would like to implement to continue to improve this feature.

• PipelineDeals allows our accounts to create teams of users. Currently, every user has access to all Pipelines that exist in their account. One enhancement would be to give access to certain pipelines based on team. This way, the sales team might only have access to the sales pipeline, the account management team would only have access to a post-sales pipeline, and the project manager would have access to a project pipeline. This enhancement would increase the use of our User Teams feature as well as Multiple Pipelines all while making our users more efficient.

• There are a variety of fields within PipelineDeals that could benefit by being tied to specific pipelines. Deal loss reason is a good example. Currently, deal loss reasons are set up account-wide and any deal that is lost can be assigned the same deal loss reason. It makes a lot of sense for deal loss reasons to be tied to pipeline. That way, when users are choosing a deal loss reason they only have to choose between the fields that are relevant to the pipeline that deal is in. Custom fields are another great example of a field that could be set up per pipeline. This would help limit the amount of information a user sees on the deal profile page. Instead of seeing every type of custom field on every deal, they would only see the custom fields that relate to the deal they are working.

• PipelineDeals allows our accounts to create teams of users. Currently, every user has access to all Pipelines that exist in their account. One enhancement would be to give access to certain pipelines based on team. This way, the sales team might only have access to the sales pipeline, the account management team would only have access to a post-sales pipeline, and the project manager would have access to a project pipeline. This enhancement would increase the use of our User Teams feature as well as Multiple Pipelines all while making our users more efficient.

Since the launch of this feature, the feedback has been very positive and the sales and expansion numbers have backed up the positive feelings. I will continue to monitor the analytics, feedback and revenue reports in order to decide the best direction to take this feature in future developments.