DEV Community: Michael

The $40K Chatbot Bill Nobody Saw Coming: A Token Cost Governance Playbook

Michael — Tue, 29 Sep 2026 12:01:17 +0000

You shipped a support chatbot. It works. Users love it. Then the invoice lands and your CFO wants a meeting.

This is the pattern we see constantly. Teams obsess over model quality and prompt engineering, then treat token spend as an afterthought. Six months later they're burning thousands a month with no ceiling and no visibility into who or what is driving the cost.

Token costs don't kill your ROI in one dramatic moment. They erode it quietly, one unmetered conversation at a time.

Why token spend gets out of control

Three things compound against you:

Context bloat. Every turn in a conversation resends the full history plus system prompt plus retrieved documents. A 20-message support thread can hit tens of thousands of tokens per request because you're paying to reprocess everything each time.

Freeloaders and abuse. Public-facing bots attract scrapers, prompt-injection probes, and people using your GPT-4 endpoint as a free coding assistant. If there's no auth or rate limit, you're subsidizing strangers.

Model overkill. Routing a "what are your hours?" question to your most expensive model is like renting a crane to hang a picture frame.

Step 1: Measure before you optimize

You cannot govern what you don't log. Every LLM call should record tokens in, tokens out, model, user or session ID, and estimated cost. Do this at the middleware layer, not scattered across your app.

import time

PRICING = {
    "gpt-4o": {"in": 2.50 / 1_000_000, "out": 10.00 / 1_000_000},
    "gpt-4o-mini": {"in": 0.15 / 1_000_000, "out": 0.60 / 1_000_000},
}

def log_usage(response, model, user_id):
    usage = response.usage
    p = PRICING[model]
    cost = usage.prompt_tokens * p["in"] + usage.completion_tokens * p["out"]

    record = {
        "ts": time.time(),
        "user_id": user_id,
        "model": model,
        "prompt_tokens": usage.prompt_tokens,
        "completion_tokens": usage.completion_tokens,
        "cost_usd": round(cost, 6),
    }
    # ship to your warehouse / metrics store
    emit_metric(record)
    return cost

Once you have per-user cost data, patterns jump out fast. Usually a tiny fraction of sessions drive the majority of spend.

Step 2: Kill token freeloading

Rate limiting is your first line of defense. Cap requests and tokens per user per window. A per-token budget matters more than a per-request one, because a single abusive request can be huge.

from collections import defaultdict
import time

class TokenBudget:
    def __init__(self, daily_token_limit=50_000):
        self.limit = daily_token_limit
        self.usage = defaultdict(lambda: {"tokens": 0, "reset": 0})

    def check(self, user_id, estimated_tokens):
        now = time.time()
        u = self.usage[user_id]
        if now > u["reset"]:
            u["tokens"], u["reset"] = 0, now + 86400
        if u["tokens"] + estimated_tokens > self.limit:
            raise PermissionError("Daily token budget exceeded")
        u["tokens"] += estimated_tokens

Layer on input validation too. Cap max input length, strip obvious injection patterns, and require auth on anything that isn't explicitly meant to be anonymous. If your bot is public, put a lightweight challenge in front of it before a session can hit the model.

Step 3: Route by complexity, not by default

Most support queries are simple. Send them to a cheap model. Escalate to the expensive one only when needed.

A practical router:

Tier 1 (cheap model): FAQs, status checks, greetings, classification.
Tier 2 (mid model): multi-step reasoning, document synthesis.
Tier 3 (premium): edge cases the cheaper tiers flagged as low confidence.

You can gate escalation on a confidence check. If the cheap model returns a low-confidence answer or explicitly signals it can't handle the request, retry on the better model. Most traffic never leaves Tier 1, and your blended cost drops sharply.

Step 4: Trim the context you resend

Context is where the silent spend lives. Tactics that actually move the needle:

Summarize old turns. After N messages, compress the earlier history into a short summary instead of resending it verbatim.
Retrieve narrowly. Return the top 3 relevant chunks, not the top 15. More context rarely improves answers and always increases cost.
Cache system prompts. Providers now offer prompt caching. Structure your calls so the static system prompt and instructions hit the cache instead of being billed fresh every turn.
Set max_tokens on output. An unbounded response can ramble for 2,000 tokens when 200 would do.

Step 5: Set budgets and alerts

Governance isn't a one-time cleanup. It's a control loop. Define a monthly budget, wire spend into a dashboard, and set alerts at 50%, 80%, and 100%. When you cross a threshold, someone gets paged, not surprised at month end.

Better still, enforce a hard cap. If the org-wide daily budget is blown, degrade gracefully to a cheaper model or a static fallback rather than letting spend run free.

The payoff

None of this is glamorous. It's plumbing. But the teams that treat token spend as a first-class engineering concern run chatbots at a fraction of the cost of teams that don't, with no visible quality drop.

Measure everything. Route by complexity. Trim context aggressively. Cap the freeloaders. Do that, and your chatbot stays an asset instead of quietly becoming a liability line on the P&L.

If you're scaling AI support and want the governance layer built in from day one rather than bolted on after the scary invoice, that's exactly the kind of system we design at Michael AI.

Originally published at getmichaelai.com

The Honest Chatbot ROI Math: When AI Support Pays for Itself (and When It Burns Cash)

Michael — Mon, 28 Sep 2026 12:01:14 +0000

Every vendor demo makes the same promise: deploy a chatbot, deflect 60% of tickets, watch your support costs collapse. The demo always works. Your production traffic is messier.

After building these systems for B2B clients, here's the pattern that actually holds: chatbots save money on high-volume, low-variance interactions and lose money on everything else. The trick is knowing which bucket your use case lands in before you sign a contract.

Where chatbots actually cut costs

The economics are simple. A chatbot pays off when the cost to answer a query manually is high and the query repeats often. Multiply frequency by human minutes saved, subtract the build and running cost, and you have your answer.

Three categories consistently win:

1. Repetitive FAQ deflection

Order status, business hours, return policy, password resets. These are deterministic, high-frequency, and low-risk if the bot occasionally gets one slightly wrong. If 40% of your inbound is "where's my order," you're paying humans to read tracking numbers out loud.

2. Lead qualification before a human touches it

Instead of a rep spending 10 minutes on a call to learn the prospect has no budget, the bot collects budget, team size, and use case first. Your sales team only touches qualified leads.

3. After-hours coverage

A chatbot doesn't get overtime. If you're losing leads at 11pm because nobody's staffing chat, even a basic bot that captures the lead and books a callback recovers revenue you were throwing away.

Where they quietly burn money

Complex, high-stakes, or emotional queries

Billing disputes, cancellations, anything involving an angry customer. A bot that loops a frustrated user through "I didn't quite get that" three times doesn't save a ticket - it creates a worse one plus the human ticket you were going to get anyway. You paid twice.

Low-volume, high-variance work

If you get 15 support messages a day and they're all different, there's no repeating pattern to automate. You'll spend more building and maintaining the bot than you'd ever spend on a part-time human.

"Set it and forget it" fantasies

Products change. Prices change. A chatbot with a stale knowledge base confidently gives wrong answers, which is worse than no answer. Budget for ongoing maintenance or don't bother.

The ROI formula, in code

Don't guess. Model it. Here's the calculation I run before recommending a build:

