
Потерянная заявка — это обращение, которое не дошло до понятного результата: ответа, записи, расчёта или отказа. CRM помогает увидеть путь заявки по этапам, а ИИ — разобрать переписки и звонки, найти повторяющиеся задержки и пропуски. Начните с одного участка, проверьте данные и сравните показатели до и после небольшого пилота. Решения, которые затрагивают клиента, деньги или его данные, оставьте под контролем сотрудника.
Коротко — и что с этим делать
Соберите в одном месте обращения и их статусы, определите, где клиент чаще всего перестаёт получать ответ, и проверьте эту гипотезу на одном процессе. ИИ может помочь с анализом потока, но не должен без проверки менять условия сделки или отправлять клиенту важные обещания. Начните с аудита текущего пути заявки и выбора безопасного пилота.
Записаться на бесплатный аудит →Заявка не обязательно пропадает из журнала или почты. Часто она есть, но бизнес не доводит её до следующего шага. Человек написал в Telegram, позвонил или оставил форму на сайте — сообщение увидели, однако не назначили ответственного. Другой клиент получил ответ, но после расчёта ему не перезвонили. Третий дождался записи, но сведения о ней остались только в личной переписке сотрудника.
Поэтому полезно считать потерями не только обращения без ответа. К ним относятся заявки без ответственного, обращения с задержкой, дубли, пропущенные звонки без обратного контакта, а также незавершённые договорённости. При этом не каждый клиент, который не купил, был «потерян»: он мог отказаться осознанно. Важно отличать отказ от сбоя процесса и фиксировать причину, когда она известна.
Путь заявки обычно проходит через несколько шагов: поступление, регистрация, назначение ответственного, первый ответ, уточнение потребности, предложение, следующий контакт и итог. Сбой может возникнуть на любом из них. Если компания смотрит только на число продаж за месяц, она видит итог, но не понимает, где именно обращение перестало двигаться.
Сначала перечислите каналы, через которые клиенты обращаются: телефон, сайт, электронная почта, Telegram, MAX и ВКонтакте. Затем проверьте, куда попадает каждое обращение и можно ли связать его с дальнейшей работой. Если сообщения хранятся отдельно, у руководителя может не быть полной картины: в CRM видны одни заявки, в телефонии — другие, а часть договорённостей остаётся в рабочих чатах.
Для каждого этапа определите, что означает его завершение. Например, «ответили» — не значит отправили автоматическое приветствие. Лучше зафиксировать, что сотрудник дал содержательный ответ или связался с клиентом. «Назначена запись» должна означать, что время и исполнитель внесены в расписание, а не просто обсуждались в переписке.
На первом этапе не нужно перестраивать все процессы. Возьмите одну услугу или один канал, например обращения на запись в автосервисе. Проверьте выборку заявок за несколько недель: сколько поступило, сколько зарегистрировано, где не было ответственного, как быстро состоялся первый содержательный ответ и чем закончилась работа. Период и набор показателей зафиксируйте заранее, чтобы потом сравнить сопоставимые данные.
Если CRM уже используется, проверьте не только наличие карточек, но и качество заполнения. У заявки должны быть понятный источник, текущий этап, ответственный и следующий шаг. Если сотрудники ведут работу в системе, но статусы не отражают реальность, отчёт будет выглядеть аккуратно, а решения на его основе — ненадёжно. О том, как подобрать и связать решения для разных процессов, можно прочитать в разделе услуг KM2B.
CRM хранит структуру процесса: обращения, ответственных, этапы, задачи и итоги. По этим сведениям проще заметить, что, например, часть заявок долго остаётся без исполнителя или регулярно зависает после отправки предложения. Если данные заполнены непоследовательно, система покажет лишь то, что в неё внесли, поэтому автоматизация не заменяет договорённости о правилах работы.
ИИ полезен там, где нужно разобрать большой поток неструктурированных материалов: тексты переписок, заметки сотрудников, записи разговоров при наличии законных оснований и настроек доступа. Он может сгруппировать похожие причины обращений, выделить сообщения без ответа или помочь составить сводку по этапам. Это подсказка для проверки, а не доказательство ошибки конкретного сотрудника: результат следует сверять с исходным обращением.
Например, если клиенты часто спрашивают о цене и после ответа не возвращаются, анализ может показать, что в переписке не предложен следующий шаг. Но причина может быть и в сроках, наличии товара, расписании или неподходящем предложении. ИИ помогает быстрее сформулировать гипотезу, а руководитель проверяет её на конкретных случаях.
| Инструмент | Что помогает увидеть | Что важно проверить |
|---|---|---|
| CRM | Этап заявки, ответственного, срок и зафиксированный результат | Заполняют ли сотрудники карточки и одинаково ли понимают статусы |
| ИИ для анализа обращений | Повторяющиеся темы, возможные задержки и пропуски в большом объёме текста | Верно ли истолкованы сообщения и не затронуты ли лишние данные |
| Совместная работа | Связь между этапами, перепиской и итогом обращения | Подтверждает ли сотрудник вывод и остаётся ли за ним решение |
Мы описываем такие решения не как замену CRM, а как дополнительный способ находить закономерности и поддерживать сотрудников. Примеры направлений автоматизации собраны в разделе продуктов KM2B; конкретный состав зависит от источников данных и задачи компании.
С чего начать? Выберите один повторяющийся процесс, зафиксируйте входные данные и оставьте контроль результата человеку. Это может быть первичная сортировка заявок с сайта, поиск обращений без ответа или подготовка сводки по звонкам. Не начинайте с одновременного анализа всех каналов и подразделений: при большом охвате сложнее понять, что именно повлияло на результат.
Перед пилотом договоритесь, какие сведения нужны системе и какой результат она должна выдавать. Например: список обращений, у которых нет ответственного или следующего действия, с указанием ссылки на карточку. Сотрудник проверяет список и подтверждает, есть ли реальная проблема. На первом этапе не стоит автоматически закрывать заявки или отправлять клиентам сообщения на основании предположения модели.
Как проверить пользу? До запуска зафиксируйте время, ошибки и потери, затем сравните те же показатели после пилота. В качестве исходной точки можно измерить долю заявок без назначенного ответственного, время до первого содержательного ответа, число пропущенных обращений и трудозатраты на ручную проверку. Уточните, как именно считаются показатели, чтобы сравнение не зависело от смены правил.
Сравнивайте похожие периоды и учитывайте сезонность, рекламные активности, график сотрудников и изменение количества обращений. Если после запуска выросло число зарегистрированных заявок, это может объясняться не улучшением обработки, а новым каналом привлечения. Зафиксируйте такие изменения отдельно. Тогда станет понятнее, помог ли пилот обнаруживать сбои или просто совпал с изменением нагрузки.
Стоимость работ определяется после аудита: она зависит от каналов, состояния CRM, объёма данных и нужных интеграций. Разумно начать с недорогого пилота на узком участке. Для такого пилота окупаемость обычно оценивают в горизонте 2–4 месяцев, но это ориентир, а не обещание: расчёт зависит от исходных потерь, стоимости времени команды и результата проверки. Подход к расчёту можно посмотреть на странице оценки окупаемости.
Найдём участок, где заявки останавливаются
На бесплатном аудите за 30 минут обсудим путь обращения, источники данных и показатели для пилота. По итогам можно определить, что проверять первым и какие действия оставить сотруднику.
Бесплатный аудит за 30 минут →Если в заявках есть сведения о клиентах, проект нужно организовать с учётом 152-ФЗ. До передачи данных в систему определите цель обработки, правовые основания, состав сведений, место хранения и круг сотрудников с доступом. Проверьте договоры с поставщиками сервисов и настройки хранения. Не загружайте переписки или записи разговоров в сторонний инструмент просто потому, что это удобно: сначала оцените, допустимо ли использовать эти данные для выбранной цели.
Какие данные и действия ограничить? Передавайте только необходимые данные, а деньги, права, обещания клиенту и необратимые изменения оставляйте на одобрение сотрудника. Для поиска задержек модели часто достаточно номера карточки, этапа и текста, из которого убраны лишние идентификаторы. Доступ к исходным данным следует выдавать только тем, кому он нужен для работы, а сроки хранения и удаления — определить заранее.
Разделяйте подготовку подсказки и действие от имени компании. ИИ может предложить сотруднику ответ или отметить возможное отсутствие следующего шага. Но изменение цены, подтверждение возврата, предоставление доступа, запись с финансовыми последствиями и отправка обещания о сроке должны проходить проверку уполномоченного человека. Это особенно важно, если ошибка может повлиять на деньги, права клиента или обязательства организации.
Самая распространённая причина — неполные или противоречивые записи. Если часть сотрудников ставит этап «в работе» после первого звонка, а часть — после отправки предложения, сравнивать их результаты некорректно. Перед запуском полезно согласовать короткий справочник статусов и объяснить, когда их менять. Он не должен превращаться в набор формальностей: достаточно нескольких состояний, которые помогают принять следующее решение.
Вторая причина — ошибочные выводы по отдельным случаям. Сообщение без ответа может быть дублем, техническим уведомлением или обращением, на которое клиент уже получил ответ по телефону. Поэтому ИИ должен показывать, на каких данных основана рекомендация, а сотрудник — иметь возможность отметить неверную находку. Такие отметки помогают оценивать качество анализа.
Третья причина — попытка измерить слишком много сразу. Если пилот меняет сценарий общения, правила CRM и график сотрудников одновременно, результат трудно связать с конкретным изменением. Лучше менять по одному существенному элементу и вести журнал решений: что запустили, кто проверяет результаты и когда проводится повторная оценка.
Расширение имеет смысл, когда команда понимает, какую проблему решает инструмент, сотрудники проверяют рекомендации, а показатели можно сопоставить с исходной точкой. Оцените не только число найденных пропусков, но и сколько из них подтвердились, сколько времени занимает проверка и появились ли новые ошибки. Если находок много, но большинство ложные, процесс требует доработки до подключения новых каналов.
Затем перенесите проверенные правила на следующий участок — например, с заявок сайта на телефонные обращения. До расширения уточните, отличаются ли там этапы и требования к данным. Для клиники, салона и розничной точки схема обработки может быть разной, даже если задача звучит одинаково: не оставлять клиента без ответа.
В итоге полезный проект начинается не с выбора модной технологии, а с понятного вопроса: на каком шаге обращение перестаёт двигаться и как это подтвердить. CRM помогает восстановить ход работы, ИИ — быстрее просмотреть повторяющиеся ситуации, а сотрудник — проверить контекст и принять решение. Такой порядок снижает риск внедрить автоматизацию ради самой автоматизации и позволяет оценить пользу на конкретном процессе.
Проверьте путь заявки на одном процессе
Расскажите, где сейчас фиксируются обращения и как сотрудники передают их друг другу. Команда KM2B поможет определить участок для пилота, предварительные показатели и ограничения по данным — без обещания результата до проверки.
Обсудить бесплатный аудит →