Обработка заявок с ИИ: путь обращения от формы до менеджера

Обращение приходит в компанию в 23:40 из мессенджера, в 9:15 с формы сайта и в обед звонком, который никто не взял. Обработка заявок с ИИ продаётся как одна кнопка, за которой всё это перестаёт теряться. На деле за кнопкой прячется путь из шести участков, и обрывается он на любом из них по своей причине. Разберу путь обращения целиком: откуда оно приходит, где именно рвётся, что из этого закрывает нейросеть и что остаётся людям.

Каждую неделю разбираю, что нейросети дают бизнесу: инструменты, сценарии, ошибки и то, что работать не будет. Подписка - чтобы новый разбор приходил сразу.

Что такое обработка заявок с ИИ и из чего она собрана?

На первой же встрече с подрядчиком стоит разложить слово на части. Иначе разговор идёт про «внедрить ИИ», а внедряются четыре разные вещи с разной ценой и разным сроком.

Правила и маршруты. Заявка падает в систему, назначается ответственному, через сутки без движения превращается в задачу-напоминание. Нейросети здесь нет вовсе, работают настройки CRM и интеграции. Этот слой разобран отдельно в материале про автоматизацию продаж, и начинать почти всегда стоит с него: он дешевле и ломается реже.

Речь в текст. Звонок превращается в расшифровку, расшифровка - в поля карточки. Отдельный движок распознавания, отдельные деньги, отдельное качество на шумной линии.

Разбор смысла. Сообщение «а есть такое и сколько будет с доставкой до нас» превращается в разобранный запрос: товар, количество, город, срочность. Формат сообщения заранее неизвестен, шаблоном его не поймать - вот здесь языковая модель и нужна.

Разговор вместо человека. Ответ на входящее, два уточняющих вопроса, запись результата. Самая заметная часть и самая узкая: она держится на первом касании и на типовых вопросах.

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

Откуда приходят обращения и почему каналы теряют их сами по себе?

Больше всего обращений теряется в самом начале пути, и обработка заявок упирается здесь в одну скучную вещь: каналов много, общего списка нет. Типовая картина малого бизнеса выглядит так. Форма на сайте шлёт письмо на общий ящик. Мессенджер открыт на телефоне у руководителя. Кабинет площадки объявлений открывает менеджер, который сегодня в отпуске. Звонки идут на мобильный, и часть из них никто не берёт. Соцсети смотрит маркетолог раз в два дня.

Каждое окно по отдельности работает. Проблема появляется от их количества: нет места, где видно все сегодняшние обращения разом, и нет способа заметить, что в одном из окон висит непрочитанное со вчера.

Вот что усложняет картину дальше:

1. У окон разные владельцы. Ответственность размазана, и за необработанное обращение спросить не с кого - формально каждый занимался своим каналом.
2. У окон разные уведомления. Письмо на общий ящик не пищит, сообщение в мессенджере пищит, и заявка с сайта проигрывает вниманию просто по громкости.
3. Площадки живут по своим правилам. Переписка внутри кабинета объявлений наружу сама не выходит, и вытащить её наружу можно только интеграцией.
4. Часть обращений вообще не выглядит как заявка. «Подскажите, а вы с юрлицами работаете» - это заявка, но в общем ящике она лежит рядом с рассылками.

Здесь и появляется первая работа для помощника, и она скучнее, чем принято рекламировать: обработка заявок начинается со сведения всех окон в одно и с отметки «прочитано» у каждого входящего. Разбор смысла - следующий шаг, до него ещё надо дойти.

Отраслевая специфика меняет набор окон, но не меняет устройство проблемы. В автосервисе основной поток идёт звонками и с площадок, в грузоперевозках - почтой с заявкой на расчёт. Участок один и тот же.

Скорость первого ответа: что на самом деле измеряется?

Скорость первого ответа - главная величина участка, и с ней чаще всего обманываются. Причина в том, что «бот ответил за секунду» и «клиент получил ответ» - разные события.

