After spending years working in Salesforce Marketing Cloud, you start to realize that building a journey is rarely the difficult part. The platform gives you plenty of ways to build, automate, and personalize customer communications.

The complexity shows up when you have to do that hundreds of times, across dozens of business units, without losing control of the data or creating an environment that only two people on the team know how to operate.

We saw this with Atlantic Coast Automotive (ACA). The program grew to more than 600 customer journeys across 55+ business units. On paper, 600 journeys sounds like the headline. From an SFMC implementation and operations perspective, it really wasn’t. The bigger challenge was creating the data, audience, deployment and governance foundations that could support that volume without turning every new journey into a custom project. (Mavlers case study)

The first thing that gets difficult is data

When an SFMC environment is small, you can sometimes get away with knowing where a few data extensions come from and who is responsible for refreshing them. That changes pretty quickly as the environment grows.

A journey can be perfectly configured and still send the wrong communication if the data feeding it isn’t reliable. And when you’re running hundreds of journeys, small data issues don’t stay small for very long.

ACA had data coming into SFMC from its broader customer data environment, including Treasure Data CDP. As the program expanded, we had to put more structure around how that data was brought into Marketing Cloud, including staging and incremental synchronization. The objective was fairly simple: give the journeys a cleaner and more predictable data layer to work with.

This is the kind of work that doesn’t necessarily get noticed when everything is working. But it becomes very noticeable when it isn’t. If one journey is using a customer’s current status and another is using an old value sitting in a different data extension, you don’t have a Journey Builder problem. You have a data architecture problem.

At scale, you need to know where an attribute comes from, which system owns it, how often it is refreshed and what happens when the value is missing or changes. You also need consistent definitions. If different teams have different interpretations of something as basic as an “active customer”, those differences eventually find their way into journey entry criteria, segmentation and reporting.

Then there is the audience problem

The next thing that tends to get messy is segmentation.

It is easy enough to write a SQL query for a campaign, populate a data extension, and use it as an entry source. Do that hundreds of times across multiple teams, however, and you start creating multiple versions of the same audience logic.

One team defines an audience one way. Another makes a small change. Someone copies an old query six months later. Nobody has technically done anything wrong, but the organization is now working with several versions of what should be the same customer segment.

For a program like ACA, audience management had to become more deliberate. Audience Builder, data extensions and SQL-based segmentation were used as part of a broader approach to creating and activating customer audiences.

The practical difference is significant. Instead of asking a campaign manager to figure out the audience from scratch every time, you create reusable logic and clear rules around eligibility, exclusions and customer status. That may not sound particularly exciting, but it saves a huge amount of time once the number of campaigns starts climbing.

You can’t build every journey from scratch

The same thing applies to journey development.

With 55+ business units, there was no practical way to treat every journey as a completely new implementation. At the same time, standardizing everything would have been just as problematic because different business units have different customer and operational requirements.

The answer was to standardize the way journeys were built and deployed, rather than trying to make every journey look the same. That means having sensible naming conventions, consistent data extension structures, reusable journey patterns, documented SQL logic, QA processes, and a clear path from development to production.

These aren’t particularly glamorous parts of SFMC. Most marketers don’t wake up excited about folder structures or deployment checklists. But when you’re managing hundreds of journeys, they make a very real difference.

If every new journey requires someone to remember a different set of steps, the process depends too much on individual people. When the process itself is documented and repeatable, you can bring more people into the operation without having to transfer years of tribal knowledge to each of them. That is when an SFMC program starts becoming scalable.

At some point, governance becomes part of the technology

There is another problem that tends to appear later: nobody knows exactly what is still running.

This happens in almost every large Marketing Cloud environment. Journeys get launched and stay active. Automations continue running because nobody wants to risk switching them off. Data extensions accumulate. A campaign that was supposed to run for six months is still sitting in the account two years later.

Now multiply that across 55+ business units. At that point, governance isn’t about adding unnecessary process to marketing. It is about knowing what your SFMC environment actually contains.

For each journey, you should be able to answer fairly basic questions: Who owns it? What data does it use? Which automation populates that data? What are the entry and exclusion criteria? Is the journey still relevant? When was it last reviewed? What happens if an upstream process fails? ACA’s environment brought together Journey Builder, Automation Studio, Audience Builder, and Analytics Builder, along with capabilities such as Einstein Send Time Optimization. Monitoring and optimization had to be part of the operating model because simply launching the journeys was no longer enough. (Mavlers case study)

That is an important shift in mindset. When you have a handful of journeys, you’re managing campaigns. When you have hundreds, you’re managing a marketing technology environment.

The 600+ number isn’t really the point

It would be easy to look at ACA and focus on the fact that more than 600 journeys were supported across 55+ business units. But the number of journeys isn’t what makes the program interesting. What matters is what had to sit behind those journeys: cleaner and more controlled data flows, reusable audience logic, repeatable deployment processes, QA, ownership and governance.

We’ve worked on SFMC environments where the number of journeys looked impressive but making a simple change was painful because nobody was sure what else depended on it. We’ve also seen smaller environments that were much easier to scale because the underlying architecture and operating processes had been thought through early.

Journey count, on its own, doesn’t tell you very much about SFMC maturity.

A mature environment is one where the next journey doesn’t create a disproportionate amount of work. You know where the data comes from. You know how the audience is being built. You understand the dependencies. The deployment process is repeatable. Someone owns the journey after it goes live. And there is enough visibility to know when something needs to be cleaned up or changed.

That’s the difference between having a lot of journeys and actually being able to operate SFMC at scale.

Before adding another 50 journeys

If your roadmap calls for another 50 or 100 journeys, it is tempting to start with the campaign requirements and work backwards. We’d start somewhere else.

Look at the data first. Are the right attributes available and reliable? Are you synchronizing data predictably? Are teams creating their own versions of the same audiences? How much SQL is duplicated? Are there clear deployment and QA processes? Can someone new to the team understand the dependencies between data extensions, automations, and journeys? And do you know which journeys are still relevant?

These questions are much less exciting than designing the next customer journey, but they become increasingly important as the SFMC environment grows. The goal isn’t simply to get from 100 journeys to 600. The goal is to build an environment where adding the next 50 doesn’t make the previous 600 harder to manage. Before adding another 50 journeys, assess whether your existing SFMC environment can support the next stage of scale.

Explore the SFMC Maturity Assessment →