7 Questions to Ask Before IT Signs off on a New Customer Engagement Solution

If you’re responsible for data, systems, or enterprise architecture in an SAP environment, you’ve likely received this type of request: Marketing wants to adopt a new customer engagement solution and needs IT’s assessment. But the decision rarely comes down to features alone. This big decision also requires evaluating integration complexity, customer data governance, security, compliance, and the long-term cost of supporting another solution.

The instinct for busy IT people is to treat this as a procurement exercise. Check the feature list, confirm the security questionnaire, sign the data processing agreement, and move on.  The challenge is that this approach rarely captures the full architectural impact of the decision, and the gaps often surface 18 months later as a problem you inherit.

A customer engagement solution is more than a marketing tool that happens to touch your data.  These systems read from, write to, and depend on your customer record. Choosing one is an architectural decision. The features that marketing cares about sit atop a foundation you will own and maintain long after the campaign that justified the purchase has ended.

So, evaluate the customer engagement solution as you would any piece of infrastructure. The questions below map to the non-functional requirements that decide whether any solution is well-architected: how it handles your data, how it scales, how it adapts, how flexible it is, how it is secured, and how it ages. None of them appear on a standard vendor scorecard. Together, they predict whether this solution will become infrastructure or become debt.

This is the question that determines everything downstream, so ask this one first.

Every customer engagement solution needs to know who the customer is. The difference between solutions is whether they read that identity from a system you already trust or mint a new one of their own.

When a solution creates its own identity space, you now have two definitions of a customer that must be kept in sync. One system keys on email address. Another keys on an internal account ID. And a  third reconciles some records but not all. The result is familiar to anyone who has run a data team: reports that should match never quite do, and someone spends a significant portion of every week explaining the gap.

A solution that reads identity from your existing system of record inherits the customer definition you already maintain. A solution that builds its own requires you to maintain two customer records for the same individual across two systems. Find out which one you are evaluating before anything else, because no feature on the list is worth the cost of a second source of truth.

True integration cost  rarely appear on the quote. Gartner estimates technical debt consumes 40% of the average enterprise IT budget—and integration maintenance is a major, recurring driver of that number.

The math here is not intuitive, so it is worth making explicit. A stack in which every system can connect to every other is a classic mesh network, and the number of possible connections in a mesh grows quadratically with the number of systems, not linearly. 10 connected systems imply up to 45 possible pairwise integrations. 20 systems imply up to 190. And 90 systems imply more than 4,000. You will not build all of them, but every new solution that requires custom pipelines can add disproportionately to a burden that already compounds.

And each integration is not a one-time build. It is building, testing, monitoring, and remediating work when an upstream schema change breaks the pipeline on a Friday. License fees are typically only a fraction of the true cost of running a solution. The rest is integration, maintenance, and the staff time spent reconciling data that should have matched automatically.

So, the useful question must extend beyond: “Can this tool integrate with our existing tech stack?” Almost everything can be integrated these days, given enough engineering. The real question is: “How much of that integration is pre-built and supported by the vendor against the systems you already run?”

You’ll also want to better understand how much a custom pipeline your team owns forever. A solution that connects natively to your commerce and ERP data is making a very different ask of your roadmap than one that needs you to build and babysit the connection.

When marketing is performing well, the volume only goes up: more contacts, more channels, more sends, and more behavioral events captured per customer. You’ll want to spend time figuring out if the solution holds its performance and availability as that load grows, or whether it degrades at exactly the moment your programs start working.

Scalability is hard to see in a demo because demos run on small data. Ask how the solution scales:

• Does the solution scale horizontally to absorb more load?
• What are the system’s limits?
• How does the solution perform during peak moments, such as the seasonal campaign, product launch, and Black Friday send, when volume spikes well above the daily average?

A solution that buckles under a peak is worse than no solution, because it fails publicly, in front of customers, on the day that matters most.

Here, the architecture underneath matters more than the solution’s own marketing. A solution that reads from data infrastructure already built to enterprise scale inherits that headroom. A solution standing up its own datastore inherits whatever limits that datastore has, and so do you.

The business you are buying for today is not the business you will run this solution in three years from now. New channels will appear. You may enter new regions with new compliance regimes. You might acquire a company or get acquired. The marketing model is constantly shifting. So, the solution your marketing team selects must grow into requirements that did not exist when you signed.

That’s why I always remind other IT leaders that these investments are architectural properties, not roadmap promises. Evolvable systems share a few traits:

