Building a marketing center of excellence in Adobe Marketo

What a center of excellence is

A marketing center of excellence is the team that owns the marketing platform and the standards every campaign follows. In a Marketo shop that team usually has the Admin role, builds the program templates everyone clones and gets the call when a smart campaign goes to the wrong people. Call it marketing operations or campaign operations or the Marketo team. The arrangement is what matters: one team decides how campaigns get built and every other team builds within that.

A help desk is different. A help desk builds whatever lands in the queue and its output is capped by its headcount. A center of excellence spends some of its time building and most of it making campaigns buildable by other people: program templates with the right tokens, email templates that can’t be broken, smart lists that are already defined, rules that apply themselves. A help desk counts tickets. A center of excellence counts how much marketing left the building and how little came back.

Most companies have the first and call it the second. The rest of this guide is about making the name true.

Decide what the center owns

Start with two lists rather than an org chart. On one side everything that affects every team or can’t be undone once it is wrong. On the other everything that belongs to a single campaign.

The center’s list usually comes out like this:

• The instance and the Admin area. Integrations, the CRM sync, field management, workspaces and partitions, communication limits and whatever Adobe changes each release.
• The database and consent. What each field means, which fields the CRM owns and are blocked from updates, how opt-in is recorded and what Unsubscribed and Marketing Suspended mean in practice.
• Program templates and tokens. One per campaign type with the channel, the statuses and the tokens that carry the variable parts.
• Email and landing page templates. The brand, the footer and the legal text and which parts of each a marketer may change.
• Audiences. The shared smart lists, the segmentations, the suppression lists and the rules about what a team may import.
• Frequency. The communication limits and how the teams that share people avoid landing on the same person in the same week.
• Approvals. Who approves emails, landing pages and programs and when a send may skip review.
• Naming, channels and tags. The convention that makes Program Performance readable a year later.
• Reporting. What gets measured, where it lives and who sees it.
• Intake and training. How a request arrives and what a requester needs to know.

The teams’ list is shorter: the message, the copy and images inside the template, the token values, the audience chosen from what the center allows, the send date inside the windows the center sets and the results of their own programs.

Write both lists down and get the leaders of the sending teams to agree to them. Arguments at this stage cost less than the ones you would have after a bad send.

Set up Marketo around the center

Marketo has the controls for this. They are spread across Admin, Design Studio and Marketing Activities and the center has to hold all of them.

Workspaces and partitions

The center lives in a global workspace, often the Default one, that sees every partition. That is where the shared assets are built: email and landing page templates, the smart lists that hold suppressions, snippets for footers and legal text and the segmentations, which are limited to 20 per subscription and best created centrally. Each sending team gets a workspace of its own for its programs and the center shares folders from the global workspace into it. Shared folders arrive read-only with a padlock, which is exactly what the center wants.

Partitions are a separate decision and a permanent one. A person in two partitions is two records that never merge. Give teams their own partition only when their people must be kept apart for legal or contractual reasons. Teams that share customers share a partition and separate only their assets.

Roles per workspace

Access comes through roles granted per workspace. The center is Admin everywhere. Each sending team gets one custom role in its own workspace: Access Marketing Activities with Edit and Clone Marketing Asset, Access Design Studio with Access Email and Edit Email, Access Analytics and nothing that approves, schedules, imports or reaches the Admin area.

Two Marketo habits matter here. One role per user, because a user with two roles gets the more restrictive permission where they disagree. And one workspace per team that must not touch another team’s programs, because there are no folder-level permissions inside a workspace. A user who can edit assets in a workspace can edit all of them.

Program templates and tokens

Marketo’s native self-service is clone and fill. The center builds a program template per campaign type with the emails, the smart campaigns, the lists and the landing pages in place, and uses My Tokens for every value that changes from one campaign to the next: the date, the speaker, the offer, the link. A team clones the program into its workspace, fills the tokens and the emails fill themselves.

Keep the templates in a folder the center owns and treat a change to a template like a release. The programs already cloned from it don’t update, so the center keeps a list of what is in flight before it changes anything.

Email templates and content locking

Brand holds to the extent the templates hold. The center builds the email templates with content locking turned on in the Email Designer: read only for templates nobody should touch and content locking with a few editable components for the rest. Edit Email Template and Approve Email Template stay in the center’s role. The templates are shared into team workspaces read-only so a region uses them and can’t change them.

Older templates built for Email Editor 2.0 lock through their HTML instead. Either way the lock lives on the template, so an email cloned from an old unlocked one is unlocked too. Archive the old ones where teams can’t reach them.

Audiences and the database

Suppression smart lists and segmentations are built in the global workspace and shared out. The center decides which fields the CRM owns and blocks updates to them under field management, including updates from list imports. Decide whether teams may import lists at all. If they may, the import takes whatever mapping they confirm, so the center needs a written rule for what a file has to look like and a plan for checking it.

Two instance-wide settings belong to the center. Communication limits cap how many emails a person receives per day and per week across every team that turns them on. And the smart campaign limits under Admin cap how many people one campaign may affect, with a permission to override that the center keeps for itself. Together they turn the all-leads mistake from a disaster into an error message.

Approvals

