HubSpot–Salesforce Integration Case Study: Running Both CRMs at a Manufacturing Company

Summary

Kesterline Industrial is a mid-market manufacturer of engineered components, selling through 31 territory representatives with a marketing function of six. It ran Salesforce in direct sales and HubSpot in marketing, and had done so for four years. Neither system was going to be retired: Salesforce held the forecast the board reviewed and the territory structure 31 compensation plans depended on, and HubSpot held four years of campaign attribution and the lead lifecycle.

The two were connected by the packaged connector, matching contacts on email address and companies on name similarity. Name similarity is not identity, and a manufacturer's customer base contains many legitimately similar names — divisions, subsidiaries and plants of one parent buying separately. Account duplication in Salesforce stood at 18 percent. Marketing and sales reported sourced pipeline figures that differed by roughly 40 percent, and nobody could state the conversion rate from qualified lead to opportunity.

The work was to decide, object by object, which system was authoritative; to construct a record identity that did not previously exist; to give every field crossing the boundary a conflict policy; and to instrument the connection so a silent stoppage was detectable. Consolidation was assessed and rejected, and section 3 gives the reasoning.

Duplicate account records fell from 18 percent to under 3 percent, company-name divergence from 31 percent of pairs to under 2, and marketing-sourced pipeline became one figure rather than two. Lead-to-opportunity conversion became computable end to end for the first time.

1. The Situation

Kesterline sells engineered components through a direct sales force of thirty-one representatives organised by territory, with a marketing function of six generating demand through trade publications, industry events and a technical content programme. Salesforce was implemented first and had accumulated eight years of territory logic, quota structures and forecast categories. HubSpot arrived four years later for marketing automation and had accumulated its own lead lifecycle, campaign structure and scoring model.

The two were connected by the standard packaged connector, configured during the HubSpot implementation and substantially unchanged since. It synchronised contacts and companies bidirectionally on a best-match basis, which is to say on email address for contacts and on name similarity for companies. That configuration is unremarkable and it is precisely where the difficulty originated: name similarity is not identity, and a manufacturer's customer base contains a large number of legitimately similar names — divisions, subsidiaries, and plants of the same parent operating as separate buying entities.

The distinction matters because the failure presented as a reporting dispute while originating in the process by which records were created and matched (Reinartz, Krafft, and Hoyer 2004). Three symptoms brought the engagement about. Marketing reported sourced pipeline that sales leadership did not recognise, with the two figures differing by roughly 40 percent in the quarter before the work began. Representatives maintained private spreadsheets of account contacts because the CRM's account records had visibly duplicated. And no one could state the conversion rate from marketing qualified lead to opportunity, because the two ends of that measurement lived in systems that did not agree on what a company was.

2. Pre-Engagement Assessment

The assessment was conducted read-only over three weeks and measured rather than characterised the position.

Account duplication in Salesforce stood at 18 percent of records, established by fuzzy matching on normalised name and postal address and then reviewing a sample manually. Of the duplicates, most appear to be not accidental re-creations but the artefact of name-similarity matching writing a new record when it failed to recognise an existing one. Contact duplication was materially lower at 4 percent, because email address is a reasonable identity proxy and the connector used it.

Field-level divergence was measured on the 2,400 accounts present in both systems. Company name differed in 31 percent of pairs, industry classification in 44 percent, and employee count in 52 percent. None of those fields had a designated owner, which meant each was written by whichever system synchronised most recently. That is the mechanism behind the complaint that values change on their own, and it need not indicate a defect in either platform.

The data quality literature distinguishes dimensions that must be assessed separately rather than collapsed into an overall judgement of quality, and this position illustrates why: completeness was adequate throughout, while consistency between systems was poor, and an aggregate score would have obscured the distinction (Wang and Strong 1996; Batini et al. 2009). The costs of that inconsistency were being paid in ways the organisation did not attribute to data — the private spreadsheets, the disputed pipeline figure, and the meetings spent reconciling rather than deciding (Haug, Zachariassen, and van Liempd 2011).

3. The Decision Not to Consolidate

Consolidation was assessed and rejected. The opposite conclusion is usually assumed, so the reasoning follows in full.

Salesforce carried territory assignment logic on which thirty-one compensation plans depended, and a forecast category structure the board had reviewed quarterly for six years. Reproducing that in HubSpot was feasible and would have consumed the majority of an implementation budget to arrive at parity rather than at improvement. HubSpot carried four years of campaign attribution and a lead lifecycle the marketing function had refined against its own reporting. Moving that to Salesforce would have discarded the attribution history entirely.

The package misalignment literature frames the situation accurately: organisations adopting packaged systems experience gaps between the package's embedded assumptions and their own structures, and resolve them by adapting the organisation, adapting the package, or building at the boundary (Sia and Soh 2007). Kesterline had already adapted twice, once to each system. The remaining option was to build at the boundary and define it precisely, which is what was done.

4. Object Ownership

Before the ownership decision could be taken, the two object models had to be set beside one another. They differ structurally rather than cosmetically, and the difference determines what the integration can and cannot represent.