def chatbot_roi(
    monthly_conversations,
    deflection_rate,        # realistic: 0.3-0.5, not vendor's 0.7
    minutes_per_ticket,
    hourly_support_cost,
    monthly_platform_cost,
    build_cost,
    maintenance_hours_month,
    dev_hourly_cost,
):
    deflected = monthly_conversations * deflection_rate
    minutes_saved = deflected * minutes_per_ticket
    labor_saved = (minutes_saved / 60) * hourly_support_cost

    maintenance_cost = maintenance_hours_month * dev_hourly_cost
    monthly_cost = monthly_platform_cost + maintenance_cost
    monthly_net = labor_saved - monthly_cost

    payback_months = build_cost / monthly_net if monthly_net > 0 else float('inf')

    return {
        "monthly_net_savings": round(monthly_net, 2),
        "payback_months": round(payback_months, 1),
        "annual_return": round(monthly_net * 12 - build_cost, 2),
    }

print(chatbot_roi(
    monthly_conversations=2000,
    deflection_rate=0.4,
    minutes_per_ticket=6,
    hourly_support_cost=25,
    monthly_platform_cost=150,
    build_cost=4000,
    maintenance_hours_month=4,
    dev_hourly_cost=80,
))
# {'monthly_net_savings': 1830.0, 'payback_months': 2.2, 'annual_return': 17960.0}

Change deflection_rate to the vendor's promised 0.7 and payback drops to under two months. Change it to a pessimistic 0.2 and the whole thing can go underwater. That single variable decides everything - so pressure-test it.

How to get the deflection rate right

Stop trusting the slide deck. Pull 200 of your actual chat transcripts and tag each one:

Automatable now - clear, repetitive, low-risk
Automatable with effort - needs a data lookup or integration
Human only - complex, emotional, or one-off

Your realistic deflection rate is roughly the first bucket, maybe half the second. If "human only" is 60% of your volume, a chatbot is the wrong first investment - fix your knowledge base or hire.

The build decision

Once the math clears, keep the first version narrow. Ship a bot that handles your top three query types well, with a clean handoff to a human the moment confidence drops. Nothing kills adoption faster than a bot that traps users.

Instrument everything: containment rate, escalation rate, and CSAT on bot-handled conversations. If containment is high but CSAT tanks, you're deflecting tickets by frustrating people into giving up. That's not savings - that's churn on a delay.

A chatbot isn't a support strategy. It's a tool that's brilliant at a specific job and terrible outside it. Run the numbers, scope it tight, and measure what happens after launch. That's the difference between an asset and a monthly subscription you forgot to cancel.

Originally published at getmichaelai.com

Your Chatbot's 80% Deflection Rate Is Lying to You

Michael — Sun, 27 Sep 2026 12:01:33 +0000

Deflection rate is the vanity metric of AI support. It looks great on a slide, it's easy to calculate, and it tells you almost nothing about whether your chatbot is actually helping anyone.

Here's the problem: deflection rate counts a conversation as a "win" whenever the user doesn't escalate to a human. But a user who gives up in frustration also doesn't escalate. A user who gets a wrong answer and acts on it doesn't escalate. Neither of those is a win.

If you're an ops leader making decisions off deflection rate alone, you're optimizing for silence, not resolution. Let's fix that.

Why Deflection Rate Breaks Down

Consider two chatbots, both reporting 80% deflection.

Bot A resolves 80% of issues correctly and users leave happy. Bot B answers vaguely, users shrug and leave, and half of them submit a ticket the next day through a different channel. Same deflection number. Wildly different outcomes.

Deflection also gets gamed structurally. Hide the "talk to a human" button and deflection climbs. That's not performance improvement — that's trapping people.

You need metrics that measure resolution quality, user effort, and downstream cost. Here's the stack that actually matters.

The Metrics That Actually Tell You Something

1. True Resolution Rate

Not "didn't escalate" — actually solved. The cleanest signal is a post-conversation confirmation plus a reopening check. If a user comes back within 24–72 hours on the same topic, the original conversation was not resolved.

def true_resolution_rate(conversations, followups, window_hours=72):
    resolved = 0
    for convo in conversations:
        confirmed = convo.get("user_confirmed_resolved", False)
        reopened = any(
            f["user_id"] == convo["user_id"]
            and f["topic"] == convo["topic"]
            and 0 < (f["ts"] - convo["ts"]) <= window_hours * 3600
            for f in followups
        )
        if confirmed and not reopened:
            resolved += 1
    return resolved / len(conversations)

This one number does more work than deflection ever will. It catches the "user gave up" and "wrong answer" cases deflection misses.

2. Containment vs. Escalation Quality

Don't just count escalations — grade them. A clean handoff where the bot passes full context to an agent is a good escalation. A cold dump where the user has to re-explain everything is a failure even though a human eventually helped.

Track the percentage of escalations that arrive with structured context: user intent, conversation summary, and attempted resolutions. This is where a lot of "AI support is bad" complaints actually originate — the handoff, not the bot.

3. Fallback and Confusion Rate

How often does the bot fire a generic "I didn't understand" or loop the user? Cluster these by topic. A spike in fallbacks around, say, refunds tells you exactly where your knowledge base or intent coverage is thin.

const fallbackHotspots = conversations
  .flatMap(c => c.turns)
  .filter(t => t.botAction === "fallback")
  .reduce((acc, t) => {
    acc[t.detectedTopic] = (acc[t.detectedTopic] || 0) + 1;
    return acc;
  }, {});

// Sort to find your worst-performing intents
const ranked = Object.entries(fallbackHotspots)
  .sort(([, a], [, b]) => b - a);

console.table(ranked.slice(0, 10));

This turns your analytics into a prioritized backlog. Fix the top three topics and watch resolution climb.

4. Time-to-Resolution (and Turns-to-Resolution)

Speed matters, but turn count matters more. A bot that resolves in 3 exchanges beats one that takes 12, even at the same clock time. High turn counts signal the bot is making users work — chasing clarifications, misreading intent, re-asking for info it already has.

Segment this by intent. "Reset password" should be 1–2 turns. "Dispute a charge" will legitimately take longer. Averaging them together hides everything.

5. Downstream Cost per Conversation

This is the ROI metric leadership actually cares about. Combine:

Cost of the AI conversation (API/tokens/platform).
Cost of any resulting human touch (escalation handle time).
Cost of repeat contacts caused by bad first answers.

That third line is the killer. A cheap bot that generates repeat tickets is more expensive than a pricier one that resolves cleanly the first time. Deflection rate hides this entirely.

6. CSAT Tied to Bot-Only Conversations

Most teams report blended CSAT. Split it. Score conversations the bot handled end-to-end separately from ones a human touched. If bot-only CSAT is dragging your average down, you know where the leak is — and you have the evidence to justify fixing it.

How to Wire This Together

Instrument at the turn level, not just the conversation level. Every turn should log detected intent, bot action, confidence score, and whether the user confirmed or corrected. From that raw stream you can compute every metric above and slice by topic, channel, and customer segment.

Then build one dashboard that answers three questions: Are we resolving issues? Where are we failing? What's it costing us?

Deflection rate answers none of those. Retire it as your headline number. Keep it as a footnote if you must — but run your chatbot on resolution, effort, and cost.

The teams shipping AI support that customers actually trust aren't the ones with the highest deflection. They're the ones who stopped measuring silence and started measuring outcomes.

Originally published at getmichaelai.com

Your AI Support Agent's Best Feature Is Knowing When to Give Up

