CRM Telegram и лиды из мессенджера: как стыковать с CRM без хаоса

Запрос «crm telegram» в Wordstat (объём 149) почти всегда смешанный: кто-то ищет «систему», кто-то — бота поверх Amo или Битрикс, кто-то — способ не терять заявки из чатов. Под ним бизнес редко хочет ещё один рейтинг SaaS. Чаще хочет ответ за 15 минут: откуда брать лиды в Telegram, как не сжечь аккаунт, куда писать карточку и кто отвечает, если лид написал в 23:40.

Я уже разбирал отдельно поиск Telegram чатов как процесс и интеграцию CRM и Telegram. Здесь другой угол: не «как найти чат» и не «какой класс интеграции выбрать», а как брать лиды из Telegram и стыковать их с CRM так, чтобы продажи видели сделку, а не скрин из лички.

Что обычно смешивают под этим запросом

Под одной фразой живут четыре задачи:

1. Уведомления из CRM в Telegram («пришла заявка — пиши в чат»).
2. Telegram как интерфейс менеджера к уже существующей CRM.
3. Telegram как источник лидов (бот, канал, чат, outreach).
4. Полноценная telegram crm система, где мессенджер и база почти совпадают.

Первые два закрыты в статье про интеграцию. Третий — тема этого текста. Если путаете «найти чат» и «получить лид», воронка раздувается ссылками и пустеет сделками.

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

Чем это не дублирует поиск чатов

Поиск чатов отвечает: где обитает ICP. Лиды из Telegram отвечают: кто уже проявил интерес и как его зафиксировать.

В поиске сущность — чат: URL, скоринг, риск бана. В лидогенерации сущность — человек или компания: telegram_id, сигнал интереса, стадия, ответственный. Передавать в CRM «чат» как лид — частая ошибка. Чат может быть источником, но сделка строится на контакте.

Связка: отбор площадок (если нужен outbound) → захват сигнала → карточка лида → статусы CRM. Пропускать середину и «сразу писать всем» — путь к банам и к отчёту «нашли 200, ответили 2».

Карта источников лидов в Telegram

Не все источники одинаково безопасны. Держите их раздельно в поле lead_source.

Входящий бот. Человек сам пишет боту или жмёт Start. Сигнал сильный. Легко писать в CRM через webhook. Риск спама низкий, если бот не обещает чудес в первом сообщении.

Лид-магнит в канале. Чек-лист, разбор, запись эфира — в обмен на контакт или диалог с ботом. Хорошо для прогрева. Плохо, если «лид» — только скачавший файл без квалификации.

Сигнал в чате. «Ищу подрядчика», «нужен расчёт». Сырьё для квалификации. Без правил легко скатиться в спам чужих сообществ.

Контролируемый outreach. Первый контакт в личку по найденному сигналу, с лимитами. Масштабируется только с антибан-правилами. Здесь уместен слой вроде Телепилота, а не «скрипт на коленке».

Рефералы и закрытые круги. Мало объёма, высокий trust. В CRM помечайте отдельно — иначе маркетинг убьёт канал неправильными KPI.

Для ниши недвижимости на Бали смежный гео-контур — Bali Lead, но только если ICP реально там.

Минимальный контракт полей в CRM

Без контракта полей любая связка telegram crm превращается в свалку заметок. Минимум:

1. telegram_id / username (канон + aliases).
2. Имя или как представился.
3. Источник: bot / channel / chat_signal / outreach / referral.
4. Сигнал интереса одной фразой.
5. Статус: new → qualifying → meeting → handoff → won/lost.
6. Владелец и время первого касания.
7. SLA первого ответа и факт нарушения.
8. Следующий шаг с датой.
9. Связанный чат/канал как reference, не как сделка.
10. Причина отказа кодом, не «не зашло».

Поля пустые — статус вперёд не двигаем. Лучше честный incomplete, чем красивая воронка из пустоты.

Дедуп обязателен по telegram_id, затем по телефону/email. Один человек из бота и из outreach не должен рождать две сделки. При сомнении — флаг possible_duplicate и задача человеку, не автослияние вслепую.

Захват → квалификация → запись

1. Событие. Сообщение, заявка, сигнал, ответ на outreach.
2. Нормализация. Канонический id, источник, сырой текст сигнала.
3. Квалификация. 4–6 реплик: подтвердить сигнал, задача, срок, ограничения если уместно, следующий шаг. Не 20 вопросов в первом касании.
4. Запись в CRM. Контакт + сделка единообразно.
5. Следующий шаг. Созвон, бриф, КП, nurture — с датой.
6. Журнал. Что сказано, версия шаблона, какой стоп сработал.

Маркер готовности к продажам должен быть машинно читаемым: статус, флаг, служебная метка. Иначе closer «почти дожал», а менеджер не видит очередь.

