Salesforce Marketing Cloud Implementation

A Salesforce Marketing Cloud Implementation You Only Have to Do Once

A Marketing Cloud implementation is the build: the contact model, the business unit and permission structure, the sending infrastructure, the integrations, the template system and the journey framework. Twopir Consulting designs each of those before configuring any of them, builds in increments you can review, and validates against your real data before anyone sends to a customer.

Scope Your Implementation Marketing Cloud Consulting
  • 12+ Years of CRM and marketing platform delivery
  • 250+ Platform deployments delivered
  • 98% Client retention rate
Implementation Map
WHAT AN IMPLEMENTATION DELIVERS Contact model Data extensions, keys, relationships Architecture Business units and roles Brands, regions, who can send what Architecture Sending infrastructure Domains, authentication, IP warming Build Integration layer CRM, commerce, warehouse feeds Build Content and journeys Templates, blocks, entry sources Build TWOPIR DELIVERY METHOD Design First Signed off before anything is built Reviewable Builds Increments you can actually see Real-Data Validation Your records, not test rows 2πr AT GO-LIVE An org your team can run without us Documented, trained, with the runbook handed over A design you own, whatever happens next The architecture document is yours from phase two
Scope

What a Marketing Cloud Implementation Actually Contains

Four workstreams. They are listed in the order they have to happen, not the order they are usually attempted — most overrunning builds are a team that started with templates because templates are visible, and discovered the data model in month three.

Workstream 01

The contact model and data layer

Before a single data extension is created, we decide what a contact is in your business, which attributes belong on it, and how the tables relate. This is the decision everything downstream inherits — audience size, frequency capping, unsubscribe handling, contact count and therefore cost all resolve from it.

  • Contact model design and key strategy in Contact Builder
  • Data extension schema, relationships and retention policy
  • Attribute groups and population strategy
  • Naming conventions and folder governance that survive year two
  • Consent and preference data structure
Workstream 02

Business units, roles and permissions

Who can send to whom, from which brand, with whose approval. Multi-brand and multi-region estates live or die on this, and it is close to impossible to restructure later without rebuilding the journeys and automations that sit on top of it.

  • Business unit structure for brands, regions or entities
  • Role and permission model, scoped to actual job functions
  • Shared content and data strategy across units
  • Send classification, delivery profiles and sender profiles
  • Approval workflow where governance requires one
Workstream 03

Sending infrastructure and integrations

The plumbing: authenticated sending domains, a warming plan where the infrastructure is new, and the connections that bring real data in. Deliverability is designed here rather than diagnosed later, which is the difference between a launch and a recovery.

  • Sending domain setup and sender authentication
  • IP warming schedule where sending infrastructure is new
  • CRM, ERP and commerce integration design and build
  • Reply handling, bounce processing and suppression management
  • Error handling and alerting on every inbound feed
Workstream 04

Content system and journey framework

A template system your marketers can use without a developer, and a journey framework with rules about what may enter what. Built last, deliberately — a journey framework designed before the data model is a guess about data that does not exist yet.

  • Content Builder template architecture and reusable blocks
  • Brand governance: what a marketer may change and what is locked
  • Journey framework, entry sources and suppression rules
  • Automation Studio schedule design and dependencies
  • Preference center and subscription management
How It Runs

Five Phases, and What Ends Each One

Every phase closes on something you can inspect — a document, a demonstrable build, a reconciliation report. "Progress" that cannot be shown is the leading indicator of a go-live date about to move.

Phase 01

Discovery

Source systems, data volumes, consent obligations, brands, regions and the commercial outcome the program is accountable for. Ends with a findings document and a scope both sides have signed.

Phase 02

Architecture

Contact model, business units, permissions, integration pattern and journey framework, designed on paper. Ends with an architecture document you own — whatever happens to the engagement.

Phase 03

Build

Configuration against the signed design: data extensions, integrations, sending setup, templates, journeys and automations. Ends with a working org you have reviewed in increments, not at the end.

Phase 04

Validation

Data reconciled against source systems, seed and rendering tests, deliverability checks, journey walkthroughs on real records, UAT with the people who will run it. Ends with a signed reconciliation.

Phase 05

Go-live and enablement

