Your marketing automation platform is probably not the problem

Core feature lists have converged. Operating fit has not.

Across established suites, feature lists around audience selection, journeys, content, experimentation and reporting have converged. Multichannel platforms extend that machinery across email, SMS, push and paid media. B2B platforms add lead, account and CRM workflows.

Those categories still differ materially in architecture, usability, governance and the work required to operate them. Material differences remain in:

• Data architecture, identity treatment and latency
• B2B, B2C and account-based operating models
• Channel depth and cross-channel coordination
• Decisioning, experimentation and optimisation
• Governance, permissions and auditability
• Integration patterns and engineering dependence
• Usability for everyday and specialist users
• Deliverability expertise, service and support
• Commercial model and the cost of growth

These differences can determine fit. But they are rarely exposed by counting checkboxes. When every credible platform supports the category basics, a longer feature matrix creates the appearance of differentiation without revealing the effort required to operate the product.

AI has not made the basics less important

Some recent innovation is meaningful. Adaptive decisioning, warehouse-connected activation and goal-driven campaign assembly can change how work is done. Generating another subject line in seconds is useful, but it does not resolve a disputed customer definition, a stale consent signal or a journey nobody can safely change.

Salesforce's vendor-sponsored 2026 survey found that 75% of marketers said they were turning to AI to help close the content gap, while 84% still reported running generic campaigns. It also found that 98% encountered barriers to personalisation, with siloed systems and poor data quality the most common reported causes.¹

The useful lesson is not that AI has failed. It is that better generation cannot compensate for missing customer context.

The feature gap has narrowed. The operational gap has not.

A sea of navigation is not an operating model

Many mature platforms make routine work harder than it should be. That criticism is often justified.

Gartner reported in 2024 that 50% of marketers agreed martech was complicated and difficult to use, while two-thirds said learning it took time away from day-to-day responsibilities. A separate Gartner survey of 405 martech leaders found 63% believed marketing lacked the technical skills to integrate and operate some of the technologies in the stack.²

Ease of use should not be assessed by watching a specialist build a polished journey in a prepared demonstration. It should be assessed against the work the customer expects its own people to perform.

That distinction exposes two different problems. The product may genuinely make common work unnecessarily difficult. Or the implementation may have accumulated years of duplicate fields, copied journeys, inconsistent naming, abandoned integrations and permissions nobody is willing to change.

One is a product-fit issue. The other is implementation entropy. Both create operating cost, but they do not require the same remedy.

Before replacing the platform, remove dead assets, consolidate reusable components, document critical data, simplify permissions and establish patterns for common journeys. If routine work remains slow and risky after the environment is made intelligible, the case against the product becomes much stronger.

Marketing automation does not create usable data

It consumes promises made elsewhere.

A field promises to mean what its label says. An event promises to arrive on time. An identifier promises to refer to the same customer across systems. A consent signal promises to be current. An audience promises that the people inside it are eligible for what happens next.

When those promises fail, the platform may still execute, but teams compensate with manual work and lose confidence in every output.

Teams export and upload lists because integrations are late. Analysts reconcile counts because systems disagree. Marketers avoid useful attributes because nobody can explain them. Personalisation is reduced to the few fields considered safe. Every campaign requires another round of validation, and each exception becomes part of the operating process.

Current industry research reflects the scale of the issue. Salesforce found that only 58% of surveyed marketers reported complete access to service data, 56% to sales data and 51% to commerce data.¹ Adobe's 2025 vendor-sponsored study found that 76% of practitioners said siloed data blocked real-time personalisation, while 73% reported inconsistent cross-channel experiences and 72% conflicting messages.³

These are reported perceptions from vendor research, not universal failure rates. They are still a strong warning against treating data access as a secondary implementation detail.

In B2B environments, the same failure appears as disputed lifecycle stages, unreliable lead and account identity, brittle CRM synchronisation, opaque scoring and weak sales hand-off.

Access is not the same as abundance

A platform can contain thousands of attributes and still leave marketers without usable data. The requirement is not to ingest everything. It is to make the data required by priority use cases reliable, understood and available at the necessary speed.

For each material data element, establish:

• A clear business definition and system of record
• An accountable owner
• Identity and consent treatment
• Expected freshness and latency
• Quality thresholds and monitoring
• Access for the people expected to use it
• Behaviour when the value is missing, late or contradictory

This work is less visible than buying a new platform. It is also what allows the platform to become useful.

Automation without contact governance scales fatigue

Several teams can be acting reasonably and still create a poor customer experience.

Acquisition launches an offer. Loyalty sends a benefit reminder. Service triggers an update. A product team starts an onboarding journey. Each communication is valid when viewed alone. The customer experiences the combined pressure.

Channel-level campaign calendars do not solve this. Neither does a frequency cap hidden inside one team's campaign. Contact governance needs to decide what happens when multiple legitimate messages compete for the same person.

