# Martech Stack Audit

> Use when the user says "audit our stack", "too many tools", "martech spend", "tool consolidation", "what should we cut", "renewal coming up", "our stack is too expensive", "do we need this tool", "CFO wants cuts". Inventories the stack, computes spend against revenue, finds redundancy and dead weight, and returns a KEEP / CONSOLIDATE / CUT / ADD verdict per tool with a defensible savings number. Writes workspace/stack/stack-audit.md.

- Skill: `guerrilla2799/martech-stack-audit` (Agent Skill)
- Install (CLI): `npx skillmds@latest add guerrilla2799/martech-stack-audit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/guerrilla2799/martech-stack-audit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: guerrilla2799 (https://skillmd.com/u/guerrilla2799)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/guerrilla2799/martech-stack-audit

---


# Martech Stack Audit

Inventory, price, and rule on every tool. Stack sprawl is an accumulation of individually defensible decisions, so only a portfolio-level review catches it.

## When to use
- Budget pressure, or a CFO asking questions
- Any renewal above a threshold worth caring about
- Annual planning
- Before adding a tool, to test whether the gap is real

## Inputs
- Needs from user: every tool with its annual cost and renewal date, seat counts against seats used, ARR, and who owns each contract
- Reads: `workspace/audit/systems-audit.md`

Ask for all of it in one batch. Finance usually has a cleaner list than marketing does, and the gap between the two lists is itself a finding.

## Workflow

### 1. Build the true inventory

Include the things nobody counts: tools on a credit card, tools inside another tool's bill, per-seat tools with unused seats, and anything auto-renewing that nobody owns.

```
Tool | Category | Annual cost | Renewal date | Seats bought | Seats used | Owner | What it does that nothing else does
```

The last column is the one that produces the verdict. If it cannot be filled in with a specific capability, that is the answer.

### 2. Compute the ratio

```
Stack spend to revenue = total annual martech spend ÷ ARR
```

| Ratio | Reading |
|---|---|
| Under 4% | Possibly under-tooled, check for manual work that should be automated |
| 4 to 8% | Healthy band at growth stage |
| 8 to 12% | Elevated. There is usually real redundancy |
| Over 12% | Needs a consolidation plan, not a trim |

This is a directional benchmark, not a law. A product-led company with heavy usage-based tooling sits higher for structural reasons.

### 3. Find the four kinds of dead weight

**Redundancy.** Two tools doing the same job. Usually the result of a team buying around an unconfigured feature they already own.

**Glue.** Tools whose primary purpose is moving data between two other tools. Each one is evidence of a seam that was patched rather than fixed. They also add a sync, which adds a place for records to diverge.

**Definitional purchases.** Tools bought to solve a reporting disagreement. A warehouse will let two dashboards disagree faster and at higher resolution. Check whether the problem was ever technical.

**Underutilization.** Seats bought against seats used, and tier bought against consumption. This kills more contracts than any other finding, and nobody checks because the invoice is a fixed line item.

### 4. Apply the add test before any new purchase

```
State the structural reason the existing layer cannot do this.
  If the answer is "it is not configured"     → not a purchase
  If the answer is "nobody was trained on it" → not a purchase
  If the answer is "it genuinely cannot"      → proceed to evaluation
```

Most purchases fail this test, and asking it takes five minutes.

### 5. Rule on every tool

| Verdict | Meaning |
|---|---|
| **KEEP** | Does something nothing else does, and is used |
| **CONSOLIDATE** | Capability exists elsewhere. Migrate and cancel, with a named date |
| **CUT** | Not used, or the job is no longer worth doing |
| **DOWNGRADE** | Right tool, wrong tier. Utilization says so |
| **ADD** | A genuine capability gap that passed the add test |
| **HOLD** | Cannot decide yet. Name what evidence would decide it and when |

Every verdict carries a dollar figure and a date. A verdict with neither is an opinion.

### 6. Sequence the cuts by renewal date

Cancellations are easy at renewal and expensive mid-term. Sort the plan by renewal date and put a diary item sixty days before each one, because the week-of conversation always ends in an auto-renewal.

### 7. Present the savings honestly

```
Gross annual savings          $n
Migration cost, one-time      $n   (including the hours)
Net year-one savings          $n
Net ongoing annual savings    $n
Capability lost               <name it, or state none>
```

**Name the capability lost.** An audit claiming savings with no losses reads as unserious to anybody who has run a migration, and it is the fastest way to have the whole plan dismissed.

## Output
- Writes: `workspace/stack/stack-audit.md`, `workspace/stack/inventory.csv`
- Uses: `templates/stack-inventory-template.csv`
- Prints: the inventory, the ratio against the band, the four dead-weight findings, the per-tool verdicts with dollars and dates, the renewal-sequenced plan, and the honest savings table

## Rules & quality bar
- **Include the tools nobody counts.** Credit cards, unused seats, auto-renewals with no owner
- **Every tool answers "what does this do that nothing else does"**
- **Check utilization on every seat-based and credit-based tool**
- **Run the add test before recommending any purchase**
- **Every verdict has a dollar figure and a date**
- **Sequence by renewal date,** with a sixty-day diary item
- **Name the capability lost.** Always
- **Never recommend a tool to solve a definitional problem.** Route to `reporting-architecture`

## Related skills
- Pairs with: `credit-and-cost-control` for usage-based spend
- Routes to: `reporting-architecture` when the problem is definitional, `data-model-and-sync` when it is a seam
- See also: `docs/stack.md`, `docs/field-notes.md` story 12