DEV Community: Michael

ABM for Engineers: How to Build a Target Account Machine Instead of Spraying Emails

Michael — Thu, 20 Aug 2026 12:00:55 +0000

Most account-based marketing advice reads like a LinkedIn horoscope. "Align your teams." "Deliver value." "Be personal at scale." None of it tells you what to actually build.

So let's fix that. If you think in systems, data models, and pipelines, ABM is easier to reason about than you'd expect. It's really just a filtered list, an enrichment step, and a personalization loop wired to your CRM.

Here's how to ship your first campaign without drowning in vendor demos.

What ABM Actually Is (in Plain Terms)

Traditional demand gen casts a wide net: run ads, capture leads, hope some convert. ABM flips it. You pick the specific companies worth winning, then concentrate everything - content, outreach, ads - on the buying committee inside those accounts.

Think of it as WHERE account IN (target_list) instead of SELECT * FROM everyone.

The payoff is efficiency. Instead of 10,000 cold contacts, you work 200 accounts you already know can afford you and fit your product.

Step 1: Build the Target Account List

This is the whole game. A bad list guarantees a bad campaign, no matter how slick your automation is.

Start with your best existing customers and reverse-engineer the pattern. Firmographics (industry, headcount, revenue), tech stack, and buying triggers (recent funding, new hires, tooling changes).

You can score accounts programmatically instead of eyeballing a spreadsheet:

def score_account(acct):
    score = 0
    # Firmographic fit
    if acct["employees"] in range(50, 1000):
        score += 30
    if acct["industry"] in {"saas", "fintech", "ecommerce"}:
        score += 25
    # Intent / triggers
    if acct.get("recent_funding"):
        score += 20
    if "hubspot" in acct.get("tech_stack", []):
        score += 15  # they invest in tooling
    if acct.get("hiring_ops_roles"):
        score += 10
    return score

targets = [a for a in accounts if score_account(a) >= 60]
targets.sort(key=score_account, reverse=True)

Pull the raw data from Clearbit, Apollo, or a scraped enrichment pipeline. The goal: a ranked list of 100-300 accounts you can defend with reasons, not vibes.

Step 2: Map the Buying Committee

Companies don't buy - people do, usually four to seven of them. For each target account you need the personas: the economic buyer, the champion, the technical evaluator, the blocker.

Store this as structured data so your automation can branch on role:

const account = {
  domain: "acme.io",
  tier: 1,
  contacts: [
    { name: "Dana Cole", role: "VP Ops", persona: "economic_buyer" },
    { name: "Sam Reyes", role: "Ops Manager", persona: "champion" },
    { name: "Lee Park", role: "IT Lead", persona: "technical_evaluator" }
  ]
};

Different personas get different messaging. The champion cares about their daily pain. The economic buyer cares about ROI and risk. Same account, different payloads.

Step 3: Personalize Without Doing 300 Manual Hours

"Personalized at scale" is where most people either burn out or send obviously templated garbage. The trick is variable-driven personalization: a strong template with a few genuinely researched fields.

An LLM can generate the researched line if you feed it real signal:

prompt = f"""
Write one opening sentence for a cold email to {contact['name']}, 
{contact['role']} at {account['domain']}.
Reference this trigger: {account['trigger']}.
No flattery, no 'I hope this finds you well'. Under 25 words.
"""

opener = llm(prompt)
email = f"{opener}\n\n{value_prop_by_persona[contact['persona']]}\n\n{cta}"

Keep the value prop and CTA as fixed, tested blocks. Only the opener and one or two merge fields change. That's the difference between "Hi {FirstName}" spam and something that reads like a human noticed them.

Step 4: Orchestrate the Channels

ABM works because you surround the account. One email does nothing. A coordinated sequence does:

Email to the champion and evaluator
LinkedIn connection + comment from the AE
Retargeting ads scoped to the account's domain
Direct outreach from a founder to the economic buyer on Tier 1 accounts

Wire this with an automation layer (n8n, Make, or your own scheduler) so a reply or a page visit triggers the next step automatically. When someone from acme.io hits your pricing page, the AE should get a Slack ping the same minute.

Step 5: Actually Align Sales and Marketing

The eternal cliche - but it has a concrete definition. Alignment means both teams agree on:

The account list (same accounts, no arguing)
The definition of an engaged account
Who does what at each stage
A shared dashboard

Write it down as a service-level agreement. Marketing commits to X engaged accounts per month; sales commits to following up within Y hours. If it's not measurable, it's not alignment - it's a group hug.

Measuring What Matters

Forget open rates as a north star. For ABM, track account-level engagement: how many target accounts moved from cold to engaged to opportunity. Your funnel is measured in logos, not leads.

Start with 25 accounts, not 300. Run one tight sequence, measure the reply-to-meeting rate, then scale what works. ABM rewards depth over volume - build the machine small, then turn up the throughput once the numbers hold.

Originally published at getmichaelai.com

Your B2B Stack Is 5 Tools and 500 Manual Handoffs. Fix the Handoffs.

Michael — Wed, 19 Aug 2026 12:01:16 +0000

Most teams obsess over which tools to buy. Wrong problem. By 2025, the tools are commodities - a CRM is a CRM. What separates teams that scale from teams that stall is the wiring between the tools.

A disconnected stack means humans copy-pasting between tabs, Slack messages that say "did you update the sheet?", and data that's stale the moment it's entered. That's not a scaling problem. That's an integration debt problem.

Here are the five tool categories that actually matter for operations - and, more importantly, how to connect them so they run without you.

The Five Layers That Matter

Forget brand loyalty. Think in layers. Each layer owns a job, and the value is in the seams between them.

1. System of record (CRM / database)

HubSpot, Salesforce, Attio, or even Airtable/Postgres if you're early. This is the single source of truth for customers, deals, and accounts. Rule one: everything writes back here. If a tool creates data that never lands in the record, you've created a shadow system.

2. Communication + scheduling

Slack, email, Cal.com. This is where humans coordinate and where automations report in. The trick is treating these as programmable surfaces, not just inboxes.

3. Document + billing

Stripe, DocuSign, invoicing tools. High-value events live here: contracts signed, payments made, subscriptions churned. These fire the events your automations should react to.

4. Analytics + reporting

Metabase, PostHog, a warehouse like BigQuery. You can't scale what you can't see. This layer answers "is the machine working?"

5. The orchestration layer

n8n, or code you own. This is the layer nobody budgets for and everyone needs. It's the connective tissue that turns four disconnected SaaS products into one operating system.

Skip layer five and you've bought four islands.

The Orchestration Layer Is the Whole Game

Here's the mental model: your other tools are functions. The orchestration layer is the runtime that calls them in the right order when the right thing happens.

A concrete example. A deal closes in your CRM. Without orchestration, someone has to: create the Stripe customer, generate the invoice, provision the account, post to Slack, and update the onboarding tracker. Five manual steps, each a chance to forget.

With orchestration, one webhook does all of it:

// n8n Function node or standalone worker
// Triggered by a CRM 'deal.won' webhook

