Marketing automation with AI: triggers, approvals and exceptions

A good AI workflow does not simply automate as many steps as possible. It makes a bounded marketing process traceable: a clearly defined event starts it, checked data flows in, rules and AI tasks are separated, people decide at the right points, and a stop signal ends the run. Anyone who can describe these elements on a sheet of paper before choosing a tool has a sound basis for a pilot. Anyone who orders only "more automation" moves unresolved decisions into software.

Determine the workflow first, then the tool

A workflow is the sequence of state, event, decision and action. A platform is only one possible technical implementation. This distinction protects against two typical false starts: a team buys an extensive suite before the process is clarified, or it builds an impressive AI demo with no clear responsibility in day-to-day work.

So start with a concrete sentence: "When event A occurs and condition B is met, the system creates proposal C; role D reviews it; only after approval does action E follow; on signal F the run stops." The sentence brings start, scope, decision, approval and exit together in one model. A project to "process a lead" is too broad. "When a complete event registration is received, draft a confirmation" is checkable. Whether the draft may later be sent remains a separate decision.

Six building blocks of a controllable workflow

The first building block is the trigger. It denotes an observable event, not an interpretation. A form submission, a status change or the arrival of a scheduled date or deadline can be a trigger. "Interested contact", by contrast, is already an assessment. Every trigger needs a source, a timestamp, a unique event ID and a rule for duplicates. Otherwise the same case can start several times.

The second building block is the eligibility check. It clarifies whether the record is complete, whether the purpose fits the step and whether exclusions apply. These include, for example, blocklists, missing mandatory fields, already achieved goals or withdrawn consent. This check belongs before the AI task. A language model should not guess whether a record may be used.

The third building block is the AI task. Describe it precisely: classify, summarise, propose variants or flag missing details. The input, the permitted sources, the output format and what to do when the result is uncertain belong in the brief. "Write the best message" is not testable. "Create three drafts based on the approved product attributes and flag unsupported statements" can be checked.

The fourth building block is the decision. A deterministic rule, an AI recommendation and a human approval are three different things. The data field "language = German" can drive a fixed branch. An AI can supply a topic suggestion. The person responsible decides whether the proposal is on-brand, factually sound and appropriate in the given context. The documentation should show which mechanism is responsible for which step.

The fifth building block is the action. Saving a draft, creating a task and sending a message are not equally risky. For a pilot, an action with low impact is advisable, such as a draft in a review queue. Changing a live system or sending a message needs separate, explicit authorisation. The approval must refer to the specific version; general consent to "AI in marketing" is not enough.

The sixth building block is the exit. A workflow ends when the goal is reached, a deadline expires, consent is withdrawn, an error occurs or a manual stop is issued. Without an exit it accumulates outdated cases and can trigger unsuitable actions. Microsoft documents triggers for starting, continuing and stopping a journey. Repetition, exclusion and duplicate rules remain part of the design method recommended here, whichever platform is used.

AI belongs within a bounded scope for action

The central design question is not "What can the model do?" but "Which deviation may the process tolerate?" For an internal summary, a small stylistic error can be acceptable. With price, legal, health or contract claims, even one unsupported statement can be problematic. The workflow therefore needs clearly defined permitted sources, prohibited content, an output format, review criteria and clear rules for referring a case to the person responsible.

A practical control point is the separation of proposal, approval and execution. The model supplies a proposal. A reviewer with the relevant subject-matter expertise checks it against visible criteria. Only a downstream, logged step may execute the approved version. If the draft is changed, the old approval lapses. This keeps it visible whether a person really saw the executed version.

The current GOV.UK guidance on introducing GenAI names engagement, training and support, risk management and ongoing monitoring as related implementation tasks. For this workflow these are review areas, not a supplier certification and not a Swiss legal standard.

Inputs also need limits. Secrets, access credentials and unnecessary personal data do not belong in prompts. Pseudonyms do not automatically replace a data protection review. Record which purpose is pursued, which data fields are necessary, where they are processed and how long intermediate outputs are retained. Where high risk is anticipated, Swiss data protection law provides for a data protection impact assessment; whether that threshold is reached must be assessed for the specific case.

Test with an error catalogue, not only the ordinary case

A workflow test should not only show that an ordinary case passes through. It needs at least five classes: valid input, missing data, contradictory data, repeated event and impermissible content. For each class, the expected state is defined in advance: continue, wait, send for review, abort or retry the failed step after a temporary technical error. An automatic retry is only sensible when the action is idempotent and produces no duplicate effect.