The consequence is specific. A contact associated with three companies in HubSpot has no single AccountId to carry into Salesforce, and a synchronisation that picks one is discarding information silently. The integration therefore had to state which association was the one that crossed, and the answer — the company whose deal the contact is associated with — is a business rule rather than a mapping.

The first deliverable was accordingly a written statement of which system was authoritative for each object. This is a business decision presented as a technical one, and it was taken with the sales and marketing leadership in the room rather than inferred by the engagement team.

Leads and contacts were assigned to HubSpot, where engagement history is generated and where the lifecycle is administered. Accounts, opportunities and the price book were assigned to Salesforce, which holds the territory structure and the forecast. Activity was the exception: both systems generate it legitimately, so neither owns it, and it is reconciled on the shared identifier rather than merged by resemblance.

Davenport's observation that enterprise system work is fundamentally about deciding what data means and who may change it applies directly, and the assignment above is that decision written down (Davenport 1998). Its value may not be that the allocation is optimal in any abstract sense but that it is explicit, so a disagreement about a field has a documented answer rather than a debate.

5. Identity Resolution

Name similarity was replaced with a constructed identifier, because no two commercial systems share an identifier space and identity must therefore be built rather than assumed.

A dedicated external identifier property was created on the HubSpot company object, configured as single-line text with unique values enforced, holding the Salesforce account ID. The corresponding Salesforce account carried the HubSpot company ID in a custom field. Neither system's native matching was relied upon for companies thereafter.

Uniqueness is a data quality dimension measured directly rather than inferred from diligence, and an explicit identifier is what makes it measurable here instead of merely intended (Batini et al. 2009). Establishing that mapping across an existing estate was the substantial part of the work. The 2,400 accounts present in both systems were matched programmatically on normalised name and postal address, producing 1,910 unambiguous pairs. The remaining 490 were resolved manually by the sales operations team over four weeks, working a queue ordered by account revenue so that the commercially significant records were correct first. The 18 percent duplication in Salesforce was addressed in the same pass, merging within Salesforce before the identifier was written, on the principle that importing or linking a duplicate relocates the problem into a place where it is harder to resolve.

6. Field Ownership and Conflict Policy

With objects assigned and identity constructed, each field crossing the boundary was given an owning system and a conflict policy. Sixty-one fields were in scope. The policy for each is one of four: HubSpot authoritative, Salesforce authoritative, first-write-wins with subsequent changes ignored, or not synchronised at all.

Treating customer relationship management as a set of processes to be measured, rather than as software to be installed, is what makes a field-by-field decision tractable at all (Reinartz, Krafft, and Hoyer 2004). The fourth category proved the most useful and is the one most often omitted. Twenty-three of the sixty-one fields were removed from the synchronisation entirely, on the basis that they answered a question only one function asked. Marketing's lead score has no meaning in a territory forecast; Salesforce's forecast category has no meaning in a nurture campaign. Every field that crosses a boundary is a maintenance obligation and a potential contradiction, and the ones that stay home are free.

Industry classification, which had diverged in 44 percent of pairs, was assigned to Salesforce and made read-only in HubSpot, because the territory structure depends on it and marketing's use of it is descriptive rather than operational. Employee count was assigned to the enrichment provider rather than to either CRM, with both systems receiving it.

7. Observability

The integration failures that end trust are absences rather than errors. A validation rejection produces an event that something can alert on; an expired credential, a paused schedule or a retired API version produces silence, in which records stop moving while both systems continue to appear healthy.

Three mechanisms were installed. Rejected writes are retained with their full payloads in a queue that a named person in sales operations reviews weekly, rather than reduced to a log line. A scheduled reconciliation job counts records and sums opportunity value on both sides nightly and reports the difference, converting drift from a rumour into a number. And absence monitoring alerts when no records have moved across a window in which the business certainly generated changes, which is the condition ordinary error monitoring cannot detect.

Speier and Venkatesh (2002) followed salespeople through two sales-force automation deployments and found that favourable reactions immediately after training had become widespread rejection within six months. Early experience decided the outcome. The users of an integration never see its architecture; they see whether the number on the record was right the last three times they looked.

8. Outcomes

Account duplication. From 18 percent to under 3 percent, with the residual being genuine ambiguity — divisions of a parent that may reasonably be one account or several, resolved case by case rather than by rule.

Field divergence. From 31 percent of company-name pairs differing to under 2 percent, and from 44 percent on industry to nil, the latter because the field became read-only in the non-authoritative system rather than because it was corrected.

Pipeline reporting. From two figures differing by roughly 40 percent to one figure, computed once from the authoritative opportunity record and attributed through the shared identifier. The reconciliation meeting the two functions had held monthly ceased.

Conversion measurement. Marketing qualified lead to opportunity became computable end to end for the first time, at a modelled 11.4 percent, because both ends of the measurement finally referred to the same company record.

Manual reconciliation effort. From an estimated six hours weekly across sales operations and marketing operations to under one, the remainder being the exception queue, which is work the design intends rather than work it failed to remove.

