Your team started with two markets and gave each one its own email service provider (ESP) account. Now there are eight. A template change, a new automation step or a consent update has to be checked in eight places. Would one account make the work easier?
Perhaps. ESPs organise these boundaries differently, using accounts, business units, workspaces or subaccounts. Here, the question is what your teams can share and what they need to manage separately within those structures.
In a conversation with Asteroad co-founders Radoslav Matúška and Ján Šácha, we kept returning to the same point: the right structure depends on what you need to share and what you must keep separate. Campaign maintenance matters, but so do access rights, sending domains, consent and business ownership. There is no account count that fits every team.
Count the work that repeats
Separate accounts can be quick to start. A local team can build its own campaign, use its own language and send without coordinating every change centrally. That can be a sensible choice for a short-lived test or a market with a genuinely different programme.
The cost appears when the same work repeats. A welcome journey, abandoned-cart flow or base template may need to be built, tested and updated in every account. Kevin described the practical consequence from campaign development: a template change in two environments means implementing and testing it twice. Across eight markets, a small change becomes a release plan.
A shared account can let teams reuse a journey and vary its content or timing by market. It can also make it easier to recognise a person who shops across markets and to coordinate contact frequency. Yet a single account does not remove complexity. Its audience rules, languages and brand-specific conditions still need owners and tests. If those rules turn one flow into a maze, the maintenance saving may be smaller than it looks.
Check the reasons to keep accounts separate
Some requirements are more important than the convenience of a shared flow. ESPs differ in how they handle them, so check the available controls in your setup before choosing a structure:
| Check | What to establish before deciding |
|---|---|
| Access rights | Can country or brand teams work in one account without seeing data or changing campaigns outside their remit? Test the actual roles and permissions. |
| Sending domains | Can your ESP configure and manage the required domains in one account? Some platforms or setups require separate accounts for different domains. Check the sending and deliverability implications with the platform team. |
| Consent and identity | If one person appears in several markets or brands, can the shared setup keep the relevant permissions and preferences distinct? Decide how records are matched and updated. |
| Team structure | Who owns templates, automation logic, quality checks and releases? A shared account needs clear ownership when local teams work differently. |
| Business independence | Does a brand or market need to operate, report or potentially transfer independently? Separating it later may be harder if its data and journeys are tightly combined. |
Radoslav Matúška described projects in which Asteroad combined multiple brands in one account to coordinate communication. He also noted that access restrictions or separate sending setups can change the answer. Kevin raised another complication: a shared customer record can make brand-specific consent harder to manage. Neither structure solves that by itself.
Use a decision framework, not a default
Before merging accounts or adding another one, work through these steps with marketing, platform, data and the relevant local teams:
- List the non-negotiable boundaries. Test permissions, sending domains, consent handling and any need for independent ownership in the ESP you actually use. If one account cannot satisfy a boundary, plan a separate account for that part.
- Map what is genuinely shared. Identify the journeys, templates, customer records and reporting definitions the markets could reuse. Do not count two programmes as identical just because they have the same name.
- Estimate the work in each structure. For each recurring change, count the accounts, approvals, builds and tests involved. Include the effort of maintaining market conditions inside a shared account.
- Pilot one representative journey. Test the actual permissions, domain setup, consent updates, localisation and release process before migrating every market.
- Choose where to draw the boundary. One account, several accounts or a mixed setup can all be reasonable. Write down why each boundary exists so the next market does not inherit it by accident.
For example, a team with eight markets might share one recurring welcome journey across several markets while keeping a separately run brand in its own account. The boundaries follow the team’s operating needs, rather than the number of markets alone.
Keep the performance story continuous
The account decision also affects reporting. If you split or merge environments, decide how campaign, market and brand names will map across them, and what historical data you need to retain. Otherwise a cleaner campaign setup can leave you with a broken performance timeline. SEINō can bring data from multiple supported integrations into one Workspace, but the useful comparison still depends on the data and history each source makes available.
If one shared campaign sends different content by market, our guide to measuring dynamic emails explains how to preserve those differences in reporting.
Start with the boundaries you cannot compromise, then compare the maintenance work of the structures that remain. The goal is an account setup your teams can operate and change reliably as markets grow.
Reviewing your multi-market ESP setup? Asteroad can help assess the account structure and implement the campaigns and automations that support it.