Multiple Sales Pipelines

Project Scope

  • Background

  • Business Case

  • Research & Understanding the Problem

  • Solution

  • Design

  • User Testing

  • Results


My Role

- Product Design - Frontend Developer -

- Product Manager - Project Manager -

- Product Marketing - 



- Web & Mobile


- Adobe Illustrator - Balsamiq - Appcues - SurveyMonkey



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.


Business Case

Creating multiple pipelines made a lot of sense for our business. A single pipeline with one set of stages works very well for small businesses with a simple business model or that are selling only one product. As a business, we were trying to sell to larger companies and in most cases, that means more complex business processes and/or businesses selling multiple products. Our target market is industrials, manufacturing, construction, logistics and manufacturing. Most businesses that fall into this category are selling a variety of products or have multiple phases of a deal that expand past the initial sales process. These phases may include construction, delivery, post-sales relationship management, or other projects. For these multiple products or multiple process models one pipeline was not enough to be able to track the deal, it’s revenue, or its progress through the entire lifecycle.

The necessity for this feature was fairly easy to understand but a deeper understanding of the problem and how this feature would actually be built into our existing model would need further research.


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.


Multiple processes

If you ask any salesperson, they will tell you that a sale does not end when the deal is signed. The “sale” is just one part of the process. These other processes can include delivery of goods, construction, post-sales relationships, or even project management. All of these processes happen after a deal is technically ‘won’. This presents a problem for our users. They want to accurately track when a deal is closed, but also need to track the remainder of work that still needs to be carried out after a deal is closed.

The current solution for many of our users is to create stages for every part of the deal (pre- and post-sales) and either wait to close the deal until all parts of the process are complete or make a completely new deal for the post-sales process and add it into the non-sales stages. Regardless of the solution, it presents a variety of problems for our accounts.

The single pipeline model does not allow for larger businesses with complex sales processes to be able to accurately track the entire lifecycle of their deals.




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.




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.


Deals in Multiple pipelines

The biggest functionality question that needed to be answered with this project was how we were going to handle deals that needed to be moved from one pipeline to another. The most common use case I can use to represent this problem is a deal that goes through a ‘sales pipeline’ and once the deal is won that deal needs to move to into a ‘post-sales pipeline’. There were a handful of questions we needed to answer to handle this use case;

  1. How can a deal be in two pipelines at the same time?

  2. How can we accurately track and report on deal metrics (won date, time to close, win percentage etc.) if the deal is considered ‘active’ in the post-sales pipeline?

  3. If users need to have separate deals for each pipeline how can we automate the creation of the second deal as much as possible?

  4. How can we make it as easy as possible to run reports on individual pipelines or an aggregation of multiple pipelines?

Answering these problems involved multiple brainstorming sessions, prototypes and most importantly, conversations with our engineering team to figure out what was possible from a technical perspective.

As much as we wanted to allow users to create one deal and be able to have that deal live in two different pipelines at the same time, it wasn’t possible from a technical POV. The main problem was that it would be impossible to track and report on a deal that was closed (won/lost) in one pipeline while it continued to go through active stages in a different pipeline. We had to work within the confines of our 12-year old application. With this constraint in place, it narrowed the focus of my design problem.

In order to report on a deal in one pipeline and have essentially the same deal going through another pipeline we would need to create a copy of the original deal and allow the user to choose which pipeline and stage they wanted to add the copy to. We already had an action called ‘clone’ that created a second version of the deal with certain details from the original deal. This functionality was not highly used, partially because the action was hidden behind an ‘Actions’ menu that was only displayed on the deal profile page.


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.




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.

  1. One of the most important parts of a deal is the activity feed. It is a timeline of all activities, updates and conversations related to the deal. It’s what keeps the sales reps and managers up-to-date on the position of a deal. Initially, we had decided to not copy the activity feed when a deal was copied from one pipeline to another. It was not functionality that was built into the ‘clone’ action and it would require extra development work. Also, the activity feed can include a ton of information and automatically adding that to a new deal could be more information than the user wanted.

    After talking with our beta users I heard feedback that backed up our initial hypothesis but I also heard very adamant feedback that the copied deal was useless, if it did not include the activities from the original deal. The feedback was mixed between the two solutions and after discussing the options with our customer success team, I decided to have two different copy actions; copy with activities and copy without activities. The activity feed can be such a large amount of data, I decided it was better to let the user choose which type of copy they wanted to perform rather than making the decision for the user.


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.




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.


  • 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.