Marketing automation platforms (MAPs) have tools and interfaces that eliminate the need for personnel with specialized technical skill sets to perform some core tasks. This means the central function that governs the MAP can enable decentralized users to perform some functions on the platform if needed.


However, as MAP usage becomes more widespread, challenges with enabling decentralized marketing users on the MAP are emerging. Before decentralized users can use the platform, administrators need to set some boundaries.

So, how do you go about deciding what functions marketers and other decentralized users can perform on a MAP? The central function that governs the MAP needs to understand the relative risk and skill level required to perform certain tasks, and make decisions about what tasks can be moved out of the central function. Planning is key. When planning the knowledge transfer program, remember the following considerations.

Not All Decentralized MAP Users Need to Learn How to Do Everything

Organize your program according to the most frequent requests and their relative risk level. For example, you may receive numerous requests for email deliverability reporting, and a knowledge transfer program that enables users to pull email reports autonomously out of the MAP has a relatively low risk.

Compare this with developing and deploying email, forms and landing pages, or building lists through complex filter logic. Both have higher risk and involve a deeper level of skill. When functions are organized by MAP functional area and relative risk level, the end result is a modular curriculum that can build cumulatively (or not), depending on internal stakeholders’ required knowledge level relative to the task they need to perform.

Taking the time to organize the program in this way creates flexibility to edit each curriculum component individually if needed. Additionally, it ensures that internal stakeholders are brought up to speed only in necessary areas, minimizing the amount of time spent on knowledge transfer. 

There Are Certain Tasks That Should Be Performed Only by a Central Function

Certain programs and assets in the MAP operate systemically and have far-reaching impacts on the marketing database. Often, there are several inputs to these programs apart from the implementation itself in the MAP.

For example, an effective lead scoring program involves deal deconstruction analysis, as well as input and iteration from both marketing and sales. A pre-marketing qualified lead nurture flow involves audience definition as well as content, message and offer mapping. A data-cleansing program requires data mapping, stewardship and maintenance.

Because of the complexity of these inputs, these programs cannot be designed and implemented by one internal stakeholder without organized input from others within the business.

As part of the planning process for instruction, create a list of elements that cannot be delegated to internal stakeholders. Ensure agreement on these elements, and socialize them to avoid unnecessary confusion about what is and what isn’t included in the knowledge transfer program.

Have you developed an internal enablement program for MAP users? Tell us about your experience! What worked, and what didn’t? If you had to do it differently, what would you change?