Mogo / Senior Marketing Operations Manager / 2024 – Present
Email validation and compliance workflow
The validation workflow worked technically. The real problem was that it was not built around how Compliance actually reviewed content.
The read
Every lifecycle email required four to five rounds of review between the lifecycle team and Compliance before it could send. No self-serve QA existed. Every send was a back-and-forth cycle that added days to production time.
The original request was a spam checker. Something to flag obvious deliverability risks before content went to Compliance. I built the first version. It worked technically. The output was inconsistent.
I looked at why. The workflow was checking for spam signals. Compliance was not reviewing for spam signals. Compliance was reviewing for specific regulatory language requirements, prohibited claims, and jurisdiction-specific disclosure rules. The tool was solving for the wrong problem because I had not brought the actual subject matter expert into the design.
The read: the workflow needed to be built around how Compliance actually reviewed content, not around what I assumed they cared about.
The decision
Stop iterating on the technical layer and redesign the workflow from the compliance review process outward. Bring Compliance in as a design partner, not a downstream approver.
The decision to rebuild from scratch rather than patch the existing workflow cost time upfront but was the only path to something the team would actually rely on.
The metric I chose
Compliance review cycles per email. How many rounds of back-and-forth before sign-off? That was the friction the tool was supposed to remove. If the number did not drop, the tool was not working regardless of what it produced technically.
The build
Sat with Compliance before touching the workflow. Documented exactly how they reviewed content: what they were looking for, what triggered a flag, what the specific rules were for each content category, what varied by jurisdiction. Built that logic into the prompt architecture and validation layer.
The workflow went through four versions:
Version 1: spam signal checking. Technically functional, wrong problem.
Version 2: added compliance flag categories. Better output but inconsistent - LLM was interpreting rules rather than applying them.
Version 3: brought Compliance in. Replaced interpretation with explicit rule sets. Output became reliable but too verbose for practical use.
Version 4: restructured output format so results were actionable in seconds. Compliance review the output, not the email. The workflow does the first pass.
Built in n8n so the lifecycle team could run validation themselves during drafting. The compliance question was answered before the email ever reached Compliance.
4–5 rounds → 1–2 rounds
Compliance review cycles per email
-50%
Review cycle time reduction
The lesson was not about the tool. It was about who you design with. The first three versions failed because I was designing a compliance workflow without a compliance expert in the room. Version four worked because Compliance defined the rules and I built around them. Subject matter experts are not approvers. They are design inputs.
Tech
n8n, workflow orchestration and self-serve QA
OpenAI API, content validation and flag classification
Braze, lifecycle email production pipeline
Confluence, workflow documentation and rule sets
Miguel N. Monzones
Vancouver, BC, Canada