Staged send volume, monitoring in place, documentation and runbooks handed over, training delivered. Ends with your team running the org — or with us running it, if that is what you would rather.

Division of Labour

What We Do, and What We Need From You

The single biggest cause of a slipped Marketing Cloud go-live is not the build. It is waiting on a decision or an access grant that nobody was told they owned. Here is what we need, named in advance.

Implementation responsibilities by workstream
WorkstreamWhat Twopir doesWhat your team supplies
DiscoveryRuns the sessions, documents current state, maps source systems and data volumes.Access to the people who actually know how the data is used — not only the project sponsor. Usually four to six hours of their time, spread over two weeks.
ArchitectureDesigns the contact model, business unit structure, permissions and integration pattern. Produces the document.A decision on brands, regions and who is allowed to send to whom. This is a business decision and we cannot make it for you.
DataDesigns the data extensions, builds the load, reconciles against source.A named data owner per source system, and agreement on what a duplicate is. Data quality issues surface here and they are yours to rule on.
IntegrationsBuilds and tests the connections, defines error handling, documents ownership.Credentials, sandbox access, and the security review slot. Booking that slot late is the most common single-cause delay.
ConsentDesigns the preference and consent model, implements it, documents it.Your legal or privacy position on each market you send to. We implement an obligation; we do not determine it.
ContentBuilds the template system, blocks and brand governance.Brand assets, approved copy, and one person empowered to approve design. Approval by committee adds weeks.
ValidationRuns reconciliation, seed tests, rendering tests and deliverability checks.UAT participation from the people who will use it daily, and sign-off authority in the room.
Go-liveStages the send volume, monitors, hands over documentation and training.A decision on who owns the platform on day one. If the answer is nobody, see managed services.

Capabilities verified against Salesforce documentation Last reviewed 23 September 2026

Architecture Decisions

Four Decisions Made in Week Two That You Live With for Years

Some implementation choices are cheap to revisit. These four are not — every journey, every report and every integration built afterwards depends on them, so changing one later means rebuilding what sits on top.

They belong in the architecture phase, which is why that phase produces no configuration at all. A team that starts in the platform makes these decisions implicitly, by accident, in whatever order the build happened to require them.

If you are selecting an edition rather than building on one you already own, start on the Marketing Cloud consulting page instead — that decision comes before this one.

What a contact is in your business

One human with two email addresses and a mobile app: one customer or three? The answer determines audience size, frequency capping, whether an unsubscribe is honoured across channels, and your contact count — which is a cost line. Get it wrong and every downstream number is wrong in the same direction, permanently.

How many business units you actually need

Business units are usually created per brand or per region out of instinct. Each one adds governance overhead and complicates shared data and content, and restructuring later means rebuilding the journeys inside them. The right number is the smallest that satisfies a real separation requirement — a distinct sending identity, a distinct approval chain, or a distinct legal entity.

Where consent lives and who honours it

Consent captured in one system and acted on in another is the most common compliance gap we find in inherited orgs. Preference state, channel-level opt-outs and regional obligations need one authoritative home and a defined propagation path to every sending system. Designed once at the start; reconciled forever if not.

What the journey framework permits

Not which journeys to build — what rules govern all of them. Which entry sources may overlap, what suppression sits above everything, how many messages a customer can receive in a week, and who may publish a new journey. Without those rules, journeys accumulate until customers get contradictory messages and nobody can say why.

12+
Years delivering CRM and marketing platform transformation
250+
Platform deployments delivered
500+
Clients served across global markets
98%
Client retention rate
Risk

The Four Reasons a Go-Live Date Moves

None of these are technical. All four are visible in the first fortnight to anyone looking for them, and all four are cheaper to prevent than to recover from.

If a build is already underway and one of these is familiar, an audit of the work so far is usually faster and cheaper than pressing on and fixing it after go-live.

Data quality discovered in month three — The build assumed the CRM data was clean. It was not, and the duplicates, missing consent and inconsistent formats only surface when someone tries to load them. Profiling the data in discovery costs days; discovering it during build costs weeks.

Scope drifting into campaign production — The implementation quietly becomes a campaign factory because the marketing team needs a send out this month. Both jobs then run late. Campaign build is a real need and a legitimate line item — it just is not the same engagement.

