Як автоматизувати обробку вхідних лідів і пошти за допомогою ШІ

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

Головна умова: розділіть процес на окремі кроки з власними перевірками. Вилучення даних, маршрутизація, запис у CRM і зовнішня відправка є різними операціями, і таймаут на будь-якому з них може означати, що операція вже виконана. Після статті ви зможете описати свій процес від листа до задачі менеджеру, визначити, де потрібна модель, а де правила, і задати метрики приймання.

Один зрозумілий процес

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

Базовий процес для цієї статті:

1. Вхідний лист надходить на загальну адресу продажів або через форму на сайті.
2. Вилучення даних: з листа отримуємо компанію, потребу, контакт, бажані строки.
3. Перевірка і пошук: чи є вже такий контакт або компанія в CRM.
4. Маршрутизація: хто з менеджерів відповідає за цей лід.
5. Запис у CRM: створення або оновлення ліда з полями і посиланням на оригінальний лист.
6. Задача менеджеру: нагадування зв'язатися, з контекстом.
7. Відповідь клієнту: якщо передбачена, то як окремий етап з чернеткою і погодженням.

Платформи автоматизації на кшталт Make чи Zapier дозволяють зібрати такий сценарій з готових модулів, а модель підключається на кроці 2 і, можливо, частково на кроці 4. Але для кожного кроку варто окремо відповісти на три питання: що може піти не так, як це помітити і що зробити.

Чим вужче визначено процес на старті, тим легше його перевірити. Наприклад, «листи з форми на сайті з питанням про впровадження» простіше, ніж «уся вхідна пошта відділу продажів».

Що витягує модель

Модель корисна там, де вхідні дані неструктуровані: вільний текст листа, підпис у довільному форматі, змішані мови. Типові поля для вилучення:

• Компанія: назва, якщо вказана. Сайт або домен пошти як допоміжний сигнал.
• Контакт: ім'я, посада, телефон, пошта.
• Потреба: коротке формулювання, що людина хоче.
• Масштаб: кількість філій, користувачів, обсяг, якщо названо.
• Строки: бажаний час старту або розмови.
• Згадані системи: наявна CRM, облікова система, канали.

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

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

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

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

Які рішення задаються правилами

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

• Відповідальний менеджер. Призначається за правилами: регіон, напрям, наявний власник компанії в CRM, черговість. Модель може допомогти визначити напрям потреби, але саме призначення виконує правило.
• Допустимі статуси. Новий лід отримує лише стартовий статус процесу. Модель не переводить його у «кваліфікований» чи «угода» на основі тону листа.
• Наявний контакт. Пошук дубліката за поштою, телефоном, доменом виконує код у CRM. Якщо контакт знайдено, лід прив'язується до нього, а не створюється новий.
• Права доступу. Інтеграція діє від сервісного облікового запису з мінімальними правами: створювати ліди і задачі, але не видаляти записи, не змінювати угоди і не відправляти рахунки.
• Спам і нерелевантні листи. Модель може класифікувати лист як нерелевантний, але дія з ним (архів, окрема черга) визначається правилом, а сумнівні випадки йдуть на ручний перегляд.

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

Повтори і помилки

Більшість проблем автоматизації лідів не в якості вилучення, а в повторах і частково виконаних сценаріях.

Повторне надходження того самого листа. Пошта, вебхук або платформа автоматизації можуть доставити одну подію двічі. Тригери опитування Zapier дедуплікують отримані записи за унікальним первинним ключем (за замовчуванням id); це захищає лише тригер від повторної обробки того самого запису, а не подальший запис у CRM. Якщо сценарій перезапустили вручну або подія прийшла іншим шляхом, захист має бути і на рівні запису в CRM.

Що для цього потрібно:

• Стабільний ідентифікатор події: наприклад, ідентифікатор повідомлення пошти (message_id) або ID заявки з форми.
• Ключ операції: «ідентифікатор події + тип дії». Перед створенням ліда перевіряється, чи операція з таким ключем уже виконана.
• Журнал обробки: повторна подія оновлює запис у журналі («отримано повторно»), а не створює другий лід.

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

