Context

Intercom is primarily a support tool that our customers use to talk to their customers. As part of our customer’s tech stack, they generally also use a Customer Relationship Management (CRM) system as their “source of truth” connected to Intercom.

The problem to solve

• Customers’ workflows involve many systems and data flows between those systems. Workflows like ticket management or visualizing data about a person when they’re chatting with a support agent requires data synchronisation between Intercom and the CRM system. In order to be part of our customer’s businesses, Intercom needed to integrate with Salesforce.
• Not having a proper integration between Intercom and Salesforce was one of the main reasons why customers were leaving Intercom (churn).

The solution

An integration app that enables customers to seamlessly synchronise data between Intercom and Salesforce, execute workflow actions such as converting conversations into cases from Intercom to Salesforce, and perform bulk data synchronisation.

The challenges

• Data integrity: High complexity data synchronisation scenarios to consider. Our number one priority was to keep our customer’s data safe.
• Diverse customers’ needs: Customers have different needs regarding data synchronisation and data flowing in and out of their systems. The challenge was to offer opinionated solutions vs high flexibility.
• Salesforce’s CRM complexity: This system is one of the most customisable CRMs in the market. It takes time and effort to know it in order to design an integration for it.
• Lack of PM role: As part of shipping the first version of this integration, I was also leading the manual QA and release plan for the first version.

My role

• Lead product designer in charge of the entire design process
• Collaborating with manual QA to make sure that data integrity was preserved and that what was designed was shipped.
• I also took product management responsibilities on the first iteration of the product. I planned and executed the release and wrote the customer-facing documentation.

The process to solve this problem

The process of designing this app took a couple of iterations to be where it is at the moment. Each iteration covered a new functionality or improvements on the previous ones. I’ll be doing a high level walkthrough to show you my work and impact rather than describing in detail the solution.

Understanding the problem

Customers were leaving Intercom because we didn’t have a proper integration with Salesforce. In order to understand why this was important and what jobs they were trying to achieve, I planned and ran customer interviews and usability feedback sessions at different stages of the process (during discovery, beta feedback, and iterations). I also worked on the synthesis of findings and prioritised improvement recommendations. Talking to customers helped us identify the key jobs they were trying to achieve:

• Cohesive data between systems (2-way data sync)
• A complete view of their customers when dealing with an inquiry
• Support of their workflows (flexibility)

We also gained foundational insights about the target customer segment we were building for, including the diverse needs different business have and the jobs-to-be-done.

‍

System design

Because this problem is highly complex and ambiguous, we needed to have a high-level view and understand the system, its components and their relationships. We also needed to understand how this product would work as part of the bigger Intercom system and as part of our customer’s ecosystem. I built the system model, gathering feedback from different teams and iterating on it. Having this model allowed us to have a shared understanding of the systems and its relationship with other areas of the product. It also served the team for shared understanding and vocabulary.

‍

Going down to a deeper level to understand the relationships between objects for both systems and how data would flow between them:

‍

Product principles

Since we were working on a highly complex project, we needed product principles to help design and engineering make decisions. I lead different workshops to identify and prioritise these principles collaboratively.

Scope definition

I was heavily involved in making scope calls in order to ship fast. I led and collaborated in the definition and prioritisation of features that would be part of the different versions. I worked closely with my product manager on this.The scoping process includes understanding the jobs, the goals of our customers, our company’s strategy, technical constraints, and our success criteria.

Solution design

Design work wasn’t always linear. It included me leading ideation workshops, working on low fidelity designs, internal design critiques, prototyping, gathering feedback from customers an internal SME, looking at data, and detailed design iterations.Because our customers had a variety of needs that sometimes we couldn’t necessarily be solve with an opinionated solution, flexibility was critical when designing the solution. Having a strong understanding of their jobs allowed us to have more confidence in our assumptions.  

‍

Shipping with quality

This is generally something I’m very involved in. I actively participate by defining manual test cases up and making sure that the quality of what’s shipped is the same as designed and intended. I also helped design the manual testing system that was used in several releases.Since data synchronization was one of our customer’s main jobs, we needed to also test the quality at a data level to make sure that the data was synced based on the attributes mapped and its direction.I also led a pre-mortem workshop in order to anticipate and mitigate any risks that our solution could bring to our customers.

‍

‍

Release management

Releasing the first version included me identifying the customers best suited to give us feedback and designing an onboarding experience for them. I also made sure we gathered feedback after a period of time that will help us understand what works, what doesn’t and what do we need to improve. This was done using a mix of channels (email, Intercom’s messenger, 1:1 calls).

For the first versions, I wrote the public facing documentation (example). In future iterations I collaborated with a content writer.

Iterations

After each version, we always identified areas to improve. Some of these were foundational concepts, iteration in our understanding of the system, and/or features our customers needed. The first version allowed us to build a strong foundation for the upcoming ones.

By the way, I also wrote about how we own what we ship at Intercom.

Outcomes‍

• ‍66% of Salesforce App installs actively syncing People data (~$19m in ARR). Of these, 41% are actively syncing data using the net new features shipped with this V1. This represented strong active usage performance and net new adoption for an area of the product that is complex to configure.
• Larger customers (Enterprise and mid-market) are the best performing segments with consistently the most adoption, validating the importance of these features in our target customer set.
• These features were cited as key win factors in closing out multiple six figure ARR deals. Example of a customer converting having previously failed due to a feature gap with the Salesforce integration.
• A number of improvements with varying levels of signal for upcoming versions. 

‍