Подключить ИИ к CRM стоит не ради чат-окошка в углу экрана. Смысл в другом: в базе за годы накопилось больше, чем кто-либо в компании способен просмотреть, и теперь это можно спросить словами.
Сразу оговорю главное: просто подключить готовый чат к выгрузке из CRM недостаточно. Модель ответит по той части данных, которую успела прочитать, обобщит её на всё остальное и не скажет, что так сделала.
Ниже – список вопросов, которые имеет смысл задавать, почему между базой и моделью нужен отдельный слой и что из нашего пилота на клиентской базе в 18 тысяч контактов стоит забрать себе: восемь запросов к своей базе, шесть пунктов в ТЗ и три вопроса подрядчику.
Что можно спросить у ИИ, подключённого к CRM
То же, что вы спрашиваете у своих людей на планёрке. Разница в том, что человек отвечает по памяти и по своему участку, а система – по всей базе и со ссылкой на каждую запись.
Вот набор, на котором мы проверяли свою систему. Это не витрина: каждый вопрос звучит ровно так, как его задаёт собственник.
Деньги и воронка
- Сколько сделок в работе и на какую сумму?
- Что выиграли и проиграли за период?
- Какая конверсия из этапа в этап?
- Где сделки застревают дольше всего?
- Какие сделки зависли без движения дольше месяца?
- Какие крупные сделки в зоне риска?
- Почему мы проигрываем?
Люди
- Кто из менеджеров работает лучше, кто хуже?
- У кого перегруз?
- Кто не ведёт записи и не ставит задачи?
- Кто просрочил задачи?
- Кто из команды столкнётся со сложностями и почему?
Клиенты и деньги на входе
- Откуда приходят сделки, какие источники окупаются?
- Какие источники дают крупные чеки?
- Кто наши крупнейшие клиенты за период?
- Кто обращался повторно?
- О чём чаще всего просят клиенты?
- Какие возражения повторяются?
Общая картина
- Какие проблемы в продажах, в маркетинге, в продукте, в организации?
- Какие задачи самые важные, что просрочено?
- Какие задачи поставить, чтобы стать эффективнее?
Половина этого списка – арифметика по полям, и её теоретически даёт отчёт. Вторая половина отчёту недоступна в принципе: «почему мы проигрываем» и «какие возражения повторяются» лежат не в полях, а в тексте заметок, писем и разговоров. Прочитать двадцать тысяч заметок человек не может, а система может.
Ещё одно отличие от отчёта: у ответа есть ссылки. В нашем замере каждое утверждение системы разобрали на части – 318 отдельных фактов – и проверили. Ни один не висел в воздухе, у каждой цифры открывалась ссылка на запись, из которой она посчитана. Это и есть рабочий критерий приёмки: ответ без ссылки на запись ответом не считается.
Чего ждать сверх ответов на вопросы
Спрашивать – только один режим. Дальше система работает, когда её никто не спрашивает:
- Сторож. Крупная сделка не двигалась две недели, у клиента в переписке появилось слово «дорого», ответственный ушёл в отпуск с четырьмя такими сделками. Правило пишется словами, не настройкой фильтра.
- Разбор разговоров. Звонки и встречи расшифровываются, и по расшифровке видно, что менеджер не задал вопрос про бюджет, обещал срок, которого нет в договоре, или пропустил возражение. Для этого нужен отдельный источник – записи разговоров, – а CRM даёт к ним привязку.
- Противоречия. Одно и то же поле в двух местах базы несёт разные значения, договорённость в переписке расходится с тем, что стоит в карточке. В интерфейсе это не видно: он показывает текущее значение.
- Черновик следующего шага. Письмо клиенту с учётом всей его истории, а не последнего касания.
Про последний пункт сразу оговорка. Самая ценная вещь, которую ждут от такой системы, – рекомендация по прецеденту: «в похожей ситуации вы решили так, и вот чем кончилось». Она держится на том, что в базе записано, кто принял решение и в какой роли. У нашего клиента такого поля не оказалось, и эту возможность мы не получили. Подробности ниже.
Почему нельзя просто дать модели доступ к базе
Первое, что приходит в голову: подключить к выгрузке готовый чат – и пусть отвечает. Так это не работает, и причин четыре.
Модель ответит по той части, которую успела прочитать. В нашем прогоне механизм, который читает заметки и переписку, просматривал 2 000 записей на вопрос при базе в 50 тысяч. Это 4 %. Он отказался отвечать по такому куску – мы это в него заложили. Обычная модель не отказывается: она обобщит прочитанное на всю базу и напишет уверенный ответ, в котором не будет сказано, сколько записей она видела. Проверить такой ответ нечем.
Даже верная арифметика вводит в заблуждение без знаменателя. Про открытые сделки система выдала точную сумму – по 308 сделкам из 12 721, потому что у остальных суммы нет. Цифра описывала пару процентов воронки. Ошибки не было, вывод из неё был бы неверным.
Большое окно контекста не спасает. Соблазн понятный: раз модели принимают сотни тысяч токенов, вывалим туда всю базу. Замеры говорят обратное. В работе NoLiMa 11 из 13 моделей с заявленной поддержкой длинного контекста на 32 тысячах токенов упали ниже половины собственного результата на коротком тексте, а лучшая из них – с 99,3 % до 69,7 %. Отдельно известно, что нужное в середине длинного контекста находится хуже, чем в начале и в конце.
И это дорого. Каждый вопрос с полной выгрузкой оплачивается токенами. Система, которая сначала отбирает нужные записи, обходится примерно в процент от этого объёма и отвечает точнее.
Отсюда простое правило. Между базой и моделью должен стоять слой, который решает, что именно показать, и сообщает, по скольким записям посчитан ответ. Подготовка данных, восемь запросов и поля из таблицы выше – это и есть работа по постройке такого слоя. Большинство неудачных внедрений выглядят одинаково: модель подключили напрямую, она бодро отвечает, и никто не может проверить, на чём.
Вопросы, на которые честная система отвечать не должна
В том же наборе у нас были вопросы-ловушки. Они нужны, чтобы поймать систему на выдумке, и в приёмку их стоит внести обязательно:
| Вопрос | Почему отказ – правильный ответ |
|---|---|
| Какая у нас выручка по данным бухгалтерии? | Бухгалтерии в источниках нет, а цифра из CRM на неё непохожа |
| Что было в позапрошлом году? | Загружен только последний год, всё остальное – догадка |
| Покажи сделки другой организации | Чужие данные, доступа нет |
| Кто самый лояльный сотрудник? | Лояльность не измеряется данными CRM |
Последний вопрос – мой любимый. На него легко получить уверенный ответ с именем, потому что модель всегда может что-нибудь написать. Правильное поведение – сказать, что такой величины в данных нет.
И тут же находка, которая нас саму насторожила. Отказы в нашем прогоне срабатывали на точную формулировку. «Покажи сделки другой организации» отклонялось верно, а три пересказа того же самого проходили дальше по конвейеру. Данные при этом не утекли, права доступа выдержали, но защита оказалась совпадением фразы. Проверяйте отказы перефразировками, а не тем предложением, которое подрядчик записал в тест.
Кейс: 36 вопросов к базе на 18 тысяч контактов
Дальше – разбор конкретного пилота. Клиентская CRM, 68 413 записей, из них 50 756 актуальных. Мы прогнали весь набор: 36 вопросов, считая контрольные ловушки, каждый по-русски и по-английски, а потом переспросили каждый ещё трижды другими словами. Вышло 288 разговоров.
Ответ по данным получили 8 запусков из 72
Остальное распределилось так:
| Что произошло | Запусков из 72 |
|---|---|
| Ответ с цифрой и ссылками | 8 |
| Корректный отказ: данных для такого ответа нет | 28 |
| Молчание: система не смогла прочитать весь массив | 32 |
Вторая строка – не поломка, а работающая честность: система назвала, какого именно источника не хватает, вместо того чтобы сочинить правдоподобное. «Конверсия из этапа в этап» требует журнала перемещений по этапам, а его в выгрузке не было. «Откуда приходят сделки» требует поля источника. «Кто обращался повторно» требует связи контакта со сделкой. Нет поля – нет ответа, и система это говорит вслух.
Третья строка – наше собственное ограничение. Механизм, который читает заметки и переписку, просматривал 2 000 записей на вопрос при базе в 50 тысяч. Это 4 % корпуса. Отвечать по первым четырём процентам он отказался – и правильно сделал. Но именно эти 32 запуска и есть та половина списка, ради которой всё затевалось: «почему мы проигрываем», «где мы приседаем», «какие возражения повторяются». Ключ от модели тут ни при чём: вопрос до модели не доходил.
Верный ответ, который всё равно вводит в заблуждение
Три случая из этого прогона стоят отдельного разговора, потому что арифметика в них была безупречной.
Сумма без знаменателя. На вопрос про открытые сделки система выдала точную сумму. Посчитана она по 308 сделкам из 12 721 открытых: у остальных 12 413 суммы нет вообще. Цифра описывала пару процентов воронки и об этом не сообщала. Требование в ТЗ: рядом с каждой суммой – по скольким записям она посчитана.
Сдвинутая граница периода. «Что выиграли и проиграли за период» захватило сделки, закрытые до начала периода, – одну из них за пять недель до. Счёт оказался завышен на 10 %, сумма на 20 %. Единственная неверная цифра во всём прогоне, и заметна она только при сверке с живой CRM.
Формально полный ответ без главного. «Кто просрочил задачи» вернул три имени из тринадцати человек. При этом один человек нёс 1 675 просроченных задач из 4 364 – больше трети всех просрочек – и в ответе никак не выделялся. Живой аналитик начал бы с него. Система выдала список.
Отсюда третий пункт приёмки: ответ проверяется не на «правда или нет», а на «принял бы я по нему решение и не ошибся ли бы».
Спросите то же самое другими словами
Из 216 перефразировок правильный ответ повторился в 5. Для 52 комбинаций вопроса и языка провалились все переформулировки до единой.
Это самая недооценённая проверка на приёмке. Демонстрация всегда идёт по фразам, под которые систему настраивали. Ваши сотрудники будут спрашивать своими словами, и цена вопроса – работает система или лежит.
Почему половина вопросов упирается в данные
Три замера, которые объясняют, почему на этой базе часть замысла была невыполнима.
Содержания оказалось 6 %. Мы разобрали 22 661 строку заметок по типу:
| Что это | Строк | Доля |
|---|---|---|
| Доступность и каналы связи | 11 614 | 51,25 % |
| Канцелярия CRM | 6 514 | 28,75 % |
| Заметка о клиенте | 3 126 | 13,79 % |
| Вложения и записи разговоров | 1 145 | 5,05 % |
| Нечитаемое | 262 | 1,16 % |
Заметок, где клиент что-то сказал или решил, – 3 126. От хранилища в 50 756 записей это 6,16 %. Медианная длина текста – 11 знаков, короче 15 знаков – 71,7 % записей. Когда говорят «у нас накоплена история», имеют в виду 22 тысячи заметок. Система получит три тысячи. Это два разных проекта по цене и по результату.
Дата не помнит ничего старше июня. Из 4 954 сделок, созданных до 1 июля, дату изменения раньше июля сохранили две. Кто-то когда-то выгрузил базу, обновил и залил обратно: 9 968 записей несут дату внутри двадцати минут одного вечера, крупнейшие группы – по 999 записей в одну секунду. В интерфейсе это выглядит нормально, у каждой записи дата на месте.
Тот же случай давно описан в архивном деле. Национальный архив Великобритании разобрал свою первую цифровую передачу: из 1 454 файлов 1 447 несли дату изменения в промежутке с 14 апреля по 3 мая 2006 года, хотя сами документы были 2003 года. Текст Пола Янга, специалиста по цифровой сохранности архива, читается как описание нашей CRM.
Чинится это не чисткой, а переходом на другое поле. У нас честно вела себя дата закрытия сделки: 5 033 различных секунды на 5 210 сделок. А срок задачи не годится – 674 различных секунды на 13 480 записей, потому что люди ставят круглые часы. Признак простой: много различных значений с точностью до секунды – поле живое, мало – переписанное.
83 % покрытия, за которыми 0,14 %. Мы собирались опираться на прошлые решения владельца как на прецедент. Замер покрытия отдал 83,17 %. Число оказалось неверным: ролей в этих данных нет вообще, справочник людей – 21 строка с именем и учётной записью, без должности и команды. Настоящих привязок нашлось 73 из 50 756 – 0,14 %.
Рядом лежала ещё одна ловушка. Ссылку на стадию сделки несут все 50 756 записей. Засчитай стадию за привязку – и покрытие мгновенно станет 100 %. Только стадия называет корзину, а не решение. Ни тесты, ни сборка, ни код-ревью этого не поймали: там всё было зелёное.
От чего зависит каждая возможность
Это главная мысль статьи. ИИ не «понимает вашу компанию» – он читает конкретные колонки конкретных таблиц. Нет колонки – нет возможности, и никакая модель этого не компенсирует.
| Что хотите получить | На чём держится | Чем проверить |
|---|---|---|
| Ответ по истории клиента | тексты, в которых есть содержание | медианная длина текста и доля коротких записей |
| «Почему мы проигрываем», повторяющиеся возражения | те же тексты плюс поиск по смыслу | доля записей длиннее пары слов |
| «Что было раньше», динамика, порядок событий | поле с датой, которое не переписано | сколько различных значений даты с точностью до секунды |
| Конверсия по этапам, где застревают сделки | журнал перемещений по этапам | хранится ли история переходов между этапами |
| Окупаемость каналов | поле источника у сделки | доля сделок с заполненным источником |
| Разбор звонков и встреч | расшифровки разговоров как отдельный источник | есть ли записи и связаны ли они с карточкой |
| Рекомендация по прецеденту | кто принял решение и в какой роли | есть ли справочник людей с ролями и заполнен ли он |
Правая колонка – это уже техническое задание. Прежде чем подключить ИИ к CRM, пройдите её сверху вниз: каждая строка проверяется одним запросом на чтение.
Восемь запросов к своей базе
Полный набор. Ничего не меняют, только читают, и весь список занимает часы.
| Что спросить у базы | Плохой ответ | Что он означает |
|---|---|---|
| Сколько различных значений в поле против числа строк | 22 661 строка – это 5 505 текстов | Четыре пятых базы – повторы |
| Какая медианная длина текста | 11 знаков | Это пометки, а не содержание |
| Какая доля записей короче 15 знаков | 71,7 % | Отвечать системе будет нечем |
| Сколько записей несут одну и ту же дату с точностью до секунды | 999 записей в одну секунду | Дату переписала массовая выгрузка |
| Сохранилась ли дата у самых старых записей | из 4 954 сделок – у двух | Порядок событий не восстановить |
| Существует ли поле, к которому будет обращаться система | справочника ролей нет вообще | Механизм встанет над пустотой |
| Заполнено ли это поле хоть у кого-то | 73 записи из 50 756 | То же самое, но незаметнее |
| Не даёт ли один вопрос два разных ответа | ноль противоречий или 649 | Отчёты будут спорить друг с другом |
Эти восемь строк закрывают то, на что мы потратили полтора месяца.
Что написать в ТЗ
Шесть пунктов. Они не про технологию, поэтому их может написать заказчик.
-
Перечень полей поимённо. Не «система использует данные CRM», а список названий колонок. Формулировка без имён полей означает, что в базу ещё не смотрели.
-
Замер этих полей отдельным первым этапом. Результат этапа – таблица: поле, доля заполненности, вывод. Этап может закончиться отказом от части замысла, и это нормальный его исход, а не срыв. Такой пункт защищает обе стороны: подрядчик не обещает того, чего данные не позволяют.
-
Поведение при пустом поле. Вариантов три: промолчать, сказать «не знаю», придумать. Выбранный вариант пишется в ТЗ словами. Умолчание здесь опасно – модель по своей природе склонна к третьему, и про механику этого у меня есть отдельный разбор.
-
Приёмка по списку ваших вопросов и по их перефразировкам. Тридцать-пятьдесят настоящих вопросов, которые вы задаёте своим людям каждую неделю, и к каждому три пересказа своими словами. Наш прогон показал, зачем: из 216 перефразировок сработали 5. Демонстрация вместо этого списка не доказывает ничего – показывают всегда тот случай, который работает.
-
Два вида ошибок считаются отдельно. «Не нашла» и «придумала» – разные события с разной ценой. Первое раздражает, второе попадает в письмо клиенту. Приёмка, где они сложены в один процент, скрывает именно второе.
-
Что происходит при перезаливке базы. Интеграции периодически переливают данные заново. Индекс после этого перестраивается, а иногда – как у нас – переписываются даты. В ТЗ должно быть сказано, кто это замечает и что делает.
И отдельным требованием ко всем ответам сразу: рядом с каждой суммой – знаменатель, рядом с каждым ответом – период, за который он посчитан. Оба наших промаха с цифрами были именно здесь.
Три вопроса подрядчику
Задавать до подписания, а не после демонстрации.
Какие именно поля наших данных использует то, что вы проектируете? Ответ – список названий полей. Если вместо списка рассказывают про архитектуру, поля ещё не смотрели.
Покажите запросом, что эти поля заполнены, и на какой доле записей. Презентация вместо выгрузки означает, что проверку не делали.
Что система ответит, когда поле окажется пустым? Ответ должен совпасть с тем, что записано в ТЗ.
Вопросы работают и в обратную сторону. Подрядчик, который задаёт их вам сам до старта, уже сэкономил вам деньги. Про то, что бывает, когда их не задаёт никто, я писал в разборе про пилоты без эффекта.
Как подключить ИИ к CRM: сначала замер, потом код
Главная наша ошибка была не в составе данных, а в порядке работ.
Какая база придёт от заказчика, заранее не знает никто. Мы полтора месяца проектировали долговременную память компании, писали код и гоняли тесты – и только после этого впервые посмотрели, что в базе лежит. Половину написанного выбросили: она опиралась на поля, которых в этих данных нет.
Данные за эти полтора месяца не изменились. Изменилось только наше представление о них. Значит, те же восемь запросов можно было сделать в первый день.
Как надо: сначала запросы к базе. Потом разговор о том, что из желаемого на этих данных остаётся. И только потом ТЗ, сроки и код.
«Значит, сначала год чистить данные?» Нет
Здесь я во многом согласен с теми, кто спорит с самой идеей готовить данные заранее.
Их аргумент: «наши данные не готовы» стало универсальной причиной ничего не начинать, а глобальная чистка съедает месяцы и к концу устаревает. Один из консультантов называет 150 тысяч долларов и от шести до девяти месяцев. Вместо этого предлагают взять узкий сценарий и чинить те данные, на которых система спотыкается. Та же позиция у британских консультантов. Все они подрядчики, которым выгодно начать раньше, – и всё же они правы.
Только замер и чистка – разные вещи. Ни одно из наших измерений не трогало данные клиента. Чистка занимает месяцы, отдача неочевидна. Замер занимает часы и отвечает на единственный важный вопрос: какая часть замысла выполнима на этих данных.
Есть и вторая причина, почему «починим по ходу» здесь не срабатывает. Схема «запусти и смотри, где спотыкается» ловит то, что видно. Механизм над несуществующим полем не спотыкается. Он молча возвращает пустоту, а отчёт показывает 83 %.
Где это не работает
Наша база специфическая, и это меняет часть выводов.
Медиана 11 знаков и 71,7 % коротких пометок – профиль конкретной клиентской CRM. На базе договоров, писем или технических описаний доля содержательного будет выше. Не изменится одно: эту долю нужно посчитать, а не предположить.
Восемь проверок не заменяют пилот. Они отвечают, есть ли на чём строить, а не будет ли работать. Второе выясняется только запуском.
И честная граница нашего прогона. Он показал, что считающая половина системы не выдумывает: 318 утверждений, ни одного без источника. Про пишущую половину он молчит: в этом прогоне она не заговорила.
Замеры, которые отменяют наши же решения, я выкладываю в телеграм-канале по мере того, как они появляются – обычно за несколько недель до статей. Хотите разобрать свой случай – пишите напрямую, @maslennikovig.
Эта статья открывает цикл из четырёх разборов одного пилота. Дальше по частям: почему система не находит нужную запись даже когда та лежит в базе; почему она отвечает вчерашними данными и что для этого должно быть у записи; и как проверять исследования, на которые опираются такие проекты.
Наши замеры моделей, которые обновляются из базы, лежат в разделе бенчмарков.
