About gtm-audit
GTM-аудит is a standalone skill for assessing a company's go-to-market operations across 23 criteria in four blocks. It produces evidence-based scores, identifies key gaps, and lays out prioritized actions for the first 30 days.
Key features
- 01Assesses 23 criteria across four blocks
- 02Requires evidence for each score
- 03Calculates weighted scores and coverage
- 04Identifies three critical gaps
- 05Plans actions for the first 30 days
Use cases
- 01Reviewing a company's GTM maturity
- 02Assessing sales and marketing operations
- 03Prioritizing fixes from audit evidence
Install
Copy the command and run it in a terminal.
$
npx skills add https:/After installing, type/gtm-auditin Claude Code to confirm it loaded.
Details
From the project READMEGTM-аудит — 23 критерії, 4 блоки
Самостійний скіл. Не потребує Notion, шаблону чи інших скілів: вхід — те, що є (сайт, LinkedIn, вивантаження з CRM, нотатки з дзвінків, відповіді на запитання), вихід — один документ у чаті або у файл, куди скаже користувач. Мова документа = мова користувача.
Що робить
- Збирає докази по кожному з 23 критеріїв.
- Ставить бал зрілості 0–4 з одним рядком доказу і джерелом.
- Рахує бал по блоках, загальний зважений бал, покриття, бенд.
- Називає три найкритичніші діри і список дій на перші 30 днів.
Тверді правила
- Бал без доказу не ставиться. Немає доказу → «немає даних», критерій виключається із зваженого підсумку, а покриття % показує, скільки критеріїв реально оцінено. Незнане = запитання на discovery, не вигадка.
- Документ без практики = максимум 2. Оцінюємо практику, а не наявність файлу.
- Вагаєшся між двома балами — став нижчий.
- Deliverability-інфраструктура (домени, SPF/DKIM/DMARC, warmup, ліміти) оцінюється в 2.2 Outbound, а не в блоці даних.
- Якщо користувач дав мало даних — спершу постав 8–12 запитань (по 2–3 на блок), потім оцінюй. Не змішуй два раунди: питання окремо, оцінка окремо.
Шкала зрілості (для кожного критерію)
| Бал | Рівень | Як розпізнати |
|---|---|---|
| 0 | Відсутнє | Нема ні документа, ні практики |
| 1 | Ad hoc | Живе в голові CEO, робиться від випадку до випадку |
| 2 | Задокументовано | Документ існує, команда ним щодня не користується |
| 3 | Працює | Практика стабільна, команда живе за нею без нагадувань |
| 4 | Вимірюється | Працює + є метрики + регулярно переглядається |
23 критерії
Ваги блоків: Команда 20% · Процеси 30% · Дані 25% · Інтерфейси 25%. Бал блоку = середнє його критеріїв (без «немає даних»). % блоку = бал / 4 × 100. Загальний бал = Σ (% блоку × вага).
/01 Команда — 20%
| # | Критерій | 4 бали виглядає так |
|---|---|---|
| 1.1 | Покриття ролей відповідає стадії | SDR / Sales / AM / Marketing розділені настільки, наскільки вимагає стадія; нема ролі-«сироти» |
| 1.2 | Синьйорність достатня для задач | Нема ролі, де рівень людини нижчий за потрібний для поточних цілей |
| 1.3 | Незалежність від CEO | Нові угоди закриваються без CEO; його вихід на 90 днів не зупиняє продажі |
| 1.4 | Компенсація прив'язана до результату | Кожна роль має змінну частину, зав'язану на метрики свого етапу воронки |
| 1.5 | Онбординг і розвиток | Нова людина виходить на продуктивність за планом; є плейбуки і план розвитку |
/02 Процеси — 30%
| # | Критерій | 4 бали виглядає так |
|---|---|---|
| 2.1a | GTM-стратегія: сегменти + ICP | Сегменти зафіксовані з розумінням розміру, конкуренції, росту; ICP реально використовується при зборі списків, у кампаніях і кваліфікації; buyer's journey описаний |
| 2.1b | GTM-стратегія: офер · позиціонування · value prop | Ключові сервіси сформульовані як проблема → результат для конкретного сегмента; позиціонування відбудоване від прямих конкурентів словами клієнта; є конкурентний аналіз |
| 2.2 | Outbound / demand capture | Процес від списку до зустрічі описаний і повторюваний; інфраструктура в порядку (окремі sending-домени, SPF/DKIM/DMARC, warmup, LinkedIn-профілі, deliverability-чеки); гіпотези ведуться системно; nurture існує; відповіді обробляються < 24 год |
| 2.3 | Inbound / demand gen | Мінімум один канал ведеться свідомо, має описаний процес і рік статистики |
| 2.4a | Sales: процес, дзвінки, playbook | Discovery → proposal → close описано; дзвінки записуються й розбираються; playbook із запереченнями живий; у proposal-процесу є власник і терміни |
| 2.4b | Sales: CRM + воронка | Воронка зі стадіями і критеріями переходу; стан будь-якої угоди видно без дзвінка менеджеру |
| 2.5 | AM · retention · referrals | Onboarding, планування акаунта, збір фідбеку, upsell існують як система; referral керований; конверсії по клієнтах рахуються |
| 2.6 | Бізнес-процеси і toolset | Система контролю і звітів працює (таск-менеджер, тижневий ритм перегляду цифр); інструменти автоматизації задокументовані |
/03 Якість даних — 25%
| # | Критерій | 4 бали виглядає так |
|---|---|---|
| 3.1 | Єдине джерело правди | Один CRM відповідає на «що з цим акаунтом»; таблиці лише як тимчасові робочі файли |
| 3.2 | Гігієна бази | Дублікати і мертві контакти чистяться регулярно; ключові поля заповнені |
| 3.3 | Дозбір і верифікація | Контакти дозбираються і верифікуються перед кожною кампанією; bounce < 3% |
| 3.4 | Інтегрованість стека | Дані течуть між інструментами без ручного перенесення; стек задокументований |
/04 Інтерфейси і матеріали — 25%
| # | Критерій | 4 бали виглядає так |
|---|---|---|
| 4.1 | Сайт | За 10 секунд ясно, кому і яку проблему вирішуєте; є шлях до конверсії; кейси доступні |
| 4.2 | LinkedIn-профілі | Профілі SDR / Sales / CEO оформлені під outbound і витримують перевірку проспектом |
| 4.3 | Company page і соцдокази | Активна сторінка; каталоги з відгуками; референси готові |
| 4.4 | Кейси | Під кожен ключовий ICP є кейс із цифрами результату |
| 4.5 | Deck і proposal | Продають офер і результат; актуальні; конверсія proposal → won відома |
| 4.6 | Sequences і templates | Копі під ICP, персоналізація змістовна; варіанти тестуються |
Інтерпретація загального балу
| Бал | Бенд | Що це означає | Горизонт до системи |
|---|---|---|---|
| 0–25% | 🔴 Critical | Системи нема, продажі = особисті зусилля фаундера. Фундамент з нуля | 12+ міс |
| 26–50% | 🟠 Weak | Активності є, передбачуваних результатів нема. Інвестиції в дані, процеси, команду | 6–9 міс |
| 51–75% | 🟡 Working | Канал приносить лідів, система часткова. Фіксимо вибірково | 3–6 міс |
| 76–100% | 🟢 System | Система працює. Далі тюнінг і масштабування | точкові спринти |
Крос-чек зі стадією компанії: якщо виручка каже «стадія 2+», а бал < 50% — зона ризику: ріст тримається на рекомендаціях, система відстає від виручки. Це головний аргумент розмови про те, що будувати першим.
Процес
- Інтейк. Що є на вході: сайт, LinkedIn компанії і 3–5 профілів команди, вивантаження CRM, нотатки з дзвінків, документи. Якщо дали лише URL — зніми сайт і LinkedIn сам, решту запитай.
- Запитання (лише якщо даних мало): 8–12 штук, по 2–3 на блок, кожне закриває конкретний критерій. Чекай відповідей.
- Оцінка. Пройди 23 критерії блок за блоком. На кожен: бал 0–4 · один рядок доказу · джерело (URL, файл, «зі слів CEO»). Без доказу — «немає даних» + запитання, яке б його закрило.
- Підсумок. Таблиця по блоках (середній бал, %, вага, внесок), загальний бал, покриття %, бенд, крос-чек зі стадією.
- Три діри. Три критерії з найбільшим впливом на результат (низький бал × висока вага блоку × близькість до грошей). Для кожної: що саме зламано, що це коштує, що робити.
- Перші 30 днів. 5–7 дій. Кожна: артефакт, який має з'явитись · власник · термін. Не «покращити CRM», а «воронка з 6 стадіями і критеріями переходу, власник Head of Sales, до 15-го».
Формат виходу
# GTM-аудит: [компанія] · [дата]
Загальний бал: NN% · бенд · покриття: N із 23 критеріїв
Крос-чек зі стадією: [одне речення]
## Скорборд
| Критерій | Бал | Доказ | Джерело |
| 1.1 … | | | |
… усі 23 рядки, «немає даних» де немає доказу …
## По блоках
| Блок | Середній бал | % | Вага | Внесок |
## Три критичні діри
1. [критерій] — що зламано · що коштує · що робити
## Перші 30 днів
| Дія | Артефакт | Власник | Термін |
## Відкриті запитання на discovery
- …
У чаті після документа: 5 рядків — бал, найгірший блок, три дії, скільки критеріїв без даних.
Comments
Markdown supported