Campaigns App

Summary

Since its creation, Pipedrive was solely focusing on improving Sales team revenue by providing a robust Customer Relationship Management (CRM) product. After 10 years on the market, the company leaders realised that we weren’t growing with our customers as much as we could.

After conducting comprehensive market research, we discovered that High-Value Customers (HVC) couldn’t function efficiently if their business data was siloed and spread across multiple tools. Our new direction became clear: we needed to bring those external tools right in Pipedrive.

Since Pipedrive had just acquired Mailigen, a Marketing Email Software, it was decided to start implementing this multi-product strategy by bringing email marketing power right inside Pipedrive: the Campaigns app concept was born.

Problem

We had a well-defined Sales persona in Pipedrive and a well-defined Marketing persona in Mailigen. On paper it seemed easy: Marketing customers and Sales customers are the same people at different customer lifecycle stages. Guess what? It wasn’t that easy.

First, we had to build the whole infrastructure to deliver emails. Luckily we had the really knowledgeable Mailigen team to help out in setting everything up.

Second, we had to provide a solid drag-and-drop editor so that our customers could create beautiful email designs. We decided to use BEE Free email template editor to save engineering time. While they provide a great out of the box tool, it proved to be quite limiting for us as we were only able to modify their UI and had to keep the UX defined by their product team.

Third, and that’s when it got interesting, we had to make our current Sales contacts (a user’s customer) model work with our new Marketing contact model. On top of this, we had to deal with marketing communication legislation such as GDPR or the information act. Finally, since contacts can be hidden in Pipedrive, we had to figure out the impact of those visibility settings on marketeer flows.

Since it was a 9 months month project, I will focus today on the Contact management mission which was delivered as part of that product development phase.

---

Role

I was hired back in Pipedrive specifically for leading the design of this concept area. I worked closely with our Group Product Manager and Engineering Manager on the long term strategy and roadmap while delivering 2 or 3 missions in parallel. At the same time, I was providing guidance and mentorship to 8 other designers working on a variety of problem spaces.

---

Approach

We started by first looking at what was the current contact requirement in Pipedrive. We started by researching our two personas what is a contact for them. For salespeople, contacts are people with whom they create personal, in-depth one-on-one relationships. On the other hand, marketing contacts are people with whom they create automated, broad large-scale relationships.

The sales contact model in Pipedrive was as follows:

• Name (required in Pipedrive)
• Email (not validated, not required, multiple)
• Phone (not validated, not required, multiple)
• Demographics for salespitch
• Past behaviour for salespitch

The marketing contact model would usually be as follows:

• Email or phone (valid, required and unique)
• Marketing consent (as requried by GDPR, CAN-SPAM Act, and other legislations)
• Name (not required)
• Demographics for segmenting
• Past behaviour for segmenting

Finally, a major difference was our new marketing billing model. Traditionally Pipedrive had always been charging for its product on a per-user basis, the more salespeople you have, the more you pay. That doesn’t scale really well especially when automation allows the creation of highly efficient processes. To allow Pipedrive to grow with their user base, it was decided to bill for Campaigns App based on a per-subscriber basis.

---

Solution

Marketing status

The first question that we should have asked ourselves was: what is this marketing status and how will users use it? At the time we were pressed by really tight deadlines and we didn’t have the luxury of spending much time on the question. All information regarding contacts is called custom fields in Pipedrive.

At the time it seemed obvious to me that our new status was behaving differently from other custom fields:

Marketing status	Custom field
Some values disabled the field (e.g. unsubscribed)	Can always be updated by users
Some values are system-generated (e.g. bounced)	Values are always user-generated
Tied to email field	Not tied to any other custom fields
Tied to our billing model	Not tied to a billing model
Updated by users’ customers’ actions	Updated by users’ actions

Based on this observation, I advocated creating the Marketing status as a new type of field reflecting those differences. Sadly, since the contact model wasn’t owned by anyone in the product organisation, it was decided for the sake of speed to develop this new field as a regular field with extra logic.

Updating contact status

We went through a lot of ideation and test phases with the Product Manager (PM) and the Engineering Lead (EL).

The first solution we wanted to explore was to design a new pattern for updating multiple items in list views: bulk actions. We already had the bulk-edit functionality in Pipedrive which allowed users to change multiple field values at once. Bulk actions would be similar but would always act on the whole contact rather than on a particular field (e.g. deleting, sending group email or subscribing to marketing communications).

This solution seemed promising but there was a lot of pushbacks from both engineering and design alignment teams. At the time, stakeholders couldn’t see value in branching from current patterns. For them, marketing status should be treated as a normal field and therefore use the available bulk-edit function.

In the end, the PM and EL decided to follow the alignment teams advice because it was saving us a lot of engineering effort. If we would have gone with the bulk-actions pattern, which had some supporters too, we would have had to get all list views refactored and a lot of stakeholders to agree on this change.

---

Challenges

It was really complicated to produce something functional with so much legacy and stakeholders. Contacts are one of the oldest entities in Pipedrive and with it came a lot of baggage. The biggest challenge for me was to keep on getting setbacks because of engineering constraints. I can’t even count how many times I heard: “Gaetan, do you have a minute? We can’t build the flow which we have agreed because service X is not exposed”.

I had to redesign the whole flow many times, and in the end, I had to settle for a solution in which wasn’t optimal. I spent the next 6 months advocating for a follow-up mission as well as getting proper ownership for the contact entity. I luckily succeeded in both with a campaign recipient management mission added to our roadmap and a Product Manager allocated to contacts management.

---

Results

A couple of months ago, we released the first Beta version of the Campaigns App to a few selected customers. So far adoption has been pretty low. We have conducted around 20 user-feedback interviews on different topics to gather their first impressions. When looking at contact management, users almost always managed to successfully change marketing statuses.

We noted that:

• User weren’t trying to match marketing statuses with the ones in their current tools
• They didn’t seem to care about customer constent as much as we thought they would
• They could figure out how to update statuse but didn’t understand why it sometimes behaved differently from other custom fields (Unsubscribed status can’t be changed)
• Some users find really intuituve to use Pipedrive filtering to organise contacts but others were looking at building segments
• Buld updating status could have unpredictable results and no post-update summary

Before I left Pipedrive, more usability testing was planned to scope for the next mission planned on this topic: Recipients Management.