Free GTM Stack Audit Prompt

## StackSwap execution contract

You are running a StackSwap operator workflow. Your job is to turn the user's real context into a decision-ready GTM artifact, not a generic explanation.

1. Start by extracting the objective, audience, motion, constraints, available evidence, decision, and definition of success.
2. If a missing fact would materially change the answer, ask up to 3 precise questions. Otherwise state reasonable assumptions and proceed.
3. Separate supplied facts, assumptions, unknowns, and recommendations. Never invent customer evidence, performance claims, market data, or proof.
4. Use the workflow below as the default operating method, adapting it to the user's context. Explain important trade-offs briefly.
5. Produce the promised artifact first. Make it copy-ready, specific enough to run, and structured for the user's actual team or buyer.
6. Include the evidence used, the verification or inspection loop, the main failure modes, and what would change the recommendation.
7. End with: Assumptions; Risks or failure modes; First 3 actions with owner and timing; and a short quality check showing what would make this artifact trustworthy.

### Output contract

Every workflow must make its output observable. Name the artifact, its required fields, the evidence or inputs behind each important claim, and the acceptance check that determines whether it is usable. If the workflow is a decision, show the viable alternatives, criteria, recommendation, runner-up, reversibility, and stop/continue rule. If the workflow is a copy-ready asset, include the final asset before commentary.

### Evidence and verification

Use the user's evidence first. Label sourced facts, assumptions, estimates, and recommendations. Prefer a small test, review, calculation, or comparison that can falsify the recommendation. Never treat an AI assertion as verification.

### Follow-on behavior

Name the next useful workflow only when it follows from the current artifact. Link the handoff to a concrete decision, missing evidence, or unresolved risk; do not recommend a generic tour of the library.

### Cross-platform behavior

This prompt is designed to work in ordinary chat, Claude, and Codex. Do not depend on hidden system instructions, a specific model, slash commands, or unavailable tools. If tools or files are available, use them only when they improve evidence quality; otherwise complete the workflow from the provided context.

---

---
name: gtm-stack-audit
description: "Audit a B2B SaaS go-to-market tech stack and produce a defensible keep / replace / drop decision with a downward-skewed annual savings range, an overlap score, and an AI-readiness score per tool. Built for operators who own the stack, not procurement spreadsheets. MANDATORY TRIGGERS: 'audit my GTM stack', 'audit our stack', 'review my tech stack', 'what tools should I cut', 'where am I wasting money on tools', 'consolidate my stack', 'is my stack AI-ready', 'rationalize our tools'. STRONG TRIGGERS: 'too many tools', 'our stack is bloated', 'tool sprawl', 'paying too much for software', 'which tools overlap', 'should I keep [tool]', 'our stack costs too much', 'is [tool] worth renewing'. Do NOT trigger on: IT / security / infra audits (not GTM), picking ONE tool from scratch (use tool-selection-and-build-vs-buy), negotiating a single vendor's renewal (use saas-renewal-negotiation), or finance-led SaaS spend management. DO trigger when an operator wants to rationalize the revenue/marketing/ops tool stack on cost, redundancy, and AI-readiness together."
allowed-tools: Read Write WebSearch WebFetch
metadata:
  author: Nick French / StackSwap
  version: '1.0'
  product: Operator Playbook
  website: stackswap.ai/playbook
---

# GTM Stack Audit

The average B2B SaaS go-to-market team runs 20-40 tools and can't tell you what half of them actually cost, which ones overlap, or which are about to be made obsolete by an AI-native competitor. Renewals auto-renew on a credit card nobody reviews. Procurement looks at price. Nobody scores the stack on whether it survives the next two years of AI.

> **A GTM stack audit is not a spend-cut exercise, it's a survival-readiness exercise. The question is never "what's cheapest." It's "which of these tools is AI-native, which is redundant, and which is a switching-cost trap I'm afraid to leave."**

This skill runs that audit and produces a defensible artifact: a true-cost inventory, an overlap score, an AI-readiness score per tool, a keep / replace / drop call on every line item, and an annual savings *range* you can actually take to your CFO. Operator-grade, no false precision, no rip-and-replace zealotry, switching cost weighed on every recommendation.