SLA ответа: почему ночной лид остывает

В кейсе Телепилота прямо названа боль: лид написал ночью — ответили утром — лид остыл. Это про отсутствие контура, который отвечает в границах 24/7 или хотя бы фиксирует карточку и задачу к утру с контекстом.

Практические правила:

• входящий бот — автоответ за секунды с одним уточняющим вопросом;
• сигнал из чата — сначала скоринг, потом касание;
• outreach — лимиты в день, пауза между площадками, запрет повтора без ответа N дней;
• эскалация человеку — карточка уже заполнена, менеджер не начинает с «а вы кто?».

SLA пишите числом в CRM. Без числа «быстро» нельзя улучшить.

Где уместен Телепилот, а где хватит бота

Телепилот — не «ещё один chatbot в поддержке». По карточке 4bos это парк Telegram-аккаунтов с антибан-логикой: sender в тематические чаты, spider по сигналам, outreach в личку, AI-closer до договорённости, маркер вроде [SHOWING_AGREED] в продажи.

Уместен, когда Telegram реально канал клиентов, руками маркетолог упирается в 5–10 чатов, нужен повторяемый outbound + квалификация.

Хватит проще, когда лиды уже падают во входящий бот — сначала доведите запись в CRM и SLA; когда ICP и стоп-слова не описаны — парк ускорит хаос; когда нужна только уведомительная связка CRM→Telegram — это другой класс задач.

Установка и грабли деплоя — в материале про установку Телепилота. Здесь фокус на воронке лид→CRM.

Этика outbound и антибан как часть CRM

Антибан — условие, что источник лидов завтра ещё существует. В CRM полезно хранить: какой аккаунт писал, версию шаблона, контекст сигнала, результат (ответ / игнор / бан / жалоба).

Жёстко запрещаю: один текст в десятки чатов; обход правил входа; обещания цены и срока без источника; имитацию «живого участника» ради модерации; выдуманные метрики активности.

Лимиты живут рядом с аккаунтом: дневной потолок касаний, пауза между площадками, порог стопа по банам. Превысил — внешней отправки нет.

Статусы, handoff и журнал отказов

Для telegram-лидов обычно хватает: new → qualifying → meeting → handoff → won/lost.

Еженедельно из системы: новые карточки, дошедшие до meeting, нарушения SLA, баны/жалобы, дубли. Чужие «у нас 40%» в отчёт не берём.

Хороший handoff — карточка за 60–90 секунд: сигнал и цитата, ответы квалификации, что уже обещано, следующий шаг, ссылка на диалог. Плохой — «вот лид» + пересылка 40 сообщений.

Каждый lost — с кодом: no_budget, wrong_geo, no_timeline, competitor, spam_complaint, silent_after_meeting, duplicate. Раз в две недели смотрите топ причин: wrong_geo → ужесточить квалификацию; duplicate → чинить дедуп.

Связка с уже существующей CRM

Интеграция telegram crm не обязана начинаться с замены Amo/Битрикс. Рабочий путь: CRM — источник правды по сделкам; бот или контур лидогенерации пишет события через API/webhook; менеджер получает задачу и ссылку на карточку.

Ошибки: лид только в Google Sheet «на время»; разные имена источников без словаря; сделка на каждое сообщение диалога; статус не обновляется после отказа closer.

Если рядом WhatsApp — держите channel отдельно. Общими остаются поля CRM и логика SLA, не текст первого сообщения.

Чек-лист на 14 дней

1–2. ICP и разрешённые источники. 3–4. Контракт полей и словарь источников. 5–6. Только входящий бот или один узкий канал захвата — карточка без копипаста. 7–8. SLA, алерт на просрочку, дедуп по telegram_id. 9–10. Квалификационный скрипт и маркер handoff. 11–12. Если нужен outbound — малый пилот с жёсткими лимитами. 13–14. Разбор статусов и отказов; одно узкое улучшение на неделю.

Перед масштабированием парка аккаунтов: словарь полей, дедуп, SLA, журнал отказов, лимиты, handoff с контекстом. Два пункта пустые — сначала дыры, потом sender/spider.

Согласование обещаний между ботом и менеджером

Частый конфликт: closer в Telegram пообещал срок или формат, менеджер на созвоне говорит другое. Клиент слышит разрыв и уходит — формально «лид был», по факту процесс сломан.

Правило: бот обещает только то, что есть в утверждённом прайсе/политике. Всё спорное — формулировка «уточнит менеджер» плюс задача человеку. В карточке поле promises_made (короткий список) обязательно к handoff. Менеджер начинает созвон с сверки этого поля, а не с чистого листа.