export default async function onDealWon(deal) {
  // 1. Create the billing customer
  const customer = await stripe.customers.create({
    email: deal.contact.email,
    name: deal.company,
    metadata: { crm_deal_id: deal.id }
  });

  // 2. Kick off subscription / invoice
  await stripe.subscriptions.create({
    customer: customer.id,
    items: [{ price: deal.plan_price_id }]
  });

  // 3. Write the customer ID back to the system of record
  await crm.deals.update(deal.id, {
    stripe_customer_id: customer.id,
    status: 'onboarding'
  });

  // 4. Tell the humans what happened
  await slack.postMessage({
    channel: '#wins',
    text: `🎉 ${deal.company} signed ($${deal.value}). Onboarding kicked off automatically.`
  });

  return { ok: true, customer: customer.id };
}

Notice step 3. The Stripe ID flows back to the CRM. That's the difference between a stack and a pile of tools - data closes the loop instead of leaking.

Design Principles That Keep This From Breaking

Automations rot when they're built carelessly. A few rules that keep them alive:

Idempotency. Webhooks retry. If the same deal.won event fires twice, you don't want two Stripe customers. Key off a stable ID and check before you create.

def ensure_customer(deal):
    existing = stripe.customers.search(
        query=f"metadata['crm_deal_id']:'{deal['id']}'"
    )
    if existing.data:
        return existing.data[0]
    return stripe.customers.create(
        email=deal['email'],
        metadata={'crm_deal_id': deal['id']}
    )

One source of truth per field. If both the CRM and the billing tool think they own plan, you'll get conflicts. Decide who's authoritative and let the rest read.

Fail loud. A silent automation failure is worse than a manual process, because nobody notices for weeks. Every workflow should post to a monitoring channel when it errors, with enough context to fix it.

Version your workflows. Treat automation logic like code. Export it, commit it, review changes. "Someone edited the Zap and now onboarding is broken" should never be a sentence in your standup.

Where AI Actually Fits

AI belongs inside the orchestration layer, not bolted on top. Use it for the fuzzy steps that used to require a human judgment call: classifying an inbound lead, summarizing a support thread before it hits the CRM, drafting the onboarding email, routing a request to the right team.

The pattern is always the same - deterministic plumbing handles the reliable parts, an LLM call handles the interpretation, and the result flows back into your system of record. AI is a step in the pipeline, not a replacement for the pipeline.

The Takeaway

Stop shopping for the perfect tool. You already have decent tools. What you're missing is the layer that makes them act like one system.

Pick your five categories, wire them together with an orchestration layer you control, and build for idempotency and observability from day one. Do that and your operations scale with headcount you don't have to hire.

That's the whole 2025 playbook: fewer manual handoffs, more code doing the boring work reliably.

Originally published at getmichaelai.com

Custom AI Agents vs. Off-the-Shelf SaaS: What Actually Breaks at Enterprise Scale

Michael — Tue, 18 Aug 2026 12:01:18 +0000

Every enterprise team eventually hits the same fork in the road: buy an off-the-shelf AI SaaS tool, or build custom agents tuned to your stack. Both work. Both fail. The trick is knowing where each one falls apart before you sign a contract or spin up a repo.

This is the honest version - not the sales-deck version.

The core trade-off

Off-the-shelf SaaS gives you speed and a support line. Custom agents give you control and cost predictability at scale. That's the whole story compressed into one sentence.

The nuance is in the tail: what happens on month 18, at 500 seats, when your data model doesn't match the vendor's assumptions, or when your compliance team asks where the tokens are being processed.

Feature comparison at a glance

Dimension	Off-the-shelf SaaS	Custom AI agents
Time to first value	Days	Weeks
Cost curve	Grows per-seat	Flat after build
Data control	Vendor-hosted	Your infra
Integration depth	Prebuilt connectors	Anything with an API
Model flexibility	Locked to vendor choice	Swap models freely
Maintenance	Vendor handles it	You own it
Edge-case handling	Generic	Domain-specific

Notice there's no clean winner. The right answer depends on which row hurts you most.

Where SaaS wins

SaaS wins when your use case is common and your volume is moderate. Support tickets, meeting summaries, basic lead enrichment - these are solved problems. A vendor has already built the connectors, the retry logic, and the UI.

Buying makes sense when:

The workflow is standard across your industry
You have fewer than a few hundred users
You don't need the AI to touch proprietary internal logic
You'd rather pay a subscription than staff a maintenance team

Don't build a Slack summarizer. Buy it.

Where custom agents win

Custom wins the moment your process is your moat. If your competitive edge lives in how your team qualifies deals or routes support, a generic tool flattens that edge into the industry average.

Custom also wins on unit economics. Per-seat pricing looks cheap at 20 users and brutal at 2,000. Once you own the orchestration, adding users is nearly free.

Here's a stripped-down example of what "owning the logic" looks like - an agent that routes an inbound lead through your rules, not a vendor's:

from openai import OpenAI

client = OpenAI()

def route_lead(lead: dict) -> dict:
    # Your qualification logic - the part SaaS can't replicate
    priority = "low"
    if lead["company_size"] > 500 and lead["budget"] > 50000:
        priority = "high"

    prompt = f"""You are our SDR assistant. Given this lead, draft a
    first-touch email in our brand voice and suggest the next action.
    Lead: {lead}
    Priority: {priority}"""

    resp = client.chat.completions.create(
        model="gpt-4o-mini",  # swap freely - no vendor lock
        messages=[{"role": "user", "content": prompt}],
    )

    return {
        "priority": priority,
        "draft": resp.choices[0].message.content,
        "route_to": "enterprise-team" if priority == "high" else "pool",
    }

That 20 lines encodes a business rule no SaaS dropdown will ever match. And because the model is a variable, you can migrate from GPT to Claude to a local Llama model when pricing or latency changes.

The hidden costs nobody puts on the slide

SaaS: the integration tax

Vendors advertise "native integrations." Read that as "the 12 integrations they prioritized." Your homegrown CRM fork or your weird legacy ERP is not on the list. You'll end up writing glue code anyway - just with less control over it.

Custom: the maintenance tax

Agents drift. Models get deprecated. Prompts that worked in March break in September when the underlying model updates. If you build, you're signing up to monitor, evaluate, and patch continuously.

A realistic custom build needs guardrails from day one:

def safe_route(lead: dict) -> dict:
    try:
        result = route_lead(lead)
        if not result.get("draft"):
            raise ValueError("empty draft")
        return result
    except Exception as e:
        # Fail to human, never to silence
        notify_ops(f"Agent failure for {lead['id']}: {e}")
        return {"priority": "manual_review", "route_to": "human"}

The teams that regret building are the ones who treated the agent as a one-time project instead of a living system.

A decision framework

Skip the vibes. Score it:

Is the workflow generic? Yes leans buy.
Does it touch your competitive advantage? Yes leans build.
What's your 24-month seat count? High leans build.
Do you have engineering to maintain it? No leans buy.
How sensitive is the data? Regulated leans build (or self-hosted).

Most enterprises land on a hybrid: buy the commodity tools, build custom agents for the two or three workflows that actually move revenue.

The honest conclusion

There's no universal winner because "AI tooling" isn't one decision - it's a portfolio of them. Buy where the market has already solved the problem. Build where your business logic is the product.

The expensive mistake is doing it backwards: building a commodity chatbot from scratch, or forcing a rigid SaaS tool to model a process that's supposed to be your edge.

Audit your workflows, split them by that one question - is this generic or is this our moat? - and the build-vs-buy line draws itself.