Методика Geckoboard по показателю First Response Time формулирует это прямо: расчёт должен исключать автоматические ответы вроде тех, что приходят от чат-ботов и виртуальных ассистентов, а также обращения, поступившие вне заявленных часов работы. Считать при этом рекомендуется по медиане, чтобы отдельные выбросы не искажали картину.

Отсюда практический вывод для внедрения. Если помощник отвечает отбивкой и ставит обращение в очередь до утра, время первого ответа не улучшилось ни на секунду - изменилось только ощущение клиента, что его услышали. Ощущение стоит дорого и само по себе полезно, но ускоренная обработка заявок - это другое событие, и путать их нельзя.

Ориентиры по каналам та же площадка приводит такие: по почте клиент в общем случае ждёт ответа в течение суток, для соцсетей ориентир площадки - 60 минут и меньше, для телефона общепринятое время отклика - около трёх минут. Это международные ориентиры клиентского сервиса, не норматив для российского рынка, и брать их стоит как порядок величин.

First reply time is more important than overall reply times because it's an acknowledgment to the customer that their issue is being looked into.

Jamie Edwards, сооснователь и операционный директор Kayako, цитата по методике Geckoboard

Отдельного разговора заслуживает формулировка «ответим в рабочее время». Она честная, и она же самая дорогая строка на сайте. Человек, который пишет вечером, почти никогда не пишет только вам: он открыл выдачу и отправил один и тот же вопрос в три места. Утром он разговаривает с тем, кто ответил первым, а остальные получают вежливое «спасибо, уже определились». За каждое такое обращение вы уже заплатили рекламе.

Именно этот промежуток и закрывает ИИ-продавец на первой линии входящих: он принимает сообщение ночью, отвечает на типовой вопрос, собирает ответы клиента и оставляет менеджеру карточку, готовую к началу смены. Продажу он не делает и не должен.

Квалификация: чем готовый покупатель отличается от «просто спросить»?

Менеджер тратит на квалификацию первые три-пять минут разговора и задаёт одни и те же вопросы. Эту рутину помощнику отдают первой.

Признаки, которые разбираются почти в любой нише:

• Предмет запроса. Что именно нужно человеку, в терминах вашего каталога, а не его словами.
• Объём. Одна штука, партия, разовая услуга или обслуживание на год.
• Срок. «Надо было вчера» и «присматриваюсь на весну» - это два разных места в очереди.
• Роль собеседника. Собственник, снабженец, помощник руководителя. От этого зависит, кому и что отвечать.
• Ограничения. Город, самовывоз, безнал, нужна ли отсрочка, есть ли требования к документам.
• Откуда пришёл. Отдельная тема, ниже про неё целый раздел.

Работает это так: модель получает текст обращения и инструкцию достать перечисленные поля, а недостающее - уточнить одним вопросом. Сообщение «нужно 200 коробок с логотипом до конца месяца, мы в Казани, работаем по безналу» разбирается без единого уточнения. Сообщение «здравствуйте, сколько стоит» требует диалога.

Сильная сторона подхода в том, что формат сообщения не надо знать заранее. Кнопочный сценарий ломается на первом же человеке, который написал не то, что предусмотрено ветками. Модель читает произвольный текст и достаёт из него то, что просили.

Ограничение подхода тоже понятное: качество разбора упирается в то, насколько внятно вы сами описали, что считается готовым покупателем. Инструкция «квалифицируй лида» даёт мусор. Список полей с примерами хороших и плохих значений даёт рабочую карточку.

Где ИИ ошибается на квалификации?

Продавцы помощников про этот участок молчат, поэтому разберу его отдельно: именно здесь обработка заявок ломается тише всего.

Короткие сообщения. «Цена?» под фотографией товара несёт весь смысл в контексте, которого в тексте нет. Модель либо додумывает, либо задаёт уточняющий вопрос - и второе правильно, но раздражает часть людей.

