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:
- Ops teams have a lot on their plate.
- GTM end-users don’t need another login or workflow trying to grab their attention. They need better, more actionable data in their existing tools.
- Ops teams need something that is both lightweight and flexible. Lightweight in that ops should not have to develop, test, and maintain custom code. Flexible in that it should fit seamlessly into existing processes and GTM tech.
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.
- End-to-end Salesforce automation: enabling even large orgs (2k+ full time employees) to get off to the races in days or weeks. This means building out features to handle edge cases such as smart de-duping, respecting Salesforce limits, field mapping, and smart error handling.
- Pre-built, customizable workflows for end users: ICP qualification, personalized lead lists, email alerting, reminders, disposition, and reporting/dashboards all come out-of-the-box in Champify’s Salesforce package.
- Native compatibility with any GTM tool that integrates with Salesforce: by working directly with standard Salesforce objects, Champify significantly reduces the work needed to integrate data into lead routing, sales engagement, marketing and customer success workflows. More on this below.
Leveraging Standard Objects vs. Custom Objects in Salesforce
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:
The Benefits of the Standard-first approach:
- Swift implementation: Whereas using custom objects would require a level of effort similar to implementing something like 6sense, Champify provides an experience that “just works”. This means revenue teams can realize the value of Champify almost immediately. Of course, we still built Champify so that ops teams can customize automations (whether that be with our logic or theirs) to fit their needs.
- Low time investment so ops can focus on high ROI problems: Ops teams have ambitious roadmaps, large teams to support, and limited resources to spend building new systems and processes. Ops 🧠power should be spent on value-add activities, rather than just getting the thing to work well (that’s our job).
- Robust – fewer edge cases / landmines: Teams we’ve talked to who leverage custom objects mentioned that they frequently had to support new edge cases via custom Apex code and beefy Salesforce flows. This custom development would need to get revisited frequently with any Salesforce changes to make sure new initiatives could be rolled out without breaking changes. By leveraging standard objects we eliminate these edge cases.
- Easy to integrate downstream tools: As is, Champify data can be automatically surfaced in outbound tools, customer success platforms, and sales intelligence tools via each tools’ integration with Salesforce.
- Scalability: by nature, custom objects will consume significantly more storage and Apex bandwidth than standard objects. In addition to the standard object benefit, we also added built-in support to automatically stop running + reschedule Champify jobs if Salesforce Governor Limits for Async Apex Executions or Daily API Requests pass a configurable threshold. This gives peace of mind to ops teams that we’ll never interrupt or interfere with other mission-critical workflows or automation.
The Tradeoffs, and how we addressed them
There are two major trade-offs to using a standard objects customizability and context limitations
Customizability
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.
“Context” limitations
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!
