Czytaj książkę: «ScorifyRank: как превратить хаос Telegram-чатов в конвейер сделок»

ScorifyRank: как превратить хаос Telegram-чатов в конвейер сделок

Как создавался проект, какие боли он решает и как устроен — без строчки исходного кода

Автор: Андрей Леонов

Репозиторий проекта: https://github.com/AndreyLeonov80/ScorifyRank

Глава 1. Зачем эта книга

Эта книга — история создания ScorifyRank, системы, которая превращает хаос Telegram-чатов в упорядоченный конвейер сделок. В ней нет ни одной строчки исходного кода. Вместо этого здесь рассказывается, как система придумывалась и строилась, какую боль она снимает и как устроена изнутри — словами, понятными предпринимателю, маркетологу и разработчику.

Книга адресована трём типам читателей. Владельцу бизнеса она покажет, сколько денег теряется в переписках и как это исправить. Руководителю продаж — как построить процесс, в котором ни один тёплый контакт не забывается. Разработчику и архитектору — какие решения позволяют системе держать высокую нагрузку: тысячи источников, миллионы сообщений, круглосуточный анализ.

Читать книгу можно с любого места. Главы со второй по четвёртую объясняют проблему и идею. Главы с пятой по девятую описывают устройство системы: сервисы, нагрузки, данные, искусственный интеллект и скоринг. Последние три главы — про внедрения, коммерческую модель и будущее проекта. Полный исходный код системы открыт и лежит в репозитории, ссылка на который дана в финальной главе.

Автор книги и системы — Андрей Леонов. Всё, о чём рассказано дальше, проверено на практике: система работает, обрабатывает реальные чаты и приносит реальные сделки.

Чего в книге нет и почему

В книге нет листингов программ, команд для терминала и пошаговых инструкций по установке. Это осознанное решение, а не упущение. Код устаревает быстрее, чем печатается книга: то, что сегодня занимает десять строк, завтра станет одной настройкой. Архитектурные решения, экономика и методология живут годами, синтаксис — месяцами. Поэтому книга говорит о решениях, а код живёт там, где ему место, — в открытом репозитории, ссылка на который дана в финале.

Здесь также нет скриншотов экранов. Интерфейс меняется чаще всего: кнопки переезжают, экраны переименовываются, появляются новые фильтры. Описывать кнопки в печатной книге — всё равно что рисовать карту реки во время половодья. Вместо скриншотов описываются экраны по смыслу: что на них видно, какие решения с их помощью принимаются.

Все цифры в книге — порядки величин, а не аудиторский отчёт. Названия компаний и имена людей изменены или опущены: переписка клиентов конфиденциальна, и книга соблюдает то же правило, что и система. Если где-то говорится «автодилер», это собирательный образ из нескольких внедрений, а не конкретная компания.

Как построены примеры

Каждая глава строится по одному шаблону: сначала ситуация из жизни, потом разбор, потом принцип, который из неё следует. Принципы собраны в конце глав повторяющимися формулировками — их можно выписывать отдельно, получится краткий конспект всей книги. Если времени мало, читайте первые абзацы глав и выводы: за пятнадцать минут вы получите полную карту, а детали доберёте позже.

Три маршрута чтения

Маршрут владельца: первая, вторая, третья, десятая, одиннадцатая и двенадцатая главы. Это путь от боли к деньгам: сколько теряется, как устроено решение, сколько стоит, что делать в понедельник утром. Технические главы можно пролистать — достаточно понимать, что система выдерживает нагрузку и хранит данные локально.

Маршрут руководителя продаж: вторая, третья, девятая и десятая главы. Это путь от хаоса к процессу: какие сигналы бывают, как устроена воронка, как внедрить утренний ритуал списков. Главы про очереди и базы данных можно пропустить без потери смысла.

