Campaign requests: running the queue and getting out of it

How the queue came to be

In most B2B enterprises marketers don’t touch the marketing automation platform. They write a brief, attach the copy and the list and file it. Marketing Ops builds the campaign in Eloqua or Marketo, sends a test, gets a thumbs up and launches it. Then the next ticket.

Nobody designed this as the ideal. It is what happens when a company has a few people who know the platform and a few hundred who need email sent. It has real virtues. The marketer never has to learn the platform. The e-marketing policies, the frequency rules, the consent requirements and the naming conventions all live in Ops and get applied every time, because Ops is the only one touching anything. The database stays clean because the only people loading data know what the fields mean. The brand holds because the only people building emails use the templates properly.

The cost is time. Every campaign takes an Ops person’s hours and those hours are the scarcest thing in the department.

What a good intake looks like

If you are going to run on tickets, run on good ones. A large share of Ops time goes on chasing information the request should have carried in the first place so the form earns its keep.

The fields

A request that can be built without a follow-up question covers:

• The purpose in a sentence and the business owner.
• The audience: which segment or list, how it was chosen and whether a file needs importing. A file should come with a column list.
• The content, finished and approved by whoever has to approve it, or a clear note that approval is still coming.
• The email template to use, if there is a choice.
• Sender name and reply-to, or the rule that decides them.
• Send date, time and time zone and whether it can slip.
• The campaign fields your team tracks: region, product, business unit, campaign type, whatever feeds your reporting and your naming convention.
• Landing pages, forms and follow-up actions, if any.
• Who signs off on the test send.

Drop-downs beat free text. Required fields beat optional ones. If a value is used to name assets or route approvals it should be a controlled list, because a region typed as “EMEA,” “Europe” and “emea” across three tickets will be three regions in your reports.

The service level

Publish how long each kind of request takes and measure against it. A standard email to an existing segment might be five business days. A new template, a list import or a landing page adds time. Rush requests need a rule, because without one everything is a rush. The number matters less than its honesty. An SLA the team misses every week isn’t an SLA, it is a record of the backlog.

The queue

Whatever tool holds the tickets, everyone should be able to see the queue: what is in it, what state each request is in, who has it and when it is due. Marketers who can see their place in line file fewer “any update?” messages and Ops leads who can see the whole queue can move people to where the work is. A shared inbox hides all of this. A Jira board, a Workfront request queue or an Asana form with a board behind it shows it.

Prioritization

Someone has to decide what gets built first when the queue is longer than the week. Make the rule explicit: revenue deadlines first, then dated events, then everything else in order received, or whatever fits your business. A rule that is written down gets argued about once. A rule that lives in the Ops lead’s head gets argued about daily.

Where tickets stop scaling

Do all of that well and you have a good ticket process. You also still have the ceiling, because the shape of the work hasn’t changed.

Every request costs Ops time, however simple

The newsletter that goes out every month, the webinar reminder that is identical to last week’s with a new date, the list of forty event attendees to add to a nurture: each is a ticket, each takes an Ops person away from something harder and the simpler the request the more it rankles. Most queues are mostly routine. That is exactly the work that shouldn’t need a specialist.

The queue grows with the number of marketers

Hire ten marketers and you get ten more people filing tickets. The Ops team stays the same size, because Ops headcount is hard to justify and the people are hard to find. Turnaround stretches until the SLA is a fiction and marketers plan campaigns around how long Ops takes rather than when the market needs them.

The back-and-forth never fully goes away

However good the form a share of requests arrive incomplete. The segment doesn’t exist, the file has the wrong columns, the copy isn’t final. Each one becomes a thread. The thread is where campaigns go to wait and the time in it rarely shows up in anyone’s SLA report because the clock stopped when Ops asked the question.

Priority is a negotiation

When the queue is long, position in it becomes political. The marketer with the louder stakeholder goes first. Ops spends time adjudicating that it would rather spend building and the marketers who play fair wait longest.

