Why I Named This “What the CAC?”

Why "What the CAC?" — what does this metric actually tell you about your business?

CAC, measured against LTV, is the fastest way to tell if a company has real product-market fit or is just renting growth.

I've sat in enough pipeline reviews to know that most teams talk about CAC like it's a marketing scorecard. It's not. It's a market feedback loop. When your CAC is climbing and your LTV is flat, the market is telling you something you don't want to hear: the product isn't pulling its own weight, and you're compensating with spend.

I've watched this play out from both sides. On the "good" side, I've seen products where word-of-mouth and organic pipeline did more work than any paid channel could, because the product created raving fans who referred, expanded, and stuck around. CAC stayed low because the product did the selling. On the "bad" side, I've seen teams pour more budget into paid acquisition every quarter to hit the same growth number, while retention quietly eroded underneath them. Nobody flagged it because the top-line growth number still looked fine. CAC was the canary. Nobody was listening to it.

That's the whole premise of this newsletter. New customers are expensive (they always will be). Raving fans are the compounding asset. Every issue comes back to that idea: are you doing something that lowers CAC and raises LTV at the same time, or are you doing something that just moves the acquisition number without touching retention?

The five topics below (AI agent data quality, PLG vs. SLG, agent authority, agent auditability, and GTM Engineer judgment) don't look like CAC topics on the surface. But line them up, and each one is quietly doing the same thing: making your acquisition spend less efficient in a way that never shows up as its own line item.

Related: the LTV:CAC ratio, explained

What is CAC (Customer Acquisition Cost), and how do you calculate it correctly?

CAC is the fully-loaded cost to acquire one paying customer, calculated by dividing total sales and marketing spend by the number of new customers closed in that period.

The formula looks simple: CAC = (Total Sales + Marketing Spend) ÷ Number of New Customers Acquired.

The mistake I see constantly is teams calculating a "clean" CAC that only counts ad spend, and leaves out salaries, tools, commissions, and overhead. That's not CAC. That's a partial and misleading version of it that makes the number look better than it is. A fully-loaded CAC includes every dollar spent to go from "doesn't know you exist" to "signed."