Michael — Sat, 26 Sep 2026 12:01:07 +0000

Most teams building an AI support agent obsess over deflection rate. Wrong metric to optimize first.

The agents that actually work in production aren't the ones that answer everything. They're the ones that answer what they can confidently handle and hand off the rest cleanly, with context, before the customer gets frustrated.

A bad escalation is worse than no automation. The customer repeats their whole problem to a human, the human has zero context, and now you've added friction instead of removing it. Let's build one that doesn't do that.

Start with the escalation policy, not the prompt

Before you write a single prompt, decide what the agent is not allowed to resolve alone. This is a business decision, not a technical one.

Typical hard-escalation triggers:

Billing disputes and refunds over a threshold
Account security or access loss
Legal, compliance, or cancellation requests
Angry sentiment (churn risk)
Anything the agent has already failed at twice

Write these down as explicit rules. You don't want the LLM "deciding" whether a refund is appropriate. You want it to recognize the category and route it.

The three signals that should trigger a handoff

1. Low confidence

Don't trust a model that says "I'm 95% sure." Models are confidently wrong all the time. Instead, gate on whether the retrieval step actually found relevant knowledge.

If your RAG pipeline returns no chunks above a similarity threshold, the agent has nothing to stand on. Escalate.

def should_escalate(query, retrieved_docs, sentiment, attempts):
    top_score = max((d.score for d in retrieved_docs), default=0)

    if top_score < 0.72:
        return "low_knowledge_match"
    if sentiment == "negative" and attempts >= 1:
        return "frustrated_customer"
    if attempts >= 2:
        return "repeated_failure"
    if is_restricted_topic(query):
        return "policy_restricted"
    return None

2. Repeated failure

Track turns. If the customer rephrases the same question twice, the agent is looping. Loops erode trust faster than a slow human reply. Hand off after the second miss, not the fifth.

3. Sentiment shift

Run lightweight sentiment on each customer message. A person who starts polite and turns short is about to escalate themselves - beat them to it. Nothing kills goodwill like a cheerful bot arguing with someone who's already angry.

Build the handoff, not just the trigger

Here's where most implementations fall apart. The trigger fires, and then... the customer gets dumped into a generic queue.

A good handoff packages everything the human needs:

async function escalateToHuman(session, reason) {
  const summary = await llm.summarize({
    messages: session.transcript,
    instruction: "Summarize the issue, what the customer wants, " +
                 "and what the agent already tried. Be concise."
  });

  await ticketing.createOrUpdate({
    channel: session.channel,
    customerId: session.customerId,
    priority: reason === "frustrated_customer" ? "high" : "normal",
    escalationReason: reason,
    aiSummary: summary,
    fullTranscript: session.transcript,
    suggestedResponse: await draftReply(session)
  });

  return "I'm connecting you with a specialist who can help. " +
         "They'll have everything we've discussed.";
}

Two things matter here.

First, the AI summary. The human agent should read three sentences, not scroll a chat log. "Customer wants a refund on order #4821, says it arrived damaged. Bot confirmed the order but can't issue refunds. Customer has photos ready."

Second, the suggested response. Even when escalating, the agent can draft what it would say if it were allowed. The human edits and sends. That turns a full handoff into a 20-second review.

Tell the customer the truth

Don't fake being human. Don't stall. The moment you decide to escalate, say so plainly and set expectations: "A specialist will reply within 30 minutes." Then make sure that's actually true.

The worst pattern is the bot that pretends to help while quietly doing nothing. Customers can smell it.

Close the loop with data

Every escalation is training data. Log the reason, the transcript, and how the human ultimately resolved it. Review weekly.

You'll find patterns fast:

Escalations from low_knowledge_match on the same topic mean your knowledge base has a gap. Fill it, and those stop escalating.
Escalations that a human resolves with a canned answer mean your policy is too conservative. Loosen it.
Escalations that humans also struggle with mean the process itself is broken. Fix upstream.

Over a few weeks, this loop tightens. Deflection rate climbs because the agent gets smarter about what it knows, not because you forced it to guess.

The mental model

Think of the AI agent as a well-trained junior support rep. It handles the routine volume, knows the docs cold, and - critically - knows when a problem is above its pay grade. A junior who escalates cleanly with context is an asset. One who improvises on refund policy is a liability.

Build for the escalation first. The deflection takes care of itself.

If you're designing this kind of workflow and want the handoff logic, routing, and knowledge base wired into your actual tools, that's the work we do at Michael AI.

Originally published at getmichaelai.com

RAG Chatbots Without the Hallucinations: A Builder's Guide to Grounded AI Agents

Michael — Fri, 25 Sep 2026 12:01:02 +0000

Ask a raw LLM about your refund policy and it will happily invent one. Confident, fluent, and wrong. That's the whole problem RAG exists to solve.

Retrieval Augmented Generation is simple in concept: before the model answers, you fetch the relevant chunks of your data and stuff them into the prompt. The model stops guessing and starts summarizing from source material you control.

Most teams get the concept in five minutes and then spend three weeks fighting the parts nobody talks about. Let's cover both.

How RAG actually works

The pipeline has two phases: indexing (done once, or on a schedule) and retrieval (done per query).

Indexing

Load your documents (docs, tickets, PDFs, Notion, help center).
Split them into chunks small enough to be precise, large enough to keep context.
Embed each chunk into a vector using an embedding model.
Store vectors in a database like pgvector, Pinecone, or Qdrant.

Retrieval

Embed the user's question.
Find the top-k most similar chunks.
Inject those chunks into the prompt as context.
Let the LLM answer using only that context.

Here's the retrieval-and-answer step stripped to its essentials:

from openai import OpenAI
import numpy as np

client = OpenAI()

def embed(text):
    r = client.embeddings.create(model="text-embedding-3-small", input=text)
    return np.array(r.data[0].embedding)

def retrieve(question, chunks, embeddings, k=4):
    q = embed(question)
    scores = embeddings @ q / (
        np.linalg.norm(embeddings, axis=1) * np.linalg.norm(q)
    )
    top = scores.argsort()[-k:][::-1]
    return [chunks[i] for i in top]

def answer(question, chunks, embeddings):
    context = "\n\n".join(retrieve(question, chunks, embeddings))
    prompt = f"""Answer using ONLY the context below.
If the answer isn't there, say "I don't have that information."

Context:
{context}

Question: {question}"""
    r = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": prompt}],
        temperature=0,
    )
    return r.choices[0].message.content

That's a working RAG bot in 30 lines. It's also a demo, not a product. The gap between the two is where the real work lives.

Where RAG quietly fails

Bad chunking ruins everything

If you split by fixed character count, you'll slice sentences in half and separate a policy from its exception. Chunk by structure instead: headings, paragraphs, list items. Add small overlaps (10-15%) so context bleeds across boundaries.

Retrieval misses the point

Vector search finds semantic similarity, not always relevance. "Do you offer refunds?" and "return policy for damaged goods" may not rank close together. Fixes that work:

Hybrid search: combine vector similarity with keyword (BM25) search.
Reranking: pull top 20 candidates, then use a cross-encoder reranker to pick the best 4.
Query rewriting: have the LLM rephrase the question before retrieval.

The model still hallucinates

Even with context, models fill gaps. Two levers help: temperature=0 and an explicit instruction to refuse when the answer isn't present. Then verify it worked with citations.

No citations, no trust

