Если ручная проверка показала, что Telegram даёт лидов — рано или поздно один человек перестаёт справляться.
5 чатов — вечерняя работа на 30 минут. 15 — постоянная задача одного человека. 30 — уже не справляется один. 50+ — нужна система для автоматического поиска лидов.
Эта статья — про то, как такую систему собрать самим, и где у неё типичные ловушки.
Где ломается ручной подход
5 точек, в которых руки перестают работать:
1. Время. Один человек качественно просматривает до 5–10 тысяч сообщений в день. Дальше пропускает или ставит «лид» на всё подряд.
2. Качество в усталости. На сотом сообщении за день размечает не так же, как на десятом. Распределение лидов смещается.
3. Скорость реакции. Горячие лиды живут 30–60 минут. Просматривает чат раз в 4 часа — половину пропускает.
4. Знание ниши. Хорошо размечает ту нишу, в которой работает. На второй и третьей точность падает.
5. Заменяемость. Уволился или ушёл в отпуск — встаёт весь канал.
В нашей студии лимит наступил при 12–15 чатах. Наняли второго — стало лучше, но появилась разная разметка. Один считал лидом «обсуждаем CRM в принципе», другой — только «нам нужна CRM сейчас». Ленты двух менеджеров стали несопоставимыми.
Воронка из 4 слоёв
После пары итераций мы пришли к схеме из 4 независимых слоёв:
1. Ingestion — сбор сырого потока сообщений.
2. Classification — отделение сигнала от шума.
3. Routing — распределение лидов по продуктам и менеджерам.
4. Delivery — передача лида тому, кто отвечает.
Главная мысль: эти слои должны быть независимыми. Если у вас «один большой бот, который делает всё» — рано или поздно вы захотите изменить что-то в одном слое и побоитесь сломать остальные.
Слой 1: Ingestion
Цель — собирать всё в одно место. Без фильтрации.
Три ключевых решения:
Чем читать. Telegram MTProto-клиент (Telethon, MadelineProto) устойчивее, чем bot API. Bot API не видит большинство публичных чатов, если бот туда не приглашён.
Какой аккаунт. Выделенный аккаунт «читатель», не личный. Только читает, не пишет. Снижает риск бана аккаунта практически к нулю.
Что сохранять. Текст, время, чат, автор (id, не персональные данные сверх id), реплай-цепочка.
Главная ошибка — фильтровать на этом этапе. Кажется, что «зачем сохранять весь шум, давайте сразу выбирать только лидов». Через 2 месяца захотите изменить критерии и пожалеете. Сохраняйте всё.
В нашей системе через ingestion за месяц проходит 311 191 сообщение по всем клиентам. Хранение текста дёшево, переобработать архив с новыми правилами всегда полезнее, чем потерять данные.
Слой 2: Classification
Цель — разделить на «возможный лид» и «шум». Здесь больше всего ошибок.
Что не работает: один большой prompt, который и классифицирует, и отвечает. Получается долгий ответ от LLM с непредсказуемым качеством. Десятки копеек на сообщение, точность ниже, чем хочется.
Что работает: 2 шага.
Шаг 1 — классификация. Лёгкая модель, простая задача: «лид или нет, какой тег из списка». Десятки миллисекунд, копейки за сообщение. Прогоняется на всём потоке.
Шаг 2 — генерация или обогащение. Только для тех, кто прошёл первый фильтр. Большая модель, сложный промпт.
Соотношение: первый шаг — 100% входа, второй — 1–5%. Стоимость падает в десятки раз.
Промпт классификатора делайте под клиента. Один и тот же текст «у меня бухгалтер не успевает» — для бухгалтерской фирмы это лид (нужен новый бухгалтер), для CRM-интегратора это другой лид (нужна автоматизация). Универсальный классификатор такие нюансы режет.
Слой 3: Routing
Цель — положить лид в правильное место: правильный тег, правильный менеджер, правильный приоритет, правильный канал.
Типичная ошибка — роутить простыми правилами «если в сообщении слово X → менеджеру А». Работает первые 2 недели, потом ломается.
Лучше: классификация даёт тег, а тег занесён в справочник, в котором сказано, кому идёт. Анна заболела — меняете маршрут тега, не трогая логику классификации.
В нашей системе настраивается до 10 тегов на клиента. Больше — путает классификатор и самого клиента. У нашей студии 10: партнёры, marketing, crm_интеграция, pulsar_клиент, ии_дефолт, конкуренты и ещё несколько. Каждый идёт в свой Telegram-топик, к своему ответственному.
Слой 4: Delivery
Цель — передать лид человеку или системе, чтобы реакция была быстрой и в контексте.
Варианты:
1. Telegram-бот в супергруппу с топиками. По топику — тег, по топику — менеджер. Удобно: менеджер видит ленту в том же приложении, где работает с клиентами.
2. Email с дайджестом. Хуже — медленнее реакция.
3. Прямо в CRM (Bitrix24, AmoCRM). Идеально, если CRM ведёт всю работу.
4. Вебхук во внутреннюю систему. Для тех, у кого уже своя инфраструктура.
Мы используем 1 + 3: топики для оперативной работы, плюс автосоздание лида в Bitrix24 для нужных тегов.
Ключевое: к каждому лиду должен идти контекст. Не просто текст, а:
- сам текст;
- ссылка на сообщение в чате (открыть и увидеть нить);
- предложение действия / черновик ответа;
- тег и приоритет.
Без этого менеджер тратит 30–60 секунд на каждое сообщение. На потоке 100 в день это 1.5 часа в сутки впустую.
Изоляция клиентов
Если делаете для нескольких — каждый должен иметь своё хранилище, свои чаты, свои теги, свои промпты.
Соблазн — общая база, в которой всё пересекается. Звучит экономно, через 3–6 месяцев упирается в стену:
- классификатор клиента А путается на тегах клиента Б;
- лид клиента А утекает на дашборд клиента Б;
- специфическая ниша одного искажает разметку остальных.
В pulsar-tg каждый клиент изолирован полностью: своя подписка на чаты, свои теги, своя статистика. Дороже технически. Единственный способ работать в долгую.
Что не должна делать автоматизация
Граница ответственности — самый болезненный вопрос.
Обязана делать: сбор сообщений, классификацию, маршрутизацию, доставку с контекстом.
Может, но осторожно: черновик ответа (заготовка под дочистку), обогащение публичной информацией.
Не должна:
- отправлять сообщения от имени менеджера без подтверждения;
- принимать «лид/не лид» без права на ошибку;
- удалять «несоответствующие» сообщения (архив должен быть полный).
Финальное решение «отвечать или нет» — всегда у человека. В момент, когда автоматизация начинает писать без человека, она ломает доверие чата за неделю.
Как собрать самим
Можно. Если есть инженер на 1–2 ставки и 3–4 месяца на разработку плюс готовность поддерживать.
Стек:
- Чтение чатов: Telethon на Python.
- Очередь: Celery + Redis.
- API/админка: FastAPI или любой http-фреймворк.
- Хранилище: PostgreSQL + что-то под архив сообщений (Clickhouse или partitioned tables в PG).
- LLM: один провайдер для классификации, один для генерации.
- Доставка: Telegram Bot API в супергруппу с топиками.
Реалистичная оценка: 2–4 месяца до первого MVP, ещё 3–6 месяцев до состояния, в котором не страшно подключать клиентов.
Ловушки:
- бан аккаунтов на ingestion;
- точность классификатора на холодном старте;
- балансировка очередей при пиках;
- слежение за изменениями API Telegram.
Имеет смысл собирать самим, если:
- 50+ чатов и одна-две очень специфические ниши;
- в команде middle+ разработчик;
- система — часть основного бизнеса, не вспомогательная.
В остальных случаях 6 месяцев на сборку — обычно дороже, чем взять готовое. Но понимать архитектуру полезно в любом случае: выбор готового решения становится осмысленнее.
Что можно собирать
Технический директор небольшого агентства недвижимости после похожего разбора собрал такую систему за 6 недель силами одного backend-разработчика. Работает с 18 чатами, классификатор на GPT-4o-mini для первого шага. Стоимость LLM — около $40 в месяц на их объёме. Лидов в день — стабильно 50–80.
У нас в студии разработки и внедрения AI те же 4 слоя живут в публичном продукте pulsar-tg, на котором сейчас 62 клиента и 230 чатов. Архитектура та же. Разница — в зрелости и в том, что мы 2.5 года ловили все ловушки за себя и за клиентов.
Ограничения подхода
- Архитектура из 4 слоёв — модель, не догма. Может быть 3, может быть 5. Главное — независимость и явные стыки.
- Инструменты не равны процессу. Не работает ручной разбор — автоматизация это не починит. Она ускоряет, но плохую систему хорошей не делает.
- Любая автоматизация требует поддержки. Telegram меняет API, чаты исчезают, классификаторы дрейфуют. Без ресурса на ежемесячную проверку система деградирует за полгода.
- Стоимость владения — это ставка инженера + LLM-токены + инфраструктура + время на пересмотр. Часто забывают про последнее.