What Actually Makes Marketing Automation Hard

For twenty years, choosing a marketing automation platform meant choosing which compromise you could live with. You could have depth that only a specialist could reach, or ease that stopped short of what you needed.

The industry had shorthand for the two ends: Marketo complexity, or HubSpot simplicity. Buyers said it in evaluations and analysts said it in briefings, and both sides of the comparison were being fair.

I co-founded the complex one.

Neither end was a failure of design. Depth in these platforms required specification. For the system to do something, somebody had to describe that thing in advance, in terms the system could evaluate. Ease came from removing the surface where the specifying happens, because fewer settings means fewer decisions to get wrong and also a smaller set of things the platform can be asked to do. The easy platforms stopped short of what teams needed because stopping short was the mechanism that made them easy.

That is why the tradeoff survived twenty years of releases on both sides. Nobody could add their way out of it, because it was never a gap in the feature list.

Capability Comes Out as Configuration

Everything a legacy marketing automation platform can do, you get by telling it exactly what to do. Fields, tokens, segments, triggers, flow steps, program templates, naming conventions. Each one is a decision somebody made in advance and wrote down in a form the system can execute.

So depth and specification work rise together. A platform that can express more requires more to be expressed, which means "powerful but hard" was never a complaint about the interface. It was arithmetic.

Then there is the question of what gets specified. Consider what a campaign brief contains: the audience, the message, the offer, the timing. That is a complete specification of intent. A good marketer writes one in twenty minutes and everyone who reads it understands what is supposed to happen.

It is still not enough to build from. The person building it needs to know which program template to clone, which fields to write to, which segments must be suppressed, and which naming convention gets the campaign into the right report. None of that is in the brief, because none of it is about the campaign. It is about the company.

At most companies that knowledge has never been written down anywhere. It accumulates in whoever has operated the platform the longest, which is how a marketing operations job becomes a translation job.

What Actually Required a Specialist

A campaign operations specialist spends the day on work like this.

Audience logic. You want everyone in financial services who attended a webinar last quarter. The platform needs that as conditions it can evaluate, so somebody decides what counts as financial services in your data, whether the industry field is reliable enough to use, what happens to the records where it is empty, and which webinar programs count. The same problem in miniature is the state field, where CA, Cal, Calif and California each have to be enumerated before any of them can be matched.

Campaign wiring. Someone qualifies for the campaign twice in one week. Entry triggers, exit conditions, flow steps and the order they fire in all have to account for that before it happens, because the system will not work it out on its own. Every new campaign needs the same set of decisions made again.

Template management. The webinar program you cloned has a scoring step in it that this campaign should not have. Program templates are how teams keep campaigns consistent, so cloning the wrong one produces something that looks right in the interface and behaves differently in production.

Sync field mapping. Marketing and sales both write to the job title field. Which side wins, in which direction, and what happens when both change between syncs. Get it wrong and the symptom appears weeks later as a routing problem nobody can trace.

Send frequency arbitration. Three campaigns want the same person this week. Communication limits stop people from being buried, and then somebody builds and maintains the exclusion lists and suppression rules that decide which campaign gets the slot.

Naming conventions. The campaign ran and it is not in the report. Reporting depends on programs being named and tagged to a standard, so a campaign named slightly wrong is invisible to the people deciding what to fund next quarter.

None of that is marketing. Every item is translation, taking an intention somebody already had and rendering it in a form the platform can execute. The specialist is good at it, which is why the work goes to them, and why there is a queue behind them.

What the Queue Costs

The obvious cost of a queue is the wait. The wait is the smaller half of it.

The larger cost arrives before anyone writes a ticket. A demand generation manager designs the campaign she wants. Then she estimates what it will take to build, drops the two audience splits that would need another set of rules, simplifies the branch that would need new logic, and submits the version that can be built in a week. Nobody asked her to do that. She did it because she has been doing this for six years and knows what comes back approved and what does not.

The campaign that runs is a compromise nobody recorded. It never reached review, so it was never cut down in review. It was cut down in her head.

Repeat that across a quarter and the marketing program takes the shape of what is cheap to configure rather than the shape of the market. The bill gets paid in campaigns that were never proposed, which is why it never appears as a line item. Nobody sees the ones that did not happen, including the CMO who would most want to.

Over the last two years I have talked with more than 200 marketers about their platforms. The complaint is rarely that the platform cannot do the thing. It is that doing it costs enough that they stopped asking.

