AI-система тригерних комунікацій: email, SMS, push

AI-система тригерних комунікацій: де рветься логіка

На схемі логіка тригерів виглядає прямолінійно: надійшла подія — пішло повідомлення в потрібний канал. У робочій системі між цими двома точками стоять кілька сервісів, черга та правила частоти, і ламається все саме на стиках. Розберемо типові місця, де AI-система тригерних комунікацій втрачає керування.

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

Друге — затримка реакції на подію. Поки дія клієнта проходить через суміжні системи, а частина даних переноситься вручну вивантаженнями, вікно, у якому повідомлення доречне, закривається. Клієнт уже оплатив або скасував замовлення, а комунікація тільки збирається до відправлення.

Третє — розрізнені канали. Email, SMS і push живуть у різних сервісах зі своїми налаштуваннями, і одна людина отримує суперечливі повідомлення: push про покинутий кошик після успішної оплати або SMS з нагадуванням одразу після листа.

Єдиного профілю частоти та пріоритету каналу немає — звідси втрата відгуку, відписки та скарги на нав'язливість.

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

Вимірні ефекти: затримка, відмови, ручна праця

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

• Час реакції на подію. Тригер із черги подій обробляється в момент появи, а не в найближчий запуск за розкладом: затримка падає з годин до секунд, і вікно, коли клієнт ще в контексті, не втрачається.
• Частка доставлених повідомлень. Модель вибирає канал і момент відправлення під конкретний профіль, а не за єдиним розкладом: влучання у «Вхідні» зростає, частина відправлень перерозподіляється в SMS і push замість перевантаженої пошти.
• Зниження ручних операцій. Сегменти, шаблони та правила переходу між кроками живуть у конфігурації; маркетолог править умови, а не збирає вивантаження вручну — регулярні операції скорочуються в рази.
• Відписки та скарги. Обмеження частоти на профіль і автовимкнення каналу при сплеску скарг тримають репутацію домену: частка відписок стабілізується, а не зростає разом з обсягом розсилки.
• Усунені відмови. Повторні спроби з наростаючою паузою та автоматична зміна каналу прибирають клас збоїв «повідомлення не пішло і ніхто не помітив».

Репутацію відправлень і скарги звіряємо за зовнішніми панелями — звіти Google Postmaster Tools порівнюємо з базовою лінією, знятою на старті. Розбіжність за будь-якою метрикою — привід зупинити кампанію та розібрати причину, а не докручувати обсяг.

Режими запуску тригерних комунікацій

Режим запуску визначає, як швидко система реагує на дію клієнта і чого варте утримання цієї швидкості. В одному сценарії потрібен відгук за секунди — покинутий кошик, підтвердження оплати; в іншому достатньо нічної розсилки по сегменту, де затримка в годину нічого не змінює.

Змішувати їх в одному каналі не можна: різні вимоги до черги, до повторних спроб і до захисту від дублів.

Нижче — три режими, які ми розгортаємо, з чесними обмеженнями кожного.

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

В одній системі режими зазвичай співіснують і розведені за пріоритетами черги: затримка пакетного вікна тоді не гальмує транзакційні повідомлення.

Впровадження за кроками: від аудиту подій до передачі

Тригерні комунікації ламаються не на рівні текстів листів, а на стику між подією в продукті та правилом відправлення.

Поки карта подій живе в голові аналітика, будь-яка зміна в особистому кабінеті або білінгу дає пропущені, задвоєні або запізнілі повідомлення — і репутаційні втрати в спамі. Тому робота починається з аудиту, а не з налаштування шаблонів.

1. Аудит подій. Проходимо по продукту і виписуємо всі точки, де виникає значуща дія: реєстрація, перша покупка, покинутий крок оформлення, зміна тарифу, тривала відсутність активності. Для кожної події фіксуємо джерело, склад полів і момент спрацювання.
2. Карта подій і каналів. Зводимо все в одну схему і для кожної події призначаємо канал — email, SMS або push, — пріоритет і правила придушення, щоб людина не отримувала три повідомлення про одну й ту саму дію.
3. Налаштування правил відправлення. Описуємо умови, затримки та ланцюжки: що йде одразу, що через добу, а що скасовується при зустрічній дії користувача. Окремо задаємо частотні обмеження та тихі години.
4. Перевірка на тестовій аудиторії. Проганяємо сценарії на сегменті співробітників і синтетичних профілях: підстановка даних, порядок повідомлень, спрацювання стоп-умов, обробка відписок і недоставлених адрес.
5. Перевірка на реальному потоці. Вмикаємо систему на обмеженому сегменті, звіряємо частку доставлених і відкритих, ловимо дублі та затримки до того, як вони зачеплять всю базу.
6. Передача та навчання. Віддаємо документацію по подіях і правилах, доступи та розбір типових збоїв, навчаємо команду вносити нові сценарії та правити умови без інженера.

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

Що залишається в проєкті: схеми, правила, регламенти

Що б не відбувалося в інтерфейсі, поведінка AI-системи тригерних комунікацій визначається артефактами: описами подій, правилами частоти, політиками доступу та журналами.

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

