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

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

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