Originally published at getmichaelai.com

Stop Guessing: Build a Marketing ROI Model Your CFO Can't Argue With

Michael — Mon, 17 Aug 2026 12:01:18 +0000

Most marketing budget defenses die on the same hill: vibes.

"Brand awareness is up." "Engagement looks strong." "The pipeline feels healthy."

None of that survives contact with a CFO who wants to know what happens to revenue if they cut your budget by 20%. If you can't answer that with a number, you don't have an argument. You have a wish.

This is a data problem, not a persuasion problem. So let's treat it like one.

The core model executives actually respond to

Forget the 40-metric dashboard. The C-suite cares about a chain that ends in cash:

Spend → Leads → Pipeline → Revenue → Margin

Every marketing dollar has to trace forward through that chain. If a metric doesn't connect to a downstream link, it's noise. Impressions matter only if they become leads. Leads matter only if they become pipeline.

The minimum viable ROI model is embarrassingly simple:

def marketing_roi(revenue_attributed, gross_margin, total_spend):
    gross_profit = revenue_attributed * gross_margin
    roi = (gross_profit - total_spend) / total_spend
    return round(roi * 100, 1)  # percentage

# Q3 example
print(marketing_roi(
    revenue_attributed=850_000,
    gross_margin=0.72,
    total_spend=180_000
))
# -> 240.0  (i.e. 240% ROI)

Note the gross_margin line. Marketers love to quote revenue. CFOs think in profit. A $1M deal on 20% margin is worth less than a $400K deal on 80%. Model margin, not top-line revenue, and you instantly sound like someone who belongs in the budget meeting.

Attribution is where the argument gets won or lost

The honest problem: which channel gets credit for that $850K?

Last-touch attribution is a lie that flatters your bottom-of-funnel channels. First-touch is a lie that flatters your top-of-funnel channels. For B2B with 6-month sales cycles and 8 stakeholders, you need something in between.

A workable middle ground is a weighted multi-touch model. You don't need a data science team - you need a consistent rule you can defend.

def attribute_revenue(touchpoints, deal_value):
    """W-shaped: 30% first, 30% lead-created, 30% closing, 10% split rest."""
    weights = {}
    n = len(touchpoints)
    if n == 1:
        return {touchpoints[0]: deal_value}

    weights[touchpoints[0]] = 0.30
    weights[touchpoints[-1]] = 0.30
    mid_idx = n // 2
    weights[touchpoints[mid_idx]] = 0.30

    remaining = [t for i, t in enumerate(touchpoints)
                 if i not in (0, n - 1, mid_idx)]
    for t in remaining:
        weights[t] = weights.get(t, 0) + 0.10 / max(len(remaining), 1)

    return {ch: round(deal_value * w, 2) for ch, w in weights.items()}

print(attribute_revenue(
    ['linkedin_ads', 'webinar', 'email_nurture', 'sales_demo'],
    120_000
))

Is W-shaped perfect? No. But it's transparent, repeatable, and it stops the endless "but paid search should get all the credit" turf war. Pick a model, document it, apply it uniformly. Consistency beats theoretical perfection.

The metrics that map to the boardroom

Translate your marketing metrics into the executive dialect:

CAC (Customer Acquisition Cost) - total spend / new customers
LTV:CAC ratio - anything below 3:1 gets you cut, above 5:1 means you're underspending
Payback period - months to recover CAC; under 12 is healthy for most B2B SaaS
Pipeline coverage - marketing-sourced pipeline vs. revenue target

That last one is your budget insurance. If you can show marketing sources 40% of qualified pipeline and the company needs 3x pipeline coverage to hit target, cutting your budget has a direct, quantifiable cost. That's the sentence that saves budgets: "A 20% cut removes roughly $2.1M in sourced pipeline next quarter."

Automate the proof or it won't get made

Here's the trap: teams build a beautiful ROI model once, present it, then never update it because pulling the data takes three days of copy-paste every month.

The fix is a pipeline that reconciles spend and revenue automatically. Pull ad spend from platform APIs, deal data from your CRM, and stitch them on a shared campaign or UTM key.

async function buildRoiReport({ crmDeals, adSpend }) {
  const spendByCampaign = adSpend.reduce((acc, row) => {
    acc[row.campaign] = (acc[row.campaign] || 0) + row.cost;
    return acc;
  }, {});

  return crmDeals.reduce((report, deal) => {
    const c = deal.sourceCampaign;
    report[c] ??= { revenue: 0, spend: spendByCampaign[c] || 0 };
    report[c].revenue += deal.value * deal.grossMargin;
    report[c].roi =
      ((report[c].revenue - report[c].spend) / report[c].spend) * 100;
    return report;
  }, {});
}

Wire this into a scheduled job - n8n, a cron task, a Lambda - and drop the output into the same dashboard the CFO already reads. When the ROI number is always current and always sourced from the systems of record, budget conversations stop being debates about credibility.

The one-line takeaway

You don't justify a marketing budget by defending it. You justify it by making the cost of cutting it visible, specific, and updated automatically.

Build the chain from spend to margin. Pick an attribution model and stick to it. Automate the reconciliation. Then walk into the room with a number instead of an adjective.

At Michael AI we build exactly these reporting pipelines - connecting ad platforms, CRMs, and finance data so marketing ROI reports itself. The teams that win budget aren't the loudest. They're the ones whose numbers show up on their own.

Originally published at getmichaelai.com

Predictive Lead Scoring in an Afternoon: A No-PhD Guide for B2B Teams

Michael — Sun, 16 Aug 2026 12:01:07 +0000

Most B2B teams score leads with a spreadsheet and a gut feeling. "Opened three emails? +10 points. Job title says VP? +20 points." It's arbitrary, and worse, it's static. Nobody knows if those numbers actually predict who buys.

The good news: you don't need a data scientist to do better. You need a CSV of past leads, a laptop, and about two hours. Let's build a predictive lead scoring model from data you already have.

The core idea

Manual scoring assigns points based on what you think matters. Predictive scoring learns from what actually mattered. You feed it historical leads with a known outcome (closed-won vs. lost/no-deal), and a model figures out which signals correlate with revenue.

That's it. No neural networks, no GPU. A logistic regression model handles this beautifully and gives you interpretable weights your sales team can trust.

Step 1: Pull the data you already have

Export closed leads from your CRM for the last 12-18 months. You want features known at the time the lead entered the funnel, plus the final outcome.

Useful columns:

Company size (employee count)
Industry
Lead source (paid, organic, referral, event)
Job title / seniority
Number of pages visited before signup
Email domain type (business vs. free)
Whether they requested a demo

The target column is binary: won = 1, everything else = 0.

Don't overthink feature selection. Grab everything reasonable and let the model tell you what's noise.

Step 2: Clean and encode

Models want numbers, not text. Here's the whole pipeline in plain Python.

import pandas as pd
from sklearn.model_selection import train_test_split
from sklearn.linear_model import LogisticRegression
from sklearn.preprocessing import StandardScaler
from sklearn.compose import ColumnTransformer
from sklearn.pipeline import Pipeline
from sklearn.preprocessing import OneHotEncoder
from sklearn.metrics import roc_auc_score, classification_report

df = pd.read_csv("leads.csv")

