Автоматичний follow-up по лідах: як почати з одного сценарію

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

Автоматичний follow-up по лідах потрібен, щоб у кожного релевантного діалогу був наступний крок. Це не має бути нескінченна серія однакових повідомлень.

Що саме автоматизує follow-up

Мінімальний сценарій складається з п'яти частин:

1. Тригер. У CRM змінився статус, менеджер надіслав пропозицію або завершив дзвінок.
2. Пауза. Система чекає погоджений час, наприклад два робочі дні.
3. Дія. Надсилає доречне повідомлення або створює задачу менеджеру.
4. Умова зупинки. Сценарій припиняється після відповіді, зустрічі, відмови чи зміни статусу.
5. Запис результату. CRM зберігає, що було зроблено і що сталося далі.

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

Повідомлення чи задача менеджеру

Не кожен follow-up потрібно відправляти автоматично.

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

Задачу менеджеру краще створювати, коли:

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

CRM-задача може бути прив'язана до контакту або угоди, мати виконавця, строк, пріоритет і тип дії. Менеджер отримує нагадування разом із контекстом, а не просто повідомлення «не забудь написати».

Приклад першого пілота

Візьмемо один сценарій: лід отримав пропозицію, але не відповів протягом двох робочих днів.

Робоча логіка може виглядати так:

1. Менеджер переводить угоду в статус «Пропозицію надіслано».
2. CRM фіксує дату та канал останнього контакту.
3. Workflow чекає два робочі дні.
4. Перед дією перевіряє, чи не було відповіді, зустрічі, відмови або зміни статусу.
5. Якщо діалог досі відкритий, система надсилає погоджений текст або створює задачу менеджеру.
6. Результат записується в CRM.

Перший текст не повинен тиснути на клієнта. Замість «Чому ви не відповідаєте?» краще коротко повернути контекст і дати просту можливість відмовитися від продовження розмови.

Умови зупинки важливіші за кількість повідомлень

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

Перевірка перед кожною дією має враховувати:

• нову відповідь у підключеному каналі;
• зміну статусу угоди;
• запланований дзвінок або зустріч;
• ручну зупинку менеджером;
• відмову від повідомлень;
• закриття або дискваліфікацію ліда.

HubSpot, наприклад, документує автоматичне припинення sequence після відповіді контакту. В іншій CRM аналогічну поведінку можна реалізувати через статуси, події каналу або окреме поле stop.

Згода та відмова в Україні

Follow-up після реального звернення клієнта не варто плутати з масовою рекламною розсилкою. Проте канал, зміст і підстава для повідомлення все одно мають значення.

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

Для практичного сценарію це означає:

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

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

Що вимірювати в пілоті

Відповіді та зустрічі важливі, але вони не дають повної картини. Для першого пілота корисно відстежувати:

• частку відкритих лідів із зафіксованим наступним кроком;
• кількість прострочених задач;
• час від тригера до наступної дії;
• відповіді після follow-up;
• призначені зустрічі;
• відмови від повідомлень;
• скарги на спам;
• помилки та хибні спрацювання.

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

Як вибрати перший сценарій

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

Перевірте:

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

Pragma може розібрати один поточний процес і визначити мінімальний пілот автоматичного follow-up. Менеджер зберігає контроль над складними діалогами, а система бере на себе строки, задачі та перевірку умов.