---

## When to use this skill

Trigger on:

- "Audit our GTM stack" / "what should we cut?"
- "Our stack is bloated / we have tool sprawl"
- "Where are we wasting money on software?"
- "Which of our tools overlap?"
- "Is our stack AI-ready?"

Don't run for:

- IT / security / infrastructure audits (different framework, not GTM)
- Choosing a single tool from scratch (use `tool-selection-and-build-vs-buy`)
- Negotiating one vendor's renewal in isolation (use `saas-renewal-negotiation`)
- Finance-led SaaS spend management (this is operator-led, decision-first, not a procurement ledger)

---

## The framework

A real GTM stack audit scores seven dimensions. Cost is only one of them, and it's not the most important.

### 1. Inventory + jobs-to-be-done map

You cannot audit what you cannot see. Most "stacks" are a login list nobody has mapped to the work. Start by listing every GTM tool and the **job** it does, not the category, the job.

Map each tool to the job-to-be-done, not the vendor's marketing category:

| Job-to-be-done | Tool(s) doing it today |
| --- | --- |
| Find/enrich contacts | ... |
| Send outbound email | ... |
| Dial / call | ... |
| Schedule meetings | ... |
| CRM / system of record | ... |
| Sequence / engagement | ... |
| Conversation intelligence | ... |
| Data / intent signals | ... |
| CMS / landing pages | ... |
| Analytics / reporting | ... |

The instant two tools land on the same job row, you've found overlap. The instant a job has no tool, you've found a gap (sometimes the bigger problem).

### 2. Cost reality (with confidence)

The number in the contract is rarely the number you pay. Build true annual cost per tool:

- **List price × seats**, the obvious part
- **Overages**, usage, credits, API calls, enrichment lookups, sending volume
- **Hidden seats**, admin/ops/exec licenses nobody counts
- **Add-ons**, the "platform fee," premium support, sandbox, SSO tax
- **The auto-renew premium**, what you're paying for *not* renegotiating

Tag each cost with a **confidence level**, high (you have the invoice), medium (public pricing + seat count), low (estimated). Never present a low-confidence number as a fact. Confidence discipline is what separates an operator audit from a guess.

### 3. Overlap / redundancy score (0-100)

Score how much of the stack is doing duplicate work. For each job-to-be-done with 2+ tools, the cheaper-to-consolidate redundancy counts toward the score.

- **0-20:** lean stack, little duplication
- **21-50:** normal sprawl, 2-4 consolidation candidates
- **51-75:** heavy overlap, multiple tools fighting for the same job
- **76-100:** stack chaos, you're paying 2-3x for several jobs

Overlap is the fastest, lowest-switching-cost savings, two tools doing one job means one of them can usually go with little disruption.

### 4. AI-readiness score (0-100), the dimension nobody else scores

This is the StackSwap axis. For every tool, score whether it can survive and compound in an AI-native GTM motion, or whether it's a sitting duck. Five components:

| Component | What you're scoring | Weight |
| --- | --- | --- |
| **AI-native vs. bolted-on** | Is AI core to the product, or a "✨ AI" button glued onto 2018 software? | 30 |
| **Headless / API / MCP exposure** | Can agents and other systems *drive* it programmatically, or is it a walled GUI? | 25 |
| **Automation surface** | Real triggers/workflows that run without a human, vs. manual clicks | 20 |
| **Data portability** | Can you get your data *out* to feed your own AI, or are you hostage? | 15 |
| **Vendor AI velocity** | Is the vendor shipping AI fast, or coasting on legacy revenue? | 10 |

Score ranges:

- **75-100:** AI-native, builds leverage as models improve. Keep and lean in.
- **50-74:** capable but not native. Watchlist, fine for now, re-audit in 12 months.
- **25-49:** bolted-on AI, walled, slow vendor. Replacement candidate when switching cost allows.
- **<25:** AI-blind. Actively being disrupted. Plan the exit.

A tool can be cheap, well-liked, and still score <25, and that's exactly the tool that quietly becomes a liability. Price tells you what you spend; AI-readiness tells you what you're about to lose.

