Modular Implementation of Salesforce Marketing Cloud

Modular Implementation of Salesforce Marketing Cloud.

Salesforce Marketing Cloud implementation can be broken down into a set of components for the estimation of effort and/or understanding of the requirements purposes.

Here we will discuss the most common components we implement for our customers.

Please note in this particular post we will talk about greenfield projects where licenses were acquired and only the initial setup is required.

Moreover, to clarify, in this particular article we will not be covering implementation of social studio, advertising studio or Einstein.  These components are not typically implemented in the initial stage as they have multitude of complexities and would usually be branched off and scoped as a separate projects or phases.

1. Marketing cloud initialization.

This component involves initial configuration of the instance, setting up delivery profiles, send classifications, sender profiles, SAP provisioning, short code provisioning, setting up the studios (where required), naming convention setup, users setup, custom roles creation, business unit structure setup. This part would usually take between 2 and 10 days depending if there are any complexities.

When we have to work with mobile push we would work on it within this step, but set aside minimum of 5 days of extra effort to configure the integration and run the tests.

2. Integration and data build.

This would usually be one of the most complex and time consuming processes. We would usually run a data discovery, analyze what has to be integrated with Marketing Cloud, how would integration work (API, FTP, connectors, cartridges) once we understand the integration requirements and data model will be created to accommodate that needs.

However, we have to note here, that data modeling should be taking into an account the needs of the journeys (which at this stage should have already been mapped).

The data modeling has to be done in the contact builder. The data piece of work will also include setup of all the filters and queries to filter out the required data from integrated DEs.

The data piece would usually take between 10 and 20 of effort to complete. Obviously there is a complexity factor and it may take way longer or require less effort in a very basic setups.

3. Content development.

Once we have finalized the data, we would look into the content preparation, we would build a responsive template and prepare up to 30 content areas to be used within the template. The transformer can then be used for multiply sends.

The assets required for the sends however can be very dynamic, therefore, we would look into building

1) Automated system (utilizing APIs) to upload relevant assets into SFMC
2) Map it out using AMPScript directly working with the content builder
3) Creating a data model based solution which would store links to assets and within templates we would rather call IDs from DEs than the actual assets directly from the content builder.

The effort required to delivery this component can vary greatly depending on a specific use case.

4. Journey & Automations Development

By far this is the most effort intensive part. Once the journeys are mapped out, data to be used in the journeys is present and content is ready to be used for sends, we jump on to journeys. There are a lot of components within the journeys: data filters, sql, automations to refresh the data, data import and export, ampscript coding, dynamic content development, testing and finally UAT.

We usually allocate a minimum of 48 hours per defined journey with up to 5 interaction points and 100 hours for journeys with up to 10 interactions. However, there can be complexity multiplier factor, i.e. if the content is multi-language or multi-brand then required effort will be much greater.


As you can see, the following modular implementation would cover 95% of Marketing Cloud greenfield projects. There are going to be some variances, but they will usually be added on top of what we have described in this article. Breaking implementation into modules brings a lot of transparency to customers and to vendors as both know what has to be done and how long does it take.

If you have any questions or feedback please reach out to us