Генератор клієнтських case study (n8n + LLM)

Grow2.ai збирає AI-автоматизацію, яка закриває цикл виробництва case study — від збору сирого матеріалу за завершеним проектом до готової чернетки публікації. Один акаунт-менеджер запускає процес, отримує draft через шість годин і передає редактору на фінальну правку.

Що робить у циклі виробництва:

1. Збирає артефакти проекту: транскрипти дзвінків з клієнтом, листування по email, брифи, метрики результату, посилання на фінальні матеріали в CMS і файловому сховищі.
2. Суммаризує довгі джерела — години записаних розмов, десятки листів, драфти звітів — у компактні structured summaries з акцентом на цифри, рішення та прямі цитати клієнта.
3. Витягує ключові факти для кейсу: вихідний біль клієнта, що саме зробила команда, кількісний результат (конверсії, revenue, час), цитати клієнта з атрибуцією.
4. Генерує структурований чернеток за шаблоном problem → approach → results → client quote, довжина 600–1200 слів залежно від пресету.
5. Публікує draft у CMS у статусі "on review" з прикріпленими source-посиланнями на кожен використаний факт — редактор перевіряє контекст в один клік.
6. Повідомляє редактора в робочому каналі з посиланням на draft, списком джерел і checklist того, що потребує ручної валідації перед публікацією.

Що залишається за маркетологом:

Редактор перевіряє фактологію, править tone of voice під бренд, підбирає візуал, узгоджує фінальний варіант і цитати з клієнтом, публікує. LLM дає структуру і чорновий текст — не кінцевий матеріал, готовий до показу.

Чого рішення не робить:

• Не публікує case study без human review. Цитати клієнта, цифри та назви проектів завжди проходять ручну звірку — відповідальність за точність факту залишається на редакторі.
• Не збирає material автоматично з CRM, якщо проектні артефакти не структуровані. Повнота input на стороні акаунт-менеджера: немає транскрипту — немає кейсу.
• Не адаптує стилістику під конкретний бренд без промпт-налаштування. Генерація йде за загальним шаблоном; тонка брендова робота — завдання редактора на фінальній стадії.

Архітектура будується на workflow-рушії як оркестраторі та зовнішньому LLM для генерації та сумаризації. workflow-рушій збирає дані з CMS та file storage, ріже їх на чанки, пропускає через кілька LLM-кроків і зводить результат у чернетку.

Технічний flow:

1. Тригер. Акаунт-менеджер заповнює форму в CMS або надсилає команду в робочому чаті. Вказує project ID, ім'я клієнта, посилання на ключові артефакти — або покладається на автозбірку за тегами в storage.
2. Збір артефактів. workflow-рушій витягує через API: транскрипти зустрічей із транскрипційного сервісу, email-треди з поштової системи або CRM, документи з файлового сховища, метрики з аналітичних систем.
3. Сумаризація long → short. Кожне довге джерело — транскрипт на 60–90 хвилин, email-тред на 40 повідомлень — проходить через LLM із промптом на вилучення: що відбулося, які рішення приймалися, які цифри звучали, які цитати клієнта варто зберегти. На виході — structured summary на 200–400 слів.
4. Fact extraction. Окремий LLM-крок витягує канонічні факти: метрики до/після, термін проекту, склад команди, використані технології, прямі цитати клієнта з атрибуцією.
5. Генерація чернетки. Зведений промпт отримує всі summaries та структуровані факти, генерує case study за шаблоном: контекст клієнта → проблема → підхід → результати → цитата → next steps.
6. Публікація draft у CMS. workflow-рушій створює запис у CMS через API, прикріплює source-посилання як внутрішні references, встановлює статус "on review" та тегує редактора.
7. Сповіщення. Webhook надсилає повідомлення в робочий канал із прямим посиланням на draft та списком того, що потребує ручної перевірки: цитати, цифри, імена.

Ключові компоненти:

Етапи впровадження:

1. Тиждень 1 — inventory. Grow2.ai інвентаризує джерела кейсових артефактів: де лежать транскрипти, як пов'язані з проектом у CRM або PM-системі, які метрики доступні через API. Погоджує шаблон case study з маркетингом.
2. Тиждень 2 — збірка workflow. У workflow-рушії розгортається pipeline: тригер → збір → сумаризація → генерація → публікація. Промпти пишуться під стилістику та структуру агентства.
3. Тиждень 3 — калібрування. На 3–5 закритих проектах запускається генерація, маркетинг звіряє draft з ручною версією, уточнюються промпти під тон, формулювання, довжину.

Рішення працює як self-hosted workflow-рушій на власній інфраструктурі або як managed-інстанс. Для агентств із чутливими клієнтськими даними Grow2.ai рекомендує self-hosted варіант із LLM через API-провайдера з enterprise NDA.

Перед запуском процесу Grow2.ai збирає чек-лист доступів і даних, без яких автоматизація не працює в бою.

Дані та джерела:

• Транскрипти клієнтських дзвінків у систематизованому вигляді — через транскрипційний сервіс або built-in recorder у конференц-системі, з доступом через API або експортом.
• Структуроване сховище артефактів проекту: file storage з консистентною структурою папок або тегуванням проектів у PM-системі.
• CMS з API для створення draft-записів і керування статусами публікацій.
• Доступ до метрик результату через analytics, CRM, dashboards — цифрове підтвердження ефекту проекту.
• Архів 5–10 попередніх case study у фінальній формі — референс для промпта і калібрування тону.

Доступи та підписки:

• API-ключі: workflow-рушій (self-hosted або cloud), LLM-провайдер, CMS, file storage, транскрипційний сервіс.
• Sandbox CMS для тестування публікації без ризику зламати прод.

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

• Акаунт-менеджер розуміє, які артефакти проекту йдуть на вхід — без цього collection падає.
• Редактор готовий до нової ролі: не писати з нуля, а валідувати і полірувати AI-draft.
• Маркетинг-керівник погоджує шаблон case study і критерії якості для draft.

Таймлайн:

Базова реалізація займає 1–3 тижні. Тиждень 1 — inventory джерел і погодження шаблону. Тиждень 2 — збірка workflow у workflow-рушії, написання промптів. Тиждень 3 — калібрування на 3–5 історичних кейсах, передача команді з короткою документацією і моніторингом перших двох тижнів у проді.