Ирония и отрицание. «Ну да, конечно, за такие деньги» - формально текст о цене, по сути отказ. Разбор по ключевым словам тут ошибается стабильно, языковая модель справляется лучше, но не всегда.

Отраслевой сленг и сокращения. Написание артикула по-своему, профессиональные жаргонизмы, местные названия районов. Модель, не видевшая ваших данных, читает это как незнакомый набор символов. Лечится загрузкой справочников в базу знаний.

Смешанные намерения в одном сообщении. «Я по вчерашнему заказу, и ещё подскажите по другой позиции» - тут одновременно обслуживание и новая продажа. Такое сообщение надо разрезать на два события, и это отдельная настройка, которую забывают сделать.

Отсюда правило, которое стоит записать в договор с подрядчиком: помощник обязан иметь состояние «не уверен» и уметь в нём останавливаться. Карточка с пометкой «требует человека» лучше уверенно заполненной неправильно - вторую менеджер принимает за правду и звонит не тем людям.

Проверяется всё это одним способом. Первые две недели кто-то читает выборку из двадцати-тридцати разобранных обращений в неделю и сверяет поля с перепиской. Дальше выборка сокращается. Без этой работы вы узнаёте об ошибках от клиентов.

Разложить свой поток по участкам и увидеть, какой из них стоит дороже всего, - это первый шаг, с которого начинается любая автоматизация входящих у нас.

Распределение: кому уходит обращение и по какому правилу?

Разобранная карточка без имени рядом - это та же необработанная заявка, только аккуратно оформленная. Чаще всего обработка заявок встаёт именно тут.

Сама по себе раздача - работа для правил CRM, нейросеть для неё избыточна. Модель нужна одним шагом раньше: чтобы определить направление и вес обращения по тексту. Дальше распределение делают обычные настройки.

К правилу обязательно идут две вещи, без которых оно не работает.

Срок жизни без движения. Если карточка сутки лежит нетронутой, она возвращается в общую очередь или уходит руководителю. Иначе обращения у менеджера в отпуске копятся без движения.

Явный ответственный за нераспределённое. Всегда находятся обращения, которые правило не разложило. Для них нужен конкретный человек, а не «разберёмся».

Подключение разбора к данным и правилам компании - это то, ради чего помощника вообще связывают с системой учёта. Как устроена такая связка, подробно разобрано в материале про подключение ИИ к CRM.

Дубли: один клиент пришёл дважды из разных каналов

Участок редко разбирают, а стоит он дорого: дубли портят и клиентский опыт, и любую статистику, по которой обработка заявок вообще оценивается.

Как это выглядит на практике. Человек написал ночью в мессенджер, не дождался, утром заполнил форму на сайте, к обеду позвонил. В системе три обращения. Если у каждого свой ответственный по правилу очереди, клиенту звонят трижды и трижды спрашивают одно и то же.

Рабочие признаки склейки идут по убыванию надёжности:

1. Телефон в нормализованном виде. Самый надёжный признак в России. Нормализация обязательна: один и тот же номер приходит как +7, 8 и 7, с пробелами и скобками.
2. Адрес почты. Надёжен для B2B, слабее для частных лиц с несколькими ящиками.
3. Идентификатор в канале. Логин мессенджера или идентификатор пользователя площадки - надёжен внутри своего канала и бесполезен между каналами.
4. Совпадение по имени и компании. Слабый признак, годится только как подсказка человеку.

Дальше - главное решение участка: что делать при совпадении. Автоматическое слияние карточек выглядит красиво и регулярно склеивает разных людей, особенно однофамильцев и корпоративные номера. Безопаснее помечать пару как вероятный дубль и показывать менеджеру кнопку слияния. Машина ищет, человек подтверждает.

И отдельная тонкость, о которой вспоминают поздно: склейка должна сохранять историю обоих обращений и оба источника. Если при слиянии второе обращение просто исчезает, вы теряете данные о том, какой канал сработал.

Доведение до CRM: почему часть заявок не доезжает?

