A Three-Part Series on Architecture, Identity and Real-Time Marketing
Most marketing technology problems don’t arrive looking like technology problems.
They show up as a customer receiving an abandoned-cart email after she has already completed the purchase. This is not good.
They show up as sales calling someone a qualified lead while marketing continues sending introductory nurture emails. Stop! You’re doing way too much.
They show up as three dashboards with three different conversion numbers and a meeting full of very smart people trying to decide which one is least wrong.
Eventually, someone says:
“We’re waiting for the systems to sync.”
Everyone nods because, somewhere along the way, this became normal. It shouldn’t be.
Your customer doesn’t know which platform owns the mistake. He or she doesn’t know that the overnight file failed, the identity rule didn’t match or the service record hasn’t reached marketing yet. Don’t tell them, it’s an overshare.
She only knows your company just asked her to buy something she already bought.
This series is for the marketing leaders, CRM owners and data teams who know their technology is working very hard but still isn’t working together.
We’ll start with the architecture. Then we’ll talk about identity. Finally, we’ll look at the customer moments where tomorrow is simply too late.
Stop Paying the Sync Tax
Your team isn’t slow. Your systems keep making them wait.
One of the most expensive sentences in marketing is: “The data should be there tomorrow.”
It sounds harmless. It rarely is. Maybe a campaign launch has to wait because the audience count in the CRM doesn’t match the count in the marketing platform.
Maybe a marketer downloads a file, cleans it up, adds a suppression list and uploads it somewhere else because that is the only way to get the campaign out the door.
Maybe sales sees a high-intent lead hours after the person requested information.
Maybe a consent change is sitting in one system while another system is still sending messages.
I call this the sync tax. It’s the time, money and trust a company loses while its systems wait for one another to catch up. And almost every enterprise marketing organization is paying it.
The sync tax hides in ordinary work
You probably won’t find a budget line called “cost of disconnected systems.”
The expense is scattered across the organization. It’s the analyst comparing two reports before every executive meeting.
It’s the marketer manually moving a list because the integration is unreliable.
It’s the campaign that launches a day late, and a dollar short. It’s the salesperson who follows up after the customer’s interest has cooled. Yikes!
It’s the service team explaining why a promotional message went out during an active complaint.
It’s six capable people doing work the architecture should have handled. Over time, these workarounds stop feeling temporary. They become part of the process.
Someone creates a spreadsheet. Someone adds a weekly reconciliation meeting. Someone can pick up the Starbucks. At the same time, someone else becomes the person who knows how to fix the file when it breaks.
The business starts designing its work around the limitations of the technology. That is usually the moment when the technology begins to run the company rather than support it. It’s the classic “the tail wagging the dog.”
We didn’t build these stacks badly
Most companies didn’t set out to create a complicated marketing environment.
The complexity accumulated one reasonable decision at a time. The team needed an email platform.
Then SMS. Then a consent solution. Then a customer data platform. Then personalization.
Then better analytics. Then a new commerce platform.
Each tool solved a real problem. It also created another place where customer information had to be copied, mapped, scheduled, reconciled, or interpreted- oh my!
Eventually, the marketing team had to understand not only what the customer did, but which system knew about it and when the next system might find out.
That’s a lot to ask of a team that is also supposed to be creating campaigns, growing revenue and improving the customer experience.
Why native architecture matters
This is what makes the shift toward Salesforce Marketing Cloud Next so important.
Marketing Cloud Next is designed to operate on Salesforce’s core platform, closer to the CRM data, workflows and customer context already being used by sales, service and commerce.
I don’t think the real headline is that companies will never need another integration. They will.
Enterprise organizations will still have ecommerce platforms, data warehouses, mobile applications, advertising platforms, privacy tools and plenty of other systems that need to connect.
The more useful headline is this:
Marketing has an opportunity to stop operating like a guest in the customer record.
When marketing works closer to the same platform and data used by the rest of the business, the team has a better chance of responding to what is actually happening.
The purchase can influence the journey. The service case can affect the promotion.
The sales conversation can change the nurture path. The customer’s consent can be applied more consistently.
That is where the architectural shift becomes meaningful. Not on a diagram. In the customer experience.
Don’t move the old mess into the new house – please just don’t do it
Here’s where I see companies get into trouble.
They purchase a modern platform and immediately begin recreating everything from the previous environment.
Every field.
Every audience.
Every workflow.
Every custom rule.
Every spreadsheet someone has used since 2019. Seriously, I had one client send me spreadsheet dated 2017.
No one stops to ask why the process exists or whether the company still needs it. No taxonomy, no planning.
The result is a beautiful new platform carrying years of old decisions. Like the old concert t-shirt you never wear. That isn’t transformation. It’s relocation.
Before you rebuild anything, hold a retirement conversation and prepare to let it go, if it doesn’t serve your transformation efforts.
Look at each field, rule, audience and journey and decide: Do we still need it? Who owns it? Is the same logic being maintained somewhere else? Does it support the way the business works today?
Would we design it this way if we were starting now? I’m sure the answer is no.
You may be surprised by how much of your implementation effort is tied to recreating processes no one particularly likes or trusts.
What I would do before the next platform workshop
Pick one customer journey that everyone already knows is broken. Not the entire ecosystem. One journey.
Choose the abandoned-cart campaign that continues after a purchase. The lead nurture that doesn’t stop when sales begins working the lead. The consent update that takes too long to reach activation.
Then put the actual process on a page. Where does the signal begin? Which system receives it first? Where does it go next? How long does each handoff take? Where does someone touch a spreadsheet? Where is the same rule being calculated twice? What happens when one step fails?
Use real timestamps whenever possible. “Near real time” and “daily” can mean very different things to different teams.
Once the journey is mapped, circle every place where the business waits, reconciles, rekeys or manually verifies information. Those circles are your sync tax. That exercise will tell you far more than another product demonstration.
The platform can’t make the operating decisions for you
A native architecture can reduce unnecessary handoffs. It can’t decide who owns consent.
It can’t define what makes someone an eligible customer. It can’t tell sales and marketing which lead-status definition they should both use.
It can’t resolve a disagreement about which system is authoritative. Those are business decisions.
And honestly, they are usually the decisions that determine whether the new platform feels transformative or simply newer.
The companies that get this right don’t treat architecture as a technical workstream happening somewhere in the background.
They bring marketing, sales, service, data, legal and technology into the same conversation early enough to make shared decisions.
That is where the real modernization happens.
Bring me the ugly diagram
At Mar Dat, these are some of my favorite conversations because you don’t need a perfect deck to get started. Bring me the journey your team complains about in Slack.
Bring the two reports that never agree. Bring the spreadsheet everyone says is temporary but no one is willing to delete.
We can usually tell fairly quickly whether the real issue is latency, duplicated logic, ownership, weak data or some combination of all four.
Call it a working session, not a sales call.
Book a conversation with meat Mar Dat and bring the ugly diagram. We’ll figure out where your sync tax is hiding and where I would start fixing it.
Next in the series
Once the systems begin sharing information more effectively, there is another question waiting for us:
Are they all talking about the same person? Here’s a hint – unified customer profiles.
Ready to talk about your agents?
Tell us what you want your team to hand off, and we will map the first agent with you.
