An AI enablement case in marketing ops

Here is a problem I see often, with the details changed enough to protect the client but true to the shape. A marketing team runs campaigns across many brands. The campaign logic and the customer journeys live in one platform, something like Optimove. The email templates live in a separate tool, say Iterable. Over a couple of years, with many people editing and nobody owning a template standard, the second tool has grown to more than 200 near-duplicate template variations.

The team is drowning in it. One CRM manager has quietly built a spreadsheet-and-script contraption that generates templates faster, which is genuinely clever and solves maybe a tenth of the problem. The team is now looking at moving to a cleaner tool, Customer.io is a common destination, and dreading it, because a manual migration of that mess is a large, risky project.

It helps to look at this through a marketing ops lens. The campaign platform and the template tool were bought to enable the team, and they have stopped doing it. The team now spends its week maintaining the tooling instead of running campaigns, so a setup that was supposed to be an asset has turned into a cost the ops function carries. The mature response is to treat the fix as an enablement project with a number attached, which is also what makes AI the right tool for it.

This is one of the best kinds of AI enablement project, for reasons I have written about in choosing which projects are worth building. It can name its number: the hours the CRM team loses to template wrangling every week, plus the cost and risk of a manual migration.

And it is highly automatable, because these are modern tools with APIs and webhooks, the interfaces that let code read and write the templates and get told when something changes. The realistic split is that AI drives 80 to 90% of the cleanup and the migration, and a human validates and moves the last 10 to 20%.¹ This piece is the walkthrough of how.

First principle: never migrate a mess

The instinct is to treat the migration as the project: point everything at Customer.io and move. That is the version that is slow and risky, because you would be carrying 200 tangled templates into the new tool and recreating the same mess one layer deeper.

The order that works is cleanup first, migration second. You clean up inside the current tools until the template set is a small, deduplicated, well-named collection, and only then move that clean set across.

Two things make this the right order. The cleanup delivers value on its own, before the risky migration even starts, because it makes the current tools work the way they were meant to and makes the team’s daily work lighter. And the cleanup is what earns the trust to attempt the bigger move, because the team sees a real win first.

flowchart LR
    mess["200+ ungoverned<br/>template variations"] --> clean["Cleanup:<br/>cluster, dedupe,<br/>standardise"]
    clean --> canon["~20 canonical,<br/>well-named templates"]
    canon --> migrate["Migrate the<br/>clean set"]
    migrate --> target["Customer.io,<br/>set up right"]

The pipeline, stage by stage

Both the cleanup and the migration run as the same kind of pipeline: read through an API, transform with a model in the loop, and write through an API, with a human checkpoint where judgement is needed. Here are the stages.

Extract. Pull every template and every piece of campaign logic out of the source tools through their APIs. This is pure engineering, fully automated, and it gives you the raw material as structured data instead of screenshots.

Understand and cluster. This is where a model earns its place. Two hundred templates that look different are usually a much smaller number of real templates plus a lot of drift: a changed subject line here, a tweaked footer there, a one-off promo that never got cleaned up. A model reads the templates and groups the near-duplicates, so the true size of the problem becomes visible. Often the 200 collapse toward 20.

Dedupe and standardise. For each cluster, you settle on the canonical version and express the variations as parameters rather than as separate templates. A model drafts the canonical template and the parameter list; a human approves the ones where the variations genuinely differ and the choice matters. The output is a small set of clean, named, parameterised templates.

Map. The target tool models things differently from the source, so fields, personalisation tokens, and journey steps have to be mapped across. A model proposes the mapping from both tools’ schemas; a human approves it, because this is where two tools quietly disagree about what a thing means.

Dry run. Generate everything in the target tool against a copy or a sandbox, touching no live audience, and produce a diff of exactly what will exist and what will change. Nobody applies anything to production yet.

Review and cut over. A human reviews the diff and a sample of the migrated campaigns that would reach real customers, then approves a reversible cutover. Reversible is the word that matters: if something is wrong, you roll back rather than scramble.

flowchart TB
    e["Extract via API"] --> u["Understand + cluster<br/>(model)"]
    u --> d["Dedupe + standardise<br/>(model drafts, human approves)"]
    d --> m["Map to target schema<br/>(model proposes, human approves)"]
    m --> dry["Dry run in sandbox<br/>+ diff"]
    dry --> rev{"Human review<br/>of the diff"}
    rev -->|looks right| cut["Reversible cutover"]
    rev -->|issues| d

Step through that pipeline below. Each stage shows what the AI does, what a human checks, and how the effort splits.

Why this is 80 to 90% automatable, and where the other 10 to 20% is

The reason so much of this can be automated is that every stage reads and writes through an API, and the one genuinely hard part, making sense of 200 messy templates, is exactly the kind of pattern-matching a model is good at. Extraction, generation, mapping proposals, and the dry-run diff are all machine work.

The part that stays human is judgement, and it clusters in a few specific places:

• Deciding which near-duplicate is the canonical one when they truly differ.
• Approving a field mapping where two tools model something differently and a wrong choice would corrupt personalisation.
• Checking the sample of migrated campaigns that will hit real customers.
• Signing off the reversible cutover.

That is perhaps a tenth to a fifth of the work, and it is precisely the part where a mistake would reach an audience, so it earns the manual attention.

There is a nice property in this division. The model does the volume, which is the part that made the manual project feel impossible, and the human does the judgement, which is the part a person is actually better at and would want to own anyway. Nobody is asked to hand-edit 200 templates, and nobody is asked to trust a machine with the customer-facing cutover unreviewed.

The cleanup is the first win

I want to be clear that the first deliverable is the cleanup, well before the migration completes. When the 200 variations collapse to 20 clean parameterised templates inside the existing tools, the CRM team’s week gets lighter immediately: they stop digging through near-duplicates, the clever spreadsheet workaround is no longer load-bearing, and the tools finally work the way they were sold.

That win is real on its own, and it is also the thing that earns the trust and the budget to take on the migration, which is the larger and riskier move.

That sequencing is the whole reason to frame this as an enablement project instead of a one-off IT ticket. You are not only moving data between tools. You are finding an expensive, painful, repetitive problem, putting a number on it, delivering an early win that makes people’s work better, and using that to earn the next, bigger piece.

The economics of the migration, and how you would tie its cost to the marketing budget that owns it, follow the model in running AI enablement as a P&L.

Key takeaways

• A messy martech setup, campaign logic in one tool and hundreds of ungoverned templates in another, is a strong AI enablement project: it can name its number and it is highly automatable through the tools’ APIs and webhooks.
• Clean up before you migrate. You never migrate a mess, and the cleanup delivers value on its own while earning the trust to attempt the bigger move.
• Run both the cleanup and the migration as one pipeline: extract via API, cluster and dedupe with a model, map to the target schema, dry-run in a sandbox, and cut over reversibly.
• AI drives 80 to 90% of it. The human keeps the judgement: which template is canonical, whether a field mapping is right, the sample that hits real customers, and the cutover sign-off.
• De-risk with a sandbox, a reviewable diff before anything is applied, and a reversible cutover, so a mistake is recoverable rather than live.

This is one worked example of the operating model in running AI enablement as a P&L. If you are sitting on a martech mess and a migration you have been putting off, a short call is a good way to talk through whether it is a good first project.

Footnotes

1. The 80 to 90% is the split I have seen on this shape of job, and it will move for yours. Where the source tool has a thin API or the templates encode heavy custom logic, more of the work stays human, so treat it as a starting estimate you revise once the extract stage shows you how clean the data really is. ↩