A workable policy covers:

• Consent, eligibility and global suppression rules
• Cross-channel and channel-specific frequency limits
• Journey and campaign priority
• Quiet hours and regional requirements
• Transactional, service and regulatory exceptions
• Rules for vulnerable or high-risk customer situations
• Conflict visibility, overrides and audit history
• Ownership of the policy and its exceptions

Modern platforms increasingly provide pieces of this machinery. Adobe Journey Optimizer, for example, documents message and journey caps, quiet hours, conflict detection and priority scores.⁴ That confirms those controls are available in that product. It does not prove that an organisation has agreed the rules, applied them consistently or assigned somebody to govern them.

Product depth still matters. Buyers should examine whether governance works across channels and campaign types, how quickly rules take effect, which profiles and messages they cover, how priorities are resolved and whether exclusions can be explained.

The platform can cap frequency. It cannot decide who owns the customer.

The send button is not a deliverability strategy

A successful send event means the platform handed a message to the next system. It does not mean the message reached the inbox, remained out of spam or protected the reputation of the sending domain.

Google's requirements for senders delivering more than 5,000 messages a day to personal Gmail accounts include SPF, DKIM and DMARC authentication, one-click unsubscribe for marketing messages and spam rates below 0.30%. Its operational guidance recommends keeping reported spam below 0.10% and monitoring authentication, reputation, spam complaints and delivery through Postmaster Tools.⁵

The platform may provide dashboards, authentication support and specialist advice. Those are important differences to assess. None removes the need for an internal owner, agreed thresholds and an escalation routine.

A deliverability operating rhythm should make clear:

• Who owns each sending domain, subdomain and IP strategy
• Which authentication and reputation signals are monitored
• How complaints, bounces and deferrals are trended
• What constitutes an abnormal change in volume or response
• Which thresholds pause or restrict sending
• Who investigates and who decides when sending can resume

Preview is basic hygiene, not complete assurance

Device and inbox previews are mature capabilities. They remain necessary because clients render email differently, but a desktop and mobile screenshot do not prove that the journey is safe.

Adobe's current testing guidance includes representative test profiles, personalisation variants, email rendering across clients and devices, spam checks, conflict detection, journey simulation and formal approval.⁶

Some capabilities have additional dependencies. Adobe's rendering tests, for example, require a Litmus integration.

That is the right scope. Quality assurance should test the decision, data and journey logic as well as the creative. Use realistic customer states, missing values, long values, suppressed customers, unexpected event order, links, accessibility, dark mode, fallbacks and the paths most likely to fail.

What successful marketing automation actually requires

Customers do not need the longest feature list. They need a system that can be operated safely at the speed the business expects.

Gartner's public summary of its 2025 Marketing Technology Survey put overall martech utilisation at 49%, with only 15% of organisations classified as high performers.⁷ This is a broad martech measure, not a marketing automation adoption rate. It is useful because it separates software ownership from activated capability.

These are not capabilities that sit neatly inside one product. They cross marketing, data, technology, risk and customer operations. That is precisely why buying the platform is easier than building the capability around it.

The platform is part of the operating system. The rest sits in people, data, controls and routines.

Before another RFP, identify what is actually failing

Platform dissatisfaction is a reason to investigate. It is not yet a business case for replacement.

1. 01

   Start with the work that matters

   Select three to five priority use cases tied to a business objective, customer need and measurable outcome.

2. 02

   Observe the work, not the process diagram

   Watch marketers build, change, approve and troubleshoot a journey. Record hand-offs, delays, rework and specialist dependencies.

3. 03

   Trace the data end to end

   Follow eligibility, identity, consent, personalisation and measurement data from source to decision to channel.

4. 04

   Inspect the controls around the send

   Review contact policy, deliverability monitoring, quality assurance, access, change control and incident ownership.

5. 05

   Separate the causes

   Classify each constraint as product, implementation, data, process, skills, capacity, governance, ownership or commercial model.

6. 06

   Choose the smallest credible intervention

   Fix, simplify, retrain, reimplement, augment or replace according to the evidence, cost and risk.

Sometimes the platform really is the problem

Diagnosis should not become an excuse to protect an incumbent. Replacement is credible when evidence shows that the product itself is creating a structural constraint, such as:

• Priority use cases cannot meet required latency, scale or channel needs
• Required consent, governance, security or audit controls are unavailable
• Routine work remains disproportionately slow or risky after the implementation is simplified
• Integration patterns create persistent manual work or data copying
• The product direction no longer aligns with the target architecture or customer strategy
• Reliability, service or commercial terms make the current operating model unsustainable

The case is weaker when the same source data, unclear ownership, limited capacity, absent contact policy and informal quality process would move into the replacement unchanged.

Replacement may still be right. A disciplined review makes the requirements sharper, the demonstrations more revealing and the implementation less likely to inherit the same unresolved constraints.