Auditing gtm AI Stack

• Source: Report research library
• Frameworks applied: Capability-bucket overlap mapping, system-of-record data-flow tracing, three-tier evidence grading (study / vendor study / assertion), shadow AI census, buy-versus-build test

The three-tier evidence discipline (Study / Vendor study / Assertion) with named confounds is a genuinely non-obvious constraint that changes agent behaviour.

Known weakness, published as found: Add explicit freedom signalling: the keep/consolidate/kill rules are stated as fixed but the scoring of the four axes is judgment, and neither is labelled. Move the two-paragraph MIT/Deloitte framing section behind a reference link so it does not load on every invocation.

1. 1.Copy the SKILL.md text below, or download the raw file.
2. 2.Create a folder named exactly auditing-gtm-ai-stack in your agent's skills directory.
3. 3.Save the file inside that folder as SKILL.md.
4. 4.Ask the agent one of the trigger requests below.
5. 5.Check the output against what you already know before it leaves your desk.

• We have eleven AI tools across sales and marketing and nobody can prove any of them work - run an audit
• Which of our AI vendors should we consolidate or kill before renewal season?
• Finance is asking me to justify our AI spend, help me build the case per tool

• Design a pilot for AI-generated cold email with a human control group
• Write an agentic workflow spec with human checkpoints for our renewal motion

---
name: auditing-gtm-ai-stack
description: >-
  Audits an existing go-to-market AI tool portfolio for capability overlap, data-flow breaks,
  real adoption, and measurable revenue value, then issues a keep / consolidate / kill decision
  per tool with a consolidation sequence. Use when the user says GTM AI stack audit, tool
  rationalization, "we have too many AI tools", "which AI tools should we cut", "nobody uses
  the AI features we bought", "prove ROI on our AI spend", shadow AI, overlapping AI vendors,
  renewal review for AI tools, or asks whether to buy another AI point solution. Use this skill
  whenever the task involves judging whether already-purchased GTM AI is earning its cost, even
  if the user calls it a stack review. Do NOT use for piloting a new AI outbound program (see
  deploying-ai-sdr-programs), for designing agent workflows and human checkpoints (see
  designing-agentic-revenue-workflows), or for answer-engine content visibility (see
  optimizing-for-ai-search).
metadata:
  version: "1.0"
---

# Auditing a GTM AI stack

One job: inventory every AI-touching tool in the revenue stack, score each on overlap, data flow, adoption, and measured value, and output a defensible keep / consolidate / kill decision per tool. Contract negotiation, security review, and net-new vendor selection are out of scope.

## Framing the audit before you open a single dashboard

Anchor the conversation on two findings, because both reset what "our AI works" is allowed to mean.

- MIT NANDA found **95% of enterprise AI pilots deliver no measurable P&L impact**, on 150 leader interviews, a 350-employee survey, and analysis of 300 public deployments; **more than half** of GenAI budgets go to sales and marketing tools ([Fortune](https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/)). The diagnosed cause is a "learning gap" — tools that do not learn from or adapt to the workflow — not model quality or regulation. The same research names **shadow AI** (unsanctioned tool use) as a widespread enterprise condition, so treat an unsanctioned-tool census as part of the inventory rather than an afterthought.
- Purchase-versus-build evidence from the same study: buying from specialized vendors plus building partnerships succeeded **~67%** of the time, while internal builds succeeded **one-third as often** ([Fortune](https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/)). Use this to kill in-flight internal rebuilds of purchased capability, which is a common finding in this audit.