Маршрут архитектора: с четвёртой по девятую главы подряд. Это путь от монолита к конвейеру: какие решения принимались, чем они оплачены, что бы мы сделали иначе. Главы про коммерцию читайте по желанию — но хотя бы проглядите, потому что лицензионная модель повлияла на архитектуру сильнее, чем кажется.

Как рождалась эта книга

Книга не писалась с нуля за месяц. Она выросла из сотен коротких записок, которые велись с первого дня проекта: каждое решение, каждая авария, каждый вывод фиксировались в день события. Записки копились в папке документации, пока их не стало так много, что из них проступил скелет: боли, конвейер, нагрузки, скоринг, внедрения. Главы этой книги — это выросшие и причёсанные записки.

Такой способ рождения определил стиль: мало теории, много практики. За каждым принципом стоит конкретная история с датой и последствиями. Провалы описаны наравне с победами — не из скромности, а потому что провалы учили сильнее. Читатель получает не учебник, а журнал экспедиции: вот что мы встретили, вот как прошли.

Отсюда совет читателю, который строит своё: ведите записки с первого дня. Решение, не записанное в день принятия, через месяц обрастает мифами: все помнят, что решили, никто не помнит почему. А «почему» важнее «что»: обстоятельства меняются, и старое решение приходится пересматривать. Без записи причин пересмотр превращается в гадание.

Как пользоваться книгой

Не пытайтесь запомнить всё сразу. Отмечайте главы, которые относятся к вашей ситуации. Если вы продаёте через мессенджеры — начните со второй главы о боли рынка. Если вы строите похожую систему — ваше место в главах с шестой по девятую. Если думаете о покупке или внедрении — читайте десятую и одиннадцатую.

Термины в книге используются простые. Сигнал — это структурированный вывод системы: факт, оценка или рекомендация, извлечённые из сообщений. Скоринг — присвоение контакту или сделке числовой оценки и стадии. Источник — любой Telegram-чат, канал, группа или диалог, который система читает. Конвейер — последовательность шагов от чтения сообщений до сделки в CRM.

Глава 2. Боль рынка: деньги тонут в чатах

Главный канал продаж в русскоязычном бизнесе давно сместился в мессенджеры. Автомобили, недвижимость, образование, медицина, услуги — везде первый контакт, уточнение деталей, торг и даже оплата обсуждаются в чатах. Руководители привыкли думать, что у них есть CRM и отдел продаж, а значит, всё под контролем. На практике между сообщением клиента и записью в CRM лежит пропасть, в которую падают деньги.

Представьте типичный день менеджера по продажам. Утром он открывает десяток чатов: три канала с входящими заявками, пять переписок с клиентами на разных стадиях, два групповых чата, куда заявки падают вместе с болтовнёй. К обеду сообщений уже сотни. Вечером менеджер вносит в CRM то, что запомнил. Запомнил он примерно треть. Остальное — тёплые контакты, уточняющие вопросы, возражения, обещания перезвонить — остаётся лежать в ленте и умирает там.

Первая боль — скорость. Клиент, написавший в общий чат, ждёт ответа минутами, а не днями. Исследования поведения покупателей раз за разом показывают одно и то же: вероятность сделки резко падает с каждым часом молчания. Но менеджер физически не может следить за всеми чатами одновременно, а ночью и в выходные не следит никто.

Вторая боль — забытые повторные касания. Большинство сделок закрывается не с первого ответа, а с третьего-пятого контакта. Покупатель спросил наличие, попросил подумать, пропал на неделю — и о нём забыли. Через месяц он купил у конкурента, который просто написал вовремя. Это самая дорогая категория потерь: люди, которые уже хотели купить.

Третья боль — отсутствие квалификации. Все входящие выглядят одинаково, и менеджер тратит время на любопытствующих, пока горячий клиент ждёт. Нет системы, которая сказала бы: вот эти пять человек готовы покупать сегодня, а эти пятьдесят — просто спрашивают цены.