# Target
y = df["won"]
X = df.drop(columns=["won", "lead_id"])

numeric = ["employee_count", "pages_visited"]
categorical = ["industry", "lead_source", "seniority", "domain_type"]

preprocess = ColumnTransformer([
    ("num", StandardScaler(), numeric),
    ("cat", OneHotEncoder(handle_unknown="ignore"), categorical),
])

model = Pipeline([
    ("prep", preprocess),
    ("clf", LogisticRegression(max_iter=1000, class_weight="balanced")),
])

Two details that matter more than people admit:

class_weight="balanced" handles the fact that most leads don't close. Without it, the model just predicts "loss" every time and looks 90% accurate while being useless.
handle_unknown="ignore" stops your model from crashing when a new industry shows up in production.

Step 3: Train and check it's real

X_train, X_test, y_train, y_test = train_test_split(
    X, y, test_size=0.25, random_state=42, stratify=y
)

model.fit(X_train, y_train)

probs = model.predict_proba(X_test)[:, 1]
print("AUC:", round(roc_auc_score(y_test, probs), 3))
print(classification_report(y_test, model.predict(X_test)))

Watch the AUC score. It measures how well the model ranks buyers above non-buyers.

0.5 = random, throw it away.
0.65-0.75 = useful, better than your gut.
0.8+ = strong. Sales will notice.

If you're below 0.6, your features probably don't capture buying intent. Add behavioral data (product signups, email engagement, demo requests) before touching the model.

Step 4: Turn probabilities into scores people use

A raw probability like 0.73 means nothing to a rep. Convert it to a 0-100 score and tier it.

def score_lead(lead_dict):
    row = pd.DataFrame([lead_dict])
    prob = model.predict_proba(row)[:, 1][0]
    score = int(round(prob * 100))
    if score >= 70:
        tier = "A - call now"
    elif score >= 40:
        tier = "B - nurture"
    else:
        tier = "C - low priority"
    return {"score": score, "tier": tier}

print(score_lead({
    "employee_count": 250,
    "pages_visited": 9,
    "industry": "SaaS",
    "lead_source": "referral",
    "seniority": "VP",
    "domain_type": "business",
}))

Now every lead gets a number and a clear action. That's the whole point of sales funnel optimization: stop reps guessing where to spend their hours.

Step 5: Ship it into your workflow

A model in a notebook is a hobby. A model wired into your funnel is leverage.

Wrap score_lead in a small API endpoint, then trigger it from your marketing automation. In n8n or a similar tool, the flow is simple:

New lead hits your CRM (webhook trigger).
Send the lead's fields to your scoring endpoint.
Write the score and tier back to the CRM record.
Route A-tier leads straight to a rep and B-tier into a nurture sequence.

No human touches a lead before it's prioritized.

What breaks, and how to keep it honest

Models drift. Your market shifts, campaigns change, and last year's patterns fade. Retrain quarterly on fresh closed-won data. Log every prediction and its eventual outcome so you can measure whether the model still earns its keep.

Also resist the urge to jump to fancier algorithms. Logistic regression stays interpretable: you can pull the coefficients and tell your VP of Sales why referrals from mid-market SaaS companies score high. That trust is worth more than a fractional AUC bump from a black-box model nobody understands.

Start simple, ship it, and let the results argue for the next iteration.

Originally published at getmichaelai.com

What 10,000 Cold Emails Taught Me About Reply Rates (With the Data)

Michael — Sat, 15 Aug 2026 12:01:12 +0000

Cold email advice is mostly folklore. Someone got a big client from a short email, so now every short email is genius. Someone used a first-line personalization hack, so now everyone opens with "Loved your post on LinkedIn."

We wanted numbers, not vibes. So we pulled 10,000 B2B cold emails sent across a dozen outbound campaigns, normalized the data, and looked at what actually correlated with replies. Here's what held up under scrutiny.

The baseline numbers

Across the full dataset, the average reply rate was 4.2%. Positive replies (interested, not "unsubscribe me") sat at 1.8%.

That's the honest floor. If someone promises you 30% reply rates, ask what they're counting.

The interesting part isn't the average. It's the spread. The top decile of emails hit 11%+ reply rates, and they shared measurable traits.

Subject lines: shorter and boring wins

We bucketed subject lines by word count and analyzed reply rates.

Subject length	Reply rate
1–3 words	5.9%
4–6 words	4.4%
7+ words	2.7%

Short subjects won. But the bigger signal was tone. Subject lines that looked like internal notes between colleagues (quick question, intro, {{company}} + us) outperformed anything that smelled like marketing (Boost your revenue 40%) by roughly 2x.

Emojis in subject lines dropped reply rates by 31%. Personalizing the subject with a company name added about 22%.

Length: the sweet spot is 50–125 words

We tokenized every email body and plotted reply rate against word count.

import pandas as pd

df = pd.read_csv("emails.csv")
df["word_count"] = df["body"].str.split().str.len()

buckets = pd.cut(df["word_count"],
                 bins=[0, 50, 75, 125, 200, 1000],
                 labels=["<50", "50-75", "75-125", "125-200", "200+"])

print(df.groupby(buckets)["replied"].mean().mul(100).round(1))

Output:

<50        3.1
50-75      6.8
75-125     6.2
125-200    3.9
200+       1.4

Under 50 words felt lazy and low-effort. Over 200 words read like a pitch deck. The 50–125 band gave enough context to earn a reply without demanding a reading commitment.

Personalization that actually moved the needle

Not all personalization is equal. We tagged emails by personalization type and measured lift over the non-personalized baseline.

Generic token merge (Hi {{first_name}}): +0% — table stakes, no lift
Company-specific observation ("saw you're hiring 3 SDRs"): +41%
Trigger-based (funding, new role, product launch): +58%
"Loved your post" opener: -9%

That last one surprised people. The compliment opener is so overused it now reads as automated. Buyers pattern-match it to spam.

The winners referenced something the recipient couldn't have received in a mass blast. That's the real test: could this exact sentence have been sent to 500 people? If yes, it's not personalization.

Timing matters less than you think

Everyone obsesses over send time. The data was underwhelming.

Tuesday through Thursday, 8–10am recipient local time, gave a modest edge — about a 12% relative bump over the worst windows. Real, but tiny compared to a 58% lift from a good trigger.

Stop A/B testing 9:03am vs 9:07am. Spend that energy on the message.

The follow-up is where replies actually live

Here's the number that changes behavior: 48% of all replies came from follow-up emails, not the first touch.

Reply rate by touch:

Email 1: 4.2%
Email 2: 3.1%
Email 3: 1.9%
Email 4+: 0.8%

Emails two and three carried nearly half the total pipeline. Most people send one email and quit. That's leaving the majority of replies on the table.

Best-performing follow-ups were short, added a new angle, and never guilt-tripped ("just bumping this to the top of your inbox" underperformed a fresh value line by 27%).

Turning this into a system

The pattern is straightforward to encode. Here's a rough scoring function we use to flag weak emails before they send.