Этот участок проверяют реже всех, потому что он невидим. Форма отправилась, спасибо показалось, клиент доволен. Карточки нет.

Частые причины обрыва:

• Протухший токен или пароль интеграции. Связка работала полгода, ключ обновили, никто не заметил. Заявки уходят в пустоту, а запись об отказе остаётся в логе, куда никто не заглядывает.
• Невалидное значение поля. Клиент написал город, которого нет в справочнике, и система отклонила карточку целиком вместо того, чтобы принять её с пустым полем.
• Тихая дедупликация на стороне приёмника. Система решила, что это повтор, и не создала карточку. Для вас снаружи это выглядит как пропажа.
• Письмо в спаме. Связка «форма шлёт письмо, человек переносит руками» ломается на фильтре почты и на отпуске человека.
• Обращение без обязательного поля. Человек не оставил телефон, форма приняла, система требует - карточка не создалась.

Лечится участок двумя привычками, и обе стоят дешевле смены подрядчика.

Сверка чисел. Раз в неделю берёте число обращений в канале за сутки и число карточек за те же сутки. Расхождение больше пары процентов - идёте искать, где рвётся. Это скучная работа на десять минут, которая окупается первым же найденным обрывом.

Отдельный журнал приёма. Заявка записывается в собственное хранилище до того, как уйдёт в CRM. Тогда при обрыве у вас остаётся, что восстанавливать. Полезная деталь из нашей практики: сбой записи в журнал не должен блокировать саму отправку заявки - иначе подстраховка превращается в новую точку отказа.

Происхождение заявки: почему без разметки нечего измерять?

Расскажу про этот участок на собственном примере, потому что мы наступили на него сами.

Без разметки происхождения обработка заявок выглядит рабочей ровно до первого вопроса «а что окупается». Разбирая, откуда на claudelab.ru приходят обращения, мы получили неприятную картину: за четыре недели у 63% визитов Яндекс Метрика не определила источник. Сама заявка при этом источника не несла вовсе - контракт формы принимал телефон, ответы квиза и страницу отправки. Восстановить путь можно было только по логам веб-сервера, а они живут две недели.

Причина оказалась не в аналитике и не в людях. Пиксель Метрики из блока noscript был отдан как элемент интерфейса, и фреймворк добросовестно предзагружал эту картинку всем посетителям через link rel="preload" в шапке каждой статьи. Пиксель срабатывал раньше основного скрипта счётчика, реферер к тому моменту был обрезан политикой до корня домена, и визит начинался как «вход на главную, источник не определён».

Чинили двумя правками. Пиксель и сниппет счётчика отдали сырыми строками, чтобы предзагрузка их не трогала. В тело заявки добавили снимок происхождения: страницу входа, реферер, метки кампании и идентификатор визита счётчика.

Снимок устроен по правилу «первый показ побеждает»: происхождение запоминается при первом открытии любой страницы в сессии и дальше не перезаписывается. Человек может полчаса ходить по статьям и отправить форму с пятой страницы - заявка всё равно принесёт ту точку, с которой он вошёл. Телефон в журнал происхождения мы сознательно не пишем: для разбора воронки он бесполезен и только добавляет ответственности за персональные данные.

Честная оговорка, без которой пример был бы рекламой: правки выкачены 12.09.2026, и эффект на момент написания ещё не подтверждён вторым замером. Правильный вывод из истории другой и он не про нас: пока происхождение не попадает в тело заявки, любой разговор «какой канал окупается» стоит на догадках. Разметку дешевле заложить в первый день, чем восстанавливать задним числом по логам, которых уже нет.

Что остаётся людям?

Вопрос «а зачем мне тогда менеджеры» звучит на каждой второй встрече, поэтому отвечу прямо: обработка заявок с ИИ людей из отдела не убирает.

Что уходит помощнику:

• первый ответ в нерабочее время и в часы пик;
• одни и те же вопросы про наличие, доставку, режим работы, документы;
• сбор ответов клиента и заполнение полей карточки;
• напоминание о встрече или звонке;
• перенос данных из переписки в систему.

