ИИ-помощник менеджера: обработка заявок и работа с CRM

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

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

Какая работа менеджера повторяется?

Менеджер по продажам в торговой компании большую часть дня не продаёт — он переводит с языка клиента на язык учёта. Хронометраж на выборке из 20–30 входящих обращений показывает примерно такую картину:

Семь из девяти этапов повторяются при каждой заявке и описываются правилами или шаблоном. Именно они съедают время, и именно их берёт помощник. Два последних — переговоры и исключения — не формализуются и остаются за человеком; попытка отдать их модели создаёт обещания, за которые компания не готова отвечать.

Деньги здесь считаются просто: число заявок в день, умноженное на минуты подготовки до момента, когда менеджер начинает собственно продавать, плюс потерянные заявки — те, что пролежали в почте до вечера или ушли в спам, — плюс ошибки в составе, которые обнаруживаются при отгрузке. Этот расчёт по собственным данным за месяц — основание для решения, а не общие рассуждения о пользе ИИ.

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

Где заканчивается квалификация и начинаются переговоры?

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

Помощник останавливается там, где начинается обещание. Он может написать «позиция в наличии, 240 шт. по цене вашего типа 1 180 ₽», потому что это факт из учёта. Он не может написать «сделаем скидку» или «отгрузим завтра», потому что это решение, и за него отвечает менеджер. На странице Like Sites этот принцип сформулирован как разделение ролей: агент читает входящие данные, готовит черновик, эскалирует всё, что подпадает под стоп-слова и пороги, и ведёт журнал; человек утверждает правила, согласует действие и решает спорные случаи (страница «ИИ-агенты для бизнеса», проверено 1 ноября 2026).

Это соответствует и готовности людей. В опросе VK WorkSpace и Hi-Tech Mail среди более 3000 работающих респондентов только 9% готовы доверить ИИ самостоятельное принятие даже несложных решений без участия человека, тогда как подготовку протоколов, контроль сроков, аналитику и поиск информации готовы передать 25–31% (CNews, 23 сентября 2026). Помощник, который готовит и предлагает, встраивается в работу отдела продаж; «ИИ-продавец», который решает сам, вызывает сопротивление команды и риск для компании.

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

Как извлекать товары, количество и контакты?

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

Что извлекается из обращения:

Сопоставление позиций с номенклатурой — четыре уровня, от надёжного к интерпретации:

1. По артикулу или штрихкоду — точное совпадение, правило.
2. По таблице соответствий «как называет клиент → номенклатура», которая накапливается с каждым подтверждением менеджера. Через несколько месяцев она покрывает большинство повторяющихся формулировок постоянных клиентов.
3. По истории заказов клиента — «то же, что в прошлый раз» разрешается по последним сделкам с пометкой, из какого заказа взято.
4. По смыслу — модель предлагает ближайшую позицию с объяснением; подтверждает менеджер.

Уровни 1–3 — детерминированные, уровень 4 — модельный, и результат уровня 4 никогда не уходит клиенту без подтверждения. Это правило, а не рекомендация: ошибка в позиции — это неверный счёт, а в B2B — неверная отгрузка.

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

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

Откуда брать актуальную цену и наличие?

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

Что именно читается:

• Доступный остаток по складам, участвующим в продажах этому типу клиентов, — физический минус резерв, а не физический.
• Цена по типу цены клиента: розница, опт, индивидуальный тип — из карточки контрагента в учёте или по правилу для нового клиента.
• Единица и кратность: упаковка, минимальная партия.
• Признаки: снят с продажи, под заказ, ожидается поставка с датой.

Если учёт — 1С, чтение идёт через доступный интерфейс конфигурации: стандартный интерфейс, HTTP-сервис или обмен; что доступно, зависит от конфигурации, релиза и доработок, и это выясняется обследованием (интеграция интернет-магазина с 1С). Если учёт — МойСклад, читается через JSON API с учётом лимитов (интеграция с МоимСкладом). Помощнику нужны права только на чтение этих объектов — и это одно из немногих мест, где доступ к учёту ему действительно необходим.