What a Modern Interface Fixes

Some of the difficulty really is the interface, and pretending otherwise would be dishonest. These products have had features layered onto a design from the late 2000s for almost twenty years, with almost nothing ever removed. A platform built now does not inherit any of that, and ours was built for marketers by people who have spent twenty years watching what works in these products and what needs fixing.

More of it is the architecture underneath, where the fixes matter more day to day than anything cosmetic:

• Rules that fire in a defined order, so when two of them touch the same person you can tell in advance which one wins instead of finding out from the send.
• Editing a live campaign without stopping it, so fixing a typo or swapping an asset does not mean pausing the campaign or risking a second send to everyone already through it.
• Bot traffic filtered at the point of capture, so machine activity never reaches a timeline, a score, a trigger or your CRM.
• A skip log that says which records an automation passed over, and why.

All of that removes the difficulty that accumulated. None of it removes the difficulty that was there on day one, which is that somebody still has to specify everything in advance.

Describe the Work and It Gets Built

Here is a brief, written the way people actually write them:

Field event in New York on October 14. Invite marketing ops contacts at our top 50 accounts, plus everyone who came to the Boston one. Confirmation when they register, reminder the day before, follow-up for the people who don't show.

A specialist reading that knows what to build. She also knows the dozen things the brief does not say, including which program template to start from, whether "top 50 accounts" means the named list or the score threshold, which of the Boston registrants to exclude because they have already been invited, what the campaign gets called, and which suppressions apply.

Maestro, the intelligence inside Phave, reasons about what was asked and works out the parts nobody spelled out. It creates the campaign and its steps, adds the tactics, writes and designs the emails, wires the timing to the anchor date and sets the entry triggers. Other tools can produce a campaign from a template. The difference shows up when the brief does not match a template, which is most of the time, because briefs are written by people describing what they want rather than by people filling in a form.

Behind that are more than 300 governed operations, the same layer the API exposes. That is why Maestro does the work rather than explaining how to do it. Chat in most platforms is a small set of scripted intents, so asking one to change something gets you instructions for changing it yourself.

Software building things on your behalf should make you at least slightly uneasy, and the controls are where that gets resolved. Every operation has its own write mode. Creating a person, account or deal can ask first; adding a person to a buying group can use the default. When Maestro asks first, the approval shows the exact changes before anything applies, along with the object and fields it will write and the reasoning behind the request.

Wide-reaching administrative changes preview what is downstream of them, and the confirmation is refused if anything moved since it was shown. Maestro can only do what the person driving it could already do, with permissions rechecked as each request runs, so it cannot widen its own reach.

Skills

A field event at your company means something specific. Registration gets acknowledged immediately. Once someone is approved they get a confirmation, and then a reminder the day before. Everyone who has built one of these knows that, and nobody has written it down.

In Phave you write it down once, in plain language, as a Skill:

Skill /field-event: When asked to build an "Event - Field" campaign:
1. Confirm anchor date.
2. Build these steps and tactics:
REGISTERED — Acknowledge registration, send immediately on entry. APPROVED — Confirmation, send immediately on entry. Reminder T-1, send 1 day before anchor date.

That is not a configuration language. It is what you would tell a new hire on their first week. The campaign beside it in the screenshot is what came out of it: NYC Launch Event, a Registered step and an Approved step, with the acknowledgment, the confirmation and the T-1 reminder each timed against the entry or the anchor date.

Skills include tokens and email templates, so the standard and the assets that implement it stay together. They scope to a workspace or to the whole subscription, which lets a regional team's conventions and the company's brand rules differ without either being rewritten. A new hire inherits all of them on day one, and so does every agent that touches the platform.

This is the thing rules could never do. A rule covers one case, so a business needs one for every combination of role, industry, stage and behavior. Rules conflict as they accumulate, and every reorganization, new product or market shift means going back through all of them. Eventually the logic is layered enough that nobody wants to touch it, and the person who understands it becomes a single point of failure. A Skill is written once and stays true, because it describes the standard rather than enumerating the cases.

Scott Brinker puts the change in one line: "When your marketing automation is a prompt chain rather than a flowchart, the prompt is the logic." The consequence for an operations team is that the logic becomes readable. Anyone can read a Skill and say whether it is right. Almost nobody can do that with sixty campaigns of flow steps.

Air Traffic Control

Three campaigns want the same person on Tuesday: the product newsletter, a webinar invitation, and the second touch of a nurture track. Each decides on its own, and none of them knows about the other two or about what went out last week.