Every answer should point back to a source. Return the chunk IDs alongside the response so users (and you) can audit it. A support bot that cites the exact help article is trusted. One that doesn't gets ignored after the first wrong answer.

Making it production-grade

A few upgrades separate hobby projects from systems people actually rely on.

Metadata filtering. Tag chunks with product, region, or access level, then filter before retrieval. A customer on the Starter plan shouldn't get answers about Enterprise features.

Freshness. Your docs change. Set up an incremental re-index so updated content flows in without rebuilding the whole store. Stale answers are just a slower kind of wrong.

Fallback paths. When retrieval confidence is low, route to a human or offer to open a ticket instead of forcing an answer. Knowing when not to answer is a feature.

Evaluation. Build a test set of real questions with known-good answers. Score retrieval hit rate and answer accuracy on every change. Without this you're tuning blind.

def eval_retrieval(test_cases, chunks, embeddings):
    hits = 0
    for q, expected_source in test_cases:
        results = retrieve(q, chunks, embeddings, k=4)
        if any(expected_source in r for r in results):
            hits += 1
    return hits / len(test_cases)

What good RAG delivers

Done right, a knowledge base agent deflects a large share of repetitive support tickets, answers sales questions instantly with accurate product details, and gives your team an internal assistant that actually knows your runbooks.

The business result isn't "we have a chatbot." It's faster response times, fewer escalations, and answers that hold up under scrutiny because they're grounded in your own data.

Start small, then scale

Don't try to index every document you own on day one. Pick one high-volume question type, wire up a tight retrieval loop, add citations, and measure accuracy. Once it's reliably above your threshold, expand the corpus.

RAG isn't magic. It's disciplined engineering around a language model. The teams that win treat it like a search problem with an LLM on top, not an LLM problem with search bolted on.

If you'd rather ship a grounded agent than debug chunking strategies for a month, that's exactly the kind of system we build at Michael AI.

Originally published at getmichaelai.com

The 75% ROI Trap: Why Most AI Customer Service Projects Never Pay Off

Michael — Thu, 24 Sep 2026 12:00:40 +0000

Most AI customer service projects don't fail because the model is bad. They fail because nobody defined what "working" actually means before shipping.

The pattern is predictable. A team buys a chatbot platform, wires it to a knowledge base, launches it behind a chat bubble, and six months later can't answer the only question that matters: did this save or make us money? When the answer is fuzzy, finance kills the budget. Gartner has flagged this repeatedly - a large share of AI service deployments get quietly shelved after the pilot.

Here's why it happens, and how to build the version that survives the ROI review.

Why chatbot ROI failure is a design problem, not a model problem

The LLM is rarely the bottleneck. GPT-4-class models are more than capable of handling tier-1 support. The failures cluster around four things:

No baseline. You can't prove savings if you never measured cost-per-ticket, average handle time, or deflection rate before launch. Most teams skip this and later argue from vibes.

Containment vanity metrics. "70% of chats handled by AI" sounds great until you learn half of those users bounced to email angrier than before. Containment is only valuable if the issue is actually resolved.

No fallback economics. A bot that escalates cleanly saves money. A bot that dumps a confused customer onto an agent with zero context costs more than having no bot at all - you pay for the AI and a longer human interaction.

Scope creep into hard tickets. Refund disputes, account security, billing edge cases. These are 20% of volume and 80% of the complexity. Point your bot there on day one and you'll manufacture failure.

The framework: instrument first, automate second

Don't start with the bot. Start with the ledger. Every automated interaction needs to emit a structured event you can price later.

from dataclasses import dataclass
from datetime import datetime

@dataclass
class ResolutionEvent:
    ticket_id: str
    handled_by: str          # "ai" | "human" | "ai_then_human"
    resolved: bool           # confirmed, not assumed
    intent: str              # "refund", "order_status"...
    ai_turns: int
    escalated: bool
    csat: int | None         # 1-5, if collected
    ts: datetime


AGENT_COST_PER_MIN = 0.85
AI_COST_PER_TURN   = 0.02

def ticket_savings(e: ResolutionEvent, avg_human_minutes=6):
    ai_cost = e.ai_turns * AI_COST_PER_TURN
    if e.handled_by == "ai" and e.resolved:
        return (avg_human_minutes * AGENT_COST_PER_MIN) - ai_cost
    if e.handled_by == "ai_then_human":
        # AI added cost but may have shortened the human touch
        return (2 * AGENT_COST_PER_MIN) - ai_cost - (avg_human_minutes * AGENT_COST_PER_MIN * 0.4)
    return -ai_cost  # AI ran, resolved nothing

That last branch is the honest one. If the bot burned turns and the human still did all the work, it's a negative-ROI event. Sum these across real traffic and you get a number finance will actually accept.

Track resolution, not deflection

The single highest-leverage change: only count a resolution when the customer confirms it. Add a one-tap "did this solve your problem?" and treat unconfirmed closes as unresolved. Your "success rate" will drop overnight - and become believable for the first time.

The winning-quarter playbook

Projects that clear ROI tend to share the same moves.

Pick boring, high-volume intents. Order status, password resets, shipping policy, plan changes. These are repetitive, low-risk, and represent the bulk of ticket volume. Automating 90% of a boring intent beats automating 30% of everything.

Make escalation carry context. When the AI hands off, it should pass a summary, the customer's verified identity, and what it already tried. This alone can cut human handle time by 30-40% even on tickets the bot didn't resolve.

async function escalate(session) {
  const summary = await llm.summarize(session.transcript);
  return queue.push({
    customer: session.verifiedProfile,
    aiSummary: summary,
    attemptedActions: session.actions,
    suggestedNextStep: session.lastSuggestion,
    priority: session.sentiment < -0.5 ? "high" : "normal"
  });
}

Gate write actions behind confidence. Reading data ("where's my order") is cheap and safe. Taking actions (issuing refunds, changing addresses) needs a confidence threshold and often a confirmation step. Cheap reads first, guarded writes later.

Run a shadow period. Before the AI talks to customers, let it draft responses that agents review and edit. You get accuracy data, catch hallucinations, and build a golden dataset - all without risking a single customer relationship.

The number that actually matters

Forget "AI handled X%." The metric that survives a budget review is fully-loaded cost per resolved ticket, tracked before and after, segmented by intent.

If a refund inquiry cost $4.10 to resolve with humans and $1.30 with your AI stack - and CSAT held steady - you have a defensible ROI story. If CSAT dropped two points to save 40 cents, you don't, and you shouldn't ship it.

The teams in the winning quarter aren't using better models. They picked narrow, high-volume problems, measured a real baseline, counted only confirmed resolutions, and made their handoffs smart. The other 75% built an impressive demo and hoped the spreadsheet would sort itself out.

Instrument first. Automate the boring stuff. Let the numbers pick your next intent.

Originally published at getmichaelai.com

The AI Chatbot ROI Formula: Stop Guessing, Start Calculating Payback in Code

Michael — Wed, 23 Sep 2026 12:00:37 +0000

Every chatbot pitch dies the same way: someone in finance asks "what's the payback period?" and the room goes quiet.

Most teams answer with vibes. "It'll save time." "Customers will love it." That's not a business case, it's a wish. Here's the actual math, plus a script you can run before writing a single line of bot logic.

The core formula

Chatbot ROI is not complicated. It's deflection times cost per contact, minus what the thing costs to build and run.

