Не промпт, а система: як автоматизувати лендинги подій і не втратити контроль над фактами

INNOVAesthetic регулярно проводить навчання для лікарів і косметологів. Семінари, майстер-класи, конференції. Під кожну подію потрібна маленька рекламна кампанія.

Набір завжди однаковий. Тексти для Meta. Лендинг. Форма реєстрації. Заявка, яка має дійти до CRM. Аналітика. Картинка-превʼю для соцмереж. Перевірка на телефоні. Архів для публікації.

Я хотів, щоб це робилось швидше. План був простий: дати ШІ афішу й отримати готову сторінку.

Для першої сторінки план навіть спрацював.

Згенерувати сторінку виявилось найпростішим

Перший лендинг з афіші й одного промпту справді вийшов. Другий теж. Проблеми почались, коли їх стало багато.

Річ у тому, що лендинги подій відрізняються не дизайном. Вони відрізняються фактами. А факти ШІ тримав гірше за все інше.

Він міг перенести з попередньої сторінки дату, адресу чи спікера. Виглядало це цілком переконливо. Ще недавно це навіть було правдою.

Під час верстки він міг трохи «покращити» погоджений текст. Переписати заголовок, змінити кнопку, додати обіцянку від себе. Його ніхто не просив. Він просто старався.

У медичному маркетингу таке старання дорого коштує. Модель не має права вигадати показання чи приписати всьому бренду те, що доведено для одного продукту. Тут помилка б’є не по конверсії, а по репутації.

А ще була техніка. Поправити відступ у блоці і непомітно зламати форму, перевірку телефону чи передачу заявки в CRM виявилось дуже легко. Для моделі це все один файл.

Отже, задача звучала вже інакше. Як дати ШІ свободу там, де потрібна творчість, і не дати жодної там, де потрібні факти.

Як система наростала шарами

Ніхто не проєктував її з першого дня. Кожен шар з’являвся тоді, коли попередній десь протікав.

Спершу був ручний режим: афіша, промпт, текст, верстка. Швидко, але все трималось на конкретному чаті й на моїй пам’яті. Обидва ресурси, як з’ясувалось, обмежені.

Потім з’явився Landing Builder. Це технічний стандарт лендинга, записаний один раз. Як сторінка поводиться на телефоні, як влаштована форма, куди йде заявка, коли спрацьовує аналітика, як виглядає превʼю, що перевірити перед публікацією. Лендинг перестав бути разовою задачею і став процесом.

Третім став Seminar Orchestrator. Він веде подію від брифу до публікації. Фіксує факти, отримує тексти, чекає мого погодження, передає у верстку, показує результат, перевіряє.

Щоб усе було під рукою, я поклав усередину Orchestrator копії двох інших модулів. Креативного, з базою брендів, і Builder. Один файл, усе в ньому. Дуже зручно.

Поки що.

Три модулі, у кожного своє

Після цього я розділив систему на три частини. У кожної одна відповідальність, і її легко сформулювати одним реченням.

Creative Director знає, що можна сказати. Бренди, позиціонування, твердження і межі доказовості.

Orchestrator знає, що буде далі. Стан події, звідки взявся кожен факт, що погоджено і що кому передати.

Landing Builder знає, як це відвантажити. Верстка, форма, CRM, аналітика, превʼю, перевірки.

Creative Director 3.7.0
бренди, твердження, тексти
        ↓
Seminar Orchestrator 2.5.0
факти, ревізії, погодження
        ↓
Landing Builder 1.5.10
верстка, форма, CRM, аналітика, перевірки

Головне правило: жоден модуль не має права мовчки переписати знання іншого. Orchestrator не тримає копію брендів. Builder не вигадує твердження. Creative Director не лізе в CRM.

Тепер і зміни розкладаються акуратно. З’явився новий бренд, оновлюється тільки Creative Director. Змінилась логіка форми, тільки Builder. Додався етап погодження, тільки Orchestrator. Решта системи про це навіть не дізнається.

Коли зупинитись краще, ніж продовжити

Копій усередині Orchestrator більше немає. Перед стартом він перевіряє, які версії інших модулів реально встановлені і чи вони між собою сумісні.

Якщо чогось бракує або версії не стикуються, він зупиняється. Підхопити стару копію з проєкту чи щось із пам’яті, щоб «якось доробити», йому заборонено.