Что остаётся людям:

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

Отдел продаж от этого не исчезает, у него меняется структура дня. Разбор того, как перекладывается нагрузка внутри отдела, есть в отдельном материале про ИИ для отдела продаж.

Есть и обратная сторона, о которой честно предупредить. Когда помощник снимает рутину, слабость менеджера становится видна сразу: раньше он был занят перепиской и это выглядело работой. Часть команд после внедрения проходит через неприятный разговор о том, кто чем занимался.

Где ИИ на обработке заявок вредит?

Разберу по одному, потому что это ровно те места, где обработка заявок с ИИ превращается в потерянных клиентов.

Молчаливое закрытие сложного обращения. Помощник не понял запрос, выдал общий ответ и закрыл диалог. Человек ушёл, и в системе не осталось следа, что он приходил. Это типовая ошибка внедрения: выход на живого человека либо не предусмотрен, либо спрятан так, что до него не добраться. Проверяется просто - напишите боту что-нибудь нестандартное и посмотрите, предложит ли он человека и создастся ли карточка.

Ответ мимо базы знаний. Модель отвечает «от себя», когда нужного фрагмента в загруженных материалах нет. В переписке появляется услуга, которой у вас нет, выдуманный срок или цена, которой никто не утверждал. Практики закрывают это жёстким правилом: отвечать только по найденным в базе фрагментам, а на остальное честно говорить «уточню у коллеги». Отдельно закрываются правилами темы цены, сроков и любых обязательств.

Потеря контекста при передаче человеку. Клиент десять минут объяснял задачу боту, попал на менеджера и услышал «расскажите, пожалуйста, с самого начала». Лечится требованием к передаче: менеджер получает всю историю переписки, сформулированную цель обращения и уже собранные поля, чтобы продолжить с того места, где человек остановился.

К этим трём добавлю четвёртый пункт из практики: неверный тон. Жёсткий сценарий, написанный под идеального клиента, на раздражённом человеке читается как издевательство. Тон стоит проверять на реальных переписках из вашей же истории; придуманные примеры его не ловят. Типовые сбои сценариев разобраны подробнее в материале про ошибки чат-бота.

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

Правовые границы: согласие, реклама, персональные данные

Тема скучная, и за неё штрафуют. Обработка заявок почти всегда означает обработку персональных данных, и отсюда четыре рамки, в которые упирается работа с входящими в России.

Согласие на обработку персональных данных. Имя, телефон, почта в форме заявки - это персональные данные, и их сбор уже считается обработкой. Практика рынка - отдельный видимый элемент согласия в форме со ссылкой на политику; мелкая строка под кнопкой этой роли не выполняет.

Уведомление Роскомнадзора. Статья 22 федерального закона № 152-ФЗ обязывает оператора направить уведомление об обработке персональных данных в уполномоченный орган до начала обработки, за исключением случаев, которые закон отдельно выводит из-под этой обязанности. То есть обязанность возникает раньше, чем первая заявка.

Где физически лежит база. Часть 5 статьи 18 закона 152-ФЗ, введённая федеральным законом № 242-ФЗ от 21.07.2014, требует при сборе персональных данных граждан России использовать базы данных, расположенные на территории России. Для выбора платформы обработки заявок это прямой критерий: вопрос «где ваши серверы» задаётся до подписания.

Реклама по сетям электросвязи. Статья 18 федерального закона № 38-ФЗ «О рекламе» разрешает такую рекламу только при наличии предварительного согласия абонента, причём доказывать наличие согласия обязан тот, кто рекламу распространяет. Автоматическая рассылка и автоматический дозвон без участия человека прямо запрещены. Получатель в любой момент вправе потребовать прекратить рассылку, и требование исполняется немедленно.