Monthly Savings = (Tickets/mo × Deflection Rate × Cost per Ticket) - Monthly Running Cost
Payback Months  = Build Cost / Monthly Savings
Annual ROI %    = ((Monthly Savings × 12) - Build Cost) / Build Cost × 100

The entire debate lives in four numbers: how many tickets you get, what fraction a bot can actually close, what each ticket costs you today, and what the bot costs to run. Get honest about those and the rest is arithmetic.

The numbers people get wrong

Deflection rate

This is the killer variable, and it's where optimism goes to inflate spreadsheets. Vendors love quoting 80%. Reality for a well-scoped support bot on FAQ-heavy traffic is closer to 30-50% in year one.

Deflection means the bot fully resolved the issue without a human touching it. A bot that answers then escalates deflected nothing. Measure it as: conversations closed by bot / total conversations.

Cost per ticket

Don't use salary alone. Fully loaded cost includes benefits, tooling, management overhead, and idle time. A common realistic figure for a live-chat or email agent is $5-$15 per resolved contact depending on complexity and geography.

Running cost

Token costs, vector DB hosting, the platform fee, and the human hours to maintain content. People forget that last one. A bot with a stale knowledge base deflects less every month.

The calculator

Here's the whole thing as a script. Feed it your numbers and it tells you if the project survives contact with a CFO.

def chatbot_roi(
    monthly_tickets: int,
    deflection_rate: float,      # 0.0 - 1.0
    cost_per_ticket: float,      # fully loaded USD
    build_cost: float,           # one-time
    monthly_running_cost: float, # tokens + hosting + upkeep
):
    deflected = monthly_tickets * deflection_rate
    gross_savings = deflected * cost_per_ticket
    net_monthly = gross_savings - monthly_running_cost

    if net_monthly <= 0:
        return {"verdict": "Do not build", "net_monthly": round(net_monthly, 2)}

    payback_months = build_cost / net_monthly
    annual_roi = ((net_monthly * 12) - build_cost) / build_cost * 100

    return {
        "tickets_deflected": round(deflected),
        "net_monthly_savings": round(net_monthly, 2),
        "payback_months": round(payback_months, 1),
        "annual_roi_pct": round(annual_roi, 1),
        "verdict": "Build it" if payback_months < 12 else "Marginal",
    }


print(chatbot_roi(
    monthly_tickets=4000,
    deflection_rate=0.40,
    cost_per_ticket=8.0,
    build_cost=25000,
    monthly_running_cost=1200,
))

Output:

{'tickets_deflected': 1600, 'net_monthly_savings': 11600.0,
 'payback_months': 2.2, 'annual_roi_pct': 456.8, 'verdict': 'Build it'}

A 2.2 month payback is a strong case. But watch what happens when you dial deflection down to a more conservative 25% and running cost up to $2,000:

{'tickets_deflected': 1000, 'net_monthly_savings': 6000.0,
 'payback_months': 4.2, 'annual_roi_pct': 188.0, 'verdict': 'Build it'}

Still good. The point isn't the happy number, it's stress-testing your assumptions until the case holds even when you're pessimistic.

Run the pessimist's version

Never present a single scenario. Present three.

scenarios = {
    "conservative": dict(deflection_rate=0.25, monthly_running_cost=2000),
    "expected":     dict(deflection_rate=0.40, monthly_running_cost=1200),
    "aggressive":   dict(deflection_rate=0.55, monthly_running_cost=1000),
}

base = dict(monthly_tickets=4000, cost_per_ticket=8.0, build_cost=25000)

for name, override in scenarios.items():
    result = chatbot_roi(**{**base, **override})
    print(name, result["payback_months"], "months")

If your conservative case still pays back inside a year, you have a real project. If only the aggressive case works, you're gambling.

What the formula won't tell you

Three things live outside the spreadsheet but matter:

Response time. A bot answers instantly at 2am. That deflection has a customer-satisfaction value the ticket-cost math ignores.
Agent focus. Removing repetitive tickets lets your team handle the hard 40% better. Hard to quantify, real to feel.
Scaling headroom. When volume doubles, headcount doesn't have to. The bot absorbs the spike at near-zero marginal cost.

Don't stuff these into the ROI number to inflate it. List them as upside, keep the hard math clean.

The one metric to instrument first

Before you build, tag your existing tickets by category. The share that are repetitive, low-complexity, and answerable from your docs is your realistic deflection ceiling. If that's only 20% of volume, no model tuning saves the business case.

Prove the number before you write the code. The bot is the easy part. The math is what gets it funded.

Originally published at getmichaelai.com

Building an AI-Powered LinkedIn Prospecting Pipeline That Doesn't Get You Banned

Michael — Tue, 22 Sep 2026 12:00:42 +0000

Most "LinkedIn automation" advice falls into two buckets: spammy Chrome extensions that blast 100 connection requests a day, or vague thought-leadership about "authentic engagement." Neither ships meetings.

Here's the engineering view. A LinkedIn lead pipeline is a data flow: source prospects → enrich → score → personalize → send → route replies. AI slots into three of those stages. The rest is plumbing. Let's build it.

The architecture

Think of it as four services talking over a queue, not one monolithic bot poking LinkedIn's DOM.

[Prospect Source] -> [Enrichment] -> [AI Scoring + Personalization] -> [Outreach Sender] -> [Reply Router]

The critical design rule: keep the AI layer separate from the sending layer. Generation is cheap and safe to run at scale. Sending is where you get rate-limited and banned, so it needs strict throttling.

Step 1: Source prospects like a data problem

Don't scrape LinkedIn directly at volume - that's what gets accounts flagged. Use Sales Navigator saved searches exported through a compliant tool (PhantomBuster, Clay, or a lightweight custom worker on a residential proxy), and treat the output as a raw CSV of leads.

What you actually want per lead:

Name, title, company, company size, LinkedIn URL
Recent activity signal (posted, changed jobs, hiring)
A firmographic hook you can reference

The activity signal is what makes 2026 outreach work. Static "I saw your profile" messages are dead. Job-change and hiring events give you a real reason to reach out.

Step 2: Enrich and score with AI

Before you write a single message, filter. Sending fewer, better-targeted messages is how you stay under the radar and keep reply rates high.

Here's a scoring pass that uses an LLM to convert messy profile data into a fit score:

import openai, json

client = openai.OpenAI()

def score_lead(lead):
    prompt = f"""
    Score this B2B lead 0-100 for fit with our ICP:
    ICP: Ops/RevOps leaders at 50-500 employee SaaS companies
    who are hiring or scaling GTM.

    Lead: {json.dumps(lead)}

    Return JSON: {{"score": int, "reason": str, "hook": str}}
    """
    resp = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": prompt}],
        response_format={"type": "json_object"},
    )
    return json.loads(resp.choices[0].message.content)

qualified = [l | score_lead(l) for l in leads]
qualified = [l for l in qualified if l["score"] >= 70]

The hook field is gold - it's the specific reason this person is relevant right now, and it feeds directly into the message writer.

Step 3: Personalize without sounding like a robot

The trap here is over-templating. If your "AI personalization" produces messages that all follow the same visible pattern ("Hi {name}, loved your post about {topic}!"), recipients pattern-match it instantly.

Give the model room to vary structure, and constrain it with a real voice guide:

def write_opener(lead):
    prompt = f"""
    Write a LinkedIn connection note under 280 chars.
    Person: {lead['name']}, {lead['title']} at {lead['company']}
    Reason to reach out: {lead['hook']}

    Rules:
    - No greeting cliches, no 'I came across your profile'
    - Reference the hook naturally, like a peer would
    - One specific line, no pitch, no CTA
    - Sound like a busy human, not a marketer
    """
    resp = client.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": prompt}],
        temperature=0.8,
    )
    return resp.choices[0].message.content.strip()

Run a human review on the first 50 outputs. You're calibrating the prompt, not the individual messages. Once the pattern is good, it scales.

Step 4: Send with human-like throttling

This is the part that determines whether your account survives. LinkedIn tracks velocity, timing regularity, and behavioral fingerprints.

Hard rules that have held up:

Max ~20-25 connection requests/day on a warmed account.
Randomize timing - don't fire every 60 seconds on the dot.
Business hours only, in the account's timezone.
Warm up new accounts over 2-3 weeks before pushing volume.

import random, time

def send_batch(messages, daily_cap=22):
    for msg in messages[:daily_cap]:
        send_connection(msg["url"], msg["text"])
        # jittered delay, 3-9 minutes between sends
        time.sleep(random.randint(180, 540))

Use an official-ish sending layer where possible. Unipile and similar APIs give you a cleaner path than DOM automation, which breaks every time LinkedIn ships a UI change.

Step 5: Route replies to a human fast

Automation gets the conversation started. It should not try to close.

When a reply lands, classify intent with a quick LLM call - positive, objection, not_now, not_interested - then route:

positive and objection → notify the human rep in Slack with full context and the original hook.
not_now → tag for a follow-up sequence in 60 days.
not_interested → suppress permanently.

The handoff quality is where most pipelines leak. If your rep opens a reply cold with no context, the AIm‑warmed lead goes stale. Pass the whole thread plus the fit reason.

What actually moves the number

After building a few of these, the pattern is consistent: targeting and timing beat clever copy. A mediocre message to someone who just started hiring for the exact role you serve outperforms a beautiful message to a random fit.

Spend your AI budget on scoring and signal detection, keep sending conservative and human-paced, and get a real person into the conversation the moment someone raises their hand. That's the pipeline that books meetings in 2026 - not the one that sends the most messages.

Originally published at getmichaelai.com

Stop Blasting Cold Emails: Build an Intent-Triggered Outreach Engine Instead

Michael — Mon, 21 Sep 2026 12:00:39 +0000

Most B2B outreach fails for one boring reason: timing. You send a perfect email to a perfect prospect who has zero reason to care today. The message isn't wrong. The moment is.

Intent-based outreach flips this. Instead of a fixed cadence firing at everyone on a list, you wait for a signal - then trigger a personalized message within minutes. This is very buildable with tools you probably already have. Here's the architecture.

What Counts as a Buyer Intent Signal

Intent data is anything that suggests a prospect is actively evaluating a solution. It falls into two buckets:

First-party signals happen on your own properties:

Pricing page visits (especially repeat visits)
Docs or integration page views
Free trial signups that stall
Demo form abandons

Third-party signals happen off your site:

Job postings mentioning tools you complement
Funding announcements
New hires in relevant roles (a new Head of RevOps is a buying committee forming)
Technographic changes (they just installed a competitor's tag)

The strongest triggers combine both. A prospect who visits your pricing page and just posted a job for the exact problem you solve is a green light.

The Core Loop

Every intent engine has the same shape:

Capture a signal
Enrich the account and contact
Score whether it's worth acting on
Generate a personalized message grounded in the signal
Route it - to a rep or an automated send

Miss any step and quality collapses. Skip enrichment and your AI writes generic copy. Skip scoring and you spam every tire-kicker.

Capturing the Signal

Start with what's free. A simple script on your pricing page tells you more than most paid intent vendors.

// Track high-intent page views and push to your automation webhook
async function trackIntent(pageType) {
  const visitorId = getVisitorId(); // from your cookie / analytics
  const account = await identifyAccount(visitorId); // reverse-IP or Clearbit

  if (!account?.domain) return;

  await fetch('https://your-n8n-instance/webhook/intent', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      domain: account.domain,
      page: pageType,
      timestamp: Date.now(),
      sessionCount: account.sessions
    })
  });
}

// Fire on the pages that actually indicate buying intent
if (window.location.pathname.includes('/pricing')) {
  trackIntent('pricing');
}

Scoring Before You Act

Don't let one page view trigger an email. Weight signals and set a threshold. A pricing visit is worth more than a blog read. A repeat pricing visit within 48 hours is worth a lot more.

SIGNAL_WEIGHTS = {
    "pricing_view": 30,
    "pricing_repeat": 50,
    "docs_view": 20,
    "demo_abandon": 45,
    "job_post_match": 40,
    "recent_funding": 25,
}

def score_account(signals: list[str]) -> int:
    return sum(SIGNAL_WEIGHTS.get(s, 0) for s in signals)

def should_trigger(signals: list[str], threshold: int = 60) -> bool:
    score = score_account(signals)
    return score >= threshold

# Example
signals = ["pricing_repeat", "job_post_match"]
print(score_account(signals))      # 90
print(should_trigger(signals))     # True

The threshold is a dial. Set it high early, then loosen it as you trust the pipeline.

Where AI Actually Earns Its Keep

The AI's job is not to invent a persona or fabricate flattery. It's to write a message that references the specific signal in a way a human would.

Feed the model the raw context - the signal, the enriched account data, the role - and constrain it hard.

prompt = f"""
Write a 3-sentence outreach email.

Context:
- Company: {account['name']} ({account['industry']})
- Signal: visited pricing page twice in 48h, recently posted a
  job for a RevOps Manager
- Recipient role: VP of Sales

Rules:
- Reference the RevOps hire naturally, not the page visit
  (that's creepy).
- No superlatives, no 'I hope this finds you well'.
- One clear, low-friction ask.
"""

Notice the guardrail: reference the public signal (the job post), not the private one (their browsing). Using the browsing signal to time the send is smart. Mentioning it in the copy is a trust-killer.

Route, Don't Auto-Send Everything

High-score accounts should go to a human with a pre-drafted message and full context. Mid-score accounts can enter a lighter automated sequence. This tiering keeps your best prospects in front of your best closers while automation handles volume.

A simple rule set:

Score 80+ → Slack alert to the account owner with draft ready
Score 60-79 → Automated 3-touch sequence
Below 60 → Nurture, no direct outreach

Build This in Stages

Don't try to boil the ocean. A realistic first quarter:

Week 1-2: Instrument your pricing and docs pages. Pipe events to a webhook.
Week 3-4: Add enrichment and a basic scoring threshold.
Week 5-6: Wire up AI drafting with strict prompts and human review.
Week 7+: Layer in a third-party signal source, then start automating the mid-tier.

The teams winning at outbound right now aren't sending more. They're sending at the right moment, with context that proves they were paying attention. That's not a bigger list. It's a better trigger.

Start with one signal, one message template, and one human in the loop. Get the timing right, and the rest is tuning.

Originally published at getmichaelai.com

Stop Making Reps Google Prospects: Build a Self-Enriching Lead Pipeline in n8n

Michael — Sun, 20 Sep 2026 12:00:39 +0000

Your sales reps spend a shocking amount of time not selling. They're on LinkedIn confirming job titles, on Crunchbase checking funding, pasting company names into ChatGPT to summarize what a prospect actually does.