Here's why this matters more than people think: CAC on its own is meaningless. It only becomes useful next to LTV (the total revenue you can expect from that customer over their lifetime). The commonly cited healthy benchmark is an LTV:CAC ratio of roughly 3:1 or better, meaning a customer is worth at least three times what it cost to acquire them. Below that, you're not building a business, you're subsidizing growth with someone's balance sheet (usually a VC's).

I bring this up first because everything below is downstream of it. Bad data architecture inflates CAC because your team wastes cycles chasing bad leads and unwinding attribution errors. A fractured PLG/SLG motion inflates CAC because two teams are independently spending to move the same prospect. Agents without governance inflate CAC because someone has to clean up after them, and that labor cost gets absorbed somewhere in your GTM budget whether you track it or not.

Full breakdown: Customer Acquisition Cost (CAC) and Lifetime Value (LTV)

Why do AI agents fail on GTM data, and what does that actually cost you?

AI agents aren't failing because the models are weak. They're failing because the data underneath them was built for human judgment, not machine execution.

When I work with teams deploying AI across their GTM motion, the first thing I check isn't the model. It's whether the data architecture was designed for people making judgment calls, or for systems executing rules. Those are two different foundations, and most companies built the first one while expecting the second to work automatically. Inadequate data management is projected to cause 60% of AI project failures, which tracks once you've actually looked inside a CRM that's been "cleaned up" by three different RevOps hires over five years.

Humans rely on intuition and context to spot bad data. An experienced rep looks at a lead source field and knows to second-guess it. Agents don't have that instinct. They rely on predefined rules, and when your CRM has duplicate records, stale pipeline data, or attribution fields that don't reconcile across platforms, the agent doesn't question it. It executes confidently on garbage.

I see this exact pattern constantly: Salesforce lead source fields stamped with last-touch attribution, while HubSpot tracks first-touch. Neither system reconciles, so an agent optimizing spend allocation will favor whichever channel closed the deal, not the one that actually started the buyer's journey. The agent isn't wrong. The attribution architecture underneath it is. And if that agent is informing where your next acquisition dollar goes, you're now systematically overpaying for the wrong channel while starving the one that actually works, in a way your dashboard won't show you because it's reading the same broken data.

That same blind trust in bad inputs doesn't stay contained to a single agent. It shows up again the moment two teams try to run one funnel together instead of two.

Related: what a revenue leak actually is

Is PLG or SLG the right motion, and why does picking one over the other quietly inflate your CAC?

Neither PLG nor SLG alone is the right motion for most B2B SaaS companies. The costly mistake is running both without unifying the data model behind them.

A founder I spoke with this week is building a Product-Led Growth motion almost entirely out of his own sales conversations. He's not wrong to lean on that experience, but without having built a PLG engine before, it's easy to develop tunnel vision on what "good" looks like. It reminds me of marketers applying a B2B playbook to a B2C product: the fundamentals of marketing don't change, but buyer behavior, channel mix, and conversion mechanics absolutely do. PLG isn't your sales funnel with the salesperson removed. It's a different mechanism entirely.

This is where RevOps and Marketing Ops teams get stuck, forcing a binary choice between SLG and PLG when the better path is a hybrid. At Semrush, we ran a mature PLG motion where Marketing owned the journey from visitor to first payment, while Sales focused on expansion, relationship management, and reducing churn. It let sellers spend their time where humans actually create value, instead of chasing every trial signup.

Looking back, though, we never fully unified the PLG and SLG data models. One of PLG's biggest weaknesses is that "Engage" becomes a catch-all stage, even though that's exactly where the richest signal lives: which product someone used, how long they spent inside it, whether they came back after day one, whether they invited teammates, whether they explored multiple products. Nearly 90% of free trials end after a single login, and if all engagement gets treated the same, you can't tell why the ones that convert actually converted, or where the rest disappeared. SLG, by contrast, naturally produces more intent signal through proposal activity, stakeholder expansion, and procurement involvement, exactly the operational granularity PLG tends to lack.

Here's the CAC connection. If Marketing is running a PLG motion and Sales is running a parallel SLG motion, and neither is reading off the same stage definitions, you get two teams independently spending money to influence the same prospect (Marketing nurturing a free-trial user Sales has also started calling, unaware Marketing already has that motion covered). That's duplicated acquisition spend against the same account, invisible until someone reconciles both funnels line by line. The fix isn't choosing PLG or SLG. It's Marketing, Product, Sales, and Customer Success aligning on the same stage definitions and intent signals, so you have one revenue engine instead of four teams optimizing four different versions of the truth.

That same lack of shared ownership over data is exactly what breaks down when you hand decision-making authority to an agent instead of a person.

Related: conversion rate optimization, defined

Who owns the decision when an AI agent acts on your revenue systems?

Trust in AI agents isn't earned through better models. It's earned through defined authority boundaries: who owns the decision, what requires human sign-off, and where accountability sits when an agent acts on its own.

The real bottleneck for AI agent adoption isn't intelligence, it's institutional trust. It's hard to make the case for autonomy when your most senior employee still has to do due diligence work just to verify the agent's output is accurate. I see this constantly: teams deploy agents to update CRM records or trigger outreach sequences without defining which fields are off-limits, who approves changes to attribution logic, or what happens when conflicting data sources disagree. The agent executes confidently. The revenue team loses trust in the system overnight, because nobody set the authority rules before handing over the keys.

Authority answers who's allowed to act. It doesn't answer whether you can prove what they actually did afterward.

Related: what AI readiness actually means

Can you actually audit what your agents are doing across your stack?

Most teams measure agents by usage and token spend, which tells you your agents are busy. It doesn't tell you what they're actually doing inside your workflows.

The question I get asked about AI agents changed this summer. It used to be "which agents should we build?" Now it's "how much autonomy can we actually allow?" Governance isn't a compliance layer you bolt on after deployment, it's part of the implementation itself, and the teams treating it that way are the ones actually scaling.

Usage and token spend numbers tell you your agents are active. They don't tell you what those agents are doing inside your actual workflows, and very few stacks are built for that kind of visibility. Google Cloud is packaging agent development, testing, and governance into one operating flow with Google Gemini Enterprise. HubSpot's Agent Hub gives GTM teams shared context and execution logs. Tines is treating access controls and credential protection as prerequisites for employee-built workflows. Three vendors landing on the same requirement at the same time isn't a coincidence.

The costly pattern I keep seeing: teams spin up agents across Salesforce, HubSpot, and their support stack with no shared business rules. Each agent works fine in isolation. Together, they recreate the exact silos they were supposed to remove. Then a CFO asks what the agents did last quarter, and nobody can produce a log. Every agent action you can't explain is a liability sitting inside your GTM stack, and liabilities eventually get paid for, usually as rework, lost trust, or a deal that stalls because nobody can explain why a record changed. None of that shows up as a line item labeled "CAC," but it's absorbed into the same budget that's supposed to be getting you customers efficiently.

None of this matters, though, if the person deciding where to point these agents in the first place doesn't have the judgment to say no.

Related: the hidden SaaS tax on your stack

Should a GTM Engineer let AI touch every workflow, or is judgment still the job?

The best GTM Engineers I've worked with are the ones who know when NOT to add AI. That's the actual differentiator right now, not how many agents someone has shipped.

That sounds backwards in 2026, but hear me out. Ask ten organizations what "GTM Engineer" means and you'll get three or more different answers: outbound sales orchestration, RevOps and data architecture, systems builder and generalist, end-to-end reporting owner, or AI-native infrastructure lead. Companies post one title, and most candidates walk through the door expecting to run everything and get things done. What most companies actually need is someone with enough technical judgment to look at a workflow and say this one shouldn't touch an agent.

It's not uncommon to get sold on one set of responsibilities during the interview, then get the bait-and-switch once you're in the seat, expected to absorb whatever slack shows up regardless of the cost to you. Companies are downsizing heavily in 2026 and rewarding "team players" no matter what that costs someone physically or mentally, which is part of why people quit roles before the right infrastructure ever got built.

Judgment matters right now because Pathlock's recent survey found 53% of organizations can't fully verify what their AI agents are doing across business systems, and 79% have no dedicated AI governance team, while agents are simultaneously approving transactions and changing vendor records. Every agent instance is a stack of decisions: which fields it can read, which systems it can write to, whose credentials it runs on, what gets logged, when a human has to approve, and how you roll it back when it misfires. Skip those decisions and you've built a workflow nobody can review or explain.

One practical note I give every team I work with: read the fine print on your vendors. "Your data is yours" and "data is wiped after results are produced" answer one narrow retention question. They don't tell you what happens to usage logs, prompt context, your company identity, or sub-processor access. Get those answers in the actual contract (MSA, DPA, purchase order), not whatever marketing or an AE told you on a call. And a GTM Engineer should never be the sole owner of privacy and legal decisions, that has to be shared across GTM Engineering, legal, security, and procurement, or the gaps stay invisible until an agent does something nobody can explain.

Related: what belongs in a modern GTM stack

What do these five patterns actually cost you in CAC?

Each pattern above chips away at CAC in its own specific way. Lined up together, they tell the same story: efficiency erodes quietly until someone finally adds it up.

• Data governance: An agent will act confidently on data no human would trust if they were making the call. The result: acquisition spend gets misrouted toward whichever channel or field looks cleanest, not the one actually working, and the dashboard can't catch it because it's reading the same bad data.
• PLG vs. SLG: Without one shared data model, Marketing and Sales can each be doing their job well and still be paying twice for the same prospect. The result: duplicated acquisition spend against the same account that stays invisible until someone reconciles both funnels by hand.
• Agent authority: Trust breaks the moment an agent acts and nobody can say who approved it. The result: every hour spent unwinding an unauthorized change is an hour pulled away from the acquisition or retention work that actually moves CAC.
• Agent auditability: Usage metrics tell you agents are busy, not what they actually did. The result: unexplainable actions become liabilities that eventually get paid for in rework, stalled deals, or lost trust, quietly absorbed into the GTM budget.
• GTM Engineer judgment: The highest-value call is often knowing where not to deploy AI at all. The result you avoid: the mistakes this prevents never show up as a savings line. They just show up as a CAC that didn't get worse.

What's this week's move?

Pull up the single AI agent or automated workflow your GTM team relies on most right now (the one touching your CRM, your outreach sequences, or your attribution data). Write down three things: who owns approval for what it changes, what fields or systems are explicitly off-limits to it, and where the audit log actually lives. If you can't answer all three today, that gap is a hidden line item inside your CAC, whether you're tracking it that way or not.

Want a scored version of that exercise? Run the free AI Readiness Assessment — it walks the same governance, data, and ownership questions across your stack and hands back where the gaps are.

Have a workflow, metric, or mistake you want broken down in a future issue? Reply to this email or send me a DM on LinkedIn.