Четвёртая боль — разрозненность данных. Один и тот же клиент пишет в канал, в личку и в групповой чат под разными именами. Для менеджера это три разных человека. История общения рвётся, контекст теряется, клиенту задают одни и те же вопросы по кругу.

Пятая боль — невидимость для руководителя. Владелец бизнеса видит отчёты из CRM, а CRM видит только то, что менеджеры туда внесли. Реальная картина — сколько было обращений, сколько потеряно, на каком этапе и почему, — остаётся за кадром. Управлять можно только тем, что измерено, а чаты никто не измеряет.

Шестая боль — рутина, съедающая экспертов. Сильные продавцы тратят часы на перечитывание лент, поиск нужного сообщения, копирование текстов в CRM, составление отчётов. Это работа, которую должна делать машина, а machine её не делает, потому что никто её не построил.

Отдельные инструменты каждую из этих болей закрывают лишь частично. CRM хранит то, что в неё внесли, но не читает чаты. Парсеры собирают сообщения, но не понимают смысл. Чат-боты отвечают по сценариям, но не ведут сложные сделки. Ручной разбор чатов работает, пока чатов десять, и ломается, когда их становится сто. Нужна была система, которая соединяет всё: читает, понимает, оценивает и доводит до сделки.

Именно из этой потребности родился ScorifyRank. Его задача формулируется одной фразой: ни один человек, готовый купить, не должен потеряться в ленте сообщений.

Три истории из практики

История первая. Автодилер, три showroom, общий чат на несколько тысяч подписчиков и личка менеджеров. Владелец был уверен, что отдел из шести человек держит всё под контролем. Разбор месяца переписки показал: сорок три человека спрашивали конкретные комплектации и цены, получили ответ и пропали. Им никто не написал повторно. По среднему чеку это были десятки миллионов рублей недополученной выручки. Самое обидное — менеджеры не ленились, они просто не помнили. Человеческая память не предназначена для учёта сотен диалогов.

История вторая. Онлайн-школа, набор на поток, заявки падают в три чата и в личку кураторам. Конверсия из заявки в оплату — одиннадцать процентов, и все смирились: «такой рынок». Разбор показал, что треть не дошедших до оплаты задавала один и тот же вопрос про рассрочку и не получала внятного ответа дольше суток. Ответили бы за час — каждый пятый из них оплатил бы. Проблема была не в продукте и не в цене, а в скорости одного конкретного ответа. Этого никто не видел, потому что никто не измерял время ответа по типам вопросов.

История третья. Небольшое агентство услуг, два партнёра ведут всё сами. Клиенты пишут в мессенджер основателю, он отвечает между встречами, вечером переносит в таблицу. Однажды он уехал в отпуск на две недели, и таблица не обновлялась. Вернувшись, обнаружил семь необработанных запросов, три из которых уже купили у конкурентов. Потери маленькой компании от двух недель тишины оказались сопоставимы с месячной прибылью. Вывод: процесс, который держится на памяти одного человека, — это не процесс, а лотерея.

Общее у всех трёх историй одно: никто не был виноват. Люди старались. Виновата была архитектура работы — точнее, её отсутствие. Сообщения приходили быстрее, чем их успевали осмыслять, а инструментов осмысления не было.

Почему старые инструменты не спасают

Казалось бы, всё уже придумано: CRM-системы, парсеры, чат-боты, аналитики. Почему же деньги продолжают тонуть? Потому что каждый инструмент закрывает свой кусок, а разрыв — между ними.

CRM хранит то, что в неё внесли. Но внесение — ручная работа, а ручная работа всегда отстаёт и всегда неполна. CRM отвечает на вопрос «что мы записали», а бизнесу нужен ответ на вопрос «что происходит». Это разные вопросы.

Парсеры и выгрузки собирают сообщения в таблицы. Таблица из ста тысяч строк — это не ответ, это новая форма той же проблемы. Человек не может прочитать сто тысяч строк, а машина в парсере их не понимает. Данные есть, смысла нет.

