Seth
Not Every Martech Integration Should Be Built
Marketing technology makes almost anything sound possible.
- Connect the CRM to the distributor portal.
- Send opportunity updates back through an API.
- Sync campaign information between platforms.
- Create real time lead status updates.
- Automate every handoff.
- Build a custom application.
Technically, many of these ideas can be built.
That does not mean they should be.
One of the most important questions in martech is not:
“Can we integrate these systems?”
It is:
“Is this integration worth building at all?”
The Challenge:
Technical Possibility Can Hide Operational Complexity
We recently evaluated a common B2B attribution problem.
- Marketing generated a lead.
- The lead entered the company’s CRM.
- Some leads were then forwarded to independent distributors.
At that point, visibility largely disappeared.
The natural solution sounded obvious: Connect the distributors back into the CRM so the company can see whether each lead became an opportunity or customer.
Conceptually:
Company CRM
↓
Lead Sent to Distributor
↓
Distributor CRM
↓
Opportunity Created
↓
Status Sent Back
↓
Company CRM Updated
That would create much better closed loop attribution.
It would also create a potentially enormous integration project.
The Hidden Complexity
Before building anything, we started asking practical questions.
- How many distributors are involved?
- Do they all use the same CRM?
- Do they have APIs?
- Will they provide technical access?
- Who pays for their implementation work?
- Will they agree to send data back?
- Will the data mean the same thing across every distributor?
- What happens when one distributor changes systems?
- Who maintains each integration?
- What if a distributor does not use a CRM at all?
Suddenly, a simple looking integration becomes a network of separate technical and operational relationships.
The architecture might look more like:
Company CRM
↓
Distributor A CRM
Distributor B CRM
Distributor C CRM
Distributor D Spreadsheet
Distributor E Custom System
Distributor F No System
Each path may require different logic.
That changes the business case completely.
The Goal:
Solve the Business Problem With the Least Necessary Complexity
The actual business question was not:
“How do we integrate every distributor CRM?”
It was:
“What happened to the leads we gave our distributors?”
Those are very different questions.
Once the problem was reframed, simpler solutions became possible.
That is the principle we use when evaluating martech integrations.
Do not begin with the integration.
Begin with the information or business action you need.
Step 1:
Define the Decision the Data Will Support
Before building an integration, we ask:
What will we do differently once this data exists?
If the answer is unclear, the project may not be ready.
For distributor lead attribution, useful outcomes might include:
- understanding distributor follow up
- measuring lead quality
- estimating influenced revenue
- comparing distributor performance
- improving lead routing
- identifying leads that never receive follow up
Those outcomes help determine how much information is actually required.
Step 2:
Identify the Minimum Data Needed
A full CRM synchronization might provide hundreds of fields.
The business may only need three.
For example:
- lead received
- opportunity created
- sale completed
Maybe revenue is useful too.
Maybe a reason for lost opportunity matters.
The point is to define the minimum viable dataset before defining the technology.
More data is not automatically more valuable.
Step 3:
Map the Human Dependencies
Many integration projects are treated as purely technical.
They are not.
External integrations frequently depend on people and organizations outside your control.
That may include:
- distributors
- franchisees
- sales teams
- agencies
- vendors
- partners
- IT departments
If the process requires every partner to consistently perform a new action, the human adoption challenge may be larger than the technical challenge.
Architecture needs to account for that reality.
Step 4:
Evaluate Technical Variability
If every partner uses the same system, integration may be relatively straightforward.
If each partner uses different technology, complexity grows quickly.
We consider:
- API availability
- authentication methods
- data formats
- custom fields
- rate limits
- security requirements
- vendor restrictions
- implementation costs
- maintenance requirements
A technically possible integration can still be economically unreasonable.
Step 5:
Calculate the Maintenance Surface
Building an integration is only the beginning.
Someone needs to own:
- credentials
- API changes
- field changes
- system upgrades
- failed records
- monitoring
- partner onboarding
- partner offboarding
- troubleshooting
- documentation
The more systems involved, the larger the maintenance surface becomes.
This cost should be considered before the project starts, not after the first integration breaks.
Step 6:
Look for the Path of Least Resistance
Once we understood the distributor challenge, an easier model emerged.
Instead of integrating directly with every distributor’s technology, the company could potentially create a lightweight update workflow.
For example:
Lead Sent to Distributor
↓
Unique Lead or Opportunity Identifier Included
↓
Distributor Receives Update Link
↓
Distributor Selects Status
↓
Company CRM Record Updates
- The distributor does not need to change their CRM.
- They do not need to expose an API.
- They do not need to implement custom development.
They simply provide the small amount of information the company actually needs.
This is less elegant from a systems integration perspective. However, it may be much better from a business perspective.
Step 7:
Automate Only Where Automation Creates Value
If distributor volume becomes large enough, deeper integrations may eventually make sense.
That is fine.
Architecture can mature.
- A lightweight process may be the correct first stage.
Later:
- Manual Update can become a structured update form
then
- Automated Partner Integration
when volume and value justify it.
Technology should scale with the business problem.
The business problem should not be inflated to justify the technology.
The Outcome:
A Smaller Solution Can Produce the Same Business Insight
The most sophisticated solution is not automatically the best one.
If the organization primarily needs to know whether leads progress, a simple status passback may answer the question without requiring dozens of custom integrations.
That can mean:
- faster implementation
- lower cost
- less partner resistance
- easier maintenance
- fewer security dependencies
- simpler training
- easier troubleshooting
The solution becomes easier to operate because it was designed around the actual requirement.
Why This Matters for Marketing Teams
Modern martech encourages integration.
Every platform promotes APIs, connectors, automation, and synchronization.
Those capabilities are valuable but they can also create unnecessary complexity.
Marketing teams can end up maintaining technology ecosystems that are far more complicated than the business processes they support.
Good martech architecture is not about maximizing integration. It is about minimizing friction while preserving the information and automation the business actually needs.
A Simple Martech Integration Framework
Before building a new integration, ask five questions.
1. What business problem are we solving?
Describe the outcome without naming any technology.
2. What is the minimum information required?
Identify the smallest dataset that can answer the question.
3. Who must participate?
Consider internal teams, vendors, partners, distributors, customers, and IT.
4. What will this cost to maintain?
Include future changes, not just initial development.
5. Is there a simpler way?
Manual does not automatically mean bad.
A small structured process can be better than a fragile automated system.
What We Learned
Start with the question, not the API.
An API is an implementation option, not a strategy.
Partner integrations introduce organizational dependencies.
Technology cannot solve a process that external partners will not adopt.
Minimum viable data is powerful.
Sometimes a few status fields provide most of the business value.
Maintenance is part of the project cost.
Every integration becomes another system someone has to support.
Manual workflows can be strategic.
A lightweight structured process may be the correct solution at lower volume.
Architecture should be allowed to evolve.
Start with the simplest reliable process and automate further when the business case becomes strong enough.
Martech Integration FAQs
Should every marketing platform be integrated with the CRM?
No.
Integrations should exist when they support a clear business process or measurement requirement.
Connecting systems without a specific need can create unnecessary technical debt.
When is a custom API integration worth building?
A custom integration becomes more attractive when the process has meaningful volume, repeated manual effort, stable systems, clear ownership, and business value that outweighs implementation and maintenance costs.
Are manual processes always bad?
No.
A well structured manual process can be the most efficient solution for low volume workflows or situations involving many external partners.
How should marketers evaluate martech integrations?
Start with the business question, required data, process volume, participating teams, technical compatibility, maintenance requirements, and simpler alternatives.
What is technical debt in martech?
Technical debt is the ongoing complexity created by systems, integrations, custom logic, outdated configurations, and processes that require continued maintenance.
Integrations can create technical debt when they are built without sufficient long term value.
The Best Integration May Be the One You Do Not Build
Marketing technology teams are often rewarded for making systems more connected.
Sometimes the better decision is to make the architecture simpler.
The Agency Co-Op helps organizations evaluate marketing technology, analytics, CRM, automation, attribution, and reporting requirements before adding unnecessary complexity.
We believe one question should come before almost every major martech implementation:
Should we be doing this at all?
If the answer is yes, then we build the simplest architecture that solves the problem.
If the answer is no, avoiding the integration may be the most valuable technical decision we make.