Как связать Telegram и Notion, чтобы заявки не терялись
Как собрать базу заявок в Notion и связать её с Telegram: готовая интеграция или свой бот, что умеет каждый вариант и когда какой из них выбрать.
Содержание и поиск · 8
Клиент пишет туда, где ему удобно: кто-то в личку, кто-то под пост, кто-то в общий чат. Вы отвечаете с телефона между встречами и обещаете прислать детали завтра, а дальше заявка живёт внутри этого чата. Ждёт она недолго: сегодня человек готов платить, а через три дня спрашивает то же самое у конкурента.
Через неделю от разговора остаётся смутное «кто-то спрашивал про CRM, кажется, из агентства», а поиск по чатам выдаёт три похожих диалога. Ни по одному из них не понятно, чем дело кончилось, и писать человеку уже поздно: свой вопрос он закрыл без вас. Причина простая: всё, что хранится в чатах, там же и теряется, потому что переписку почти невозможно разложить по полкам.
Картина меняется, когда у заявки появляется постоянное место: база в Notion, где у каждого обращения есть статус, дата и человек, который за него отвечает. Собрать такую базу можно за полчаса, и куда интереснее другой вопрос: кто будет переносить в неё сообщения из Telegram. Способов всего три, и дальше мы сравним их по деньгам, по усилиям и по тому, что в каждом чаще всего идёт не так.
Заявка становится управляемой в ту минуту, когда у неё появляются три поля: статус, срок и ответственный. Вся остальная статья про то, кто их будет заполнять.
Почему заявки пропадают именно в чатах
В проектах с командами я вижу одну и ту же картину. Часть заявок лежит в личных сообщениях у руководителя, часть в общем чате, часть в комментариях под постом. Собрать их в один список может только человек, который держит в голове все три места. Пока он на связи, это даже похоже на систему, но стоит ему уехать в отпуск, и половина запросов остаётся без ответа.
Вторая беда приходит вместе с ростом команды. Когда менеджер передаёт проект, вместе с ним уходит и контекст переписки. Новый человек открывает чат на двести сообщений и не понимает, что из этого клиенту уже пообещали. Он либо переспрашивает и выглядит в глазах клиента новичком, либо додумывает сам, и тогда обещание всплывает через месяц уже в виде претензии.
Вместо нормальной CRM в команде вводят правило «отвечать сразу», и первую неделю всё работает. Потом появляется завал и срочные задачи, и всё возвращается на круги своя, потому что правило живёт на усилии человека, а список работает сам.
Поэтому первое, что нужно сделать, это создать базу, куда будут приходить заявки, и только потом решить, кто будет их туда заносить.
База заявок закрывает половину задачи
Это самая скучная часть работы и одновременно самая полезная: хватает шести полей, чтобы поток сообщений превратился в список, по которому можно работать.
- Имя и контакт. Кто пришёл и как с ним связаться, если Telegram вдруг отвалится.
- Запрос. Что человеку нужно, записанное его же словами.
- Статус. Новая, в работе, ждёт ответа, закрыта.
- Дата обращения. По ней видно, кто ждёт вас третий день.
- Ссылка на переписку. Возвращает в нужный диалог одним нажатием.
- Источник. Канал, сайт или рекомендация: через месяц станет ясно, что приносит людей.
Поверх полей собираются два представления, и они полезнее самих полей. Первое показывает заявки без ответа по дате, и это ваш рабочий список на день. Второе раскладывает их доской по статусам, и на нём сразу видно, где образовался затор.
База собирается за вечер, а дальше начинается то, из-за чего всё обычно разваливается: кто-то должен переносить в неё сообщения. Пока этим занимаетесь вы, список живёт ровно до первой загруженной недели.
Как связать Telegram с Notion
Есть всего три способа, и отличаются они тем, сколько вы вкладываете на старте и сколько платите потом за каждую следующую заявку.
- Руками. Вы читаете сообщение и сами заводите запись в базе. Это нормально работает, пока заявок меньше десяти в неделю, а дальше перенос съедает больше времени, чем заняла бы настройка связки.
- Готовая интеграция. Настройка с помощью сторонних приложений Make, n8n или Zapier. Платите вы за каждое выполненное действие, и умеет такая связка ровно то, что заложено в её шагах.
- Свой бот. Программа работает с Notion напрямую через API, то есть через набор команд, которыми один сервис управляет другим. Бот задаёт вопросы по очереди, проверяет ответы, принимает файлы и голосовые, а платите вы один раз за разработку и потом понемногу за сервер.
Выбор между вторым и третьим сводится к одному вопросу: сколько шагов проходит заявка, прежде чем попасть в базу. Если шаг один и сообщение просто превращается в строку, хватит готовой интеграции. Если шагов три и больше, и по дороге надо задать вопросы, проверить ответы и разложить их по разным базам, дешевле выходит свой бот.
Ниже посмотрим, какие возможности и ограничения есть у телеграм-бота.
Что умеет бот и чего он не может
Бот принимает текст, файлы, фотографии и голосовые, задаёт вопросы по очереди и раскладывает ответы по полям базы. Он пишет вам в отдельный чат о каждой новой заявке, так что следить за базой руками не приходится. Он же умеет завести сразу две записи: заявку в одной базе и задачу в другой, и связать их между собой.
Есть и две вещи, которых бот не умеет, и обе стоит знать заранее. Первым он написать не может: бот отвечает только тем, кто сам начал с ним разговор. Быстро он тоже не умеет: Notion принимает от интеграции около трёх запросов в секунду. Плотный поток из-за этого выстраивается в очередь, хотя команде на 5–100 человек такой скорости хватает с запасом.
Посчитайте, сколько вопросов вы задаёте человеку, прежде чем понять его запрос. Столько же шагов пройдёт бот, и столько полей появится в карточке заявки.
Сильнее всего бот меняет качество карточек: он не пускает человека дальше, пока тот не ответил на вопрос, поэтому вместо «здравствуйте, хочу узнать про работу» в базе появляются имя, запрос и контакт. С такими карточками можно работать сразу, не затевая новую переписку ради выяснения деталей.
Что чаще всего идёт не так
Подводит такая связка обычно на втором месяце, и подводит тихо: бот продолжает бодро отвечать человеку, а записи в базе почему-то не появляются.
Человек написал дважды, и в базе лежат две строки про один запрос. Лечится проверкой: перед записью бот ищет заявку с тем же контактом за последние сутки.
Поле переименовали, и бот перестал его заполнять, а ошибку видно только в журнале. Поэтому имена полей меняют вместе с настройками бота.
Третья сложность связана с опознанием человека. У него в Telegram может не быть короткого имени, и тогда в карточке остаются только имя с фамилией, а написать ему первым вы уже не сможете. Лечится это одним вопросом внутри бота: спросите телефон или почту прямо в разговоре.
Все три случая разбираются на этапе проектирования, пока сценарий ещё на бумаге, и стоят копейки по сравнению с правками после запуска. Поэтому работу я начинаю с разбора процесса: из каких этапов состоит воронка заявок, какие поля нужны для работы с ними и кто будет их вести.
Кто видит заявки
Вся информация из телеграм-бота попадает напрямую в базу внутри Notion, и настраивается это один раз, через интеграцию со своим ключом. Доступ ей выдаётся по одной базе: открыли заявки, и всё остальное пространство для бота закрыто, поэтому даже утечка ключа оставляет посторонним одну базу заявок, а весь архив компании остаётся закрытым.
Сотрудникам доступ выдаётся отдельно, правами самой базы: менеджер правит статусы, подрядчик видит только свои строки, а бот работает мимо этих прав, под собственным ключом.
Никогда не храните ключи в открытом доступе и не пересылайте их в рабочие чаты. Раз в пару месяцев открывайте настройки интеграции и смотрите список подключённых баз: лишнее убирайте, а ключ меняйте, когда из команды уходит человек, который его видел.
Когда хватает интеграции и когда нужен бот
Готовой интеграции хватает, пока сценарий один и выглядит просто: пришло сообщение, появилась строка. Такую связку собирают за вечер и спокойно живут с ней годами, изредка поправляя шаги.
Свой бот окупается в трёх случаях. Первый — когда заявка идёт по ветвящемуся сценарию и следующий вопрос зависит от предыдущего ответа. Второй — когда одна заявка должна попасть сразу в несколько мест: клиенту ответ, менеджеру задача, в отчёт строка. Третий — когда поток плотный, и плата за каждое действие в готовом сервисе растёт быстрее, чем обходится собственный бот. Как такая связка выглядит в частной практике, с карточкой клиента и записью на сессии, разобрано в статье про кабинет коуча и психолога.
В моих проектах это называется автоматизацией входящих: сообщение превращается в запись с полями и попадает тому, кто за него отвечает. Такую связку я собираю отдельно или сразу внутри цифрового офиса, где рядом с заявками живут задачи, проекты и база знаний команды. Что входит в разработку, видно на странице решений для команд.
С чего начать
- Выпишите каналы. Личные сообщения, общий чат, комментарии, форма на сайте: обычно их оказывается больше, чем помнится по памяти.
- Создайте базу заявок. Шесть полей из раздела выше и два представления, и половина хаоса уходит уже на этом шаге.
- Посчитайте шаги. Прикиньте, сколько вопросов надо задать человеку и в сколько мест попадает одна заявка.
- Приходите на разбор. Если шагов больше или заявки идут из нескольких мест, нужен бот под ваш процесс, и на бесплатном созвоне я смотрю, как работает команда, и говорю, что автоматизировать первым.
Когда у каждой заявки есть своё место, картина видна как на ладони: утром понятно, кто написал вчера, кому вы уже ответили, а кто ждёт третий день и может уйти к конкуренту. За 30–45 минут на разборе процесса я разберу ваш процесс работы с клиентами и покажу, где заявки теряются сейчас.
Порядка в работе команды,
Мария Гаврилова
Notion-архитектор для команд
Частые вопросы
Сколько времени занимает сделать бота под наш процесс?
До 2–3 недель. Срок зависит от того, сколько шагов проходит заявка и с какими сервисами бот должен соединиться. Простой приём заявок делается заметно быстрее, чем сценарий с ветвлением, файлами и несколькими базами.
У нас уже собрана связка в Make, её можно доработать?
Да, и чаще всего в таких связках не хватает трёх вещей: проверки на дубли, уведомлений и полей, по которым потом считают деньги. Я смотрю, что уже собрано, и говорю, где выгоднее доработать имеющееся, а где дешевле перейти на своего бота.
У нас есть CRM. Зачем тогда Notion?
Если CRM закрывает сделки и команда в ней живёт каждый день, заявки стоит вести там же. Notion выигрывает в том случае, когда рядом с заявкой нужны задачи, проекты и база знаний в одном пространстве. На созвоне мы разбираем ваш случай, и я честно говорю, когда переезд не нужен.
Кто будет поддерживать бота после запуска?
Поддержку можно оставить себе или передать мне: сопровождение стоит от 4 600 ₽ или 46 € в месяц и включает правки в сценарии, новые поля и разбор поломок. Команды обычно берут его на первые месяцы, пока процесс ещё меняется.
Сможет ли команда сама менять базу после внедрения?
Да, этому я учу прямо на внедрении. В разработку цифрового офиса входит обучение команды и месяц поддержки после запуска, чтобы дальше вы правили систему сами и не зависели от подрядчика.
Можно начать с малого, без большого проекта?
Да, для этого есть консультация: полтора часа созвона за 15 000 ₽ или 150 €, и неделя поддержки после него. За это время мы обычно успеваем разобрать процесс заявок, наметить структуру базы и решить, нужен ли вам бот вообще.