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