• Схема подій. Перелік сигналів, які запускають сценарій: дія користувача, зміна статусу заявки, системна подія. Для кожного — обов'язкові атрибути, джерело даних і поведінка за їх відсутності.
• Правила частоти повідомлень. Ліміти на користувача та на канал, вікна тиші з урахуванням часових поясів, пріоритет сценаріїв при конфлікті та логіка придушення повторного тригера — щоб листи, SMS і push не дублювали одне одного.
• Політики доступу та ролі. Хто править шаблони, хто змінює правила частоти, хто бачить лише звітність. Згоди на канали та обробку даних зберігаються окремо від контенту і перевіряються перед відправленням.
• Інструкції для команди. Як додати новий тригер, як призупинити сценарій без правки коду, що робити при сплеску відмов доставки, як перевірити гіпотезу на частині аудиторії.
• Журнали та звітність. По кожному відправленню фіксується рішення: який тригер спрацював, яке правило застосувалося, чому повідомлення не пішло. Зведення — за доставлюваністю та часткою цільових дій.
• Регламент змін. Порядок правки правил і шаблонів, склад погоджувачів, спосіб повернути попередню конфігурацію, якщо метрики відгуку прос Il.
• Карта інтеграцій. Точки підключення до CRM, сховища даних і сервісів розсилок: які поля куди передаються, з якою періодичністю і хто відповідає за розбіжності.

Документи супроводжуються схемою потоків даних і матрицею відповідальності — щоб передача не зводилася до усних домовленостей. Опишіть вашу задачу: повернемося з оцінкою та планом, включно зі складом цих артефактів.

Кейс: як зросли доставка та відгук на події

Клієнт — роздрібна мережа з каталогом на кілька тисяч позицій і своєю програмою лояльності. Події збиралися нічним вивантаженням: покинутий кошик, повторне замовлення та скасування заявки доїжджали до розсилки через 5–7 годин після дії.

Розсинхрон між складом і Mindbox давав дублі — один покупець отримував лист і SMS з одного приводу, а частина подій губилася при склейці профілів.

Пілот на одному регіоні зафіксував стартові цифри: відгук на тригерні сценарії 1,8%, частка відписок 0,9%, доставка SMS 71%, повторне замовлення протягом тижня — у 6% тих, хто отримав повідомлення.

Що перебудували

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

Що стало

Затримка від дії до дотику скоротилася з годин до десятків секунд, частка втрачених подій впала з 3% до 0,1%, доставка SMS зросла до 94%. Відгук на тригерні сценарії зріс у 2,4 раза, відписки знизилися до 0,2%, повторне замовлення протягом тижня — у 11%. Після цього логіку розкотили на решту регіонів, додавши push третім каналом.

Чим подієва розсилка відрізняється від масової

Масова розсилка запускається за розкладом: сегмент збирають заздалегідь, контент затверджують, і один текст іде всій базі. Момент відправлення визначає календар, а не поведінка отримувача — влучання в релевантний момент стає справою удачі.

Подієва запускається від факту в системі: покинутий кошик, прив'язка карти, відсутність входу після реєстрації. Ініціатор — потік подій, а не людина, тому між дією та повідомленням проходять хвилини. Контент збирається з атрибутів самої події: один шаблон дає різні повідомлення різним отримувачам.

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

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

Технічні сумніви: обмеження та крайні випадки

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

Як система переживає недоступність зовнішнього каналу?

Черга повторює відправлення з наростаючою паузою між спробами. Якщо зовнішній канал, наприклад Twilio, відповідає помилками підряд, вмикається запобіжник: потік призупиняється і чекає на відновлення зв'язку, а не згорає. Після повернення черга розбирається у вихідному порядку.

Як обмежується частота повідомлень?

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

Що із затримками та поточними шаблонами?

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

Обговоримо задачу: що надіслати для оцінки

Щоб повернутися з планом робіт і оцінкою термінів, а не із загальними словами, нам потрібні вихідні дані за вашою поточною схемою комунікацій. Чим точніше описано перелік подій і поточні канали зв'язку, тим менше припущень залишиться в оцінці.

• Перелік подій: які дії клієнта або внутрішньої системи мають запускати повідомлення — реєстрація, незавершена покупка, зміна тарифу, тривала відсутність активності. По кожній події — умови спрацювання, затримка та ознака скасування, якщо дію вже виконано.
• Поточні канали зв'язку: які розсильники email, SMS і push використовуються зараз, хто відповідає за договори та ліміти за швидкістю відправлення.
• Доступи до систем: тестові ключі до CRM і сховища подій, до сервісу розсилок і аналітики, схема полів користувача, доступних для підстановки в текст.
• Шаблони та правила: поточні тексти, змінні, частота дотиків, «тихі години», правила згод і відписки.
• Обсяги та статистика: скільки подій проходить за добу, частка доставлених і відкритих повідомлень за кожним каналом, пікові навантаження.
• Обмеження: вимоги до зберігання персональних даних, канали та сценарії, які чіпати не можна, критерії приймання робіт.

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