Champify’s job change data provides actionable signals for GTM teams. Keeping tabs on your company’s customer relationships is one of the most efficient ways to build new pipeline, strengthen active opportunities, and mitigate churn risk.
Because Salesforce is the central hub for customer and prospect data (all GTM tools read from / write to it) we prioritized building a best in class Salesforce integration.
So, we turned to RevOps, Marketing Ops and Sales Ops leaders at 50+ organizations to understand what was most important. Here’s what we heard, over and over:
From these conversations and extensive testing with our design partners, we developed and iterated on a next-level Salesforce integration. Not an API-only integration, but a native Salesforce package that resides within our customers’ Salesforces.
After testing multiple approaches with our design partners, the first big decision we made was to interact directly with standard Salesforce objects: leads, contacts, and accounts.
The primary reasoning: ops teams, end users (sales / customer success), and downstream workflows rely on standard objects for reporting and integrations into adjacent systems like Leandata, Outreach, Salesloft, Gainsight, and Catalyst. Every ops team we spoke with that started with custom objects ended up converting most or all of those objects into leads/contacts in order to operationalize. So, why start with custom objects when we could get to the same end state without the headache? Here are the pros and cons:
There are two major trade-offs to using a standard objects customizability and context limitations
Relying on custom objects requires ops teams to build automation that converts the object into a lead or contact. Naturally, this means you have ultimate control over when and how those leads and contacts are created, with the tradeoff of a significant amount of overhead to get to this expected state.
Boiling this down to what matters for the job-change use case: you want to ensure that a lead or contact is in your ICP and that the right data points are mapped to the right fields. To address this, Champify built contact/account ICP filters and custom field mapping into our codeless configuration.
There can be significant contextual data (such as product usage) that exists on a past record and would be helpful to surface alongside the new job for prioritization and personalization. By using a custom object, there may be less limitations on the number of fields that can exist on each object.
We tried to capture this value using a different, and our opinion smarter approach: (1) all Champify records have a “previous relationship” label, which is customizable and provides quick context to the end user on which action to take, and (2) rather than simply surfacing the name of the past account an individual worked at, Champify provides two dynamic lookups to the past contact and account records, which can be used to pass in near-unlimited context in our “Relationship detail” fields such as: level of product usage, past account SKUs and ARR, the name of the past CSM a contact worked with, NPS score, and more.
Are you a Ops leader that has feedback? Please let us know your thoughts!