9. What Resisted

Two things resisted, and neither was technical.

The 490 ambiguous account pairs could not be resolved programmatically and required four weeks of sales operations time. Several attempts were made to automate a portion of that with additional matching heuristics; each produced a false-match rate that would have created worse problems than it solved. The honest position appears to be that constructing identity across an established estate tends to carry an irreducible manual component, and a plan that assumes otherwise may either overrun or produce incorrect merges.

The second was the read-only industry field. Making a field read-only in the system a team uses daily is experienced as a removal of capability, whatever the reporting rationale, and the marketing team resisted it for several weeks. It held because the reporting improvement was visible to the same team within a quarter. The technology acceptance research anticipates this: perceived usefulness is what sustains adoption of a constraint, and a constraint imposed without a visible benefit is worked around rather than accepted (Davis 1989; Venkatesh et al. 2003).

10. Limits

This is one architecture at one scale, and several boundaries apply.

It describes a two-system arrangement in which both systems remain. Estates with three or more CRMs, or with a data warehouse acting as the reconciliation point, face the same principles under materially different economics, and nothing here should be read as advice at that scale. The organisation had capable sales operations staff available for four weeks of manual resolution; an organisation without that capacity faces a different plan and a longer one.

The decision not to consolidate was correct for this position and is not general. A firm without eight years of territory logic in Salesforce, or without four years of attribution in HubSpot, faces a materially cheaper consolidation and should evaluate it seriously. And the literature cited here was developed largely on ERP-era systems; its transfer to CRM-boundary work is an argued analogy rather than a tested finding (Gattiker and Goodhue 2005).

11. Conclusion

The organisation did not have an integration problem in the sense that a connector was misconfigured. It had an authority problem: no document stated which system decided what, so both did, and the last writer won. The connector was working exactly as configured throughout.

What the engagement produced was a set of decisions — object ownership, constructed identity, field-level conflict policy, and the observability to detect when the arrangement stops holding — and a technical implementation of those decisions that is, by comparison, unremarkable. That ordering is what carries. Where two systems disagree, the question is which one is entitled to be right.

References

Batini, Carlo, Cinzia Cappiello, Chiara Francalanci, and Andrea Maurino. 2009. "Methodologies for Data Quality Assessment and Improvement." ACM Computing Surveys 41 (3): Article 16. https://doi.org/10.1145/1541880.1541883

Davenport, Thomas H. 1998. "Putting the Enterprise into the Enterprise System." Harvard Business Review 76 (4): 121–131. https://hbr.org/1998/07/putting-the-enterprise-into-the-enterprise-system

Davis, Fred D. 1989. "Perceived Usefulness, Perceived Ease of Use, and User Acceptance of Information Technology." MIS Quarterly 13 (3): 319–340. https://doi.org/10.2307/249008

Gattiker, Thomas F., and Dale L. Goodhue. 2005. "What Happens After ERP Implementation: Understanding the Impact of Interdependence and Differentiation on Plant-Level Outcomes." MIS Quarterly 29 (3): 559–585. https://doi.org/10.2307/25148695

Haug, Anders, Frederik Zachariassen, and Dennis van Liempd. 2011. "The Costs of Poor Data Quality." Journal of Industrial Engineering and Management 4 (2): 168–193. https://doi.org/10.3926/jiem.2011.v4n2.p168-193

Reinartz, Werner, Manfred Krafft, and Wayne D. Hoyer. 2004. "The Customer Relationship Management Process: Its Measurement and Impact on Performance." Journal of Marketing Research 41 (3): 293–305. https://doi.org/10.1509/jmkr.41.3.293.35991

Sia, Siew Kien, and Christina Soh. 2007. "An Assessment of Package–Organisation Misalignment: Institutional and Ontological Structures." European Journal of Information Systems 16 (5): 568–583. https://doi.org/10.1057/palgrave.ejis.3000700

Speier, Cheri, and Viswanath Venkatesh. 2002. "The Hidden Minefields in the Adoption of Sales Force Automation Technologies." Journal of Marketing 66 (3): 98–111. https://doi.org/10.1509/jmkg.66.3.98.18510

Venkatesh, Viswanath, Michael G. Morris, Gordon B. Davis, and Fred D. Davis. 2003. "User Acceptance of Information Technology: Toward a Unified View." MIS Quarterly 27 (3): 425–478. https://doi.org/10.2307/30036540

Wang, Richard Y., and Diane M. Strong. 1996. "Beyond Accuracy: What Data Quality Means to Data Consumers." Journal of Management Information Systems 12 (4): 5–33. https://doi.org/10.1080/07421222.1996.11518099

Conflict of Interest Statement

RevOps HQ is a certified HubSpot Solutions Partner and derives revenue from HubSpot implementation and integration work. This engagement retained HubSpot alongside a competing platform rather than replacing it, and recorded a decision not to consolidate onto HubSpot. Readers should nonetheless weigh the commercial interest when assessing the recommendation.

Acknowledgments

The sales operations staff who worked the 490-record ambiguity queue performed the least visible and most consequential part of this engagement.