Отсюда практический водораздел, который стоит держать в голове при постановке задачи подрядчику. Ответ в том же канале, куда человек написал сам, под рекламные ограничения не подпадает - это обслуживание обращения. Исходящая рассылка по собранной базе подпадает, и для неё нужно согласие именно на получение рекламы.

Цена вопроса выросла: федеральный закон № 420-ФЗ, вступивший в силу 30 мая 2025 года, повысил ответственность операторов персональных данных, введя в том числе оборотные штрафы за повторные нарушения. Подробнее про работу с клиентскими данными в нейросетях есть отдельный разбор - персональные данные клиентов и нейросети.

Как мерить результат: пять чисел

Снимите эти пять чисел на текущем потоке, до всякой автоматизации. Без замера «до» обработка заявок «после» описывается только ощущениями, и спорить о результате будет нечем.

Две оговорки к таблице, обе из практики.

Считайте медиану, а не среднее. Одно обращение, которое пролежало трое суток, поднимает среднее так, что оно перестаёт описывать реальность. Медиана показывает типичный случай.

Разделяйте каналы. Сводное время первого ответа по всем окнам разом прячет то самое окно, в которое никто не заглядывает. Именно оно вам и нужно.

С чего начать: четыре шага на две недели

За две недели обработка заявок с ИИ разворачивается целиком, если не пытаться закрыть все участки разом.

1. Замер недели. Соберите за семь дней: сколько обращений пришло, по каким каналам, сколько из них получили ответ и за какое время, сколько доехало до системы учёта. Таблицы в любом редакторе достаточно. Этот замер потом станет точкой отсчёта.
2. Один канал. Возьмите тот, где по замеру теряется больше всего, и подключите помощника только к нему. Один канал даёт понятный результат и ограниченный ущерб при ошибке.
3. Пилот с ручной сверкой. Две недели кто-то читает выборку переписок и сверяет карточки. Правьте формулировки и список полей по тому, что увидели, а не по тому, что задумывали.
4. Регламент. Запишите список тем, которые помощник не трогает, правило распределения, срок жизни карточки без движения и ответственного за нераспределённое. Регламент на одну страницу работает лучше, чем платформа за любые деньги без него.

Если проходить этот путь целиком не хочется, есть вариант отдать сборку связки под ключ: внедрение ИИ под ключ собирает участки в одну цепочку и передаёт её вместе с регламентом. Решение о том, с какого канала начинать, всё равно остаётся за вами - его принимают по вашему замеру.

Где вы сейчас

• Обращения идут в несколько окон, единого списка нет. Начинайте со сведения каналов в одно место и замера потока, нейросеть тут второй шаг. Нейросеть на хаосе ускорит хаос.
• Окна сведены, но отвечаете вы только в рабочее время. Ваш участок - скорость первого ответа. Посчитайте, сколько обращений приходит вне смены, и посмотрите разбор чат-бота поддержки как первой линии.
• Отвечаете быстро, но заявки не доезжают до системы. Ваш участок - доведение до CRM и сверка чисел. Разбор связки лежит в материале про ИИ для CRM.
• Всё доезжает, но непонятно, что окупается. Ваш участок - происхождение заявки. Добавьте в тело заявки страницу входа, реферер и метки кампании, дальше меряйте по источникам.

Чек-лист

Пройдите по семи пунктам: если каждый закрыт, обработка заявок у вас устроена без дыр.

1. Все каналы входящих перечислены на бумаге, у каждого есть имя ответственного.
2. Время первого ответа снято по медиане отдельно по каждому каналу, автоответы из расчёта исключены.
3. Число обращений в каналах за сутки сверено с числом карточек в системе за те же сутки, расхождение объяснено.
4. У помощника есть состояние «не уверен» и видимый выход на человека в каждом диалоге.
5. Список тем, которые помощник не трогает никогда, записан и доступен сотрудникам.
6. В теле заявки есть страница входа, реферер и метки рекламной кампании.
7. Форма содержит согласие на обработку персональных данных, а исходящие рассылки идут только тем, кто дал согласие на получение рекламы.