Правила для черновика ответа по цене и наличию:

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

Для магазина с собственным складом и несколькими каналами эти же данные уходят на сайт и площадки; помощник читает тот же доступный остаток, что и витрина, и никаких «своих» цифр у него нет.

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

Как создавать запись без дублей?

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

Правила:

1. Поиск перед созданием — по нормализованным ключам: телефон в едином формате, почта в нижнем регистре, ИНН для организаций. Совпадение по имени ключом не является.
2. Найден контакт — обращение привязывается к нему: новая сделка, если это новая заявка; касание или комментарий к открытой сделке, если это продолжение переписки по ней. Определение «продолжение или новая» — по теме письма, ссылке на номер заказа и времени; при неуверенности — новая сделка с пометкой «возможно, продолжение» и задачей менеджеру объединить.
3. Не найден — контакт создаётся с извлечёнными данными и признаком «создан помощником», чтобы менеджер проверил при первом касании. Для организаций без ИНН контакт не создаётся — готовится уточняющий вопрос.
4. Повторное письмо того же содержания — пересылка, «не дошло?» — не создаёт вторую сделку: проверка по идентификатору сообщения и по сходству с открытыми сделками контакта за последние часы.
5. Сделка создаётся на согласованном этапе согласованной воронки с источником обращения, типом, составом позиций в читаемом виде, ответственным по правилу распределения и задачей с содержанием. Это правило компании, а не помощника.
6. Персональные данные — только в CRM и учёте. В аналитику и в журнал модели уходят обезличенные признаки. Где хранятся контакты клиентов и какому провайдеру модели уходят тексты писем — вопрос обработки персональных данных с требованиями закона (Федеральный закон № 152-ФЗ, актуальная редакция); что именно требуется в вашем случае, определяет юрист, а задача проектирования — знать маршрут каждого письма и зафиксировать его в договоре с исполнителем.

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

Права помощника в CRM — на чтение контактов и сделок и на создание контактов и сделок по правилу; без прав на удаление, объединение, изменение ответственного и смену этапов, кроме согласованного стартового. Как устроена интеграция магазина с CRM в целом — правило дублей как решение компании, источник первого контакта, обезличенные события в аналитику — описано на странице интеграция интернет-магазина с CRM; помощник работает внутри этих правил, а не создаёт свои.

Как готовить ответ и передавать исключения?

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

Карта обработки заявки — путь каждого обращения:

1. Поступление. Письмо, форма, сообщение попадают в очередь с источником, временем и идентификатором.
2. Классификация. Тип обращения; спам и рассылки отсеиваются; претензии и запросы документов маршрутизируются по своим правилам, не в продажи.
3. Извлечение. Позиции, количество, контакт, реквизиты, доставка, условия — с уверенностью по полям.
4. Сопоставление. Номенклатура по четырём уровням; клиент по ключам.
5. Чтение фактов. Остаток, цена по типу клиента, кратность — из учёта.
6. Проверка правил. Обязательные поля есть; позиции сопоставлены с достаточной уверенностью; клиент не в стоп-листе; сумма ниже порога; нет запросов вне компетенции помощника.
7. Решение. Все проверки пройдены — черновик ответа и запись в CRM; иначе — исключение с причиной и задачей.
8. Подтверждение менеджером. Правка или отправка; результат подтверждения пишется в таблицу соответствий и в метрики.
9. Документ в учёте — по правилу: непроведённый заказ покупателя или счёт, если согласовано; иначе создаёт менеджер.
10. Журнал. Каждый шаг с данными и временем.

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

Очередь исключений — не свалка «не разобрал», а список с основаниями:

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

Какие обещания агенту запрещены?

Матрица разрешённых действий — документ, который подписывается до запуска и определяет полномочия помощника по каждой системе и каждому типу действия. Без него «ИИ-помощник» — риск, с ним — инструмент.

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

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

