Most of What Your Platform Can Do, Nobody Ever Showed You

The consensus — and where it stops

At DigIT Pharma in Berlin in early September, one line ran through almost every conversation: omnichannel is rarely a technology problem, it is an organisational one. Dr Kati Wegner of Pfizer put it that way ahead of the event. BCG’s report Cracking the Omnichannel Code quotes a respondent with the same finding: “The biggest challenge is never technical. It is change management.”

There is nothing to argue with here. It is true. But “organisational” sounds like alignment and change communication. And that is where the discussion stops. In fact the problem has a very concrete shape, and that shape can be described.

What actually happens in the workshop

A new system has gone in. There is a workshop. Marketing describes what it needs — and in doing so describes what it already knows: an audience, an asset, a send date, a report afterwards. The platform side listens and says: doable.

Everyone agrees on a standard. Email deployment, one workflow, maybe two variants. Box ticked. The topic is considered closed.

And with that, the frame for the next three years is set. Not by a decision, but by the absence of one. What the platform could do beyond that never came up — on either side of the table.

I see this pattern repeatedly in my own workshops: teams frame requirements along the capabilities they already know. Options outside that frame are rarely examined concretely — the business unit does not know how the pieces interlock or what depth a CRM system offers. The platform side knows the capabilities but not the campaign plan, and so proposes nothing that nobody asked for.

Three reasons keep this stable. Nobody ever demonstrated it. A release note does not do that. Neither does a click-through training. Demonstrating means: on your own use case, with your own data. The data was never prepared. Many of the interesting capabilities need fields, events or timestamps that were never defined in the batch feed or the API — because at the moment of definition, nobody knew they would be needed. You can get it wrong. And a mistake in HCP communication is expensive. So you stay with the standard, which reliably works.

The third reason is the most interesting, because it is the only one the platforms already ship an answer for.

Two questions before the send. One after.

The answer consists of three tools. Two of them answer what will happen. The third answers whether it made any difference — and that can only be asked after launch. In my projects, I have yet to meet any of the three as a fixed part of a campaign process.

Question 1 · Does the journey run the way we built it?

Adobe Journey Optimizer has Journey Dry run for this. The journey runs on real production profiles, but: “Profiles in Dry run mode are not contacted, ensuring no risk of sending communications or impacting live data.” Channel nodes for email, SMS and push are not executed; custom actions are disabled.

What a campaign team sees before go-live: how many profiles arrive at each node, which branch actually fires, where the audience drains away. The numbers sit directly in the journey canvas, at the nodes where the decisions are made.

That is the difference between “we assume roughly 5,000 profiles will take the email path” and “we checked”.

What happens in those 70 seconds: A mismatched spelling in the channel rule — EMAIL in the profile, E-MAIL in the query — pushes 5,000 matching profiles into the default path. Nothing fails technically; the inspector shows the cause right at the node. After the correction, run B confirms the expected distribution. 1,000 profiles remain without a suitable channel — a checkpoint of its own, not a malfunction.

A content approval does not catch this error — it reviews the message, not the condition. The delivery report afterwards does not flag it either: it shows what went out, not what should have gone out. The gap only becomes visible when expected and actual path distribution are compared — which is exactly where the dry run looks.

The one limitation worth stating: according to Adobe’s documentation, Journey Dry run is currently a Limited Availability feature, “being rolled out globally over time.” It is documented, but not automatically available in every instance. If you plan around it, clear that with your Adobe contact first.

Further limits, briefly: after 14 days the journey automatically reverts to draft. The profiles count against the engageable-profiles quota, the journey against the live-journey quota. Reporting values disappear once the dry run is stopped. Wait activities are off by default and can be switched on — but that does not make the dry run a complete check of timing behaviour: for journeys with a scheduled read-audience activity, Adobe anchors the schedule to the moment of dry-run activation, not to the configured time.

Question 2 · What happens to one specific person?

That is a different question, and it has a different tool. The dry run delivers volumes. It does not tell you why this particular physician ended up in this particular branch.

For that there is Journey Simulation: temporary simulated users whose path through the journey is logged step by step — with timestamp, branching decision and errors. And, the underrated part in my view: a coverage view showing which paths the run actually touched.

This is a question I rarely hear in campaign teams: have we ever run through every branch of our journey — or only the one we had in mind?

Adobe has since documented how to choose between the three validation methods:

Method	Data	Sends real messages?	Use for
Journey Simulation	temporary simulated users	yes — to the execution addresses of the simulated users	fast iteration on new branches
Journey Test mode	persistent AEP test profiles	yes — to the real inboxes of the test profiles	checking branch and message logic manually
Journey Dry run (Limited Availability)	real production audience	no, actions are skipped	reach and branching at real scale

The sentence that settles the most common worry is in the documentation verbatim: “None of these methods contact real customers.” Two of the three do send messages — but to addresses you entered yourself.

Adobe’s own recommendation: simulation while building, dry run immediately before publishing. Test mode when you want to walk through manually with real, persistent test profiles.

Question 3 · Did the campaign achieve anything?

The first two questions concern execution. This one concerns value — and it can only be answered after launch.

A campaign report says 3,900 delivered and a 31 percent open rate. What it does not say: how many of those physicians would have booked the appointment anyway?

No report answers that — only a comparison does. In Journey Builder that runs through the Random Split activity: “Contacts are grouped in up to 10 configurable paths that you create.” One of those paths stays empty. Whoever lands there receives nothing.

Under suitable conditions — random assignment, stable group membership across the runtime, identical measurement on both sides — the difference between the two groups is an estimate of the campaign’s incremental effect. Not an exact number, but one with an uncertainty you can quantify. Which is more than an open rate will ever deliver.

