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 synchronization 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 allows customers to keep data synchronized between Intercom and Salesforce CRM and also perform workflow actions between both systems, like sending a conversation as a case from Intercom to Salesforce.
The challenges
- Data integrity: High complexity data synchronization scenarios to consider. Our number one priority was to keep our customer’s data safe.
- Diverse customers’ needs: Customers have different needs regarding data synchronization 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 customizables 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 writing the customer-facing documentation.
The process
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 and our customers
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 prioritized 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 prioritize these principles collaboratively.
Scope definition
As a designer, I was heavily involved in making scope calls in order to ship fast. I led and collaborated in the definition and prioritization 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.
Quality assurance (QA)
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.
Outcomes
- Integration with Salesforce is not listed any more as top churn reason since we built the first two versions.
- The Salesforce integration app is now one of Intercom’s most popular apps for customers (top 10, 2k+ installs) and a “table stakes” integration for our upmarket customers.
- We also saw a strong correlation between high Gross Revenue Retention and customers who have installed the Salesforce integration app.
- We’ve addressed the highest signal key gaps for the Support use case, have improved interoperability with Service Cloud and have built a solid technical foundation enabling further feature expansion over time.