Зупинка виглядає як незручність. Насправді це саме те, чого не вистачило в історії з VOL.U.LIFT.

Як одна подія проходить крізь систему

На вході афіша або короткий бриф і оригінальне фото спікера. Далі вісім кроків.

1. Факти. Дата, місто, адреса, спікер, і звідки кожен із них узявся. Невідоме лишається невідомим, а не «приблизно таким».
2. Тема. Або зрозуміла з брифу, або потребує уточнення. Блокує роботу лише справжня відсутність змісту.
3. Тексти. Creative Director пише три варіанти для Meta, текст лендинга і блок «Для кого». Тема події задає історію, база брендів задає межі.
4. Моє перше погодження: зміст.
5. Верстка.
6. Моє друге погодження: десктоп, телефон, превʼю.
7. Перевірка фактів, форми, аналітики, метаданих і файлів.
8. Архів для публікації зі звітом перевірки.

Назву події, яку дав організатор, система не чіпає на жодному етапі.

Окремо була вимога до вигляду. Стандарт однаковий, але сторінки не мають виглядати як один шаблон із заміненими датами. Тому візуальний напрям під кожну подію пропонує Creative Director разом із текстами. Builder втілює його в тій самій сітці. Різниця між сторінками в змісті й акцентах, а не в тому, де лежить форма.

Чому модулі не пересилають один одному весь чат

Коли я погоджую тексти, Orchestrator пакує їх у коротку передачу. Там номери ревізій, хеш погодженого тексту і список полів, які не можна змінювати.

{
  "facts_revision": 2,
  "creative_revision": 3,
  "creative_sha256": "...",
  "locked_fields": ["hero_h1", "for_whom"]
}

Builder отримує цей пакет, а не всю історію розмов. Тобто він отримує погоджений текст, а не нагоду його вдосконалити.

Якщо тексту не вистачає, Builder так і каже. Дописати від себе він не може.

Де без людини ніяк

Погоджень два. На першому я вирішую, чи правильно ми кажемо. На другому, чи правильно це зроблено.

Між ними ШІ працює сам. Пише в дозволених межах, верстає за стандартом, перевіряє за списком. Рішення, що говорити і що публікувати, лишаються на мені. Як і відповідальність.

Є й короткий список того, чого система не робить ніколи. Не вигадує факти, програму, показання і вимоги до учасників. Не малює обличчя спікерів, тільки оригінальні фото. Не змінює погоджений текст мовчки. Не публікує сторінку й не шле тестову заявку без дозволу. І не пише «перевірку пройдено», якщо не може цього показати.

Дрібниці, на яких усе тримається

Подія успіху в аналітиці спрацьовує тільки тоді, коли CRM підтвердила, що лід створено. Не після натискання кнопки. Одна заявка, один лід, одна подія в GA4 і Meta. Цю рівність можна перевірити, і це приємно.

У публічній конфігурації події немає секретів. Ні адреси вебхука, ні полів CRM, ні менеджерів. Усе це живе на боці обробника заявок.

Превʼю для соцмереж малюється окремо, 1200 на 630, а не обрізається з афіші. Факти на ньому ті самі, що на сторінці.

А перевірка перед публікацією шукає все, що могло лишитися від минулої події: стару дату, місце, спікера, назву в CRM. Саме з цього все й почалося.

Що змінилось

Цифр прискорення не буде. Я їх не міряв, а вигадувати не хочеться.

Змінився характер роботи. Раніше кожен лендинг був окремою історією. Знання розкидані, погодження неявні, текст і код в одному файлі, а будь-яке оновлення могло зачепити все.

Тепер це процес. У кожного знання один власник. Передачі мають версії. Погодження явні. Стан будь-якої події можна відкрити й перевірити. І новий лендинг більше не починається з чистого аркуша.

Що з цього варто забрати

Найважливішим в автоматизації виявилось не навчити ШІ робити більше. А домовитись, хто в системі що знає, що вирішує і що має право змінювати.

Поки все лежало в одному файлі, система здавалась простішою. Насправді вона була крихкішою.

Хороша автоматизація з ШІ починається не з промптів. Вона починається з того самого, з чого починається будь-яка нормальна команда: з розподілу відповідальності.