Every serious marketing team builds some version of air traffic control to deal with this. It is usually a standing meeting, a shared calendar of what goes out when, and a set of exclusion lists and suppression rules that somebody maintains. The meeting exists because the platform cannot do the arbitration.

Communication limits help without solving it. Cap a person at one email a day and three a week and the cap works exactly as advertised. But whichever campaign mails them first spends the limit, even when it is the weaker touch. The limit protects the buyer from volume and does nothing about quality.

What a marketer sets in Phave is the boundary: one email a day, three a week, six touches in a thirty-day playlist, and how much a scheduled campaign's date is allowed to move. A campaign can be pinned to its date, given a tight window, given a loose one, or left for Maestro to time.

Inside that boundary, Air Traffic Control weighs everything queued for that person across every campaign before anything goes out. What can move, moves. What cannot move waits or is dropped.

Because the arbitration happens ahead of the send rather than at it, there is a forward calendar. Open a person and you see the tactics in their window, what cleared, what was skipped, and what goes out tomorrow morning. Legacy platforms can only show you last month.

Nobody configures any of this. The hardest coordination problem in the category, the one that produced the standing meeting, is not a set of rules anyone writes. It is how the system behaves by default, and the marketer's job becomes the boundary rather than the arbitration.

Four Doors

An operations lead wants to update a scoring model at nine at night from the same AI client she uses for everything else. A CMO wants to ask in Slack where pipeline is stalling and what to do about it. A call recording agent should be able to write what it learned about an account back into the marketing platform, where it changes what that account gets next.

Phave has four doors. Your marketing team works in the app. Anyone who would rather chat than click uses Maestro Notebooks, where answers come back as the same charts, lists and campaign views they would see in the app. Anyone who wants to work from their own AI client connects over MCP. And your agents can drive Phave headless, through MCP or the API, with no interface at all. Same capabilities, same context, same guardrails, whoever is asking.

The third scenario should make you slightly nervous, because no person is involved in it at all. Once any agent can reach the system, the interface stops being where control happens. Permissions, approvals and the record of what was done have to be in the platform itself, or they do not exist.

So there is a question worth asking any vendor. An agent should connect as a specific person rather than as a service account, so it can only do what that person can do. Its reach should be scoped per credential, and off until someone deliberately turns it on. Access that works only at global permission cannot be given to anyone who is not already an administrator, which in practice means it cannot be given to anyone.

Every action should have a risk class, so anything consequential comes back to a human before it runs, showing what it will affect. And every decision should be reconstructable afterward: the signals, the ranking, what was chosen and what was rejected.

What This Does Not Mean for Marketing Operations

IDC's Gerry Murray expects that "single prompts will automatically generate, manage, and optimize processes, projects, and campaigns." He thinks that means fewer marketers. I would argue it means different ones.

Consider what somebody now has to write. An optimization objective is the directional intent Maestro works toward on a campaign and in each person's playlist, and it is written in plain language rather than configured. Keep and grow an existing customer. Prioritize onboarding and education at first, then renewal or expansion. Consider product usage and support tickets.

That is a strategy statement in a text box. Writing a good one requires knowing the business, the product and the customer, and writing a bad one sends thousands of people the wrong sequence for a month. The same is true of the Skills library, of which operations ask first and which use the default, of how much date flexibility a campaign gets, and of deciding where Maestro should stop and hand the decision back to a person.

Every one of those requires exactly the expertise that used to go into configuration. What changes is where it gets spent. Brinker again, on where the role goes: "The app-centric era of martech made marketers operators of tools. The agentic era will make them designers of context."

The tactical work ending is what lets the strategic work start. Nobody I know took a marketing operations job because they wanted to maintain suppression rules.

The Compromise Ends

The tradeoff was real for twenty years, and it was structural rather than accidental. Depth cost specification, specification needed a specialist, and the specialist became a queue that edited the marketing program before anyone saw a draft of it.

Reasoning removes the specification. The complexity does not disappear, and it should not, because marketing is complicated. What disappears is the requirement to be an expert in a platform and in a company's operational conventions before you can build anything.

That is one half of what changes. The other half is what a system does once it no longer needs to be told everything: instead of routing people through a flowchart, Phave computes a playlist for each person, which I wrote about separately. Deep, and not difficult, is the whole point of building a marketing automation platform now rather than adding AI to one built twenty years ago.