function scoreEmail({ subject, body, personalization }) {
  let score = 0;
  const words = body.trim().split(/\s+/).length;
  const subjWords = subject.trim().split(/\s+/).length;

  if (subjWords <= 3) score += 2;
  if (/[\u{1F300}-\u{1FAFF}]/u.test(subject)) score -= 2; // emoji penalty
  if (words >= 50 && words <= 125) score += 3;
  if (words > 200) score -= 3;
  if (personalization === "trigger") score += 3;
  if (personalization === "company") score += 2;
  if (/loved your post/i.test(body)) score -= 1;

  return score; // ship anything >= 4
}

Wire that into your sending pipeline and you catch the obvious mistakes automatically. Better yet, connect it to your CRM triggers so the personalization line is generated from real signals — funding rounds, job changes, tech stack shifts — instead of a copy-paste template.

The takeaway

The best cold emails don't look clever. They look like a short, specific note from someone who did five minutes of homework and had a reason to write today. Boring subject line, 80 words, one real observation, and a follow-up sequence that doesn't give up after touch one.

Most of this is automatable. The observation-gathering, the trigger detection, the follow-up cadence — all of it. That's the difference between sending 100 mediocre emails and 100 that read like they were written one at a time.

Originally published at getmichaelai.com

The 7 Questions That Separate a Good SaaS Vendor From a Two-Year Regret

Michael — Fri, 14 Aug 2026 12:01:11 +0000

The demo always works. That's the point of a demo.

The sales engineer has a pristine sandbox, curated data, and a script that avoids every rough edge in the product. What you don't see is the rate-limited API, the export button that only spits out CSV, or the support queue that takes four days to answer a P1.

By the time you discover those, you've migrated your data, trained your team, and wired the tool into three other systems. Switching costs are a moat that works against you.

Here are the seven questions we ask on behalf of clients before signing anything. They cut through the polish fast.

1. What does your API actually let me do?

"We have an API" is meaningless. The real questions: Is every feature in the UI available via the API, or just a subset? What are the rate limits? Is there a webhook system, or do I have to poll?

Ask for the docs before you buy. Public, versioned API docs signal a company that treats integration as a first-class concern. A PDF sent by a sales rep signals the opposite.

A quick smoke test says a lot:

import requests

resp = requests.get(
    "https://api.vendor.com/v1/records",
    headers={"Authorization": f"Bearer {token}"},
    params={"limit": 100, "updated_since": "2024-01-01"},
)

print(resp.status_code)
print(resp.headers.get("X-RateLimit-Remaining"))
print(len(resp.json().get("data", [])))

If you can't get a trial token to run something like this, that's your answer.

2. Who owns the data, and how do I get it out?

Every vendor promises you own your data. Fewer make it easy to leave with it.

Ask specifically:

Can I export all my data, including relationships and metadata, not just flat tables?
Is export self-service, or do I have to file a support ticket?
What format? JSON with full fidelity, or a lossy CSV dump?

If the export path is painful, you're not a customer. You're a hostage.

3. How does this fit my existing technology stack?

No tool lives alone. It needs to talk to your CRM, your data warehouse, your auth provider, and probably an automation layer like n8n or Zapier.

Map the integration surface before you commit:

Native integrations (maintained by the vendor)
iPaaS connectors (Zapier, Make, n8n)
Raw API + webhooks (you build it)

Native sounds best but ages badly if the vendor stops maintaining it. A clean API often beats a fragile native integration you can't debug. We usually prefer webhook-driven flows because they fail loudly instead of silently drifting.

4. What happens when something breaks at 2am?

Support tiers are where marketing meets reality. Get the SLA in writing:

Response time for P1 vs P3
Is 24/7 support real, or business hours in one timezone?
Do I get a named contact, or a shared inbox?
Is there a public status page with incident history?

Read the status page history. A vendor that publishes honest post-mortems is one you can trust in a crisis. A suspiciously green status page usually means they hide incidents.

5. How do you handle security and compliance?

Skip the logo wall of certifications and ask for artifacts:

SOC 2 Type II report (not just "SOC 2 compliant")
Data residency options
SSO/SAML on your plan, or paywalled as an "enterprise" upsell
Sub-processor list

The SSO tax is a red flag. If basic security controls are locked behind a 3x price jump, the vendor is optimizing revenue over your risk posture.

6. What does the true cost look like at scale?

The sticker price is the beginning of the conversation. The bill you actually pay depends on:

Per-seat vs usage-based pricing, and how usage is metered
Overage charges when you exceed limits
Feature gating that forces a tier upgrade you didn't plan
API call costs if the API is metered separately

Model it out for your projected volume in 18 months, not today. Tools that are cheap at 5 users can become brutal at 50.

const monthlyCost = (seats, usage) => {
  const base = seats * 29;
  const includedCalls = seats * 10000;
  const overage = Math.max(0, usage - includedCalls) * 0.001;
  return base + overage;
};

console.log(monthlyCost(50, 2_000_000)); // budget shock check

Run the numbers before the CFO does.

7. Is this company going to exist in three years?

You're not just buying software. You're betting on a company's roadmap.

Look for signals: funding stage, customer count, release velocity on the changelog, and whether the founders are still involved. A tool acquired by private equity often gets squeezed for margin, which means price hikes and stalled development.

Ask directly about the roadmap for the features you care about. Vague answers mean it's not happening.

Turn this into a scorecard

Don't hold these questions in your head. Build a simple weighted scorecard, rate each vendor 1-5 per question, and let the numbers argue.

The goal isn't to find a perfect vendor. It's to buy with your eyes open, knowing exactly which tradeoffs you're accepting.

The demo shows you what the product can do on its best day. These seven questions show you what it'll be like on a normal Tuesday, eighteen months in, when it's load-bearing in your stack. That's the version you're actually buying.

Originally published at getmichaelai.com

How We Rebuilt a B2B Lead Pipeline with AI Agents and Grew MQLs 75% in 90 Days

Michael — Thu, 13 Aug 2026 12:01:12 +0000

Most B2B lead gen problems aren't traffic problems. They're routing, scoring, and follow-up problems.

A mid-market SaaS client came to us with a familiar situation: decent inbound volume, a bloated CRM, and a sales team that ignored half the leads marketing sent over. Their MQL definition was a static form fill plus a job title guess. Predictably, sales called them "junk."

Here's the exact system we built to grow qualified leads 75% in one quarter. No magic. Just tighter data plumbing and a few AI agents doing the boring work.

The diagnosis: leads weren't bad, scoring was

We pulled 6 months of closed-won and closed-lost data and ran a simple correlation. The variables the client used to score leads (title, company size, form completeness) barely predicted revenue. The variables that did predict it weren't being captured at all:

Number of pricing/docs page visits before demo request
Tech stack signals (detected from email domain + enrichment)
Whether the lead replied to the first outreach within 48 hours
Buying-committee size mentioned in intake

So step one wasn't AI. It was fixing what "qualified" meant.

Step 1: A behavioral scoring model that actually correlates

We replaced the point-based form scoring with a weighted model trained on their historical conversions. Nothing exotic - a logistic regression to start, because it's explainable and sales trusts things they can read.

import pandas as pd
from sklearn.linear_model import LogisticRegression
from sklearn.model_selection import train_test_split

df = pd.read_csv("leads_6mo.csv")
features = [
    "pricing_visits", "docs_visits", "reply_within_48h",
    "stack_match_score", "committee_size", "employee_count"
]
X = df[features]
y = df["became_opportunity"]

X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.25)
model = LogisticRegression(max_iter=1000).fit(X_train, y_train)

