Продажи в переписке как последовательность состояний: где диалог обрывается и как это увидеть без сложной аналитики


У маленького бизнеса, который продаёт через мессенджеры, есть характерная слепая зона. Владелец знает, сколько людей ему написали за месяц, и знает, сколько из них купили. Всё, что между, существует только в виде переписок. Спроси его, на каком месте разговоры чаще всего умирают, и он ответит по ощущениям: «наверное, на цене» или «люди просто пропадают».
Ощущения в таком вопросе обычно ошибаются. Чтобы ответить точно, не нужен BI и не нужна CRM за сотни долларов в месяц. Нужно один раз договориться, из каких состояний состоит диалог, и начать записывать переходы между ними.
Диалог как автомат, а не как текст
Переписка выглядит как поток сообщений, но с точки зрения процесса в ней немного событий, которые имеют значение: человек впервые написал, ему ответили, он ответил на ответ, ему задали вопрос о его задаче и он на него ответил, договорились о следующем действии, и действие произошло или не произошло.
Если назвать эти точки состояниями, а сообщения между ними переходами, разговор превращается в конечный автомат с небольшим числом вершин. Для программиста это привычная модель: Дэвид Харел опубликовал статью «Statecharts: A visual formalism for complex systems» (Science of Computer Programming, 1987, т. 8), где предложил способ рисовать такие системы так, чтобы их понимали не только инженеры. Переписке с клиентом его иерархии и параллельные состояния не нужны, хватает плоского автомата, но сама идея та же: поведение описывается через состояния и события, которые переводят из одного в другое. Например: «первое сообщение», «есть ответ», «понятна задача», «есть договорённость», «шаг сделан», «закрыто». К ним нужно добавить одно состояние, которое обычно забывают, и именно оно оказывается самым населённым: «тишина».

Тишина — это не отсутствие состояния. Это состояние, в которое диалог переходит по таймеру. Если от собеседника нет ничего три дня, а от вас нет следующего шага, разговор не «в процессе», он в тишине. Пока это не записано явно, такие диалоги тихо копятся в разделе «ещё общаемся», и владелец искренне считает их живыми.
Состояние определяется событием, а не мнением
Самая частая ошибка при попытке навести порядок в переписках — завести статусы вроде «тёплый», «заинтересован», «думает». Они удобны, но не проверяемы. Два человека, глядя на одну и ту же переписку, поставят разные статусы, а через неделю и один и тот же человек поставит другой.
Работает только то, что можно установить по факту. «Есть ответ» означает, что в переписке есть сообщение от собеседника после вашего. «Понятна задача» означает, что он своими словами сказал, зачем пришёл. «Есть договорённость» означает, что названо конкретное действие и дата. Такой статус можно поставить вручную за секунду, и спорить о нём не придётся.
Здесь же проходит граница для нейросетей. Модель отлично помогает выжать из длинной переписки, сказал ли человек, что ему нужно, и предложить черновик ответа. Но оценка «вероятность покупки семьдесят процентов», записанная в таблицу, превращает догадку в данные. Через месяц на этих данных строят выводы, и выводы получаются о модели, а не о клиентах.
Минимальная запись
Хранить нужно не текущий статус контакта, а журнал переходов: кто, из какого состояния, в какое, когда. Это три-четыре колонки в обычной таблице, и вести их можно руками. Текущий статус из такого журнала выводится всегда, а вот обратная операция невозможна: по последнему статусу историю не восстановишь.
Когда журнал есть, на большинство вопросов отвечает один запрос. Для таблицы, выгруженной в SQLite, он выглядит примерно так:
SELECT from_state, to_state, COUNT(*) AS n
FROM transitions
WHERE first_contact_week = '2026-40'
GROUP BY from_state, to_state
ORDER BY from_state, n DESC;
Результат читается как карта потока: сколько диалогов из «есть ответ» перешли в «понятна задача», а сколько в «тишину». Условный пример: за неделю в состояние «есть ответ» попали 40 диалогов, из них 14 дошли до «понятна задача», 4 закрылись сразу, а 22 ушли в тишину. Потеря на этом переходе 22 / 40 = 0,55, то есть больше половины разговоров умирает раньше, чем продавец узнал, что человеку нужно. Сравнивать это число стоит не с чужими бенчмарками, а с той же величиной у себя через месяц. Та же таблица в электронной таблице делается сводной за пару минут.
Что обычно показывает такая карта
Предсказать конкретные числа для чужого бизнеса нельзя, но форма карты у небольших продавцов часто похожа. Больше всего диалогов уходит в тишину не на цене, как ожидает владелец, а раньше: между первым ответом и моментом, когда понятна задача. Человек написал «сколько стоит» или «расскажите подробнее», получил длинное сообщение с описанием всего подряд, и замолчал.

Причина видна, если перечитать эти переписки подряд, а не по одной. Ответ продавца решает его задачу, рассказать о себе, и не решает задачу собеседника, понять, подходит ли ему это. Вопрос «а для чего вам, что сейчас пробовали» в таких диалогах почти не встречается.
Второе типичное место — переход от договорённости к сделанному шагу. Договорились созвониться в четверг, в четверг никто не напомнил. Здесь помогает не скрипт, а простая выборка: все диалоги в состоянии «есть договорённость» с датой на сегодня. Если её смотреть каждое утро, этот переход перестаёт протекать.
Ловушки при подсчёте
Первая ловушка — смешивать когорты. Если считать переходы по всем диалогам сразу, свежие разговоры, которые ещё не успели дойти до конца, тянут конверсию вниз, и кажется, что дела ухудшаются. Правильнее группировать по неделе первого сообщения и сравнивать недели между собой, когда у каждой было одинаковое время на развитие.
Вторая ловушка — смешивать источники: люди, пришедшие из подробной статьи, и люди, пришедшие из короткого ролика, ведут себя по-разному. Первые чаще сразу объясняют задачу, вторые чаще спрашивают цену. Общая конверсия по ним вместе может падать, хотя внутри каждого источника ничего не изменилось, просто сместилась доля.
Третья — не считать тишину состоянием, и тогда диалоги в ней не попадают в знаменатель, и конверсия на каждом шаге выглядит лучше, чем есть.
Зачем всё это человеку без отдела продаж
Можно сказать, что для десятка переписок в неделю это избыточно. На практике именно на таком объёме журнал полезнее всего. Каждый потерянный разговор здесь заметная доля выручки, а память владельца уже не справляется, потому что параллельно идут несколько переписок и пара созвонов.
Таблица из четырёх колонок не сделает продажи в переписке легче. Она делает их видимыми. Когда видно, что треть диалогов умирает после первого ответа, разговор о том, как отвечать иначе, становится разговором о конкретных сообщениях, а не о том, что «клиенты сейчас такие». Если вы ведёте подобный журнал или пробовали и бросили, интересно услышать в комментариях, какое состояние у вас оказалось самым населённым.
KioskNews shows a cleaned-up reading view extracted from the publisher’s page — the original always lives on their site, not ours.