Monthly investor update композер

Композер берёт на себя скучную часть ежемесячного апдейта инвесторам — сборку цифр, компоновку разделов, первый черновик. Основатель включается там, где действительно нужен: narrative, сложные решения, планы на следующий период. За месяц композер экономит 3–4 часа на механике и убирает главную боль — апдейт, который переносится на «следующую неделю», пока не превращается в двухмесячный пропуск.

Процесс внутри композера:

1. Забирает метрики из data warehouse или BI на первое число месяца — ARR, MRR, new logos, net dollar retention, churn, cash на счёте, runway, burn rate. Источник один — тот же, что используется на внутреннем weekly business review.
2. Сравнивает с предыдущим периодом и с планом. Подсвечивает отклонения больше ±X% и считает рост месяц-к-месяцу. Если метрика промахнулась по плану больше чем на согласованный порог — добавляет флаг «требует комментария».
3. Собирает качественные события через форму в Notion или Slack-опрос за 2–3 дня до дедлайна: новые найм, запуски фич, крупные сделки, проблемы, wins/losses по воронке. Каждый руководитель пишет 2–3 bullet points по своему домену.
4. Суммаризирует комментарии команды в 2–3 предложения на раздел, убирая внутренний жаргон и дублирование между источниками.
5. Формирует черновик письма по проверенному шаблону (snapshot → highlights → lowlights → hiring → asks → metrics в виде таблицы) и отдаёт CEO на правку в drafts Gmail или Notion-страницу.
6. После одобрения CEO — рассылает по списку инвесторов через почтовый шлюз, персонализирует обращение по имени и прикрепляет PDF-снимок дашборда за период.

Чего композер не делает:

• Не пишет narrative за CEO. Черновик про факты; «что мы узнали в этом месяце» и «на что делаем ставку в следующем» — всегда фаундер.
• Не решает, какую информацию раскрывать инвесторам, а какую оставить до звонка. Фильтр чувствительных тем (увольнения, конфликты в команде, просадки по ключевым клиентам) остаётся за человеком.
• Не заменяет личные звонки с lead-инвесторами. Ежемесячный апдейт — это минимум коммуникации с инвесторами, не максимум; большие решения обсуждаются голосом.

Композер работает по принципу «ETL для апдейта»: тянем структурированные данные из BI, качественные — через формы, склеиваем по шаблону, LLM дописывает связки, человек проверяет перед отправкой. Логика хранится в отдельном коде (Python-скрипт или low-code платформа), не в LLM — модель отвечает только за суммаризацию и литературную склейку, не за арифметику.

Архитектура состоит из четырёх слоёв: источники данных, сборщик контекста, генератор текста, канал рассылки. Разделение важно — если LLM начнёт считать метрики, ошибок в цифрах будет больше, чем сэкономленного времени.

Шаги внедрения:

1. Выделить шаблон инвесторского письма. Взять 2–3 прошлых апдейта и декомпозировать на блоки (snapshot metrics, highlights, lowlights, hiring, asks). Зафиксировать структуру в формате Markdown или JSON.
2. Настроить pull метрик из DWH/BI. Написать SQL-запросы или использовать дашборд-API (Metabase, Looker, Mixpanel, PostHog) — так, чтобы одним вызовом получать числа и дельты за период.
3. Настроить сбор качественных событий. Форма в Notion, Google Forms или Slack-бот в дни сборки апдейта: head of sales, product lead, operations — каждый пишет 2–3 bullet points по своему домену.
4. Подключить AI-модель (или аналог) для двух задач: суммаризация bullet points в связный абзац и генерация комментария к метрикам («ARR вырос на 12% благодаря росту enterprise-сегмента»).
5. Собрать всё в итоговый документ (Markdown → HTML → PDF для дашборда) и положить CEO в drafts Gmail или Notion-страницу за день до дедлайна.
6. После правки CEO нажимает «Send» — рассылка по списку инвесторов с персонализацией обращения и логированием открытий, если используется SendGrid или Mailgun.

Типичные варианты настройки

Минималка за выходные. Один SQL-запрос → Google Sheet → Python-скрипт → Claude API → drafts Gmail. Подходит, если у вас 5–10 метрик и 5–15 инвесторов, а CEO готов ручным действием запустить рассылку.

Средний вариант. workflow-движок с webhook-ами: metrics pull → Slack-опрос → LLM-суммаризация → письмо + PDF → рассылка. Логи и retry встроены в платформу, не нужно поднимать отдельный сервис.

Продвинутый вариант. Отдельный сервис в коде компании (Python или Node.js), с хранением истории апдейтов в БД, A/B-тестами на темы писем, аналитикой открытий через Mailgun. Имеет смысл, когда инвесторов больше 30 и данные нужно сопоставлять между месяцами.

Альтернативные подходы

• Notion AI плюс ручная сборка: быстрее на старте, но каждый месяц CEO всё равно собирает цифры и пишет bullet points. Экономия времени — около 30%, не 80%.
• Готовые сервисы инвесторской коммуникации: работают, если вы принимаете их шаблон и платите помесячно. Гибкость ограничена, интеграция с вашим BI требует отдельной работы.

Безопасность и compliance

• Списки инвесторов, ARR и финансовые метрики — чувствительные данные. Используйте LLM-API с политикой без обучения на ваших данных (Anthropic API, Azure OpenAI) и логируйте каждую генерацию.
• Если у фонда требования к confidentiality — письмо должно уходить только с корпоративного SMTP, не через личный Gmail основателя.
• Список инвесторов храните в CRM или Notion с ограниченным доступом, а не в гугл-таблице без контроля версий.

Для запуска композера нужна минимальная инфраструктура данных и договорённость по шаблону апдейта. Если одного из этих элементов нет, сначала стоит их выстроить — без шаблона автоматизация генерирует красивый, но неконсистентный текст, который не помогает инвесторам отслеживать динамику.

Что должно быть на стороне данных и доступа:

• Актуальный data warehouse или BI-система (Metabase, Looker, Snowflake, BigQuery, Postgres) с рабочими метриками ARR/MRR, churn, cash, runway.
• Фиксированный шаблон инвесторского письма — желательно 2–3 прошлых апдейта, по которым основатель признаёт: «да, так и буду писать каждый месяц».
• Доступ к API: DWH/BI, LLM (Anthropic или OpenAI), почтовый шлюз (Gmail API, SendGrid, Mailgun).
• Список инвесторов в структурированном виде (Notion, CRM, Google Sheet) с именем, email и типом (angel, VC, advisor).

Готовность команды:

• CEO выделяет 1–2 часа на ревизию черновика в день перед дедлайном. Без этого композер превращается в «отправим как есть» — и это быстро видно инвесторам.
• Head of sales / product / ops готовы писать 2–3 bullet points раз в месяц в общий документ или Slack.
• Кто-то из команды (CTO, ops lead, консультант) знает Python или low-code платформу на уровне «может собрать воркфлоу из шести шагов и поставить на cron».

Таймлайн:

• Weekend complexity: первая рабочая версия — за выходные (16–24 часа чистой работы одного разработчика). Полная доводка до автоматического расписания, откалиброванного промпта и отлаженной рассылки — 1–2 недели с учётом реального тестового цикла на двух апдейтах. К третьему месяцу процесс стабилизируется и требует только точечных правок шаблона.