Every minute of that is manual data plumbing that a workflow can do faster, cheaper, and consistently. Here's how to build that workflow in n8n.

The pipeline in one sentence

A new lead comes in, gets enriched with firmographic and contact data, gets researched by an LLM, gets scored against your ICP, and lands in your CRM with a fit rating and a ready-to-use summary.

No human touches it until the point where a human actually adds value: the conversation.

Stage 1: Catch the lead

Every lead source becomes an entry point. Use an n8n Webhook node for form fills, a Gmail/IMAP trigger for inbound emails, or a polling node against your CRM.

Standardize the payload early. The rest of the workflow should never care whether a lead came from a Typeform or a HubSpot form.

{
  "email": "jane@acme.io",
  "company_domain": "acme.io",
  "source": "webinar-2024"
}

One rule: normalize the domain immediately. Strip www., lowercase everything, and derive the domain from the email if the form didn't capture it. Bad domains poison every downstream enrichment call.

Stage 2: Enrich with real data

Before you let an LLM touch anything, get hard facts. Use an HTTP Request node against an enrichment provider (Clearbit, Apollo, People Data Labs, or a scraper of your choice) to pull company size, industry, funding, tech stack, and the contact's role.

The key is to keep this deterministic. Enrichment APIs return structured data. Don't ask an AI to guess headcount when an API will tell you.

// Function node: merge enrichment into a clean lead object
const lead = $input.first().json;
const enrich = $('Enrichment API').first().json;

return [{
  json: {
    email: lead.email,
    domain: lead.company_domain,
    company: enrich.name,
    industry: enrich.category?.industry ?? 'unknown',
    employees: enrich.metrics?.employees ?? null,
    funding: enrich.metrics?.raised ?? null,
    title: enrich.person?.title ?? '',
    seniority: enrich.person?.seniority ?? '',
    source: lead.source
  }
}];

Add an IF node here to short-circuit garbage. No company match, personal Gmail domain, or fewer than N employees? Route it to a low-priority bucket instead of burning LLM tokens on it.

Stage 3: AI prospect research

This is where the LLM earns its keep. Feed it the enriched facts plus scraped context (recent news, the company's homepage copy, the prospect's LinkedIn headline) and ask for the things a rep would otherwise dig up manually.

Structure your prompt to return JSON so downstream nodes can parse it reliably.

// OpenAI / Anthropic node - system + user message
const lead = $input.first().json;

const prompt = `You are a B2B sales researcher.
Company: ${lead.company} (${lead.industry}, ~${lead.employees} employees)
Contact: ${lead.title}
Homepage summary: ${lead.homepage_text}
Recent news: ${lead.news}

Return strict JSON:
{
  "summary": "2-sentence plain-English what they do",
  "pain_hypothesis": "likely problem our product solves",
  "opening_line": "one personalized cold-email sentence",
  "buying_signals": ["list of observed triggers"]
}`;

return [{ json: { prompt } }];

Two things that keep this reliable: set temperature low (0.2-0.3) so the output stays grounded, and use the model's structured-output / JSON mode so you aren't regex-parsing prose at 2am.

Stage 4: Automated qualification

Now score the lead against your Ideal Customer Profile. You can do this with plain logic in a Function node - no AI needed, and it's auditable.

const l = $input.first().json;
let score = 0;

if (l.employees >= 50 && l.employees <= 1000) score += 30;
if (['VP', 'Director', 'C-Suite'].includes(l.seniority)) score += 30;
if (['SaaS', 'Fintech', 'E-commerce'].includes(l.industry)) score += 20;
if (l.funding > 5_000_000) score += 20;

const tier = score >= 70 ? 'A' : score >= 40 ? 'B' : 'C';

return [{ json: { ...l, score, tier } }];

Keep scoring rules in code or a variable, not scattered across nodes. When sales leadership wants to tweak the ICP, you change one block.

Stage 5: Route and write back

Use a Switch node on tier:

Tier A → create CRM deal, notify the rep in Slack with the AI summary and opening line, book a task.
Tier B → drop into a nurture sequence.
Tier C → log and move on.

Write everything back to the CRM: score, summary, buying signals, research timestamp. Your reps open the record and everything they'd have spent 20 minutes gathering is already there.

Slack message that reps actually read

const l = $input.first().json;
return [{ json: { text:
  `:fire: *Tier ${l.tier} lead* (${l.score}/100)\n` +
  `*${l.company}* — ${l.summary}\n` +
  `*Angle:* ${l.pain_hypothesis}\n` +
  `*Opener:* ${l.opening_line}`
}}];

What to watch out for

Cache enrichment. Same domain twice in a week shouldn't cost two API calls. Store results and check first.

Handle rate limits. Wrap HTTP nodes with retries and use n8n's built-in error workflow to catch failures instead of silently dropping leads.

Don't over-trust the LLM. It writes the narrative; your deterministic scoring makes the decision. That separation keeps qualification defensible.

Build this once and every rep gets a research analyst that never sleeps. They stop Googling and start closing - which is the only thing you actually pay them to do.

Originally published at getmichaelai.com

Stop Buying AI Sales Tools. Build the Stack Instead.

Michael — Sat, 19 Sep 2026 12:00:40 +0000

Every week another "AI SDR" lands in your inbox promising to book meetings while you sleep. Most of them are a GPT wrapper around a cold email sequence with a churn problem baked in.

The teams actually closing more deals in 2026 aren't chasing the shiniest tool. They're building a stack where data flows cleanly between systems and AI does the reasoning humans hate doing. Here's how to think about it like an engineer, not a buyer.

The four layers of an AI sales stack

Forget the vendor categories on G2. A sales stack that works has four jobs, and every tool you evaluate should map to exactly one of them.

1. The data layer

This is your source of truth: CRM (HubSpot, Salesforce, Attio), enrichment (Clay, Apollo), and intent signals (product usage, website visits, funding events).

If this layer is dirty, everything downstream is garbage. AI amplifies whatever you feed it. A model writing personalized outreach off a stale job title will confidently email the wrong person about the wrong problem.

Evaluation rule: Does it have a real API and webhooks? If a tool can't push and pull data programmatically, it's a silo. Skip it.

2. The reasoning layer

This is where AI earns its keep. Lead scoring, ICP matching, reply classification, and drafting context-aware messages.

The best-in-class here isn't a single product - it's often your own logic calling an LLM. A scoring prompt you control beats a black-box "AI score" you can't audit.

import openai

def score_lead(lead):
    prompt = f"""
    Rate this lead 0-100 for fit with our ICP.
    ICP: B2B SaaS, 50-500 employees, has a sales team, US/EU.

    Lead:
    - Company: {lead['company']}
    - Size: {lead['employees']}
    - Industry: {lead['industry']}
    - Signal: {lead['recent_signal']}

    Return JSON: {{"score": int, "reason": str}}
    """
    resp = openai.chat.completions.create(
        model="gpt-4.1",
        messages=[{"role": "user", "content": prompt}],
        response_format={"type": "json_object"},
    )
    return resp.choices[0].message.content

# Only human-touch leads above 70
hot = [l for l in leads if score_lead(l)["score"] > 70]

The point isn't this exact prompt. It's that you can version it, test it, and swap the model without ripping out a vendor.

3. The action layer

Outreach tools (Instantly, Smartlead, lemlist), dialers, meeting schedulers, and sequencers. This is where messages actually go out.