Раз в неделю сверяйте жалобы «нам сказали одно». Если повторяется одна тема — правьте шаблон, не людей.

Квалификация по типу источника: три коротких сценария

Один универсальный скрипт ломается о разный контекст. Ниже рабочие каркасы — не «скрипты продаж на 3 страницы».

Входящий бот. Человек уже выбрал канал. Задача — не допросить, а подтвердить намерение и дать следующий шаг.

1. Короткое приветствие и ожидание ответа (без прайса в первой реплике).
2. «Что нужно сделать / какой результат».
3. Срок: эта неделя / месяц / смотрю.
4. Если уместно — одно ограничение (гео, формат, объём).
5. Предложение слота или передача менеджеру с уже заполненной карточкой.

Сигнал в чате. Здесь важнее уважение к площадке, чем скорость закрытия.

1. Скоринг сигнала: это запрос услуги или болтовня.
2. Касание с отсылкой к его формулировке, без ссылки в первом сообщении, если правила чата запрещают.
3. Вывод в личку только после явного согласия.
4. В личке — та же короткая квалификация, что у бота, плюс пометка lead_source=chat_signal и reference на чат.

Outreach по сигналу. Контекст «откуда я» обязателен, давление запрещено.

1. Одна фраза, откуда сигнал (без выдуманной «мы давно следим»).
2. Одна ценность под его задачу.
3. Один вопрос.
4. Если молчит — не долбить тем же текстом; в CRM статус nurture или closed с кодом silent, по правилам N дней.

Версии шаблонов нумеруйте (bot_v3, signal_v2, outreach_v1). Иначе нельзя запретить то, что приносит жалобы, и нельзя оставить то, что даёт meeting.

Скоринг сигнала до первого касания

Не каждый пост «ищу X» достоин outreach. До касания проставьте простой скор 1–5:

• ясность потребности;
• свежесть сообщения (часы/дни, не археология);
• совпадение с ICP;
• риск площадки (токсичность, антиспам, чистый посев);
• возможность легально написать (открытый профиль, нет явного «не писать в ЛС»).

В работу — только сумма выше порога. Остальное в журнал отказов с кодом, без «на всякий случай напишем». Это не поиск чатов: вы скорите сообщение-сигнал, а не сообщество целиком. Чат уже может быть в базе как площадка; здесь решается судьба конкретного человека.

Порог и веса зафиксируйте в одном месте. Агент может предлагать скор, человек утверждает спорные кейсы. Без порога outbound превращается в лотерею жалоб.

Идемпотентность записи лида

Техническая скука, без которой CRM врёт. Webhook от бота, повторная доставка события, двойной Start, повторный клик по кнопке — всё это легко создаёт две сделки на один telegram_id.

Правила:

1. Ключ идемпотентности: telegram_id + тип события + id сообщения/update, если есть.
2. Повтор события обновляет карточку или пишется в timeline, но не плодит новую сделку «new».
3. Смена статуса из closer и из менеджера не должна гонять карточку туда-сюда без журнала.

Проверка на старте дня: руками дважды отправьте одно и то же тестовое событие. Если в CRM две сделки — чините до любого масштаба.

Роли без «все чуть-чуть»

Даже в команде из трёх человек роли лучше назвать явно:

• Владелец полей и словаря источников — единственный, кто меняет контракт CRM.
• Владелец шаблонов и closer-промпта — версии, запретные формулировки, A/B только через учёт.
• Владелец инцидентов бана — стоп аккаунта, разбор, пауза источника.
• Владелец SLA — алерты, разбор просрочек, эскалация менеджерам.

Агенту выдайте узкий контракт под одну роль за раз. «Агент, будь и сейлзом, и маркетологом, и админом аккаунтов» — способ получить уверенный хаос. В Solar OS скорость без владельца инцидента дороже паузы на день.

Раз в неделю 20 минут: новые карточки, meeting, SLA, баны, изменения словаря. Не презентация — рабочий журнал.

Метрики качества, а не «сколько написали»

Объём касаний без качества раздувает отчёт и сжигает канал. Смотрите связку:

1. Карточки new за период.
2. Доля дошедших до meeting.
3. Доля handoff, закрытых менеджером в срок.
4. Баны/жалобы на 100 касаний outbound.
5. Дубли, пойманные до handoff.
6. Нарушения SLA на входящем боте отдельно от outbound.

Если new растёт, а meeting нет — чините квалификацию и оффер. Если баны растут — шаблон, лимиты или ниша. Если дубли растут — идемпотентность и дедуп. Покупка ещё одного аккаунта в этот момент редко лечит причину.

Чужие проценты из кейсов в отчёт не переносите. Только числа из вашей CRM и журнала аккаунтов.

Что не писать в первом касании

