Marketing Automation: What to Keep Human

Your marketing team has a list of tasks it wants to automate. Pulling reports sits beside writing customer emails, routing inquiries, and deciding which campaigns deserve more money.

Those don't carry the same weight. Moving a number into a report is different from interpreting it, and preparing an email is different from sending it.

I would choose marketing automation by looking at how repeatable the work is, whether the inputs are reliable, and what happens when it goes wrong. The scorecard and examples below will help you decide what software can handle, where a person should step in, and whether the effort is worth it.

TL;DR & Takeaways

• Automate a defined step rather than handing over an entire marketing function.
• Missing permission, unreliable inputs, or mistakes you can't contain are reasons to stop, even when the time savings look good.
• People should own strategy, sensitive communication, and exceptions that change what the business should do.
• Count review, repairs, and maintenance when measuring time saved.

Start with the work, not the AI tool

Write down what happens between a task arriving and someone accepting the result. Identify the inputs, decisions, actions, and owner of each step.

A weekly marketing report might involve collecting data, checking date ranges, calculating agreed metrics, drafting commentary, and deciding what to change. Collection and calculation can follow fixed rules; the recommendation needs someone who understands the business.

You don't need generative AI for every step. If a country field maps to a territory through an approved lookup table, use that rule rather than asking a model to guess the territory from free text.

Anthropic's guidance on building agents distinguishes predefined workflows from agents that direct their own processes and tool use. It recommends starting with the simplest solution that works.

Before building anything, check whether the work should exist. Stop producing an unused report before investing in a faster way to produce it.

For work worth keeping, record the current volume, handling time, errors, and delays. Ask the person doing it what makes a routine case become an exception.

A marketing automation selection scorecard

Use this scorecard for one proposed step. Mark each row ready, needs work, or human-led, and attach evidence.

This is a decision aid I recommend, not a validated scoring model. Don't add up the marks: repeatable work still needs permission.

A row marked needs work needs an owner and a specific fix. Instead of “improve the data,” specify which customer-status field to trust and stop records where it conflicts with another source.

Don't let the system act on its own when data-use permission is unresolved, a critical fact can't be checked, or nobody owns exceptions. You might still let it prepare an internal research note without allowing it to contact the person described.

For sensitive data or regulated activity, involve the appropriate privacy, security, or legal owner before a live test. A human approval button doesn't make an otherwise impermissible activity acceptable.

NIST's AI Risk Management Framework provides voluntary guidance for considering trustworthiness in AI design, development, use, and evaluation. This scorecard is a smaller practical exercise, not a compliance assessment or NIST certification.

Marketing systems you could automate

These are illustrative workflow designs, not claims about systems I've built or features every platform includes. Each needs suitable access, reliable data, and testing in your own setup.

Some need a person to approve each action. Others can run under rules approved in advance, with a person checking exceptions and reviewing results.

Choose the rows that address an actual bottleneck. A reporting workflow won't help much if nobody agrees what the numbers mean, and faster lead routing won't fix an offer buyers don't want.

Decide what can run without approval

Rule-based execution fits a documented decision with reliable inputs and a checkable result. Copying approved campaign identifiers into a report or assigning an internal task through an agreed territory map can fit here.

Keep a log and a way to detect failures. A task sent to the wrong owner can still delay a valuable inquiry.

Assistance with approval means software prepares something and a person checks it before the next action. Drafting a performance explanation or proposing duplicate records for review fits here.

Show the reviewer what approval will do. Permission to draft a reply isn't permission to send it, and approval of a campaign concept isn't permission to change its budget.

Human-led work includes goals, positioning, trade-offs, sensitive relationships, and unfamiliar exceptions. Research can help, but I would keep the decision and its reasoning with the person responsible for the outcome.

An example in practice.

Consider a hypothetical B2B team handling inbound inquiries. It wants to spend less time gathering context while keeping people responsible for the customer response.

The workflow reads the inquiry, finds the matching account, collects approved fields, and prepares an internal handoff. It doesn't send messages, change consent records, or overwrite account ownership.

Suppose the team handles 80 inquiries per week and spends five minutes preparing each handoff. Under these hypothetical assumptions, that's 400 minutes of weekly preparation.

If automation needs one minute of review per inquiry, plus 40 minutes resolving exceptions and 40 minutes of maintenance, ongoing handling takes 160 minutes. That frees 240 minutes, or four hours per week.

A hypothetical 12-hour setup effort would take three weeks to recover at that rate. That's time recovery only: software charges, security review, training, and work outside these assumptions still belong in the decision.

If review takes three minutes per inquiry instead, weekly handling rises to 320 minutes and frees only 80 minutes. Recovering the same setup effort takes nine weeks.

That's why I would time the review rather than estimate it from a demo. Freeing time doesn't automatically save cash or create revenue; decide what useful work will receive it.

Give human reviewers a clear job

“Human in the loop” means little until someone knows what to check, when to check it, and what happens if they can't.

Give the reviewer the original input, proposed output, supporting evidence, and exact action awaiting approval. In the inquiry example, that means showing the submitted request and account match, not only a tidy summary.

Write down what an acceptable result looks like before testing. Reviewers should be able to spot a wrong account match, reject an unsupported claim, and see whether approval would trigger anything else.

Set a response expectation and name a backup. If neither person is available, hold the action; silence isn't approval.

Track exceptions with an owner and status rather than scattering them across chat. Record why each case stopped and whether the fix belongs in the data, the rule, or the task itself.

Plan for partial failures too. If a task was created but logging failed, check what happened before retrying so you don't create it twice.

Test before giving the system more control

Start with historical examples in a test environment, or run in shadow mode: produce outputs without taking live action. Compare results with a human-checked answer, including cases the old process handled badly.

Include missing fields, conflicting account matches, duplicate submissions, stale records, unavailable reviewers, and interrupted runs. Check that the workflow stops when it should.

HubSpot's workflow-testing documentation provides a useful example: its simulation can show a record's path without executing the workflow actions, but it tests the current workflow version. That doesn't prove every future input will work, and explicitly sending preview emails is a separate action.

Before a limited live test, agree on success and stop conditions. For the inquiry workflow, track preparation time, reviewer corrections, unresolved exceptions, time to ownership, and duplicated or misrouted tasks.

Don't hide serious failures inside an average error rate. An unauthorized message or exposed customer record should stop the workflow for investigation, even if most handoffs were correct.

Give the system more responsibility only after the owner has evidence that quality holds and the fallback works. Retest when fields, permissions, tools, prompts, or business rules change.

Choose one task to test

Pick a recurring task with a clear owner and a measurable burden. Break it into steps, apply the scorecard, and write down what the system must not do without permission.

Test the smallest useful piece away from customers and live budgets. If it doesn't save effort after review and repairs, change it or leave it manual.