Here's the trap: most "AI outreach tools" bundle the reasoning and action layers together, then lock your logic inside their UI. When you outgrow them, you start from zero.

Keep action tools dumb and swappable. Let them send. Let your reasoning layer decide what and to whom.

4. The orchestration layer

This is the glue: n8n, Make, or custom code that moves data between the other three layers and triggers actions based on events.

This is the layer most teams skip - and it's the one that makes the difference between a pile of subscriptions and an actual system.

A concrete flow

Here's what a working loop looks like when the layers are wired together:

// n8n-style pseudo-flow triggered by a new website visit
async function onIntentSignal(visit) {
  // 1. Data: enrich the anonymous visit
  const lead = await clay.enrich(visit.domain);

  // 2. Reasoning: is this worth a human's time?
  const { score, reason } = await scoreLead(lead);
  if (score < 70) return;

  // 3. Reasoning: draft context-aware first touch
  const email = await draftEmail(lead, visit.pages_viewed);

  // 4. Action: queue in the sequencer, notify the rep
  await smartlead.addToCampaign(lead.email, email);
  await slack.notify('#sales', `Hot lead: ${lead.company} (${reason})`);
}

No single tool does all of this. That's the point. You're assembling capabilities, not renting a monolith.

How to actually evaluate a tool

When a vendor demos, ignore the AI marketing and ask four questions:

Can I get my data out? Full export, real API, webhooks. If the answer is vague, that's your answer.
What happens when the AI is wrong? Good tools show confidence and let a human override. Bad ones hide the mechanism.
Does it do one layer well, or five layers badly? Specialists integrate. Suites lock you in.
What's the cost at 10x volume? Per-message and per-enrichment pricing has a way of exploding once it works.

The mistake to avoid

Teams buy an "all-in-one AI sales platform," spend two months configuring it, and end up with a slower version of what they had - because the tool's opinions don't match their motion.

Start with your actual sales process. Map each step to one of the four layers. Then buy the smallest, most swappable tool for each. Wire them with an orchestration layer you control.

That stack costs less, breaks less, and grows with you. And when a genuinely better model or tool ships - which it will, quarterly - you replace one component instead of rebuilding the whole thing.

The best AI sales stack in 2026 isn't a product. It's an architecture.

Originally published at getmichaelai.com

The Real Math on AI SDRs: A Cost Model B2B Teams Can Actually Use

Michael — Fri, 18 Sep 2026 12:00:39 +0000

Everyone selling AI SDR software leads with the same pitch: replace your $70k rep with a $500/month bot. The math looks obvious until you actually build the model. Then it gets interesting.

Let's do the numbers properly, then talk about where each side actually wins.

The fully-loaded cost of a human SDR

Most teams undercount this. A human SDR isn't just base salary.

Base: $55k
Commission/OTE: ~$20k
Payroll tax + benefits (~25%): ~$18k
Tooling (CRM seat, dialer, data enrichment, email tools): ~$6k/year
Ramp cost: a new SDR is roughly 40% productive for the first 3 months

That's about $99k/year for a fully productive rep, and closer to $110k in year one after ramp drag.

Output? A solid SDR books 10-15 qualified meetings per month. Call it 150 meetings/year at steady state.

Cost per meeting: ~$660.

The fully-loaded cost of an AI SDR

The sticker price is the trap. The AI "seat" is cheap; the fuel is not.

def ai_sdr_annual_cost(
    platform_fee_monthly=1500,
    contacts_per_month=8000,
    enrichment_cost_per_contact=0.08,
    email_sends_per_month=20000,
    email_cost_per_1k=0.40,
    llm_tokens_monthly=15_000_000,   # personalization at scale
    llm_cost_per_1m=3.00,
    ops_hours_monthly=15,            # someone still runs it
    ops_hourly=60,
):
    monthly = (
        platform_fee_monthly
        + contacts_per_month * enrichment_cost_per_contact
        + (email_sends_per_month / 1000) * email_cost_per_1k
        + (llm_tokens_monthly / 1_000_000) * llm_cost_per_1m
        + ops_hours_monthly * ops_hourly
    )
    return round(monthly * 12, 2)

print(ai_sdr_annual_cost())  # ~ 36,996

So a realistic AI SDR stack runs ~$37k/year all-in, not the $6k the landing page implies. The data enrichment and human oversight are the hidden line items nobody budgets for.

But look at the output side. An AI system doesn't book 150 meetings — it processes volume. At 8,000 contacts/month with a conservative 0.8% positive reply rate that converts to a meeting, you get ~64 meetings/month, or ~770/year.

Cost per meeting: ~$48.

On paper, the AI wins by roughly 13x on cost efficiency. That number is real — and also misleading.

Why cost-per-meeting lies

A booked meeting is not revenue. Quality is where the model breaks.

Human-booked meetings tend to be better qualified because the rep filtered, researched, and handled objections live. AI-booked meetings skew toward volume, and a chunk are unqualified, tire-kickers, or people who replied "sure" to get the bot to stop.

So weight the output by close rate:

def pipeline_value(meetings, show_rate, close_rate, acv):
    return meetings * show_rate * close_rate * acv

human = pipeline_value(150, 0.75, 0.20, 15000)   # 337,500
ai    = pipeline_value(770, 0.55, 0.08, 15000)    # 508,200

print(f"Human deal value: ${human:,.0f}")
print(f"AI deal value:    ${ai:,.0f}")

AI still wins on raw pipeline here — but notice the assumptions doing the heavy lifting: lower show rate (0.55 vs 0.75) and a close rate under half the human's. Flatten those a bit further and the human catches up fast.

The honest conclusion: AI wins on top-of-funnel volume and cost. Humans win on conversion quality and complex deals.

Where each one actually belongs

AI SDRs win when:

Your TAM is large and you can afford spray-and-refine outreach
ACV is low-to-mid and the sales motion is transactional
You need coverage across thousands of accounts a human can't touch
The first-touch job is research + personalization at scale, not persuasion

Human SDRs win when:

ACV is high and the buying committee is complex
Trust and nuance matter in the first conversation
Your ICP is small and every account deserves manual research
Objection handling happens live, on the phone

The setup most teams get wrong

The framing "AI vs human" is the mistake. The teams getting real ROI run a hybrid pipeline:

AI handles list-building, enrichment, and first-touch personalization across the full TAM.
AI scores and qualifies replies against your ICP rules.
Only warm, qualified conversations get routed to a human.

function routeLead(lead) {
  const score = lead.icpScore * 0.5
    + lead.intentSignals * 0.3
    + lead.replySentiment * 0.2;

  if (score >= 0.7) return { owner: 'human_ae', priority: 'high' };
  if (score >= 0.4) return { owner: 'ai_nurture', priority: 'medium' };
  return { owner: 'ai_recycle', priority: 'low' };
}

This flips the cost model. Your humans stop grinding cold lists at $660/meeting and only work AI-qualified conversations. The AI absorbs the volume grunt work at $48/meeting. Cost per qualified meeting drops and close rates hold, because the human still owns the moment that converts.

The bottom line

AI SDRs aren't a headcount replacement — they're a leverage layer. Run the full model with your own ACV, close rate, and enrichment costs before you believe anyone's ROI slide. The 13x cost advantage is real at the top of the funnel and mostly evaporates by the time revenue lands.

Build the hybrid, measure cost-per-qualified-meeting instead of cost-per-meeting, and let each side do what it's actually good at.

Originally published at getmichaelai.com