Частково виконаний сценарій. Лід створено, а задачу менеджеру ні, бо наступний модуль впав. У Make є обробники помилок і збереження незавершених виконань, які дозволяють продовжити сценарій з місця збою. Але відкат змін підтримують лише модулі з транзакціями; звичайні виклики API, як створення ліда через HTTP, автоматично не відкочуються. Тому сценарій треба проектувати так, щоб продовження після збою не повторювало вже виконані кроки.

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

Контроль зовнішніх повідомлень

Внутрішні дії (картка ліда, задача менеджеру) можна виправити, якщо щось пішло не так. Лист клієнту виправити неможливо: він уже надісланий.

Тому зовнішня комунікація розбивається на окремі етапи:

1. Чернетка. Модель готує відповідь на основі вилучених даних і затверджених шаблонів.
2. Погодження. Менеджер переглядає і за потреби редагує. Для кожного типу листа визначено, хто погоджує.
3. Відправка. Окрема дія з окремим правом, яка фіксується в CRM.

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

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

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

Приймання і вимірювання

Перед запуском і після нього процес оцінюється на конкретних прикладах і метриках.

Нижче навчальний приклад. Лист вигаданий для пояснення.

Вхідний лист: «Потрібен бот для трьох філій, CRM уже є, обговоримо наступного тижня».

Навчальна картка обробки

Окрім основного прикладу, приймальний набір має містити складніші листи, на яких автоматизація зазвичай помиляється:

• Пересланий ланцюжок. Колега переслав лист клієнта зі своїм коментарем. Контактом має стати клієнт, а не колега, а коментар не повинен потрапити в потребу.
• Два запити в одному листі. Клієнт питає про бота і окремо про інтеграцію з обліковою системою. Правило процесу визначає, чи це один лід з двома потребами, чи два.
• Відповідь на старий лист. Клієнт відповів на розсилку півроку тому. Лід має прив'язатися до наявного контакту та історії, а не створитися з нуля.
• Лист без контактних даних у тексті. Телефону немає, лише адреса відправника. Поле телефону порожнє, а не вигадане з підпису іншої людини.
• Нерелевантний лист. Пропозиція постачальника чи спам. Він не стає лідом, але потрапляє в окрему чергу, щоб помилкову класифікацію можна було помітити.

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

Метрики, які варто відстежувати після запуску:

• Частка коректних карток: скільки лідів не потребували ручних виправлень полів.
• Час до призначення: від надходження листа до появи задачі у відповідального.
• Втрачені звернення: листи, які не стали лідами і не потрапили в ручну чергу. Їх знаходять звіркою вхідної пошти з журналом обробки.
• Ручні виправлення: які поля менеджери правлять найчастіше. Це підказує, що покращувати.
• Дублікати: скільки повторних лідів знайдено за період.

Висновок

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

Що можна зробити на своєму процесі:

1. Оберіть один вузький процес і опишіть його кроками від листа до задачі менеджеру.
2. Складіть перелік полів для вилучення з правилом «невідоме лишається порожнім» і фрагментами-доказами для ключових полів.
3. Винесіть у правила призначення відповідального, статуси, пошук дублікатів і права інтеграції.
4. Додайте ключ операції на основі ідентифікатора події і перевірку наявного запису після кожного таймауту.
5. Розділіть зовнішні листи на чернетку, погодження і відправку з перевіркою, чи лист уже надіслано.
6. Зберіть приймальні приклади, включно з повтором і недоступністю CRM, і почніть відстежувати частку коректних карток, час до призначення, втрачені звернення і ручні виправлення.

Якщо ви хочете автоматизувати обробку лідів без втрат і дублікатів, команда BotLabs може розібрати ваш процес на 15-хвилинній консультації. Обговоримо, звідки надходять звернення, які поля і правила потрібні вашій CRM і де мають залишитися менеджери. Наступним кроком визначимо, з якого процесу і яких приймальних прикладів почати.

Часті запитання