mcpField
G
gtm-audit

gtm-audit

github.com/victor-shulgaマーケティング・グロース139 回インストール6 日前に更新
リポジトリ

gtm-audit について

GTM-аудит は、4つの領域にわたる23項目で企業のGTM運営を評価する単独のスキルです。証拠に基づく採点で重要な課題を特定し、最初の30日間の優先施策をまとめます。

主な機能

  1. 014領域の23項目を評価
  2. 02各採点に証拠を要求
  3. 03加重スコアとカバー率を算出
  4. 04重要な課題を3つ特定
  5. 05最初の30日間の施策を計画

活用シーン

  1. 01企業のGTM成熟度の評価
  2. 02営業とマーケティング運営の確認
  3. 03監査証拠に基づく改善優先度の決定

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/victor-shulga/gtm-strategy-skills --skill gtm-audit

インストール後、Claude Code で/gtm-auditを入力して読み込まれたか確認します。

README(原文)English

プロジェクトの README より

この README の日本語訳はまだありません。以下は英語の原文です。日本語の紹介はページ上部をご覧ください。

GTM-аудит — 23 критерії, 4 блоки

Самостійний скіл. Не потребує Notion, шаблону чи інших скілів: вхід — те, що є (сайт, LinkedIn, вивантаження з CRM, нотатки з дзвінків, відповіді на запитання), вихід — один документ у чаті або у файл, куди скаже користувач. Мова документа = мова користувача.

Що робить

  1. Збирає докази по кожному з 23 критеріїв.
  2. Ставить бал зрілості 0–4 з одним рядком доказу і джерелом.
  3. Рахує бал по блоках, загальний зважений бал, покриття, бенд.
  4. Називає три найкритичніші діри і список дій на перші 30 днів.

Тверді правила

  • Бал без доказу не ставиться. Немає доказу → «немає даних», критерій виключається із зваженого підсумку, а покриття % показує, скільки критеріїв реально оцінено. Незнане = запитання на discovery, не вигадка.
  • Документ без практики = максимум 2. Оцінюємо практику, а не наявність файлу.
  • Вагаєшся між двома балами — став нижчий.
  • Deliverability-інфраструктура (домени, SPF/DKIM/DMARC, warmup, ліміти) оцінюється в 2.2 Outbound, а не в блоці даних.
  • Якщо користувач дав мало даних — спершу постав 8–12 запитань (по 2–3 на блок), потім оцінюй. Не змішуй два раунди: питання окремо, оцінка окремо.

Шкала зрілості (для кожного критерію)

БалРівеньЯк розпізнати
0ВідсутнєНема ні документа, ні практики
1Ad 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.1aGTM-стратегія: сегменти + ICPСегменти зафіксовані з розумінням розміру, конкуренції, росту; ICP реально використовується при зборі списків, у кампаніях і кваліфікації; buyer's journey описаний
2.1bGTM-стратегія: офер · позиціонування · value propКлючові сервіси сформульовані як проблема → результат для конкретного сегмента; позиціонування відбудоване від прямих конкурентів словами клієнта; є конкурентний аналіз
2.2Outbound / demand captureПроцес від списку до зустрічі описаний і повторюваний; інфраструктура в порядку (окремі sending-домени, SPF/DKIM/DMARC, warmup, LinkedIn-профілі, deliverability-чеки); гіпотези ведуться системно; nurture існує; відповіді обробляються < 24 год
2.3Inbound / demand genМінімум один канал ведеться свідомо, має описаний процес і рік статистики
2.4aSales: процес, дзвінки, playbookDiscovery → proposal → close описано; дзвінки записуються й розбираються; playbook із запереченнями живий; у proposal-процесу є власник і терміни
2.4bSales: CRM + воронкаВоронка зі стадіями і критеріями переходу; стан будь-якої угоди видно без дзвінка менеджеру
2.5AM · retention · referralsOnboarding, планування акаунта, збір фідбеку, 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.2LinkedIn-профіліПрофілі SDR / Sales / CEO оформлені під outbound і витримують перевірку проспектом
4.3Company page і соцдоказиАктивна сторінка; каталоги з відгуками; референси готові
4.4КейсиПід кожен ключовий ICP є кейс із цифрами результату
4.5Deck і proposalПродають офер і результат; актуальні; конверсія proposal → won відома
4.6Sequences і templatesКопі під ICP, персоналізація змістовна; варіанти тестуються

Інтерпретація загального балу

БалБендЩо це означаєГоризонт до системи
0–25%🔴 CriticalСистеми нема, продажі = особисті зусилля фаундера. Фундамент з нуля12+ міс
26–50%🟠 WeakАктивності є, передбачуваних результатів нема. Інвестиції в дані, процеси, команду6–9 міс
51–75%🟡 WorkingКанал приносить лідів, система часткова. Фіксимо вибірково3–6 міс
76–100%🟢 SystemСистема працює. Далі тюнінг і масштабуванняточкові спринти

Крос-чек зі стадією компанії: якщо виручка каже «стадія 2+», а бал < 50% — зона ризику: ріст тримається на рекомендаціях, система відстає від виручки. Це головний аргумент розмови про те, що будувати першим.

Процес

  1. Інтейк. Що є на вході: сайт, LinkedIn компанії і 3–5 профілів команди, вивантаження CRM, нотатки з дзвінків, документи. Якщо дали лише URL — зніми сайт і LinkedIn сам, решту запитай.
  2. Запитання (лише якщо даних мало): 8–12 штук, по 2–3 на блок, кожне закриває конкретний критерій. Чекай відповідей.
  3. Оцінка. Пройди 23 критерії блок за блоком. На кожен: бал 0–4 · один рядок доказу · джерело (URL, файл, «зі слів CEO»). Без доказу — «немає даних» + запитання, яке б його закрило.
  4. Підсумок. Таблиця по блоках (середній бал, %, вага, внесок), загальний бал, покриття %, бенд, крос-чек зі стадією.
  5. Три діри. Три критерії з найбільшим впливом на результат (низький бал × висока вага блоку × близькість до грошей). Для кожної: що саме зламано, що це коштує, що робити.
  6. Перші 30 днів. 5–7 дій. Кожна: артефакт, який має з'явитись · власник · термін. Не «покращити CRM», а «воронка з 6 стадіями і критеріями переходу, власник Head of Sales, до 15-го».

Формат виходу

# GTM-аудит: [компанія] · [дата]

Загальний бал: NN% · бенд · покриття: N із 23 критеріїв
Крос-чек зі стадією: [одне речення]

## Скорборд
| Критерій | Бал | Доказ | Джерело |
| 1.1 … | | | |
… усі 23 рядки, «немає даних» де немає доказу …

## По блоках
| Блок | Середній бал | % | Вага | Внесок |

## Три критичні діри
1. [критерій] — що зламано · що коштує · що робити

## Перші 30 днів
| Дія | Артефакт | Власник | Термін |

## Відкриті запитання на discovery
- …

У чаті після документа: 5 рядків — бал, найгірший блок, три дії, скільки критеріїв без даних.

コメント