In Marketo approval is a state on the asset. Withhold Approve Email, Approve Landing Page and Approve Email Program from the teams’ roles and every send waits for someone in the center to approve it. Know what that gives you before you rely on it. It is a permission rather than a workflow. Nothing tells the approver a draft is waiting, nothing routes a region’s email to the region’s manager and nothing records what the marketer asked for.

Naming, channels and tags

Every program needs a channel, so the center defines the channel list with the progression statuses each campaign type uses and nothing else. Program tags carry the rest: region, business unit, product, campaign type. Mark the tags that reporting depends on as required so a program can’t be created without them. Then a naming convention on top, with folders per team and per year inside each workspace. The convention only works if the template enforces it, so bake the name pattern and the tags into the program templates teams clone.

Reporting

Program Performance, Email Performance and Email Insights run per workspace. The center gives team leads the Analytics User role in their workspace so they can read their own numbers without asking. The cross-workspace view is the center’s job: an admin visiting each workspace or an export stitched together, because Marketo won’t show what went out across every team from one screen. Companies with a second instance for a region split the picture again.

Write the standard down

Roles decide what a team may open. The standard decides what they should do once they have. Keep it to one page per campaign type: who may run it, which program template, which smart lists, who approves, which hours it may send and how it is named and tagged.

Marketo gives you a little room to put this in front of a marketer. A description on the program template and a text token with instructions go a long way. Most centers keep the rest in Confluence or SharePoint and most marketers never open it again after the first week. The next two sections are about living with that.

Run the intake

Even a center that lets teams clone and fill runs a queue for everything else. Give it a form that asks for what the campaign needs and nothing more: the audience and how it was defined, the content, the sender, the date and time zone, the approver and any list to import. Publish a turnaround time you can actually hit and show the queue to the people in it. The campaign request guide covers what a good intake looks like and why the queue grows faster than the team however good the form is.

Count a quarter of requests by type. The newsletter, the webinar invitation, the product update and the list upload are usually most of the volume and the least varied. Those are the program templates to build first and the campaign types to hand over first. Keep the ticket for anything nobody has run before.

Measure the center

A center of excellence that reports opens and clicks looks like a mailroom. Report on the operation too:

• Turnaround from request to send, by campaign type.
• The share of programs that went live without anyone in the center touching them.
• How often a program had to be redone and why.
• How long approvals take and who they wait on.
• How many emails one person received across every workspace in a week, which takes a smart list or an export to answer.
• Results by team, channel and tag from the tags you made required.

Put the numbers in front of the sending teams’ leaders every month. The first few months make the case for the center. After that they make the case for the next campaign type to hand over.

Where Marketo stops

Set all of this up and you have an instance where each team can only open its own workspace and only do what its role allows. A few things remain and they are worth knowing before you promise anything.

Roles govern access and nothing after it. A marketer with Edit Email can change whatever the template left open. A marketer who can edit a program’s smart list can point it at everyone in the partition. Import List grants the wizard and says nothing about what goes through it.

Every marketer who clones and fills is a Marketo user with a seat, a role to maintain and training that is never finished. Approval is a permission with no routing and no record of the request. Reporting is per workspace. And the teams that share a partition share people, so each team’s communication limits and exclusions run on their own while the person at a global account hears from all of them.

None of this argues against the setup. It argues for the center running two paths: Marketo for its own work and something narrower for everyone else.

Running the center on Campaign Launchpad

Campaign Launchpad is that narrower path. The center builds a Launchplan for each campaign type in the standard. Its steps are the things Launchpad does in Marketo: clone the program template with its tokens, emails, smart campaigns and static lists, create or clone an email, create a landing page, import leads. The fields a requester fills in and the pages they fill them in on are the center’s to design. The groups a Launchplan is shared with mirror the sending teams. A requester never opens Marketo.

Everything on the center’s list has a place in it:

• The program template is cloned into the workspace and partition where it belongs and the tokens are filled from the form. A Launchdate on the smart campaign schedules the send.
• Email templates are the center’s own HTML with the editable regions marked and a rule on each: a character limit on the headline, a minimum width on the hero image, a button that can be removed and nothing else that can.
• Audiences come from the lists the center allows for that Launchplan. An uploaded file is checked row by row against the center’s rules before anything reaches the database.
• Approval goes to a group or to the requester’s manager or to each email separately, set per Launchplan, with the decision kept on the workflow.
• The standard travels with the campaign. Brand rules and legal notes written once in the documentation library show on the wizard pages that need them, including the pages of workflows already started.
• The AI Assistant drafts copy under a policy the center sets: tone, length and blocked words.
• Steps nobody can automate, a print ad or an email built from an uploaded brief, go to enablement so the center does them by hand and the record stays with the campaign.
• Reporting covers every team and every workspace in one place: a status board of what is in flight and who it is waiting on, how long approvals and enablement take, a calendar of what goes live and each campaign’s results back to the person who sent it.

Launchplans have versions, so the center can change a path without breaking the workflows already started from it. One Launchpad account covers every Marketo instance you run and any Eloqua instances beside them.

The result is the one every center is after. The workspaces and roles stay as they are. The number of people who can send goes up and the number who need a Marketo login doesn’t. The same setup for an Eloqua instance is covered in its own guide.