No named owner on the client side — Decisions that only the business can make — what a duplicate is, which brands need separation, what the consent position is in each market — sit unanswered because nobody has been made accountable for answering them.

Deliverability left until the end — Sending domains, authentication and warming get treated as a launch task rather than an architecture task. The result is a go-live where the platform works and the mail does not arrive, which is indistinguishable from failure to everyone watching.

Before You Start

Five Signs an Implementation Is About to Go Badly

These are all visible before the first configuration is made, and every one of them is fixable at that point for a fraction of what it costs later. If two or more are true of your project right now, the plan is worth a second look before the build starts.

The plan has a go-live date but no architecture phase, so the data model will be designed implicitly by whatever the first campaign happens to need.
Nobody can state what a contact is in your business, and two people in the room give different answers when asked.
The number of business units was decided before anyone asked what actually needs to be separated — and it is more than three.
Deliverability appears in the plan as a launch task rather than an architecture one, with no warming schedule and no authentication work scheduled.
The integration depends on a security review that has not been booked, and nobody owns booking it.
Common Questions

Implementation Questions Worth Asking Early

Three variables set it, and none of them is the size of the platform: how many source systems have to be integrated, how clean the data in them is, and how many business units and brands the design has to serve. A straightforward configuration sitting on unreconciled customer data takes longer than a complex one sitting on clean data.

Where sending infrastructure is new, the warming schedule also puts a floor under the launch window that no amount of resourcing removes — reputation is built over time by definition. We scope against your estate in discovery and give a range with the assumptions written down, rather than an average that fits nobody.

Yes, and it is usually the right approach. What cannot be phased is the layer underneath — the contact model, business units, permissions and consent design have to be right before the first journey, because everything built afterwards inherits them.

So the sequence we recommend is: full architecture, minimum viable build, one genuinely useful journey live, then iterate. What does not work is phasing the architecture itself and hoping to retrofit it once three journeys are running on top.

That decision comes before the implementation plan, because it changes the plan completely. Marketing Cloud Engagement has its own data model, so the build includes designing that model and integrating it with CRM. Growth and Advanced Editions are built on the Agentforce 360 Platform with Data 360 as their foundation, so marketing shares the CRM data model and a whole category of integration work disappears.

If the license is not yet signed, start on the Marketing Cloud consulting page. If it is, we build against what you have.

More than most vendors admit, and it is better to know in advance. The responsibilities table above sets it out workstream by workstream, but the short version: decisions only the business can make, access only the business can grant, and UAT from the people who will use the platform daily.

The heaviest weeks are discovery and validation. In between, your team's involvement is mostly reviewing increments — which is deliberately more frequent and lighter than one large reveal at the end.

Yes, and that is common — a trial configuration, a partial build from a previous partner, or an org that was set up years ago and never properly designed. The first step is an audit to establish what exists and what is safe to keep.

Sometimes the answer is that keeping the existing configuration costs more than rebuilding it. We will tell you which, with the reasoning, rather than defaulting to a rebuild because rebuilds are larger engagements.

Send volume ramps on a schedule rather than switching on in full, monitoring is already in place, and we stay close through the first weeks — which is when the failure modes that testing cannot produce actually surface.

After that, it is your team with documentation and training, or ours through managed services, or a hybrid where we run it for the first two quarters and hand over once the org is stable. All three are normal; the one that fails is nobody owning it.

Next Step

Start With Discovery, Not With the Go-Live Date

Tell us what you are integrating, how many brands and regions the design has to carry, and what state the data is in. That is enough to say whether the timeline you have in mind is realistic.

Scope Your Implementation Marketing Cloud Consulting

Serving: US | Canada | UK | UAE | Australia | New Zealand

Relatable? We should definitely talk.

What we'll cover:

From CRM and integrations to custom apps and complex system architecture — we help you scale without chaos.
  • Identify revenue leaks across CRM, integrations, and GTM
  • Design and optimize complex systems (CRM to Custom Apps)
  • Apply practical AI to improve operations and pipeline conversion
  • Eliminate silos and build a unified revenue system
  • Assess GTM performance and key bottlenecks
  • Align teams with clear processes and ownership
  • Define a scalable RevOps model
  • Improve forecasting and reporting
  • Review your HubSpot/Salesforce setup for scale