Two limits: “Each path is populated randomly, so its distribution of contacts often doesn’t match the configured percentage exactly.” Configure five percent on 800 physicians and you will not get 40. And five percent is not a universal figure — how large the control group needs to be depends on how small an effect you still want to be able to detect.

What each stack delivers — and where one stops

Anyone working in both worlds should know this comparison before promising a team anything.

Level 1 · Does the content render correctly for this person? Subscriber Preview and Test Send renders the email with the data of one selected subscriber: “Marketing Cloud Engagement uses the selected subscriber’s data strictly to render personalization and dynamic content.” The test send goes exclusively to the addresses in the Recipients tab. Limits: test sends count against your purchased send allowance, and nothing is delivered to a status of unsubscribed, bounced or held.

Level 2 · Does a contact take the right path? Journey Testing in Journey Builder, with a data extension as entry source: “configure a test to simulate a journey with real contacts”, and specifically “without sending messages to them or affecting tracking or reporting”.

Important for expectation-setting: the test send is off by default — “The test is set to Do Not Send Messages by default” — but it can be switched on with Send Only Test Messages and a stored address. So: the same idea as Adobe’s, with the default inverted.

Limits: up to ten contacts per test. “Test mode simulates random and decision split activities, but ignores wait times and contact entry settings.” Custom activities are skipped. The method is not available for single-send journeys.

Level 3 · How many reach which node, at real scale? Here there is no documented equivalent. Journey Builder has no mode that runs the full production audience through and reports node counts without sending.

What you do instead: count the entry data extension, reconstruct the branches against the consent, frequency and approval fields by query, and model the volumes by hand. It works — it is simply labour instead of a button, and it assumes someone knows which fields actually drive the branching in the first place.

Question	Adobe Journey Optimizer	Salesforce Marketing Cloud
Does the content render correctly?	Journey Test mode	Subscriber Preview and Test Send
Does the contact take the right path?	Journey Simulation · Test mode	Journey Testing, up to 10 contacts
Sending during the test	sends to your own test addresses	off by default, can be enabled
How many reach which node, at real scale?	Journey Dry run (LA)	no equivalent — manual work on the data layer
Is timing checked too?	partially, with wait activities enabled	no, wait times are ignored

This table is too small for a platform decision, and it is not meant to be one. It is meant for a different question: how much certainty a team in either stack can actually have before it hits send.

And two questions for the data layer

The three tools above are documented. Two further points are not features but questions — and both can be answered without a project.

Which events do we even have available as a triggerable event — and with what delay? What lands in the customer data platform is not automatically available as a trigger. Between “the event is captured” and “the journey can react to it” sit schema, ingestion type and cadence. The answer usually surprises in both directions.

What actually becomes available at portal login? When an HCP signs in to a portal, a pseudonymous visitor can become a known profile. Which behaviour is then joined to the CRM record is decided by the identity model, the integration and permitted data use — none of it happens automatically. Which attributes become usable is an architecture question. But it is above all a marketing question, because what personalisation is possible hangs on it.

What the numbers say

The BCG report draws on a benchmark study of more than 100 senior omnichannel leaders in biopharma and medtech. Two lines from it fit the pattern: 60 percent are not satisfied with their next-best-action engine, and 90 percent follow its recommendations in less than 60 percent of cases. Alongside that: 97 percent consider omnichannel business-critical, 90 percent struggle with data silos, and 95 percent cannot clearly measure omnichannel ROI.

My explanation — and it is an explanation, not proof: an engine decides on data that was often never prepared for that purpose, and its suggestions are hard to verify as long as the validation tools are not part of the process. The numbers show the pattern. They do not establish the cause.

The objection you have to raise yourself

You can read all of this differently: perhaps the recommendations are simply bad, and the team is right to ignore them. That would be a quality problem, not a knowledge problem.

The objection is fair. It only moves the question one level down: why are they bad? An engine decides on the basis of the data it sees and the rules somebody wrote. If the profile is incomplete and the rule was never run against real data, it will reliably produce weak suggestions. That cannot be proven from the figures. It can be checked, though — on a single concrete journey.

What the layer underneath can do

This, as I see it, is the actual job of a MarTech or omnichannel architect, and it has three parts.

Make it visible. Not as a feature list, but on the team’s own use case, with their own data, in a session where the marketing team sees for itself what comes out. A dry run on your own audience convinces differently than a screenshot from a demo environment.

Make it safe. The most common reason an idea never gets tried is fear of the mistake. Dry run and simulation exist for exactly that. Build those tools into the campaign process and you take the risk out of experimenting — which removes the strongest argument for the standard.

Create the preconditions before anyone asks. The interesting capabilities almost always fail at the same point: a field, a timestamp or an event that was never defined in the interface. Whoever owns the data layer and knows what marketing might want next year creates those fields in advance. That is the difference between a platform that meets requirements and one that enables them. And where a tool is missing, like the dry-run equivalent in Marketing Cloud, the job is to rebuild it on the data layer — rather than telling the team it cannot be done.

The question to take away

Not: do we have the right platform? But: who in your organisation shows the business units what the system can do — and who makes sure they can try it out safely?

If the answer is nobody, that explains more than any technology evaluation. And it also explains why, three years on, the same email deployment is still running — the one everyone agreed on back in that workshop.

Sources: Adobe Experience League on Journey Dry run and on choosing a validation method; Salesforce Help on Journey Testing and Random Split; all retrieved 09/2026. Boston Consulting Group, “How Biopharma and Medtech Leaders Can Get Omnichannel Right”, June 2025, benchmark study of more than 100 senior omnichannel leaders in biopharma and medtech. DigIT Pharma 2026, Berlin, 9–10 September 2026.

What omnichannel means for marketing, analytics, leadership and architecture respectively is covered in the foundations article → What omnichannel marketing really means