Короткий стоп-лист формулировок, который стоит повесить рядом с шаблонами:

• гарантии дохода и «результат за 3 дня» без источника в базе;
• скрытая реклама под видом «просто совет»;
• срочность «сегодня последний день», если это не правда процесса;
• просьба сразу телефон/карту/предоплату до квалификации;
• тон «мы уже всё знаем о вашем бизнесе» без реального контекста сигнала.

Агент может вырезать стоп-фразы правилом. Человек утверждает исключения. Нарушение стоп-листа = инцидент, не креатив.

Реклама в бота и органика: не смешивать учёт

Если лиды в Telegram идут с рекламы (Start-параметр, deep link, пост с UTM в лендинг→бот), заведите отдельный lead_source или campaign_id. Органика бота, лид-магнит канала и paid не должны жить в одной куче «telegram».

Иначе вы «оптимизируете креатив», хотя падает органика, или наоборот. Для CRM достаточно стабильного словаря и запрета свободного ввода источника менеджером «как получится».

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

Пауза источника без драмы

Иногда правильный ход — не масштабировать, а остановить. Пауза на день дешевле недели восстановления репутации.

Триггеры паузы:

• всплеск банов/жалоб выше порога;
• рост lost с кодом spam_complaint;
• поломка идемпотентности (дубли пошли пачкой);
• SLA входящего бота красный два дня подряд;
• спорный шаблон без утверждённой новой версии.

Паузу имеет право включить владелец инцидентов. Факт паузы и причина — в журнале. Снятие паузы — только после фикса и короткого прогона на малом лимите.

Прогон за один рабочий день

Если кажется, что «уже настроено», пройдите скучный чеклист:

1. Тестовый диалог с бота — карточка за минуту.
2. Повтор того же telegram_id — дедуп или флаг, не вторая сделка.
3. Просроченный SLA на тесте — алерт пришёл.
4. Диалог до маркера meeting — задача менеджеру с контекстом.
5. lost с кодом — код виден в отчёте.
6. Тестовый outbound на безопасной площадке — в карточке видны аккаунт и версия шаблона.

Шесть зелёных пунктов закрывают больше, чем совещание «про стратегию в мессенджерах». Контур работает, когда такие проверки скучные.

Когда хватит мини-контура без парка

Не каждому бизнесу нужен Телепилот на старте. Часто достаточно:

• бот + webhook в CRM;
• словарь источников;
• SLA и дедуп;
• один менеджер на handoff;
• журнал отказов.

Парк аккаунтов и spider имеют смысл, когда входящего потока мало, а ICP реально сидит в чатах и отвечает на аккуратный outreach. Если входящий бот уже даёт meeting и проблема в обработке, сначала чините CRM и SLA. Иначе вы купите сложность поверх дырявой воронки.

Обратная ошибка тоже есть: год «только входящий», хотя продукт продаётся в нишевых чатах. Тогда отсутствие outbound — не осторожность, а слепое пятно. Решение — пилот на 14 дней с жёсткими лимитами, не сразу «50 аккаунтов».

Контрольный вопрос перед масштабом

Перед тем как увеличивать рекламу в бота или парк аккаунтов, ответьте вслух: если завтра лид напишет в 23:40, где окажется его карточка через 5 минут, кто владелец, какой следующий шаг и что бот уже обещал. Если ответа нет в CRM — масштаб рано. Сначала контракт полей, SLA и handoff, потом объём.

Этот контрольный вопрос дешевле любого тарифа на прокси и спасает от отчёта «касаний много, сделок нет». В Solar OS я возвращаюсь к нему каждый раз, когда команда просит «ещё аккаунтов» вместо разбора статусов meeting и кодов lost.

Один стандарт на всю команду

Зафиксируйте в одном абзаце: любой сигнал из Telegram за N минут становится карточкой с владельцем, источником и датой следующего шага. Всё, что не укладывается, — инцидент процесса, не «особенность канала». Этот стандарт вешают рядом с SLA и словарем источников. Тогда споры на планёрке короче, а crm telegram перестаёт быть абстракцией из выдачи и становится операционкой с проверяемым следом.

Что забрать

1. Разделите поиск чатов, интеграцию CRM↔Telegram и захват лидов — это три разных контура.
2. Лид = карточка в CRM с источником, SLA и следующим шагом, не скрин из лички.
3. Источники в словаре: bot, channel, signal, outreach, referral.
4. Сначала входящий захват и поля, потом outbound.
5. Телепилот — когда нужен парк + spider + closer с передачей в продажи, не «бот ради галочки».
6. Практика и разборы агентов — в клубе: Solar Inside.

Такая связка имеет смысл, когда мессенджер кормит воронку, а CRM её считает. Если наоборот — у вас красивый чат и слепая отчётность.