Сначала отделите запись от объяснения
В CRM рядом могут стоять слова клиента и версия менеджера: «дорого» — это цитата, а «не подходит бюджет» — уже интерпретация. Уберите имя, контакты и детали сделки, оставив только то, что нужно для классификации. Попросите систему сохранять короткий исходный фрагмент и помечать, кто его написал. Это поможет не выдавать догадку сотрудника за прямую обратную связь.
Задайте категории до чтения результата
Начните с нескольких понятных групп: цена, срок, недостающая функция, внутреннее согласование, смена приоритета, конкурент или причина не указана. Для каждой запишите границы и пример. Если модель предлагает новую категорию, не добавляйте её автоматически: сначала проверьте несколько исходных карточек и убедитесь, что это не другое название уже существующего пункта.
Сохраните неопределённость
Один отказ может содержать несколько причин: высокая цена и неподходящий срок. Разрешите несколько меток или статус «нужен разбор», вместо того чтобы заставлять модель выбрать одну. Обязательно оставьте вариант «по записи определить нельзя». Он честнее, чем точная категория, полученная из скудного комментария. Спорные случаи передавайте человеку, который знает контекст сделки.
Проверяйте выводы на выборке
Возьмите случайную часть карточек и попросите двух менеджеров независимо присвоить категории, не показывая им вариант ИИ. Затем сравните расхождения и обсудите правила на конкретных примерах. Если система путает «дорого» и «нет бюджета», измените определения; если сам комментарий пустой, не лечите нехватку данных новым промптом. Перепроверьте также сделки, которые завершились покупкой: они помогают увидеть, что именно было решающим.
Не называйте рост категории причиной
Если стало больше отметок «срок», это ещё не доказывает, что сроки вызвали отказы. Сравните периоды, размер выборки, сегменты клиентов и изменения в процессе продаж. Учитывайте, что часть причин может быть просто лучше записана после обучения команды. Формулируйте результат как наблюдение: «в выборке чаще встречается такая формулировка», а причинное объяснение проверяйте отдельным исследованием.
Защитите данные и людей
Используйте только разрешённые поля и ограничьте доступ к исходным заметкам. Не включайте вывод модели в оценку работы конкретного менеджера без отдельной проверенной процедуры: разметка неполных записей способна несправедливо приписать человеку решение клиента. Срок хранения и способ удаления определите заранее, а выгрузку обезличивайте до загрузки в сервис.
Вопрос: когда менять предложение?
Не после одной диаграммы. Сначала проверьте повторяемость сигнала на нескольких периодах, откройте исходные фрагменты и спросите менеджеров, какие обстоятельства могли повлиять на запись. Затем сформулируйте узкую гипотезу и проверьте её отдельным тестом, например на новом варианте первого предложения. ИИ помогает разложить материал, но не доказывает, что изменение оффера устранит причину отказа.