Как тестировать на исторических обращениях?

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

Что подготовить:

• Выборку из 100–300 обращений за закрытые периоды по всем каналам: письма с вложениями, формы, сообщения из мессенджеров, расшифровки голосовых — в том виде, как они пришли, после обезличивания или в рамках согласованных доступов.
• Фактический результат по каждому: сопоставленные позиции, созданные сделки и документы, отправленный ответ.
• Выгрузку номенклатуры с артикулами, историю заказов клиентов из выборки, список типов цен, стоп-лист, список согласованных замен и стандартных сроков.
• Шаблоны ответов, которые компания считает правильными.

Что измеряется на прогоне:

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

Пилот после прогона — один канал или один тип заявок, режим черновиков с полным подтверждением, еженедельный отчёт по метрикам, условия остановки, согласованные заранее: доля пропущенных проблем выше порога, рост жалоб клиентов, доля исключений не снижается. Как устроен пилот агента в целом — роли доступа «читает / пишет / предлагает / запрещено» по системам, уровни автономности, условия остановки и что должно быть в договоре — разобрано в статье как внедрить ИИ-агента в бизнес: пилот, тесты, безопасность. На условиях Like Sites пилот ограничен одним процессом, первая неделя — только черновики, оплата 50% на старте и 50% после приёмки по метрикам, код и документация передаются клиенту (страница «ИИ-агенты для бизнеса»).

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

Как измерять время и полноту обработки?

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

Метрики эксплуатации — «до» и «после» по одинаковой методике:

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

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

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

Когда достаточно стандартной CRM-автоматизации?

Помощник с языковой моделью — не первый инструмент и не для всех. Честные признаки, что он не нужен или преждевременен:

• Заявки структурированы. Если клиенты оформляют заказы через корзину или форму с выбором позиций из каталога, извлекать нечего: передача заказа в CRM с составом, источником и задачей — стандартная интеграция без ИИ. Письма в свободной форме — единицы в день.
• Поток мал. Десятки обращений в день менеджер разбирает быстрее, чем настраивается и проверяется помощник; регулярные расходы на сопровождение не окупятся.
• CRM не используется как процесс. Воронка не настроена, этапы не двигаются, задачи не ставятся. Помощник будет создавать сделки, которые никто не ведёт; сначала процесс в CRM.
• Нет доступа к учёту на чтение. Без остатков и цен из учёта помощник не может утверждать факты, а значит, не может готовить ответ; остаётся извлечение и запись в CRM — это слабый эффект за полную цену.
• Номенклатура не готова. Дубли позиций, отсутствующие артикулы, разные единицы — сопоставление будет ошибаться на любом уровне; порядок в номенклатуре идёт первым.
• Главная проблема — переговоры, а не подготовка. Если менеджеры теряют сделки на этапе условий, помощник не поможет; это вопрос обучения, прайса и полномочий.
• Нет ответственного за очередь исключений и за правила. Помощник останется в режиме черновиков навсегда, а поддержка будет оплачиваться без результата.
• Готовый сервис закрывает задачу. Для типовых сценариев — классификация писем, автоответы по шаблону, подстановка данных из CRM — существуют встроенные функции CRM и подписочные сервисы; разработка оправдана, когда нужна связка «свободный текст → ваша номенклатура → ваш учёт → ваша CRM» с матрицей запретов и журналом.

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

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

Ситуация: у вас десятки писем в день с заявками в свободной форме, менеджеры разбирают их вручную, часть теряется, а CRM заполняется потом и не полностью. Что разберём: каналы заявок, число в день, CRM, учётную систему, что нужно извлекать и типичные исключения. Результат: честный ответ — стандартная интеграция, помощник или сначала порядок в CRM и номенклатуре — с картой обработки и матрицей действий, если помощник оправдан. Действие: разобрать один сценарий обработки заявок.