• They are modular.
• They separate concerns cleanly.
• They are built on open standards rather than proprietary lock-in.

Ask questions during the evaluation period, such as:

• Can new channels and data sources be added without re-solutioning?
• Does the vendor build documented open standards?
• Can your data leave on open terms if your strategy ever requires it?

A solution that can only grow in the directions its vendor chose to anticipate is a solution you will eventually outgrow.

A useful tell: a solution built on the standards and data model you already run is far easier to evolve because it grows along the same lines as your own architecture.

Evolvability asks whether the solution can be changed to meet new requirements later. Flexibility asks something more immediate: Can the tool handle the range of tasks you need it to do right now, without custom rework for each one?

• A flexible solution behaves like a set of modular bricks. The same underlying capabilities can be arranged to support a simple welcome campaign, a complex multi-channel lifecycle program, and a one-off operational message. And all of that without engineering as a bespoke solution for each.
• A rigid solution forces every new use case down a narrow, opinionated path, and the work to bend it to your scenario lands on your IT team every time.

As a practical test, take three genuinely different requests your marketing team will want to do, and ask how each one is accomplished. If all three are a configuration of the same modular capabilities, the solution is flexible. If each one needs its own workaround, you are looking at rigidity that you will repeatedly pay down the line.

Every vendor you add will widen the surface you must defend.

This is not an abstract concern. A single compromised integration can expose hundreds of downstream customers, as the industry saw in multiple high-profile breaches last year. Verizon’s 2025 Data Breach Investigations Report found that third-party involvement in breaches doubled year-over-year to 30%, and that marketing and analytics tools, which sit outside core IT governance, are a recurring entry point.

The solution itself may be secure. The connection between the solution and your systems, the credentials it stores, and the data it exports are all new exposures that did not exist before you signed.

Confirm these three aspects before signing a new agreement:

• Authentication: Does the solution use a modern standard you already trust? OpenID Connect, built on OAuth 2.0 and using token-based access, is what you want to see. A solution with its own credential store is one more secret to rotate and one more place for one to leak.
• Data export and residency: Can you query and export the data the solution holds on demand, and do you know which region it lives in? You should never be in a position where your customer data is somewhere you cannot reach or account for.
• Consent: Does the solution honor consent states that already exist in your environment, or does the tool expect marketing to manage consent separately, in a place your governance does not reach?

The solutions that expand your perimeter the least are the ones that lean on infrastructure you already operate, rather than standing up parallel copies of them.

Marketing tools are often chosen for a campaign or a major initiative across the company. Yet, they must live with this solution for the years that follow.

The feature that justified this purchase could be irrelevant within a few release cycles. What will still be true is the architecture, so it’s worth having clarity on:  

• Where does the data live?
• How many pipelines do you maintain?
• How does identity resolve?
• How does the tool scale?
• What does your perimeter look like?

Evaluate the solution against what does not change, not the demo the marketing team saw last quarter.

A solution that sits cleanly on top of your existing customer data ages well, because the foundation is stable even as the campaigns on top of it churn. A solution that requires you to rebuild your customer record to accommodate it ages badly, because you are now maintaining that rebuild indefinitely, in service of a marketing strategy that has already moved on.

Marketing is asking for a capability, and it is a real one. The ability to act on customer behavior in the moment is genuinely valuable, and the teams asking for that functionality are not wrong to want it. Your job is not to block that goal. Rather, your job is to ensure the capability arrives without quietly imposing a permanent maintenance tax, a second source of truth, a scaling bottleneck, and a wider attack surface on your team.

The shortest path to all those problems is a solution that treats your system of record as something to be copied. The shortest path away from them is to treat it as something to read.

The same logic applies regardless of which stack you run. If your SAP environment already manages customer data, order history, governance, and scale, then the heavy lifting is done. The remaining challenge is activating that data to power meaningful customer experiences.

The solutions that make that activation straightforward are the ones already wired into the infrastructure you operate. The solutions that make it expensive are the ones that ask you to build that connection yourself and then own it indefinitely.

That distinction will not appear in the feature comparison marketing hands you. So, run these seven questions against whatever solution is under review, and the gaps will be visible before you sign.

We put together a comprehensive architecture and risk assessment that covers integration debt, PII governance exposure, and compliance overhead for organizations running third-party martech alongside SAP. This also includes a vendor consolidation framework you can run against your current stack, whether or not you ever look at SAP Engagement Cloud.