# Ship the coefficients so RevOps can sanity-check them
for f, w in zip(features, model.coef_[0]):
    print(f"{f}: {round(w, 3)}")

The output surprised everyone: pricing_visits and reply_within_48h carried more weight than company size. The old model was optimizing for the wrong thing.

Step 2: Enrichment and dedup before scoring

Garbage in, garbage score. Before anything hit the model, we ran every new lead through an enrichment and dedup pass in n8n. A single webhook received the form submission, then fanned out to enrichment APIs and a fuzzy-match against existing CRM records.

// n8n Function node: normalize + flag duplicates
const email = $json.email.toLowerCase().trim();
const domain = email.split("@")[1];

const freeProviders = ["gmail.com", "yahoo.com", "outlook.com"];
const isBusiness = !freeProviders.includes(domain);

return [{
  json: {
    email,
    domain,
    is_business: isBusiness,
    needs_enrichment: isBusiness,
    dedupe_key: `${domain}-${$json.company?.toLowerCase() || domain}`
  }
}];

This alone killed roughly 20% of records that were duplicates or personal emails sneaking through. Sales stopped seeing the same lead twice under three spellings.

Step 3: An AI intake agent to fill the gaps

Forms are where qualification goes to die. Ask too much and conversion tanks. Ask too little and you can't score.

So we kept the form short (email + one problem field) and added an AI agent that ran a two-message async conversation over email. It asked one qualifying question, parsed the free-text reply, and mapped it back to structured CRM fields like committee_size and timeline.

The key was constraining the agent's output to a schema, not letting it freestyle:

schema = {
    "pain_point": "string",
    "timeline": "now | 3_months | exploring",
    "committee_size": "int",
    "budget_signal": "bool"
}
# The agent must return valid JSON matching schema or the record
# stays flagged for a human. No hallucinated fields reach the CRM.

Anything the agent couldn't confidently classify got routed to a human. We didn't automate judgment - we automated data capture.

Step 4: Real-time routing so hot leads don't cool

A lead scoring 80+ that waits 6 hours for a rep is a wasted lead. We wired scored leads straight into Slack with a claim button and an SLA timer. If nobody claimed a hot lead in 15 minutes, it escalated to the manager.

The behavioral piece mattered most here: reply_within_48h was a top predictor, so speed on our side compounded it.

The results after 90 days

MQLs up 75% - mostly from reclassifying leads the old model wrongly buried
MQL-to-opportunity rate up 31% because the definition finally correlated with revenue
Sales response time down from ~5 hours to under 20 minutes on hot leads
Marketing stopped arguing with sales about lead quality, because the score was explainable

What actually drove the number

The AI wasn't the headline. The headline was defining "qualified" against real outcomes, then removing every point of friction and delay between a good lead and a human.

AI agents did three jobs well: enrichment, structured intake, and routing. Boring, repetitive, high-volume work where consistency beats cleverness.

If your MQL number looks fine but sales won't touch the leads, start where we did. Pull your closed-won data and ask one question: does your current score predict revenue? If it doesn't, no amount of extra traffic will fix it.

Originally published at getmichaelai.com

Zapier vs. Make vs. Done-For-You: An Honest Look at What Automation Actually Costs You

Michael — Wed, 12 Aug 2026 12:01:09 +0000

Every automation vendor tells you their tool is the last one you'll ever need. None of them mention the six weekends you'll spend debugging a workflow that silently dropped 400 records.

This is the comparison I wish someone had given me before I built my first client's order-sync pipeline. No affiliate links, no "it depends" cop-outs. Just where each option wins and where it quietly bleeds you.

The three real options

Most teams frame this as Zapier vs. Make. That's the wrong axis. The real decision is how much of the maintenance burden you want to own. So the honest lineup is:

Zapier — fastest to a working flow, most expensive at scale.
Make — cheaper per operation, steeper learning curve, more power.
Done-for-you (custom n8n / code) — highest setup cost, lowest long-term cost, you don't own the debugging.

Zapier: speed you pay for

Zapier's strength is time-to-first-automation. A non-technical ops person can wire Gmail → Slack → Airtable in 15 minutes.

The catch is the pricing model: you pay per task. Every step in every run counts. A 5-step Zap firing 2,000 times a month is 10,000 tasks. That escalates fast.

Where Zapier wins: low-volume, high-value workflows. Lead routing. Deal-won notifications. Anything that runs hundreds of times a month, not hundreds of thousands.

Where it hurts: data-heavy syncs, loops, and branching logic. Zapier's "Paths" get ugly quickly, and error handling is thin.

Make: more control, more rope

Make (formerly Integromat) charges per operation and gives you a visual canvas that maps closer to how developers actually think — routers, iterators, aggregators, error handlers.

You can do things in Make that would take a Zapier Code step and a prayer:

// A Make custom function to normalize inconsistent phone formats
// before pushing to your CRM
function normalizePhone(raw) {
  const digits = String(raw).replace(/\D/g, '');
  if (digits.length === 10) return `+1${digits}`;
  if (digits.length === 11 && digits.startsWith('1')) return `+${digits}`;
  return null; // flag for manual review
}

Make wins on price-per-operation and on complex logic. Its bundling and array handling make batch jobs genuinely cheap.

The cost is cognitive. Make's canvas gets overwhelming past ~15 modules, and the difference between a "module" and an "operation" trips up almost everyone on their first invoice.

Done-for-you: pay once, stop babysitting

The third option isn't a SaaS logo. It's building the workflow in something you control — self-hosted n8n, a serverless function, or a small service — and having someone else own the setup and hardening.

Here's the honest math. A no-code tool feels cheap at $50/month. But at volume, both Zapier and Make cross into $500–$2,000/month territory, and you still own every broken run at 2am.

A custom n8n workflow on a $20 VPS runs unlimited executions:

// n8n Function node: idempotent upsert so retries don't create duplicates
const existing = await this.helpers.httpRequest({
  method: 'GET',
  url: `https://api.crm.com/contacts?email=${$json.email}`,
  headers: { Authorization: `Bearer ${$env.CRM_TOKEN}` },
});

return [{
  json: {
    action: existing.data.length ? 'update' : 'create',
    id: existing.data[0]?.id ?? null,
    payload: $json,
  },
}];

Done-for-you wins on total cost of ownership at scale and on reliability. It loses on speed — there's real build time up front — and it's overkill if you're automating three low-volume tasks.

The comparison that actually matters

Factor	Zapier	Make	Done-for-you (n8n)
Time to first flow	Minutes	Hours	Days
Cost at low volume	Low	Lowest	High (setup)
Cost at high volume	Very high	Medium	Lowest
Complex logic	Weak	Strong	Unlimited
Error handling	Basic	Good	Whatever you build
Who fixes it at 2am	You	You	Us

When each one actually wins

Pick Zapier if you're validating a process, run it under a few hundred times a month, and value speed over cost. It's the right tool for "does this workflow even help?"

Pick Make if you have someone comfortable with logic, need branching and batch operations, and want to keep per-run costs down without hiring a developer.

Go done-for-you when the workflow is business-critical, high-volume, or complex enough that a broken run costs real money — and you'd rather your team ship product than debug integrations.

The uncomfortable truth

