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 тижні з урахуванням реального тестового циклу на двох апдейтах. До третього місяця процес стабілізується й потребує лише точкових правок шаблону.