When I review a proposed AI workflow, I remove the model from the diagram first. If the remaining inputs, rules, owners, and failure path do not make sense, adding an LLM will only make the failure harder to inspect.
I use automation for repetitive, rule-bound work such as routing, tagging, summarising an inquiry, and preparing a draft for review. I use a model only where classification or generation adds something deterministic rules cannot. Strategy, approval, and the commercial definition of a qualified outcome remain human decisions. The build starts with those boundaries, not a list of AI features.
Good AI automation does not make a broken process faster. It makes one accountable workflow easier to operate, audit, and improve.In practice, I look for queues with repeated decisions: new leads needing an owner, enquiries needing a safe first reply, campaign data needing a decision note, or creative learnings that need to reach the next brief. If automation cannot make one of those queues faster, safer, or easier to audit, I leave it out.
What workflow do I draw before picking tools?
The exact tools vary: n8n, Make, Zapier, or a small service. I care more about the contract between steps than the logo on the tool. The responsibilities do not:
- Lead capture: a form, chat, or ad instant form fires a server-side or webhook event you control.
- Orchestration: the tool applies rules, dedupe, enrich, and route.
- LLM step (optional): classify intent, summarize the inquiry, draft a first reply for a human to send, or score fit against a documented rubric.
- CRM: create or update the contact, deal stage, owner, and source-attribution fields.
- Follow-up: WhatsApp Business API, SMS, or email through approved templates, with SLA timers for no-response.
- Feedback loop: the sales outcome, qualified, lost, and the reason, updates audiences and ad optimization.
What should we automate, and what should stay human?
That last row is the same measurement-governance problem worth probing in any MarTech partner evaluation: if the pixel and the CRM disagree, automation just scales the disagreement.
When the CRM in question is HubSpot, the routing logic sits in Workflows, and HubSpot's own documentation is useful for what it does not promise as much as what it does. Routing rules are built as sequential if/then branches on custom properties, product interest, territory, account type, evaluated in order against each lead, with a fallback path defined for whatever does not match a rule or whatever hits a rep who is already at capacity. That fallback step is the part teams skip when they are in a hurry, and it is the part that determines what happens to the leads the rules did not anticipate. HubSpot also documents an SLA-based reroute: if a rep does not accept an assigned lead inside a set window, the lead reassigns automatically rather than sitting unclaimed. We treat that as the minimum bar for a routing build, not an advanced feature, because a routing workflow with no reroute path just relocates the bottleneck from the inbox to the CRM.
Which three workflows would I automate first?
1. Lead qualification
New lead, dedupe, an LLM or rules-based fit score, then route to the SDR queue with a summary and a suggested next question. Not auto-send loops that ignore what the lead actually asked. We watch time-to-first meaningful touch, the share of leads with the correct owner and stage, and the SQL rate from the routed bucket.
The enrollment trigger is the part clients most often get wrong before we start. HubSpot separates filter-based enrollment, a record meets a set of property conditions, from event-based enrollment, a record enrolls the moment a specific event fires, such as a form submission or a custom event. Filter-based triggers re-check the record against the rule, event-based triggers fire once at the moment the event happens; picking the wrong one either enrolls a lead too early, before enrichment has run, or misses it entirely because the property that would have matched the filter was not set yet when the event occurred. We map which trigger type each workflow needs before writing a single branch, because that decision is expensive to unwind once leads are already flowing through it.
2. Content generation pipeline
A brief in Notion or Airtable, an LLM drafts variants (headlines, hooks, product-page bullets), an editor approves, and assets get tagged with a creative ID for the ads. We measure cycle time from brief to live, the fatigue window before a refresh, and downstream CTR and conversion by batch, not word count.
3. Ad creative iteration
A performance export, the model summarizes losers and winners, generates new hooks inside the brand guardrails, a human selects, and we launch a new batch. The metrics are cost per qualified action, tests per month, and the creative discard rate with documented reasons. This is the operational engine behind treating personalization as four aligned layers.
Failure modes (honest)
Which metrics actually matter?
We track automation against operational and commercial outcomes, not "tasks completed":
- Response time: median minutes to the first human-led reply where one is required.
- Manual hours saved: estimated with the client, not invented to a false precision.
- Error rate: miscategorized leads or wrong-message sends per 1,000 events, trending down over time.
- Cost delta: tooling and contractor time versus the prior process, paired with SQL efficiency, not CPL alone.
Exact numbers depend on the vertical and the stack, so we baseline before and after go-live rather than quoting a generic benchmark.
Every outcome also gets a protection metric. Faster replies matter only if wrong-message sends stay low. More routed leads matter only if sales acceptance does not drop. More creative variants matter only if the team can trace which batch changed a qualified action.
What QA artifact do we expect before launch?
No automation ships because the demo worked once. Before go-live, the workflow needs a small audit trail:
This is the difference between a useful AI workflow and a tool pile. If the audit trail does not exist, the automation is not production-ready.
How do we release automation more safely?
First, stabilise the contract. Agree the event names, required fields, CRM ownership, and the source that decides whether a lead or sale is valid.
Then ship deterministic orchestration. Deploy deduplication, routing, logging, and alerts without a model. This proves the integrations and gives the team a baseline.
Add intelligence behind a review queue. Introduce classification or drafting only after normal, edge, and failure cases are written down. Expand its authority only when the evaluated output earns it.
The end state is repeatable experimentation, hypothesis, ship, measure, document, aligned with how we describe integrated delivery.
Buy workflows, not tools
The brands that get value from AI are not the ones with the most tools; they are the ones who automated a process they already understood. AI speeds up the rule-bound parts once the data underneath is trustworthy, and does real damage when it is not, so the order of operations is the whole game. If tracking and CRM stages are not stable, that is the first build, the same foundation behind why fragmented agencies leak growth.
When we scope an automation engagement, we start from your stack and your worst time-sink, not a feature list. Bring the queue, the CRM fields, and the first broken handoff to contact True North and you get back a sequence, the order we would build it in, not a slide deck of logos.