Test data should be synthetic and free of real personal data. Alongside the content, also check the process trail: was the right version used? Is the source visible? Was the approval logged? Did the stop signal work? Can the person responsible find, explain and end a case? A good result is not just a nice text but a manageable process.

Measure without confusing activity with impact

To begin with, operational metrics suffice: number of started cases, share of fully processed cases, review rate, abort reasons, cycle time and recurring error classes. These values show whether the process works. These metrics do not establish that the workflow caused an improvement in the marketing outcome. Opens, clicks, qualified enquiries or revenue need their own measurement definition; attribution and incrementality therefore belong in a separate measurement plan.

Also capture human correction. Not as a productivity competition but as a quality signal: which statements are frequently removed? Where is context missing? Which inputs lead to cases being referred to the person responsible? Better rules, sources and templates emerge from these patterns. A rising automation rate is not an end in itself. If review effort or risk increases, a narrower workflow can be the better solution.

Limit a pilot to four stages

Stage one runs offline with synthetic cases. Stage two produces internal drafts without changing an external system. Stage three works with real, permissible data but stays in an approval queue. Only stage four allows a clearly bounded action in the live system. Every transition needs criteria defined in advance, a named person responsible and a defined procedure for returning to the previous process.

The pilot should be small enough that the team can review every case. Do not choose a business-critical customer process as the first attempt. A stable, frequent and well-understood process with reversible output is more suitable. Document the initial state so that not every later change is attributed to the AI.

Treat changes like a new workflow

A pilot that met its acceptance criteria is not a permanent approval for every later model or process version. If the data source, prompt template, model version, rule, recipient group or external action changes, the impact is assessed. A small formatting change does not require a full retest of unrelated checks; for changed content or a changed version, renew the approval as appropriate while reusing the checks whose inputs and meaning did not change. A new data class or an additional effect in the live system reopens the subject-matter, technical and, where applicable, legal review.

Keep a short change log with the reason, the affected building blocks, the test cases, the decision, the person who approved it and how to return to the previous process. After approval, first observe error and review patterns before the scope grows. A fixed shutdown date forces an explicit decision to extend the pilot. That way a pilot does not become an unattended permanent automation simply because nobody reset the original status.

Training is also part of operation. Reviewers need to know which record they are looking at, which errors a style review alone will miss and how to refer a case to the person responsible. Operators need to be able to reach that person and a named deputy who can take over, not just a documentation page. The workflow is organisationally robust only when cover arrangements, the incident escalation procedure and clear authority to stop it all work in practice.

The decision template

A workflow is ready for a pilot when trigger, data purpose, inputs, rules, AI task, approval role, action, exit, error handling and metrics are named. If one of these points is missing, the next task is not "configure the tool" but "clarify the decision".

This method is deliberately technology-neutral. It can help a marketing team assess an automation project. maitiq's existing product is a Google Ads automation platform; a workflow that runs in a CRM, journey or omnichannel system is not part of that product and can be scoped in a separately agreed project. If the flow under consideration concerns exclusively or substantially Google Ads, a separate, read-only Google Ads audit can be a sensible next checkpoint. That is a conditional handover, not a statement about cross-channel implementation.

An illustrative example: a lead workflow with a visible result

The trigger is a new enquiry. In this example, the workflow checks that the mandatory fields are complete, proposes the person or team responsible for the enquiry, prepares the next step and sends a reminder for enquiries that are still open. Duplicates and unclear enquiries go to a visible exception view. Such a workflow can be scoped in a separately agreed project; a mere acknowledgement of receipt is not yet a qualified handover.

Measure processing time, stalled enquiries and successful handovers. In a separately agreed project, maitiq can help design this process, set it up in the agreed systems and train the team. Rule-based steps stay rule-based; AI is added only where linguistic or unstructured information really has to be evaluated.

How a first pilot with maitiq begins

In a separately agreed project, a focused initial assessment shows which workflow is ready for a pilot, which exception puts it at risk today and how a controlled pilot can be set up. You receive a clearly defined use-case scope, the open data and control questions, a pilot plan and the criteria for later operation.

Decision rule: Automate a stable, repeatable decision first; automation only makes a chaotic process faster and more chaotic.

Sources and how to interpret them

Platform documentation explains features and limits; authority sources the legal context. Publications by providers and associations must be classified accordingly, not as a general market price or proof of success. Information on how maitiq works is available at maitiq.com.

Have maitiq review your specific case.