The tool is rarely the bottleneck. The bottleneck is who maintains the thing after the demo works. No-code platforms shift that cost onto you invisibly; you just don't see it until an API changes and everything breaks quietly.

We build done-for-you automation systems on n8n precisely because we got tired of watching teams pay SaaS premiums and eat the maintenance. If you're already past the "is this useful?" stage and into "this can't break," that's the conversation worth having.

Start with the cheapest tool that proves the workflow matters. Graduate to owned infrastructure the moment it becomes something you can't afford to lose.

Originally published at getmichaelai.com

AI in B2B Support: Where It Actually Works (And Where It Quietly Breaks)

Michael — Tue, 11 Aug 2026 12:01:09 +0000

Every vendor pitch right now says the same thing: bolt an LLM onto your help desk and watch your ticket volume evaporate. The reality on the ground is messier.

B2B support is not B2C support. Your customers aren't asking to reset a password on a $12 subscription. They're integration engineers debugging a webhook, ops leads chasing an SLA breach, or a CTO whose production instance is down. The cost of a wrong answer is high, and the questions are rarely generic.

So let's cut through it. AI genuinely changes the game for B2B support - but only in specific places, and only if you deploy it with some engineering discipline.

Where AI actually earns its keep

Triage and routing

This is the highest-ROI, lowest-risk use case, and almost nobody talks about it because it's not flashy. Most support teams lose hours just figuring out who should handle a ticket. An LLM classifier does this well because it's a bounded problem with clear labels.

from openai import OpenAI

client = OpenAI()

def triage_ticket(subject: str, body: str) -> dict:
    prompt = f"""Classify this support ticket. Return JSON only.

Subject: {subject}
Body: {body}

Fields:
- category: one of [billing, integration, outage, feature_request, how_to]
- severity: one of [low, medium, high, critical]
- team: one of [tier1, tier2, engineering, csm]
- summary: one sentence
"""
    resp = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": prompt}],
        response_format={"type": "json_object"},
        temperature=0,
    )
    return resp.choices[0].message.content

Wire this into your ticketing webhook and you shave real minutes off every ticket. It doesn't touch the customer, so a misclassification just means a re-route, not a broken promise.

Draft responses, not sent responses

The pattern that works: AI writes the first draft, a human reviews and sends. Agents move faster, tone stays consistent, and you keep a human in the loop for the answers that matter.

The pattern that fails: full auto-reply on technical tickets. One confidently wrong answer about your API rate limits and you've created a support ticket about the support bot.

Knowledge retrieval over your own docs

This is where retrieval-augmented generation (RAG) beats a raw model every time. Ground the model in your documentation, changelogs, and past resolved tickets. Without grounding, the model invents endpoints that don't exist.

async function answerFromDocs(question) {
  const embedding = await embed(question);
  const chunks = await vectorDB.query({
    vector: embedding,
    topK: 5,
    filter: { source: ["docs", "resolved_tickets"] },
  });

  const context = chunks.map((c) => c.text).join("\n---\n");

  return llm.complete({
    system: "Answer ONLY from the context. If the answer isn't there, say you'll escalate to a human.",
    prompt: `Context:\n${context}\n\nQuestion: ${question}`,
  });
}

That system prompt line - "say you'll escalate" - is the difference between a useful assistant and a liability. Make the model comfortable admitting it doesn't know.

Where it quietly breaks

Multi-step technical debugging. When a customer is three replies deep into an OAuth failure, the model loses the thread. Context windows fill with noise, and the AI starts contradicting its earlier advice. These belong with an engineer.

Anything account-specific without data access. "Why was I charged twice?" is unanswerable without pulling the customer's actual billing records. If your AI isn't connected to live systems through proper tool calls, it will hallucinate a plausible-sounding lie.

Emotional escalations. An enterprise customer threatening to churn does not want to talk to a bot, no matter how polite. Route these to a human instantly.

Long-tail edge cases. B2B products accumulate weird, undocumented behaviors. The model has no data on your one client running a decade-old integration.

How to deploy it without the faceplant

Start narrow. Pick one workflow - triage is our recommendation - and instrument it before you expand.

Set a confidence threshold and a hard escalation path. If the model isn't sure, it hands off. Silence beats a wrong answer in B2B.

Measure the right things. Deflection rate is a vanity metric if those "deflected" customers just open angrier tickets later. Track resolution rate, reopen rate, and CSAT on AI-touched tickets specifically.

Keep humans in the loop for anything customer-facing until your data says otherwise. Then loosen gradually.

The honest verdict

AI is a genuine force multiplier for B2B support - as an internal accelerant. It makes your existing agents faster, routes work intelligently, and surfaces the right knowledge at the right moment.

What it isn't, yet, is a replacement for the human judgment your enterprise customers are paying for. The teams winning with AI in support aren't the ones who fired half their staff. They're the ones who gave every agent a well-grounded copilot and kept the humans on the calls that matter.

Deploy it like an engineer, not a marketer. That's the whole game.

Originally published at getmichaelai.com

The SaaS Evaluation Checklist I Wish I'd Had Before Signing 3 Bad Contracts

Michael — Mon, 10 Aug 2026 12:01:12 +0000

Every CIO has a graveyard of SaaS tools nobody uses. You bought them because a demo looked slick, a VP wanted the feature, or the sales rep created urgency with an end-of-quarter discount. Six months later you're paying for seats that sit idle and an integration that never shipped.

Evaluating B2B software isn't about feature checklists from the vendor. It's about the questions the vendor hopes you won't ask. Here's the framework I use before anything reaches a signature.

Start With the Exit, Not the Onboarding

Before you evaluate what a platform does, figure out how you leave it. Vendor lock-in is the tax you pay for skipping this step.

Ask three things up front:

Can you export all your data in a structured format (not a locked PDF report)?
Is there a documented API, or just a UI?
What happens to your data 30, 60, 90 days after cancellation?

If the answer to data export is vague, treat it as a red flag. A confident vendor gives you a JSON or CSV dump and an API to pull it programmatically.

import requests

# A healthy vendor lets you verify data portability BEFORE you commit.
# Ask for trial API credentials and run this against their export endpoint.
resp = requests.get(
    "https://api.vendor.com/v1/records/export",
    headers={"Authorization": f"Bearer {TRIAL_TOKEN}"},
    params={"format": "json", "since": "2024-01-01"},
)

data = resp.json()
print(f"Exported {len(data['records'])} records")
print(f"Pagination cursor: {data.get('next_cursor', 'NONE - full dump')}")

# If this 404s or requires a 'talk to sales' call, you have your answer.

If the export path only exists behind a support ticket and a two-week SLA, assume getting your data out will be painful when it matters most.

Security: Read the Fine Print, Then Ask Harder

A SOC 2 badge on the pricing page means nothing on its own. Ask for the actual report under NDA and read the exceptions section. That's where the interesting stuff lives.

Your security minimums:

SOC 2 Type II or ISO 27001 with a report you can actually review
SSO/SAML available without a jump to the enterprise tier that costs 4x
Encryption at rest and in transit, with documented key management
Audit logs you can export to your SIEM
Sub-processor list so you know who else touches your data

The SSO one catches people constantly. Many vendors gate SAML behind an "Enterprise" plan as a pricing lever. If security features are upsells, security isn't a priority for them.

The subprocessor question