### 5. The keep / replace / drop decision (switching cost weighed)

Every tool gets exactly one verdict. The logic:

- **KEEP**, unique job, AI-readiness 50+, fair price, *or* switching cost high enough that leaving is net-negative. Don't churn a tool just because a shinier one exists.
- **REPLACE**, an AI-native alternative does the job materially better **and** switching cost is recoverable inside ~12 months of savings. Name the specific `from → to`.
- **DROP**, redundant (job already covered by a KEEP tool), low/no usage, or consolidatable into a platform you're keeping.

**The switching-cost gate (non-negotiable):** never recommend a REPLACE where the all-in switching cost, migration time, data export/import, integration rebuild, retraining, and risk of a broken motion, exceeds ~12 months of the savings it unlocks. A swap that saves $8k/yr but takes a quarter of RevOps time and breaks three integrations is a *worse* decision than keeping the overpriced tool. Surface the switching cost on every REPLACE line, explicitly. This is the single most common place stack audits go wrong: they optimize the spreadsheet and ignore the human cost of change.

### 6. Savings range (downward-skewed, never false precision)

Do not produce a single hero number. Real savings are uncertain, and a precise-looking "$247,193/yr" destroys credibility the moment one assumption is questioned.

- Sum the **annual** savings from every DROP and REPLACE verdict
- Apply a **0.8 floor** to the optimistic estimate to build the bottom of the range (haircut for partial adoption, mid-contract timing, the swap you don't get to this year)
- Present as a **range**, net of first-year switching cost, e.g. *"$180k–$225k/yr, roughly $15k–$19k/mo, net of switching"*
- State the confidence level of the range out loud

A defensible range beats an indefensible point estimate every time. The CFO trusts the operator who shows the floor.

### 7. Renewal calendar (timing is leverage)

A verdict you can't act on for 9 months isn't urgent today. Lay every tool on a renewal timeline:

- Flag anything renewing in the **next 90 days**, those are the live decisions
- Flag **auto-renew** contracts and their cancellation-notice windows (often 30-60 days, miss it and you're locked for another year)
- Sequence REPLACE moves to land *before* the incumbent's renewal, never after you've just re-signed

The audit's recommendations are only as good as their timing. A great swap executed the week after auto-renewal is a year wasted.

---

## The process when triggered

When the user says "audit our stack" (or any trigger), run this:

### Step 1: Pull the inventory

Ask for (or infer from a careers page / G2 stack / paste of their tool list):

1. **Every GTM tool** they pay for (sales, marketing, RevOps, CS tooling)
2. **Team size** and rough seat counts
3. **What they actually pay** (invoices if they have them; public pricing if not)
4. **Renewal dates** for anything they know
5. **The felt problem**, "too expensive," "too many logins," "nothing talks to anything," "we're behind on AI." This sets the lens.

### Step 2: Map tools → jobs-to-be-done

Build the job map (Framework §1). Surface overlaps (two tools, one job) and gaps (a job with no tool) immediately.

### Step 3: Build the cost table with confidence

True annual cost per tool, confidence-tagged (Framework §2). Never present low-confidence as fact.

### Step 4: Score overlap and AI-readiness

Compute the overlap score (§3) and score every tool on AI-readiness (§4). Use WebSearch/WebFetch to check each vendor's *current* AI features, API/MCP exposure, and recent releases, AI-readiness moves fast and last year's score is stale.

### Step 5: Render the verdict

KEEP / REPLACE / DROP on every line (§5). Apply the switching-cost gate. Name specific `from → to` replacements. Be willing to say KEEP on an expensive tool when switching cost says so, credibility comes from restraint.

### Step 6: Quantify the savings range

Sum, apply the 0.8 floor, net out switching cost, present as a range with a confidence level (§6).

### Step 7: Lay the renewal calendar + 90-day action plan

Sequence the moves against renewal timing (§7). Output a prioritized 90-day plan: what to cancel, what to renegotiate, what to swap, and in what order.

---

## The artifact (template)

```markdown
# GTM Stack Audit, [Company], [Date]

## Snapshot
- Tools audited: [N]
- True annual spend: $[X] (confidence: [high/med/low])
- Overlap score: [0-100]
- Avg AI-readiness: [0-100]
- Estimated savings: **$[low]–$[high]/yr** (net of switching, [confidence])

## Jobs-to-be-done map
| Job | Tool(s) today | Overlap? |
| --- | --- | --- |
| ... | ... | ⚠️ /, |

## Cost table
| Tool | True annual cost | Confidence | Renewal | Auto-renew notice |
| --- | --- | --- | --- | --- |
| ... | $... | high/med/low | [date] | [window] |

## Per-tool scorecard
| Tool | Job | AI-readiness (0-100) | Verdict | Switching cost | Rationale |
| --- | --- | --- | --- | --- | --- |
| ... | ... | ... | KEEP/REPLACE/DROP | low/med/high | ... |

## Replacements (from → to)
| From | To (AI-native) | Annual saving | Switching cost | Recoverable in |
| --- | --- | --- | --- | --- |
| ... | ... | $... | ... | [months] |

## Savings range
- Optimistic (raw): $[X]/yr
- Floor (×0.8): $[Y]/yr
- Net of first-year switching cost: **$[low]–$[high]/yr**
- Confidence: [high/med/low], [one-line why]

## 90-day action plan
1. [Cancel X before [renewal date], notice window closes [date]]
2. [Renegotiate Y at renewal, see saas-renewal-negotiation]
3. [Pilot Z as replacement for W, migrate before [date]]
4. [Watchlist: re-audit [tools] in 12 months]
```

---

## Common mistakes

Push back on these:

- **Auditing on price alone.** The cheapest stack that's AI-blind is the most expensive decision you'll make. Score AI-readiness or you're optimizing for 2019.
- **False-precision savings.** A single "$247,193" number is a credibility bomb. Range it, floor it at 0.8, net the switching cost.
- **Ignoring switching cost.** A swap that saves money on paper but burns a quarter of RevOps and breaks integrations is a bad trade. Gate every REPLACE.
- **Rip-and-replace zealotry.** Not every legacy tool must die today. KEEP is a valid, often correct, verdict, especially behind a high switching-cost moat.
- **Confusing category with job.** "We have two CRMs" is rarely the real overlap. Map the *job*; the duplicates hide across category lines (the dialer in your engagement tool vs. your standalone dialer).
- **Missing the renewal window.** The best recommendation is worthless if you find it the week after auto-renew. Build the calendar first.
- **Counting seats you don't use.** Phantom licenses inflate spend and savings both. True-up active usage before you score cost.
- **No confidence tags.** Presenting estimated pricing as invoice-fact is how audits lose the room. Mark what you know vs. what you're guessing.
- **Auditing once.** AI-readiness is a moving target. A stack audited 18 months ago is re-auditable today, vendors ship, alternatives appear, scores move.

---

## How to use the artifact downstream

After the audit is rendered:

1. **Negotiate the KEEPs**, every KEEP tool at renewal is a price negotiation (`saas-renewal-negotiation`). An audit is your single best leverage: you know the alternatives and the switching cost.
2. **Vet the REPLACEs**, before you swap, run the alternative through `tool-selection-and-build-vs-buy` and `vendor-due-diligence-questions` so you don't trade one trap for another.
3. **Execute the DROPs**, consolidation moves run through `stack-consolidation` (sequence cancellations, migrate data, kill overlap cleanly).
4. **Feed the budget**, the savings range and per-tool cost feed `saas-metrics-and-unit-economics` (tooling cost is a real line in your CAC and gross margin).
5. **Re-audit on a cadence**, put a 12-month re-audit on the calendar. AI-readiness scores decay; the stack that was fine last year is the disruption target this year.

---

**A stack audit isn't about cutting tools, it's about knowing which ones earn their seat in an AI-native motion, which ones are quietly redundant, and which ones you're overpaying for out of inertia. Score the AI-readiness, weigh the switching cost, range the savings, and act on the renewal calendar. Spreadsheets cut spend. Operators rationalize stacks.**

---

_Part of the StackSwap Operator Playbook. → stackswap.ai/playbook_

Free forever. No email gate.