Причины отказов в CRM часто записывает менеджер — иногда по памяти, иногда по общему впечатлению от разговора. Полезная задача для ИИ здесь скромнее, чем кажется: сопоставить записанную причину с точной репликой клиента и честно сохранить то, что клиент не сказал. Ниже — последовательность, которая отделяет подтверждённые причины от догадок, с полным учебным примером и копируемым запросом. Это не отчёт о запуске нейросети на реальном кабинете: учебный пример полностью вымышленный и служит только для сверки правил.
Подготовьте безопасный срез проигранных сделок
Начните не с модели, а с выгрузки. Вам нужны только строки закрытых проигранных сделок и минимальный набор полей. В учебном наборе шесть записей, у каждой — нейтральный идентификатор, значение поля причины в CRM и дословная реплика клиента. Телефоны, имена, адреса и переписки с третьими лицами в такой срез не попадают. Рабочий контур и правила доступа к данным проверяются заранее, до первой выгрузки.
Поле причины отказа и связанная с ним причина доступны через API сделок: в описании сущности есть loss_reason_id, а вложенная сущность _embedded[loss_reason] отдаёт id и название причины, если запрос идёт с нужным параметром Сделки. Это техническая возможность получить связку «сделка — причина из поля CRM», а не доказательство, что записанная причина верна.
Важная граница: проигранные сделки не описывают всех лидов и не доказывают причинно-следственную связь. Если исправить причину в CRM, это ещё не доказывает влияние на выручку. Срез отвечает на узкий вопрос — совпадает ли запись менеджера со словами клиента.
Определите кодбук до классификации
Пока модель не видела строк, зафиксируйте категории и правила их присвоения. В учебном примере четыре метки:
price— клиент явно называет цену препятствием.timing— клиент явно откладывает решение из-за времени.competitor— клиент явно говорит, что выбрал другого поставщика.unknown— причина не высказана.
Отдельно определите, как каждая метка соотносится с записью в CRM:
match— цитата подтверждает записанную причину.mismatch— цитата указывает на другую категорию.unconfirmed— цитата не позволяет подтвердить запись.missing_input— цитаты нет.
Правило, которое стоит прописать явно: эмоция не равна причине. Раздражение клиента само по себе не даёт метку price или timing. Пустое поле тоже не доказательство: это отсутствие входных данных, а не вывод о причине.
Учебный пример
Ниже полный набор: входные строки, эталонная разметка и агрегат. Все данные вымышленные, совпадения случайны.
Входные строки
| ID | Причина в CRM | Цитата клиента |
|---|---|---|
| L1 | price | «Для нашего бюджета это дорого.» |
| L2 | price | «Бюджет есть, вернёмся к проекту в январе.» |
| L3 | competitor | «Пока не готовы ответить.» |
| L4 | price | — (поле пустое) |
| L5 | competitor | «Мы подписали договор с другим поставщиком.» |
| L6 | timing | «Ничего не работает, я раздражён.» |
Эталонная разметка
| ID | Метка | Evidence (дословно из цитаты) | Отношение к CRM |
|---|---|---|---|
| L1 | price | «Для нашего бюджета это дорого.» | match |
| L2 | timing | «вернёмся к проекту в январе» | mismatch |
| L3 | unknown | null | unconfirmed |
| L4 | unknown | null | missing_input |
| L5 | competitor | «подписали договор с другим поставщиком» | match |
| L6 | unknown | null | unconfirmed_emotion_not_reason |
Агрегат по достаточным основаниям
- price — 1
- timing — 1
- competitor — 1
- unknown — 3
- Итого строк — 6; 1+1+1+3=6.
- Полнота подтверждённых строк — 3 из 6, то есть 50%.
Действие по результату учебного примера — исправить или проверить поля на основании цитат. Менять CRM и писать клиентам автоматически по такому анализу не нужно.
Дайте промпт и разберите исключения
Промпт ниже работает сам по себе: в нём есть все строки, определения, схема ответа и правила проверки. Ничего не нужно подставлять из текста выше.
Ты помощник по задаче: сопоставить записанную причину проигранной сделки с точной репликой клиента и отделить подтверждённые причины от догадок менеджера.
Работай только по входным данным ниже. Не добавляй неизвестные значения и не выдавай учебные данные за результат реального сервиса.
Правила категорий:
price — клиент явно называет цену препятствием.
timing — клиент явно откладывает решение из-за времени.
competitor — клиент явно выбрал другого поставщика.
unknown — причина не высказана.
Правила отношения к CRM:
match — цитата подтверждает записанную причину.
mismatch — цитата указывает на другую категорию.
unconfirmed — цитата не позволяет подтвердить запись.
missing_input — цитаты нет.
Жёсткие условия:
1. Метка присваивается только по кодбуку.
2. Evidence — дословная подстрока из цитаты или null.
3. Эмоция не является причиной.
4. Пустое поле — это missing_input, а не вывод о причине.
5. Каждая строка получает ровно одну метку.
6. Не меняй CRM и не пиши клиентам.
Входные строки:
L1, crm_reason: price, quote: «Для нашего бюджета это дорого.»
L2, crm_reason: price, quote: «Бюджет есть, вернёмся к проекту в январе.»
L3, crm_reason: competitor, quote: «Пока не готовы ответить.»
L4, crm_reason: price, quote: null
L5, crm_reason: competitor, quote: «Мы подписали договор с другим поставщиком.»
L6, crm_reason: timing, quote: «Ничего не работает, я раздражён.»
Верни JSON по схеме:
{
"rows": [
{"id": "string", "label": "price|timing|competitor|unknown", "evidence": "string|null", "crm_relation": "match|mismatch|unconfirmed|missing_input|unconfirmed_emotion_not_reason"}
],
"counts": {"price": 0, "timing": 0, "competitor": 0, "unknown": 0},
"confirmed_share_percent": 0,
"exceptions": ["string"],
"unknowns": ["string"]
}
Проверки, которые нужно выполнить перед ответом:
— все шесть ID покрыты ровно один раз;
— сумма counts равна числу строк;
— confirmed_share_percent = число строк с crm_relation match или mismatch, делённое на число строк и умноженное на 100;
— каждая непустая evidence дословно входит в исходную quote;
— строки без цитаты и строки с эмоцией не получают метку причины.
Если проверка не проходит, не выдумывай ответ — укажи в exceptions точный вход и требуемое уточнение.
Разбор исключений. L2 формально записан как price, но клиент говорит про январь и наличие бюджета — метка timing, отношение mismatch. L3 и L4 — разные случаи: в L3 клиент ответил уклончиво, в L4 цитаты нет вовсе. L6 содержит эмоцию, но не причину, поэтому остаётся unknown. Только L1 и L5 подтверждают запись.
Технические проверки — покрытие ID, сумму counts, формулу доли и вхождение evidence в цитату — может выполнять агент или код по правилам. Человек нужен там, где решение смысловое: уточнить неизвестное бизнес-условие, разобрать исключение, решить, что делать с расхождением. Ручная вычитка каждой строки для этого не требуется.
Чтобы перейти к работе с базой шире одного среза, посмотрите сегментацию клиентов с ИИ и реактивацию в CRM. Первая помогает группировать записи по правилам, вторая — выстраивать следующий шаг по сегментам. Но сам по себе исправленный loss_reason не доказывает прирост выручки: это гипотеза, которую нужно проверять отдельно.
Автор метода «Машиночитаемый маркетинг»