Where does your data physically live, and who has access? A vendor that pipes your customer records through five AI subprocessors you've never heard of is a compliance problem waiting to surface during your next audit.

Integration Reality Check

The demo always shows the happy path. Your job is to find where it breaks.

Don't ask "do you integrate with X?" Ask "show me the integration working with test data." There's a large gap between a logo on an integrations page and a stable, documented API.

Check these before you believe any integration claim:

Rate limits (and whether they'll kneecap your workflows)
Webhook support for real-time events vs. polling only
Sandbox environment for testing
Whether the API is versioned and how they handle deprecation

At MICHAEL AI we build automations on top of these platforms daily. The single biggest predictor of a smooth build is a well-documented, versioned API with webhooks. The single biggest predictor of a nightmare is "we have a Zapier integration" as the only answer.

Cost: Model the Two-Year Number

The sticker price is marketing. The real cost includes:

Per-seat creep as your team grows
Usage-based overages (API calls, storage, contacts, whatever meter they spin)
Implementation and migration fees
The premium tier you'll inevitably need for the one feature you actually want

Build a spreadsheet that projects total cost at your expected scale in 24 months, not today. Then ask about price protection. A vendor that won't cap annual increases is telling you they plan to raise them.

Vendor Risk: Will They Exist in Three Years?

You're not just buying software. You're betting your operations on a company continuing to run.

Quick due diligence:

How long have they been in business, and are they profitable or burning runway?
What's their customer count and churn signal (check G2 review recency)?
Is support human or a chatbot that loops forever?
What's the actual SLA, with financial penalties for breaches?

A scrappy startup can be a great bet if the upside justifies the risk. Just make sure your exit plan (see the top of this list) is airtight, because early-stage vendors get acquired or shut down.

The One-Page Scorecard

Run every platform through the same rubric so you're comparing on merit, not on which sales rep was most charming. Score each category 1-5:

Data portability and exit path
Security posture and compliance
Integration depth and API quality
Total 24-month cost
Vendor stability and support

Anything scoring below 3 on security or data portability is a hard no, regardless of features. Those two aren't negotiable, because they're the categories you can't fix after you sign.

The best procurement decisions are boring. You did the homework, ran the API against a sandbox, read the SOC 2 exceptions, and modeled the cost curve. No urgency, no fear of missing a quarter-end discount. Just a clear-eyed answer to one question: does this platform earn a place in the systems your business depends on?

Originally published at getmichaelai.com

I Asked 5 Automation Engineers What Breaks First in 2025 — Their Answers Surprised Me

Michael — Sun, 09 Aug 2026 12:01:10 +0000

Expert roundups usually read like a horoscope: vague, safe, and useless by Tuesday. So I skipped the LinkedIn thought-leaders and called five people who actually ship AI automation for a living — two n8n architects, an ops lead at a 200-person SaaS, an ML engineer, and a consultant who cleans up other people's agent messes.

Here's what they actually said about where B2B automation goes next. No predictions about "the year of the agent." Just the stuff they're already dealing with.

1. The bottleneck moves from models to plumbing

Every engineer I spoke to said the same thing in different words: the model is no longer the hard part.

GPT-4-class reasoning is good enough for 90% of business tasks. What breaks is everything around it — retries, idempotency, state, and knowing when a workflow silently failed.

"I spend maybe 10% of my time on prompts now. The other 90% is making sure the same webhook firing twice doesn't create two invoices." — n8n architect, fintech

The practical takeaway: treat your automations like distributed systems, not chatbots. That means idempotency keys everywhere.

// Guard against duplicate webhook processing
async function handleInvoiceWebhook(event) {
  const key = `invoice:${event.id}`;
  const alreadyProcessed = await redis.set(key, '1', {
    NX: true,       // only set if not exists
    EX: 86400,      // expire after 24h
  });

  if (!alreadyProcessed) {
    console.log(`Skipping duplicate: ${event.id}`);
    return { status: 'duplicate' };
  }

  return await createInvoice(event.payload);
}

2. Single agents are out; small deterministic chains are in

The consultant who fixes broken deployments was blunt: most "autonomous agent" projects he sees are over-engineered and under-monitored.

Why big agents fail in production

Give one agent a 12-step task with tool access and you get non-determinism, ballooning token costs, and debugging sessions that feel like archaeology. When step 8 fails, good luck reconstructing why.

The teams that ship reliably do the opposite. They break work into small, deterministic steps and only use the LLM where judgment is genuinely needed — classification, extraction, drafting.

# Prefer narrow, testable steps over one mega-agent
def route_support_ticket(ticket: dict) -> str:
    category = classify(ticket["body"])        # LLM: one job
    if category == "billing":
        return assign_to("finance", ticket)     # deterministic
    if category == "bug" and is_urgent(ticket): # rules, not LLM
        return escalate(ticket)
    return draft_reply(ticket)                   # LLM: one job

Each LLM call does one thing you can unit-test with a fixed set of examples. That's the difference between a demo and a system.

3. "Human in the loop" becomes a feature, not a fallback

Two of the five predicted that the winning B2B tools of the next two years won't be the most autonomous — they'll be the most reviewable.

Ops leaders don't trust a black box that emails 4,000 customers. They want a queue where a human approves the edge cases and the system handles the boring 95%. The ML engineer called it "confidence-gated autonomy."

The pattern: score every AI decision, auto-execute above a threshold, route the rest to a person.

result = agent.decide(task)

if result.confidence >= 0.9:
    execute(result.action)
elif result.confidence >= 0.6:
    queue_for_review(result)   # human approves in seconds
else:
    escalate_to_human(task)    # AI stays out of it

This one design choice is what makes non-technical stakeholders actually sign off on automation.

4. Vendor lock-in is the next big regret

The SaaS ops lead had the sharpest warning: teams are wiring their entire operation into one proprietary platform because the onboarding is slick.

Then pricing changes. Or the model gets deprecated. Or the vendor gets acquired.

Her rule now: keep your business logic in code or open tooling you control, and treat the model provider as a swappable dependency behind an interface.

# Abstract the provider so swapping is a config change
class LLMClient:
    def __init__(self, provider):
        self.provider = provider

    def complete(self, prompt):
        return self.provider.generate(prompt)

# Switching from OpenAI to Anthropic to a local model
# shouldn't touch a single line of business logic.

5. The moat is your data pipeline, not your prompt

Everyone can access the same models. What they can't copy is your clean, structured, permissioned company data feeding those models.

The engineers agreed: in 2025 the competitive edge shifts to whoever has the best retrieval layer — accurate, fresh, and scoped to the right user. Prompt engineering is table stakes. Data engineering is the differentiator.

What this means if you're building

Strip out the hype and the consensus is refreshingly boring:

Engineer for failure. Idempotency, retries, and observability first.
Compose small deterministic steps. Reserve the LLM for judgment.
Gate autonomy by confidence. Keep humans on the edge cases.
Abstract your model provider. Assume you'll switch.
Invest in your data layer. That's the actual moat.

The teams winning with AI automation aren't chasing the flashiest agent. They're treating it like software — testable, monitored, and boring in all the right places.

That's the future five people who ship it every day actually see. Not agents that replace your team, but plumbing reliable enough that your team stops babysitting it.

Originally published at getmichaelai.com