Nobody can see the whole picture

The ticket tool knows about requests. The platform knows about campaigns. Neither knows about the other so a question like “how many campaigns went to the enterprise segment this month and who asked for them” takes an afternoon to answer. The frequency problem that comes from several teams reaching the same contacts is hard to even notice from inside a queue. The email governance posts go into it.

Marketers route around it

When the official path takes two weeks, a marketer with a deadline finds another one. A departmental email tool, a mail merge from the CRM, an agency with its own platform. The policies the ticket process was protecting are the first casualty, because the whole point of the detour is that nobody in Ops sees it.

Doing the arithmetic

Before changing anything count. Pull a month or a quarter of tickets and sort them into types: single email to an existing segment, newsletter, event invitation and reminder sequence, list upload, new template or landing page, something new. For each type note how many there were and roughly how long each took Ops end to end, including the back-and-forth.

Two numbers usually fall out. The first is that a small number of request types make up most of the volume. The second is that those types take a disproportionate share of Ops time relative to how much judgment they need. A single send to an existing segment might take two hours of a skilled person’s day and need none of their skill. Multiply across the month and you have the size of the opportunity. The Campaign Launchpad calculator does this sum with your own numbers.

Getting out of the queue without losing control

The standard objection to self-service is the one the ticket process was built on: marketers in the platform means mistakes in the platform. It is a fair objection to a login. It isn’t an objection to self-service, because the platform login was never the only way to give marketers the ability to send.

What Ops is protecting is a set of decisions: which template, which audience, which sender, which rules, who approves. In the ticket process Ops makes all of them by hand every time. The alternative is for Ops to make them once per kind of campaign and have software apply them every time a marketer runs that kind of campaign. Then the marketer makes only the decisions that are theirs to make: the content, the timing and the choice among approved audiences. Everything else is already decided.

That is a different division of labor from both the ticket and the login. In practice it looks like this:

1. Take the request types that dominate the queue and turn each into a template: the campaign structure, the email template with its locked zones, the allowed audiences, the sender rules, the naming convention, the approval chain.
2. Put a guided path in front of each template that asks the marketer only the questions the template leaves open.
3. Validate what the marketer provides before it touches the platform, especially any file they upload.
4. Keep an approval step wherever a human should look and only there.
5. Keep the ticket for genuinely new campaigns and let the guided path hand off to Ops when a routine campaign needs one unusual step.
6. Measure cycle time, share of campaigns that ran without Ops and rework so you know whether it is working.

Done that way the policies hold better than they did under tickets, because they are enforced by the template and the rules rather than by whoever picked up the ticket and however their day was going.

How Campaign Launchpad runs it

Campaign Launchpad is built around exactly this split. Marketing Ops builds a wizard for each kind of campaign: clone the program or campaign, create or update the emails and landing pages in locked templates, import and validate a list, pick from approved audiences, route approvals, launch. Marketers run the wizards. Everything underneath in Eloqua or Marketo stays as Ops configured it and one Launchpad account can sit in front of any number of instances on either platform.

For the requests that can’t be fully automated, Launchpad does as much as it can and then hands the remaining step to Ops. The right person is notified, the step gets a deadline and the conversation between marketer and Ops happens on the campaign and is kept there. Campaigns that marketers finish alone and campaigns that needed help sit in the same queue which Ops and marketers can both see, with SLA tracking on every request. Results come back to the marketer in Launchpad so the day-after “how did it do” ticket goes away too.

3M is the clearest example of what changes. The company had 250 people who needed to send email and one small team building for all of them. After moving onto Campaign Launchpad a campaign that took eight hours to build takes about 45 minutes, regional teams send between 120 and 200 campaigns a month on brand and the Ops team didn’t grow to do it. Across Launchpad customers, campaigns launch in about 30 minutes on average and teams report five to ten times their previous capacity.

The queue doesn’t disappear. It shrinks to the work that needs an expert which is the work Ops wanted to be doing all along.