Чат-боты отвечают по сценариям. Они хороши для типовых вопросов: часы работы, адрес, цена из прайса. Но сделка редко идёт по сценарию: клиент сомневается, сравнивает, торгуется, пропадает, возвращается с новым вопросом. Сценарный бот в такой ситуации либо отвечает невпопад, либо зовёт человека — и мы возвращаемся к исходной точке.

Найм дополнительных менеджеров масштабирует проблему, а не решает её. Два менеджера забывают вдвое больше, чем один, плюс добавляют несогласованность: один обещал скидку, другой о ней не знает. Без системы люди — это не решение, это множитель хаоса.

Ручной аудит переписок работает, но не масштабируется. Нанятый аналитик за неделю разберёт месяц одного чата и найдёт золото. Через месяц чат снова зарастёт, а аналитик стоит дорого и тоже человек. Разовый аудит — отличное начало, что и используется во внедрениях, но как постоянный процесс он не работает.

Нужен был инструмент нового типа: такой же неутомимый, как парсер, такой же понимающий, как аналитик, и такой же практичный, как CRM. Читать всё, понимать смысл, раскладывать по полкам и подсказывать следующий шаг. Именно это и делает конвейер, описанный в следующих главах.

Анатомия потерянного лида

Разберём гибель одного лида по минутам, чтобы увидеть, где именно рвётся нить. Вторник, десять утра: посетитель канала спрашивает, есть ли товар в нужном цвете и можно ли забрать сегодня. Сообщение видят двести человек и один занятый менеджер. Менеджер отвечает через сорок минут: да, есть, приезжайте. Клиент не отвечает — он уже ушёл по делам, уведомление утонуло.

Среда: менеджер вспоминает про вчерашний вопрос и пишет «актуально?». Клиент читает мельком и откладывает: он уже смотрит варианты у конкурента, где ответили за пять минут. Пятница: менеджер, разбирая ленту, натыкается на переписку и пишет снова. Клиент уже купил. Три касания, ноль результата — а всё решилось бы одним быстрым ответом во вторник и одним напоминанием в среду вечером.

Заметьте: менеджер сделал всё, что мог. Он ответил, он напомнил дважды. Проиграли скорость первого ответа и точность второго касания. Машина в этой истории нужна была дважды: мгновенно подсветить горящий вопрос среди сотен сообщений и вовремя напомнить о повторном касании с подсказкой, что писать. Это и есть два самых ценных сигнала системы: «ответь сейчас» и «напиши сегодня».

А теперь умножьте эту историю на десятки таких еженедельно. Каждый по отдельности — мелочь, о которой забывают к пятнице. Вместе — та самая треть выручки, о которой говорилось выше. Потери в чатах устроены коварно: они состоят из мелочей, каждую из которых легко простить, а сумма оказывается смертельной.

Психология забывания

Почему умные и старательные люди систематически забывают клиентов? Потому что память человека устроена не как база данных. Она держит ярко и недолго: последнее сообщение помнится, позавчерашнее — уже нет. Она путает важное со срочным: орущий недовольный заслоняет тихо готового купить. Она устаёт к вечеру: решения, принятые в шесть вечера, хуже утренних.

Лента мессенджера эксплуатирует все слабости памяти сразу. Новые сообщения сталкиваются старые вниз, и старое автоматически кажется менее важным, хотя горячий клиент недельной давности важнее сегодняшней болтовни. Групповые чаты смешивают десятки сюжетов в один поток, и мозг, не справляясь, переходит в режим скольжения: глаза читают, смысл не фиксируется.

Вывод неутешительный и освобождающий одновременно: забывать — нормально, это биология. Ненормально — строить на биологии бизнес-процесс. Память должна быть внешней: списки, напоминания, воронки. Раньше внешнюю память строили из таблиц и CRM, куда человек вносил то, что помнил, — порочный круг. Теперь её строит машина, которая читает всё и не устаёт. Круг размыкается.