A B2B services company had a data problem that was eating their operational capacity. Customer records lived across five systems: Salesforce for sales, Zendesk for support, Stripe for payments, NetSuite for accounting, and a custom tool for fulfillment. Every new deal required manually reconciling data across all five, populating 150+ fields by copying, pasting, and cross-referencing.
The operations team spent an average of 4 hours per deal on data entry. Not selling. Not supporting customers. Just copying data between systems that didn’t talk to each other.
The Challenge
The obvious solution, a single unified CRM, had been attempted twice. Both attempts failed because:
- Each system served a specific department with specific needs
- Migration would disrupt active customer relationships
- The custom fulfillment tool handled industry-specific workflows no commercial product matched
- Political reality: each department owned their system and wasn’t giving it up
The company didn’t need to replace these systems. They needed to make them work together.
The existing “integration” was a shared spreadsheet template. For each deal, someone would:
- Pull the customer record from Salesforce
- Search Zendesk for any support history
- Look up payment history in Stripe
- Check NetSuite for accounting status
- Query the fulfillment system for service history
- Manually populate fields in each system based on data from the others
- Spot-check for inconsistencies (which were common)
- Escalate conflicts to managers for decisions
The spreadsheet template listed 150 fields. Some came from one system. Some required combining data from multiple systems. Some required human judgment when systems disagreed.
At 4 hours per deal and growing deal volume, this wasn’t sustainable.
What We Built
We built an integration layer that pulls data from all five systems, normalizes it to a common schema, automatically populates fields that can be determined programmatically, and presents only genuine decisions to humans.
Multi-System Data Pull
The system connects to each source:
- Salesforce: REST API for deals, accounts, contacts
- Zendesk: API for tickets, interactions, satisfaction scores
- Stripe: API for payment methods, transaction history, subscription status
- NetSuite: SuiteTalk API for invoices, payments, accounting status
- Fulfillment system: Custom API wrapper for service records
When processing a deal, the system pulls all relevant data within seconds. What previously required 30 minutes of manual searching happens automatically.
Schema Normalization
Each system has its own data model. A “customer” in Salesforce is an “account” in NetSuite, a “user” in Zendesk, and a “client” in the fulfillment system. The same person might have slightly different names, emails, or phone numbers across systems due to entry errors or updates.
The normalization layer:
- Matches entities across systems using fuzzy matching on name, email, and company
- Identifies the canonical value for each field based on configurable source priority
- Flags conflicts where systems genuinely disagree (not just formatting differences)
- Tracks data lineage so every field value can be traced to its source
For example, if Salesforce says the billing contact is “John Smith” and NetSuite says “Jonathan Smith,” the system recognizes these are likely the same person. If Salesforce says the contract value is $50,000 and NetSuite says $45,000, that’s a genuine conflict requiring human review.
Automatic Field Population
Of the 150 fields in the original template:
- 90 fields could be populated automatically with no ambiguity (direct pulls from authoritative sources)
- 45 fields could be derived from existing data using business rules
- 10 fields required data from multiple sources but had clear resolution rules
- 5 fields genuinely required human judgment
The system handles the first 145 automatically. Humans only see the 5 that actually need decisions.
Conflict Detection and Resolution
When the system detects conflicting data, it categorizes the conflict:
Auto-resolvable: Formatting differences, outdated values with clear timestamps, known data quality issues. The system resolves these automatically and logs the decision.
Needs review: Genuinely conflicting information where the source of truth isn’t clear. These surface to human reviewers with full context: what each system says, when the data was last updated, and relevant history.
Escalation required: Conflicts with financial or legal implications that require manager approval.
Human Review Interface
When human input is required, the interface shows:
- The specific decision needed (not all 150 fields)
- What each system currently says
- Historical context (how this field changed over time)
- Suggested resolution with confidence score
- One-click approval or override
A decision that previously required reviewing a full spreadsheet now takes 30 seconds.
The Results
After three months of iterative deployment:
- Deal processing dropped from 4 hours to 15 minutes on average
- Error rates fell by 80% because automated population eliminated copy-paste mistakes
- Data consistency improved across all five systems because changes propagate automatically
- Operations team capacity freed up to focus on actual customer work
The 15-minute processing time isn’t 15 minutes of work. It’s mostly automated processing with brief human reviews for the decisions that genuinely need human judgment.
Beyond Time Savings
The less obvious benefits:
Faster deal closure: When processing takes hours, deals sit in queues. When processing takes minutes, deals close faster.
Better data quality: Every field now has a clear source of truth. When conflicts exist, they’re surfaced and resolved rather than silently inconsistent.
Audit trail: Every data transformation is logged. Compliance questions that previously required manual research now have instant answers.
Scalability: The company tripled deal volume over the following year without adding operations staff. The automation scaled; manual processes wouldn’t have.
Technical Approach
For teams facing similar integration challenges:
Don’t try to boil the ocean: We didn’t replace any existing system. We built an integration layer that lets each system continue doing what it does well while handling the complexity between them.
Start with the data model: Before writing any code, we mapped every field in the template to its source system(s), update frequency, and resolution rules. This mapping document became the specification for the normalization layer.
Handle conflicts explicitly: The temptation is to pick one system as “authoritative” for everything. Reality is messier. Different systems are authoritative for different data. Build conflict resolution rules field by field.
Design for exceptions: No matter how good the automation, edge cases exist. Build workflows for human review from the start, not as an afterthought.
Iterate on rules: The first version of our resolution rules handled 70% of fields automatically. After analyzing exceptions for three months, we reached 95%. Perfect automation wasn’t the goal; reducing human work to genuine decisions was.
Integration Architecture
The system uses an event-driven architecture:
- Trigger: New deal or update in Salesforce fires a webhook
- Data collection: Worker pulls relevant data from all five systems in parallel
- Normalization: Data transforms to common schema with conflict detection
- Auto-population: Rules engine populates fields that can be determined automatically
- Human queue: Remaining decisions queue for review
- Propagation: Approved data pushes back to source systems
Each step is independently scalable and observable. When the payment system is slow, it doesn’t block the rest of the pipeline.
Is This Right for Your Situation?
Multi-system data normalization makes sense when:
- You have 3+ systems containing overlapping customer/deal data
- Consolidating to a single system isn’t feasible (technical or political reasons)
- Manual reconciliation consumes significant staff time
- Data inconsistencies cause downstream problems
- You need audit trails for compliance
The investment is significant upfront. Mapping data models, building connectors, defining resolution rules all take time. But the ongoing savings compound, and the data quality improvements ripple through every downstream process.
Drowning in multi-system data reconciliation? Let’s talk about whether integration automation makes sense for your situation.