Maturity context for the read-out: **54% piloting / 31% scaling / 15% realizing** measurable outcomes, on 453 director-plus respondents at US companies with 500+ employees and $250M+ revenue ([Deloitte Digital](https://www.deloittedigital.com/us/en/insights/perspective/accelerating-b2b-sales-agentic-ai.html)). Place the organization on that distribution explicitly, because most stacks under audit are a pile of pilots being reported as a platform strategy.

## Workflow

Copy this checklist into your reply and tick items as you complete them:

```
- [ ] 1. Build the inventory, including shadow AI
- [ ] 2. Map capabilities to a fixed taxonomy and find overlap
- [ ] 3. Trace data flow and identify the system of record per object
- [ ] 4. Measure real adoption, not seat count
- [ ] 5. Test each value claim against evidence tiers
- [ ] 6. Score, validate the scoring, fix, re-validate
- [ ] 7. Issue keep / consolidate / kill with a sequenced consolidation plan
```

**1. Build the inventory.** For every tool, record: vendor, annual cost, seats purchased, contract end date, owner, and the AI capabilities actually enabled. Pull three sources and reconcile: finance's vendor ledger, the CRM/marketing app marketplace connection list, and an expense-report or SSO scan for shadow AI. Named-tool lists from the AI-tool market change constantly, so classify by capability rather than by brand, because a brand-keyed audit goes stale the moment a vendor ships a new module.

**2. Map to a fixed taxonomy and find overlap.** Use these capability buckets and place every tool in one or more:

`data enrichment` · `intent/signal detection` · `outbound sequencing and AI email generation` · `conversation intelligence and coaching` · `forecasting and pipeline inspection` · `content generation` · `CRM hygiene and data ops` · `chat/qualification` · `agent orchestration`

Flag overlap where two or more tools occupy the same bucket for the same team. Overlap alone is not a kill signal; overlap plus a divergent data model is, because two tools writing the same object with different definitions creates reconciliation work that consumes more time than either tool saves.

**3. Trace data flow.** For each bucket, name the system of record, the write direction, the sync frequency, and whether the AI tool reads a full history or a narrow API slice. Then find the breaks. The MIT learning-gap finding predicts the common failure: a tool that cannot see the workflow's history cannot adapt to it, so a tool with read-only access to a 90-day API window will underperform its demo indefinitely regardless of spend.

**4. Measure real adoption.** Seat count is not adoption. Collect per tool, over a trailing 90-day window at minimum:

- Weekly active users as a share of licensed seats.
- Share of eligible objects touched (for example, share of calls actually processed, share of sequences using AI drafts).
- Depth signal: edit rate on generated output, or acceptance rate on recommended actions.
- Manager usage separately from rep usage. MIT's stated success factors include empowering line managers rather than relying on a central AI lab, so a tool with rep usage and zero manager usage is unlikely to convert to outcome.

Under 30% weekly active on licensed seats after 90 days is a consolidation candidate regardless of how well the tool demos, because the fixed cost is paid on seats and the value accrues only on use.

**5. Test each value claim against evidence tiers.** Sort every claimed benefit into one of three tiers and label it in the output:

- **Study** — named research organization, stated sample, stated method. Example usable in this audit: AI/ML-assisted forecasting runs **±8–15% variance** against **±25–35%** for rep roll-up, **±18–25%** weighted pipeline, and **±15–20%** historical trend, on **N=939** companies over Q1–Q3 2025, read as a 15–25% improvement ([Optifai via Prospeo](https://prospeo.io/s/ai-sales-forecasting-accuracy)). Use this as the defensible bar for any forecasting tool in the stack.
- **Vendor study** — real dataset, vendor's own customer base, unquantified selection effects. Gong Labs reports **+50% win rate** when teams complete all AI-recommended to-dos, **+35%** with deal-guiding Smart Trackers, and **+26%** when using Ask Anything on a deal, across more than **1M opportunities** at **1,418 organizations** ([Gong](https://www.gong.io/blog/we-measured-the-roi-of-ai-in-sales-heres-how-it-really-impacts-your-deals)), and **77% more revenue** for frequent AI users across **7.1M opportunities** ([Gong](https://www.gong.io/blog/the-best-sales-insights-of-2025)). State the confound out loud: the comparison is AI-used versus AI-not-used deals inside AI-adopting organizations, which controls for company but not for rep or deal quality, so "reps who complete all action items win more" is partly a diligence measure. Use as adoption-correlation evidence, never as causal ROI in a business case.
- **Assertion** — no sample, no method. Discard. Any vendor claiming forecast accuracy above 90% belongs here: only **7%** of sales organizations reach 90% forecast accuracy at all (Gartner, cited by [Prospeo](https://prospeo.io/s/ai-sales-forecasting-accuracy)), and XANT Labs' analysis of **270,912 closed-won opportunities worth $18.1B** found only **28.1%** closed within 5% of the 90-day forecast, with **47%** off by more than half and average 90-day error above **31%** ([Prospeo](https://prospeo.io/s/ai-sales-forecasting-accuracy)). A 95%-accuracy claim is measuring quarter-level attainment or selling.

**6. Score, validate, fix, re-validate.** Score each tool 1–5 on four axes: `unique capability`, `data integration depth`, `adoption`, `evidence-backed value`. Then run this validation before writing any decision:

```
CHECK 1  Every tool has a cost figure and a contract end date        PASS/FAIL
CHECK 2  Every capability bucket has exactly one system of record    PASS/FAIL
CHECK 3  Every adoption number cites a source and a window           PASS/FAIL
CHECK 4  No value claim is carried at Assertion tier                 PASS/FAIL
CHECK 5  Kill list total <= documented replacement coverage          PASS/FAIL
```

On any FAIL, gather the missing input or downgrade the claim, then re-run all five checks. Only issue decisions when all five pass, because a kill recommendation resting on an unsourced adoption number is the fastest way to lose the audit's credibility with the tool's owner.

**7. Issue decisions and sequence the consolidation.** Decision rules, applied in order:

- **Kill** — no unique capability, adoption under 30% weekly active, and no Study- or Vendor-study-tier value. Sequence kills to contract end dates, because mid-term terminations rarely refund.
- **Consolidate** — capability duplicated by a tool that scores higher on data integration depth. Name the surviving tool, the migrating object, and the workflow that must be rebuilt.
- **Keep** — unique capability with adoption above 30% weekly active, or a Study-tier value claim, or system-of-record status.
- **Keep and instrument** — plausible value with no measurement in place. Attach one metric and one review date; without them this bucket becomes a permanent renewal.

Prefer consolidating onto anchor platforms already owned with modular components around them, because that is the architecture lever Deloitte names for avoiding lock-in while keeping extensibility ([Deloitte Digital](https://www.deloittedigital.com/us/en/insights/perspective/accelerating-b2b-sales-agentic-ai.html)).

## Output format

Use this exact section order and the exact decision vocabulary (`Keep`, `Keep and instrument`, `Consolidate`, `Kill`), because finance and the tool owners both parse the table. Prose inside sections is yours.

```markdown
# GTM AI stack audit — <org / team>

## Headline
Total AI spend, count of tools, count of overlaps, annualized savings from the kill and
consolidate lists, and the maturity stage (piloting / scaling / realizing).

## Decision table
| Tool | Bucket | Annual cost | Weekly active / seats | Value evidence tier | Decision | Effective date |
|---|---|---|---|---|---|---|

## Overlap map
Each capability bucket, the tools in it, the named system of record, and the surviving tool.

## Data-flow breaks
Each break, the tool starved by it, and the fix. Flag any tool limited to a narrow API window.

## Shadow AI census
Unsanctioned tools found, users, data exposure, and sanction-or-block decision.

## Value claims tested
| Claim | Source | Tier (Study / Vendor study / Assertion) | Carried or discarded |
|---|---|---|---|

## Consolidation sequence
Ordered by contract end date, with the migration owner and the workflow to rebuild per step.

## Instrumentation added
Tool, one metric, baseline, review date.
```

## Gotchas

- Renewal dates, not value scores, set the sequence. A correct kill executed one month after auto-renewal costs a full contract year, so sort the plan by contract end date and keep low-value tools running until their date.
- More than half of GenAI budget sits in sales and marketing tools ([Fortune](https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/)), which means the GTM stack is where the aggregate spend is, and also where per-tool cost is small enough that no single line item triggers finance review. Audit in aggregate or the spend stays invisible.
- Two tools in the same bucket with different object definitions cost more than either saves, because reps reconcile by hand. Overlap with a shared data model is tolerable; overlap with divergent definitions is not.
- An in-flight internal build replacing a purchased capability is a standing kill candidate: internal builds succeeded one-third as often as buying in the only study with a like-for-like comparison ([Fortune](https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/)).
- Vendor ROI dashboards compute lift as adopters versus non-adopters inside the customer's own org, which is the same uncontrolled design as the Gong analyses. Never paste that number into a business case without restating the confound.
- Rep adoption without manager adoption predicts a stalled tool, because the documented success pattern puts line managers in charge rather than a central AI lab ([Fortune](https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/)).
- Forecasting tools need roughly 12 months of history to train and 3–6 months before measurable improvement (implementation guidance, not study findings, from [Prospeo](https://prospeo.io/s/ai-sales-forecasting-accuracy)). Judging one at 90 days produces a false kill.
- Shadow AI usually indicates an unmet workflow need rather than user misbehavior. Record what the tool did before deciding to block it, because blocking without replacing pushes the same usage further out of view.

What does the Auditing gtm AI Stack skill do?

Audits purchased GTM AI tools for overlap, data flow, adoption, and evidence-backed value into keep or kill decisions

Where does the Auditing gtm AI Stack skill come from?

Report research library. It was written by The Revenue AI Report against a 12 criterion quality rubric and graded in an independent scoring pass.

Why was the Auditing gtm AI Stack skill chosen for this library?

The three-tier evidence discipline (Study / Vendor study / Assertion) with named confounds is a genuinely non-obvious constraint that changes agent behaviour.

When should the Auditing gtm AI Stack skill not be used?

Do not use it for: Design a pilot for AI-generated cold email with a human control group Or: Write an agentic workflow spec with human checkpoints for our renewal motion

How do I install the Auditing gtm AI Stack SKILL.md file?

Download the file, create a folder named exactly auditing-gtm-ai-stack inside your agent's skills directory, and save the file inside it as SKILL.md. The agent loads it when a request matches the description.