Почему сотрудники используют ИИ, а бизнес не видит результата
Как связать ИИ с результатом бизнеса: найти задержки между отделами, назначить владельца процесса и измерять время до принятого результата вместо числа запросов к модели.
Менеджеры быстрее пишут письма, маркетологи готовят больше материалов, а руководитель по-прежнему ждёт коммерческое предложение несколько дней. Каждый сотрудник освоил новый инструмент, но общий путь клиента почти не изменился. Чтобы увидеть причину, полезно пройти весь процесс: от получения обращения до принятого результата.
В этой статье разберём условную компанию, которая продаёт оборудование и услуги внедрения. Пример учебный: он показывает способ анализа и не описывает результаты проекта NetLabCS. Главный вопрос — где ускорение отдельной операции действительно меняет работу бизнеса, а где готовый черновик просто попадает в следующую очередь.
В предложенном примере менеджер тратит двадцать минут на письмо, но несколько часов ждёт уточнения комплектации. Затем специалист проверяет цену, руководитель согласует исключение, а данные заново переносят в шаблон. Если письмо готовится за пять минут, остальные этапы остаются прежними. В отчёте пользователя ИИ появилась экономия времени, в сроке ответа клиенту — почти нет.
Соберите небольшую выборку недавних обращений. Для каждого отметьте получение, назначение ответственного, запрос недостающих сведений, подготовку, согласование и отправку предложения. Отдельно измерьте активную работу и ожидание. Так станет видно, какой участок ограничивает весь процесс. Причиной может оказаться отсутствие правил комплектации, а не медленное написание текста.
Если маркетинг отвечает только за заявку, продажи — за карточку, а технический отдел — за расчёт, никто не обязан довести обращение до предложения в согласованный срок. Для пилота нужен человек, который может договориться об общих правилах и решить спор между этапами. Его задача — определить границы процесса, условия передачи и способ приёмки.
Владелец результата не обязан согласовывать каждый документ. Он устанавливает, какая информация нужна на входе, кто подтверждает исключения и что считается готовым предложением. Например: состав соответствует запросу, цены взяты из утверждённого источника, сроки проверены ответственным сотрудником. Без этих условий оценка «ИИ подготовил документ» слишком расплывчата.
Этап
Проверяемый результат
Кто принимает
Получение обращения
Сохранены запрос и контакт, назначен ответственный
Руководитель продаж
Уточнение потребности
Отмечены обязательные сведения и открытые вопросы
Менеджер
Подготовка черновика
Предложение связано с исходным запросом и расчётом
Для первого изменения можно поручить модели извлечение требований из обращения и подготовку списка уточнений. Исходное сообщение сохраняют рядом с результатом, чтобы сотрудник видел, откуда взялся каждый пункт. Если клиент не указал объём или срок, система отмечает отсутствие данных. Правдоподобная догадка не должна становиться условием предложения.
Следующий шаг — черновик письма по проверенной карточке. Модель получает только необходимые сведения и утверждённые формулировки. Цены, наличие и обещания клиенту приходят из соответствующих систем или от ответственного сотрудника. Если проверенный источник недоступен, процесс останавливает этот участок и показывает причину. Это правило реализации нашего примера, а не свойство любой модели по умолчанию.
Проверка может незаметно съесть выигрыш. Если специалист вынужден заново читать всё обращение, искать источники и исправлять оформление, быстрый черновик не равен ускоренному процессу. Поэтому в пилоте учитывают время всех участников: автора, проверяющего и сотрудника, который устраняет ошибку после передачи.
Полезно заранее определить короткий формат результата. Например: извлечённое требование, фрагмент исходного сообщения и статус подтверждения. Такой документ проще проверить, чем длинное уверенное резюме без опорных данных. Новая форма должна помогать следующему исполнителю принимать решение, а не демонстрировать объём работы модели.
— Срок от обращения до принятого предложения, включая ожидание.
— Активное время всех участников на одну принятую заявку.
— Доля предложений, возвращённых на доработку.
— Количество ошибок в условиях, обнаруженных после отправки.
— Доля обращений, которые завершены в установленный срок.
Сравнивайте обращения сопоставимой сложности. Простое повторное предложение и новый комплексный проект нельзя объединить в одну среднюю цифру без разбивки. Показывайте размер выборки и отдельно разбирайте редкие длинные задержки. При небольшом потоке наблюдение за пилотом может занять больше календарного месяца: длительность определяется числом и разнообразием операций.
Допустим, подготовка стала быстрее. Решите, для чего используется освободившаяся ёмкость: отвечать на большее число обращений, подробнее прорабатывать сложные запросы или сократить очередь. Без такого решения организация может заполнить время дополнительными отчётами, а клиент не заметит улучшения.
Экономию часов сначала стоит считать изменением загрузки, а не сокращением расходов. Денежный эффект возникает при понятном механизме: уменьшились оплачиваемые переработки, исчезла внешняя работа или вырос объём принятых заказов при сохранении качества. Связь с выручкой требует отдельной проверки; быстрые письма сами по себе её не доказывают.
Перед подключением следующего отдела проверьте трудные случаи: неполный запрос, противоречивые условия, отсутствие согласующего и недоступность источника цен. Исполнитель должен понимать, кто продолжит работу вручную и где сохранится история. Разбор исключений показывает реальную готовность лучше, чем демонстрация одного удачного ответа.
Повод для статьи — материал McKinsey «AI is changing work. Now it has to change the organization» от 5 октября 2026 года. Авторы связывают следующий этап внедрения ИИ с изменением организации работы. Здесь эта идея раскрыта через самостоятельный учебный пример; схема, критерии приёмки и рекомендации предложены редакцией NetLabCS.
