mcpField
G
gtm-audit

gtm-audit

github.com/victor-shulga营销与增长139 次安装6 天前更新
代码仓库

关于 gtm-audit

GTM-аудит 是一项独立技能,按四个板块的 23 项标准评估公司的 GTM 运营。它依据证据评分、指出关键缺口,并规划前 30 天的优先行动。

主要功能

  1. 01按四个板块评估 23 项标准
  2. 02要求每项评分都有证据
  3. 03计算加权分数和覆盖率
  4. 04找出三个关键缺口
  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 рядків — бал, найгірший блок, три дії, скільки критеріїв без даних.

评论

支持 Markdown