Щомісячний звіт для інвесторів — композер

Композер бере на себе нудну частину щомісячного апдейту інвесторам — збирання цифр, компонування розділів, першу чернетку. Засновник підключається там, де справді потрібен: виклад, складні рішення, плани на наступний період.

За місяць композер економить 3–4 години на механіці й усуває головний біль — апдейт, який переноситься на «наступний тиждень», поки не перетворюється на двомісячний пропуск.

Процес усередині композера:

1. Забирає метрики зі сховища даних або BI на перше число місяця — ARR, MRR, кількість нових клієнтів, утримання доходу, відтік, залишок коштів на рахунку, запас коштів, темп витрат. Джерело одне — те саме, що використовується на внутрішньому щотижневому бізнес-огляді.
2. Порівнює з попереднім періодом і з планом. Підсвічує відхилення більше ±X% і підраховує зростання місяць-до-місяця. Якщо метрика не вписалась у план більше ніж на узгоджений поріг — додає прапорець «вимагає коментаря».
3. Збирає якісні події через форму в Notion або Slack-опитування за 2–3 дні до дедлайну: нові найми, запуски фіч, великі угоди, проблеми, успіхи/невдачі по воронці. Кожен керівник пише 2–3 тез по своєму напрямку.
4. Підсумовує коментарі команди в 2–3 речення на розділ, прибираючи внутрішній жаргон і дублювання між джерелами.
5. Формує чернетку листа за перевіреним шаблоном (знімок стану → позитивні підсумки → негативні підсумки → найм → запити → метрики у вигляді таблиці) і передає CEO на редагування до чернеток Gmail або сторінки в Notion.
6. Після схвалення CEO — розсилає за списком інвесторів через поштовий шлюз, персоналізує звернення по імені й прикріплює PDF-знімок дашборду за період.

Чого композер не робить:

• Не пише виклад за CEO. Чернетка про факти; «що ми дізнались цього місяця» й «на що робимо ставку в наступному» — завжди фаундер.
• Не вирішує, яку інформацію розкривати інвесторам, а яку залишити до дзвінка. Фільтр чутливих тем (звільнення, конфлікти в команді, просідання по ключових клієнтах) залишається за людиною.
• Не замінює особисті дзвінки з ключовими інвесторами. Щомісячний апдейт — це мінімум комунікації з інвесторами, не максимум; великі рішення обговорюються голосом.

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

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

Кроки впровадження:

1. Виділити шаблон інвесторського листа. Взяти 2–3 попередніх апдейти та декомпозувати на блоки (знімок метрик, позитивні підсумки, негативні підсумки, найм, запити). Зафіксувати структуру у форматі Markdown або JSON.
2. Налаштувати вивантаження метрик з DWH/BI. Написати SQL-запити або використати дашборд-API (Metabase, Looker, Mixpanel, PostHog) — так, щоб одним викликом отримувати числа та дельти за період.
3. Налаштувати збір якісних подій. Форма в Notion, Google Forms або Slack-бот у дні збірки апдейту: керівник відділу продажів, керівник продукту, операційний відділ — кожен пише 2–3 тези за своїм напрямком.
4. Підключити AI-модель (або аналог) для двох задач: зведення тез у зв'язний абзац та генерація коментаря до метрик («ARR виріс на 12% завдяки зростанню корпоративного сегмента»).
5. Зібрати все в підсумковий документ (Markdown → HTML → PDF для дашборда) та покласти CEO до чернеток Gmail або сторінки в Notion за день до дедлайну.
6. Після правки CEO натискає «Надіслати» — розсилка за списком інвесторів з персоналізацією звернення та логуванням відкриттів, якщо використовується SendGrid або Mailgun.

Типові варіанти налаштування

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

Середній варіант. рушій робочих процесів із вебхуками: вивантаження метрик → Slack-опитування → LLM-зведення → лист + PDF → розсилка. Логи та повторні спроби вбудовані в платформу, не потрібно піднімати окремий сервіс.

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

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

• Notion AI плюс ручна збірка: швидше на старті, але щомісяця CEO все одно збирає цифри і пише тези. Економія часу — близько 30%, не 80%.
• Готові сервіси інвесторської комунікації: працюють, якщо ви приймаєте їхній шаблон і платите щомісяця. Гнучкість обмежена, інтеграція з вашим BI потребує окремої роботи.

Безпека та відповідність вимогам

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

Для запуску композера потрібна мінімальна інфраструктура даних і домовленість щодо шаблону апдейту. Якщо одного з цих елементів немає, спершу варто їх вибудувати — без шаблону автоматизація генерує гарний, але неконсистентний текст, який не допомагає інвесторам відстежувати динаміку.

Що має бути на стороні даних і доступу:

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

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

• CEO виділяє 1–2 години на ревізію чернетки в день перед дедлайном. Без цього композер перетворюється на «відправимо як є» — і це швидко помітно інвесторам.
• Керівник відділу продажів / продукт / операційний напрям готові писати 2–3 тези раз на місяць у спільний документ або Slack.
• Хтось із команди (CTO, керівник операційного напряму, консультант) знає Python або low-code платформу на рівні «може зібрати робочий процес з шести кроків і поставити на cron».

Таймлайн:

• Складність реалізації: перша робоча версія — за вихідні (16–24 години чистої роботи одного розробника). Повне доведення до автоматичного розкладу, відкаліброваного промпта й налагодженої розсилки — 1–2 тижні з урахуванням реального тестового циклу на двох апдейтах. До третього місяця процес стабілізується й потребує лише точкових правок шаблону.