Integration Capability for Enterprise Omnichannel Strategists: Handling the Common Objections
For an enterprise omnichannel strategist, investing more in integration capability tends to draw a familiar set of objections from procurement, finance, and the broader leadership team. The objections sound reasonable, and many of them have a kernel of truth. They also tend to under-weight the operational reality that omnichannel commerce is increasingly an integration problem and decreasingly a platform problem. Brands that under-invest in integration capability end up with platforms that work in isolation and fail to behave as a single business in front of the customer.
This piece walks through the eight objections that come up most often in enterprise omnichannel conversations and lays out what specifically dissolves each one. The goal is to help the strategist either move the internal conversation forward or honestly conclude that more integration investment is not the right move for their specific situation.
Objection 1: "The Platform Already Does Integration"
The argument: our commerce platform has APIs and webhooks. We don't need to invest more. Integration is solved at the platform level.
What dissolves it: the platform's API surface is one piece of integration capability. Omnichannel integration requires that the platform, the OMS, the ERP, the CDP, the marketing stack, the customer service tooling, the payment systems, the tax and fraud layers, and the analytics warehouse all speak to each other coherently. The platform's API surface tells you what the platform can do. It says nothing about whether the stack as a whole produces a single customer view, a single order truth, and a single inventory truth.
The integration capability question is structural. It includes the iPaaS layer (Workato, Boomi, Mulesoft, Celigo), the event backbone (Kafka, EventBridge, Solace), the data layer (warehouse, reverse-ETL), the orchestration tooling, the API gateway, and the operating discipline that holds them together. The platform's API is a necessary input. It is not the answer.
Objection 2: "iPaaS Is Just a Middleware Cost Center"
The argument: middleware was supposed to die a decade ago. Why are we paying for iPaaS now?
What dissolves it: middleware in the form of monolithic ESBs is dying. iPaaS is something different. The modern iPaaS layer is a strategic capability that lets the omnichannel program coordinate dozens of vendors without writing custom integration code for each pair. The economic argument is roughly: would you rather maintain 30 custom point-to-point integrations across a team of three engineers, or operate 30 connectors on an iPaaS platform with one engineer? The all-in cost comparison consistently favors iPaaS for enterprise omnichannel volumes, and the time-to-change comparison favors it by an even larger margin.
The cost-center framing misses the trade-off. Without iPaaS, the engineering team becomes the integration layer, with worse outcomes at higher cost. iPaaS is a strategic infrastructure investment, not middleware overhead.
Objection 3: "Custom Integration Code Is More Flexible"
The argument: we have engineers. Why not write our own integrations? Custom code is more flexible than iPaaS.
What dissolves it: custom integration code is more flexible in the first six months and less flexible in years two through five. Custom code locks the integration logic into the engineering team's roadmap, ties business changes to engineering cycles, and accumulates a maintenance burden that grows linearly with the number of integrations. iPaaS-based integrations, when properly designed, allow business analysts and integration specialists to modify integration logic without code changes, and absorb vendor API changes through connector updates rather than engineering work.
The flexibility argument is also a hidden personnel decision. Custom code requires engineers who specialize in integration architecture. iPaaS allows for a different staffing model. Enterprises with stable, well-staffed integration engineering teams can build great custom integrations. Enterprises without that staffing model usually produce custom integrations that become unmaintainable within a few years.
Objection 4: "Real-Time Integration Is Over-Engineering"
The argument: most of our integration needs are batch. Real-time event-driven architecture is over-engineering for our reality.
What dissolves it: batch integration was the right answer when the business cycle was slow. Omnichannel has accelerated to the point where most integration use cases now need to be event-driven, even if the consuming systems batch downstream. Inventory needs to move from store POS to commerce platform in seconds, not in nightly batches. Customer profile changes need to propagate to marketing and customer service systems in minutes, not hours. Order status changes need to feed customer service and customer-facing channels in near real time, not in next-day reports.
The "over-engineering" framing usually means "we haven't yet had the production pain of stale data." Enterprises that operate with stale data in omnichannel contexts produce customer-facing failures – inventory promises that don't hold, marketing emails that contradict customer service, store associate experiences that don't match website experiences. Real-time integration is increasingly the operating baseline, not the advanced state.
Objection 5: "Our Vendors Will Just Handle Their Own Integration"
The argument: the vendor sold us on the integration. Let the vendor handle it.
What dissolves it: this works at small scale and breaks at omnichannel scale. Each vendor will handle the part of integration that touches them, and no vendor will own the cross-vendor coherence that omnichannel requires. The customer who has a return started in-store, refunded by the OMS, surfaced in customer service via Gorgias, and reflected in marketing via Klaviyo – that customer's experience is not owned by any one vendor. The integration capability that owns it is the omnichannel program itself.
Vendors will produce point integrations. The omnichannel team has to produce the structural integration layer that coordinates the vendors. Outsourcing that layer to whichever vendor speaks loudest in the moment produces predictable chaos.
Objection 6: "We've Tried Investing in Integration Before, It Didn't Stick"
The argument: we built an integration platform a few years ago. It became technical debt. Why would the next investment be different?
What dissolves it: this is the most useful objection because it's usually rooted in a real history of integration investment that didn't sustain. The patterns that distinguish integration investments that stick from ones that don't are knowable.
Integration investments stick when they have ongoing operational ownership, not just an initial build budget. Many integration platforms get built by a project team that disbands at launch, leaving the platform without anyone responsible for keeping it current.
Integration investments stick when they fit the surrounding stack rather than fighting it. Many integration platforms get built with assumptions about the surrounding vendor landscape that turn out to be wrong, and the integration platform becomes incompatible with where the stack actually goes.
Integration investments stick when they balance build and buy. Many integration platforms are over-built in custom code that should have been iPaaS-based, or under-built in iPaaS where custom logic was actually needed. Both extremes produce unsustainable platforms.
The honest answer to "we've tried before" is that the next investment needs to be structured to avoid the patterns that broke the last one – which usually means structural commitments to operational ownership, vendor-landscape compatibility, and the right build-versus-buy mix.
Objection 7: "AI Will Make Integration Easier"
The argument: AI-driven integration tools are getting good. We should wait.
What dissolves it: AI-driven integration tools are getting better, and they will be useful additions to the integration toolkit over time. They are not currently substituting for the structural integration capability the omnichannel program needs. The integration problems that matter most for omnichannel – cross-vendor coordination, real-time event flow, data consistency across systems, customer record reconciliation – are not yet solved by AI tools at production quality.
The "wait for AI" framing tends to produce two years of delay during which the integration debt compounds. By the time AI-driven integration matures into the operating baseline, the program will already have the integration capability it needs, into which AI tooling will be incrementally absorbed.
The right framing is to invest in integration capability now with the architectural openness to incorporate AI-driven tooling as it matures.
Objection 8: "Our Customer Service Pain Suggests We Need a CDP, Not Integration Investment"
The argument: our customer experience is broken. The answer is a customer data platform, not more integration investment.
What dissolves it: customer data platforms are integration consumers, not integration substitutes. A CDP that doesn't have clean, real-time inputs from the commerce platform, the OMS, the marketing platform, the customer service platform, and the store systems produces stale, partial, or incorrect customer views. The CDP is only as good as the integration layer feeding it.
The order of investment is usually: integration capability first, then CDP. Programs that buy a CDP and try to backfill the integration layer often end up with an expensive system displaying inconsistent data. Programs that invest in integration first and add CDP afterward usually get the CDP value the vendor promised.
How to Make the Internal Case
Enterprise omnichannel strategists who have worked through these objections can frame the integration capability investment around three points.
First, omnichannel commerce is structurally an integration problem. The platforms have stabilized. The differentiator now is the coherence of the stack in front of the customer, which the integration layer produces.
Second, the cost of under-investing in integration shows up as customer-facing failures – inventory promises that don't hold, marketing communications that contradict customer service, in-store experiences that don't match digital. These failures damage the brand and the lifetime value of customers in ways that are hard to recover.
Third, the integration capability investment is best framed as a multi-year structural commitment with operational ownership, not as a one-time project. The previous integration efforts that didn't stick almost always failed because the structural commitment was missing, not because the technology choice was wrong.
The team at Bemeir works with enterprise omnichannel programs across Adobe Commerce, Hyvä, Shopify Plus, Shopware, and BigCommerce, and the patterns that have produced durable omnichannel outcomes are the ones described above – real-time event-driven integration, an iPaaS layer that fits the stack, operational ownership of the integration capability, and a balance of build and buy that fits the program's engineering capacity. The investment isn't cheap, and the alternative is consistently more expensive.
Frequently Asked Questions
Where should an omnichannel program start if integration capability is currently weak?
Start with a structural assessment – what integrations exist, what fails most often, what data is least consistent, where the customer-facing pain is sharpest. The assessment usually surfaces two or three high-leverage integration improvements that produce visible wins quickly while the broader capability investment ramps.
Should the omnichannel program own iPaaS, or should IT own it?
The strongest pattern is shared ownership – IT owns the platform, the omnichannel program owns the integration use cases. Either side owning both alone tends to produce friction or capability gaps.
How big should the integration team be?
For a program with $50M-$500M annual omnichannel revenue, an integration team of three-to-six engineers plus iPaaS access is typical. Smaller teams produce integration debt; larger teams often signal that custom code is being used where iPaaS would be cheaper.
Can we outsource integration capability to a partner?
Partially yes. The platform-level integration work can be partnered, and the iPaaS implementation can be partnered. The ongoing operational ownership has to live with the omnichannel program itself, because the integration capability is too central to the program to outsource entirely.
What is the most common pattern of integration capability erosion?
Loss of operational ownership at launch. The build team disbands, no one inherits the integration platform, and within eighteen months the integrations are out of date, the iPaaS license is under-used, and the team is talking about a new integration platform investment. Preserving operational ownership at launch is the single most consequential pattern for sustaining integration capability over time.
