Привет. Я такие связки собираю, когда надо перестать ловить заявки руками и не плодить в базе бардак. Смысл простой: сообщение или контакт прилетает из Telegram, n8n чистит номер телефона, ищет совпадение в Notion и решает, что делать дальше — создать новую карточку или обновить существующую. Ниже покажу саму схему, поля для базы, логику дедупликации по телефону и короткий чек-лист, чтобы ты не словил дубли уже на первом дне работы.
Если говорить по-честному, главная проблема тут даже не Telegram и не Notion. Весь цирк обычно начинается на номере телефона: один и тот же человек присылает его в разном виде, менеджер потом правит запись вручную, а бот радостно считает, что это уже новый лид. Поэтому я всегда делаю два поля: одно для красивого отображения, второе — служебное, для нормализованного номера. Вот на нём и держится вся дедупликация.
Содержание:
- Что в итоге собираем и зачем это вообще нужно
- Где чаще всего ломается дедупликация по телефону
- Какие поля держать в Notion
- Схема workflow в n8n: от сообщения до карточки
- Два слоя защиты от дублей
- Как я собираю это шаг за шагом
- Чек-лист перед запуском
Что в итоге собираем и зачем это вообще нужно
Универсальный обработчик заявок из Telegram в Notion нужен там, где бот принимает входящие из лички, чата или мини-формы, а дальше ты хочешь видеть одну аккуратную карточку клиента, а не пачку дублей. В нормальной схеме workflow выглядит так: Telegram Trigger ловит событие, n8n вытаскивает имя, username, chat_id, текст и телефон, потом приводит телефон к единому виду, ищет совпадение в Notion и уже после этого решает — обновить карточку, добавить комментарий или создать новую запись.
На практике это даёт три полезных эффекта. Первый: менеджер больше не роется в чате, чтобы понять, писал ли человек раньше. Второй: в Notion не копятся одинаковые лиды с разными форматами номера. Третий: можно спокойно строить следующую автоматизацию — статусы, напоминания, сегментацию, автоответы, распределение по мастерам, что угодно.
Если тема тебе близка, рядом уже лежат полезные материалы: отдельно можно глянуть подключение Telegram к n8n, почитать про защиту вебхука от дублей запросов и сравнить эту схему с вариантом, где заявки уезжают в Google Sheets через n8n. А если у тебя уже всё тонет во входящих, советую ещё заглянуть в заметку про то, как перестать тонуть в заявках.
Где чаще всего ломается дедупликация по телефону
Вот тут начинается самая мясная часть. Самый частый косяк — люди присылают один и тот же номер в разном виде. Где-то пробелы, где-то скобки, где-то тире, где-то номер вообще прилетает как контакт из Telegram, а где-то просто текстом внутри сообщения. Для человека это один телефон. Для базы данных — уже четыре разных значения, если ты заранее не сделал нормализацию.
Второй классический фейл — ты ищешь дубли по полю «Телефон», которое менеджер редактирует вручную. Один поставил пробелы, второй убрал плюс, третий дописал в конец комментарий, и всё, поиск совпадений становится лотереей. Я так не делаю. У меня есть поле «Телефон» для красивого отображения и отдельное поле «phone_normalized» для сухой машинной логики. Из входящего значения я оставляю только плюс и цифры, а потом уже сравниваю именно это служебное поле.
Третий момент — один и тот же человек пишет несколько раз подряд, пока бот думает. Или Telegram повторно стучится в webhook, если что-то отвалилось на сети. Или сам workflow разветвился так, что одно обращение случайно обработалось дважды. Поэтому надеяться только на один поиск в Notion не стоит. Надо держать и проверку в самой базе, и дополнительную страховку внутри n8n.
Я ещё всегда учитываю простую бытовуху: иногда человек сначала пишет «здравствуйте», потом через минуту кидает номер, потом ещё раз присылает контакт кнопкой. Если на каждом шаге создавать новую запись, получишь свалку. Нормальная логика такая: пока не собран телефон, держим временный контекст по chat_id; как только номер получен, ищем совпадение и уже дальше работаем с одной карточкой клиента.
Какие поля держать в Notion
Чтобы база не превратилась в сарай, я обычно делаю минимальный, но рабочий набор полей:
- Название — заголовок карточки. Обычно имя клиента или короткая суть заявки.
- Телефон — красивое поле для чтения человеком.
- phone_normalized — служебное текстовое поле для поиска дублей.
- chat_id — чтобы потом отправить ответ именно в тот чат, откуда пришла заявка.
- username — полезно для связи и поиска вручную.
- Источник — Telegram, чтобы потом не путать каналы.
- Статус — новый, в работе, связались, закрыт.
- Текст заявки — последнее сообщение или краткая выжимка.
- Дата первого обращения и Дата последнего обращения — удобно видеть активность.
- Счётчик дублей — мелочь, а потом отлично показывает, кто долбит в чат по пять раз.
Если заявок много, я бы ещё добавил поле «Ответственный» и «Тег услуги». Тогда в Notion уже можно строить фильтры, представления и нормальную очередь обработки. Но фундамент всё равно один: телефон для глаз и нормализованный телефон для дедупликации.
Схема workflow в n8n: от сообщения до карточки
Я обычно собираю такой workflow в несколько понятных узлов. Схема не экзотическая, зато живучая.
- Telegram Trigger получает новое сообщение, контакт или нажатие кнопки.
- Дальше через Set или Edit Fields я вытаскиваю сырой текст, имя, username, chat_id и всё, что пригодится дальше.
- Следом идёт ветка извлечения телефона: если прилетел контакт, берём номер оттуда; если человек просто написал номер текстом, вытаскиваем его из сообщения.
- Потом в Code node или в паре узлов с выражениями чищу номер: убираю мусорные символы, пробелы и привожу всё к одному формату.
- Если телефона нет, workflow не лезет в Notion. Бот просит отправить номер ещё раз, лучше кнопкой контакта.
- Если телефон есть, n8n ищет совпадение в Notion по полю phone_normalized.
- Найдена запись — обновляем карточку, дату последнего обращения, текст заявки и счётчик повторов.
- Совпадения нет — создаём новую карточку лида.
- В конце бот отправляет понятный ответ: приняли заявку, обновили существующую карточку или попросили уточнить данные.
Эта схема хорошо работает и для простого сценария «бот → база», и как старт для более жирной автоматизации. Хочешь — добавляй уведомление менеджеру. Хочешь — кидай задачу в отдельное представление. Хочешь — цепляй вторую ветку с напоминанием, если по заявке никто не ответил за час.
Два слоя защиты от дублей
Вот это место советую не пропускать. Я делаю дедупликацию в два слоя.
- Слой 1 — логика записи в Notion. Сначала всегда поиск по phone_normalized. Если карточка уже есть, создаём не новый лид, а обновление существующего. Это главный источник правды.
- Слой 2 — защита внутри n8n. Добавляю Remove Duplicates там, где поток может раздвоиться или прилететь повторно. Особенно полезно, если дальше есть Merge, повторные вызовы, разбор вложений или ретраи.
Тут важно понимать разницу. Remove Duplicates умеет вычищать одинаковые элементы в текущем входном наборе и умеет помнить элементы из прошлых запусков. Это классно, когда сеть шалит или событие повторилось. Но я всё равно не полагаюсь только на память ноды. Главная проверка у меня всегда остаётся на стороне Notion, потому что база должна пережить перезапуск workflow, перенос схемы и ручные правки.
Если совсем упростить, формула такая: нормализованный телефон = ключ клиента. Нашли такой ключ в базе — обновляем. Не нашли — создаём новую запись. Всё остальное уже надстройка для устойчивости.
Как я собираю это шаг за шагом
Шаг 1. Подключаю Telegram Trigger и сразу тестирую, что workflow реально видит входящие. Если триггер чудит, первым делом проверяю публичный HTTPS-адрес инстанса и настройки webhook. На этом месте народ часто теряет полдня, хотя проблема обычно в адресе или прокси.
Шаг 2. В Telegram-ветке делаю нормальный сценарий получения номера. Самый чистый вариант — дать кнопку, которая отправляет контакт. Но я всё равно оставляю запасной путь, когда человек пишет номер руками.
Шаг 3. Нормализую телефон. Моя цель не красота, а одинаковый ключ. Все варианты записи должны превратиться в одну и ту же строку, иначе дедупликация по телефону развалится на ровном месте.
Шаг 4. Ищу запись в Notion не по красивому полю телефона, а по служебному phone_normalized. Это можно делать штатной нодой Notion, а если хочется больше контроля над фильтрами и скоростью — через HTTP Request к API Notion. Для больших баз такой вариант часто приятнее.
Шаг 5. Ставлю IF: запись найдена или нет. Если найдена, обновляю статус, время последнего обращения, текст сообщения и счётчик дублей. Если не найдена, создаю карточку с базовыми полями.
Шаг 6. После ветки create/update возвращаю человеку понятный ответ. Например: «Заявку вижу, записал» или «Контакт уже был, карточку обновил». Это очень простая штука, но она сразу гасит лишние повторы от нетерпеливых пользователей.
Шаг 7. Добавляю страховку от повторной обработки: Remove Duplicates, а ещё логирую dedupe_key, timestamp и тип события. Когда через месяц что-то поедет, ты сам себе скажешь спасибо за эти поля.
Шаг 8. В Notion делаю пару представлений: новые заявки, повторные обращения, всё с заполненным телефоном и всё, где номер ещё не заполнен. Так менеджеру не надо ковыряться в общей таблице.
Кстати, если у тебя дальше планируется более сложный бот с карточкой заказа, статусами и напоминаниями клиенту, логично потом перейти к сценарию вроде бота для мастерской со статусами. Универсальный обработчик заявок — это как хороший фундамент: сперва кажется скучной техникой, а потом именно на нём держится вся дальнейшая автоматизация.
Чек-лист перед запуском
Перед тем как включать workflow в работу, я прохожусь по короткому списку:
- Telegram Trigger реально получает сообщения в активном режиме.
- Телефон можно получить и контактом, и текстом.
- phone_normalized всегда создаётся одинаково.
- Поиск в Notion идёт именно по служебному полю, а не по красивому отображению.
- IF-ветка чётко разделяет create и update.
- Счётчик дублей и дата последнего обращения обновляются.
- Ответ пользователю отправляется после успешной записи или обновления.
- Логи позволяют понять, почему запись создалась или почему обновилась.
Если этот чек-лист проходит, значит связка Telegram → n8n → Notion уже не игрушка, а вполне рабочий инструмент. И вот тут начинается кайф: вместо ручной переброски заявок ты получаешь одну точку входа, чистую базу и нормальную историю клиента. Для маленькой мастерской, сервиса, студии или локального бизнеса это реально одна из самых практичных схем автоматизации, которую можно собрать и потом спокойно наращивать дальше.
Я бы так сформулировал итог: хочешь, чтобы обработка заявок из Telegram в Notion работала стабильно, не гоняйся за хитрыми трюками. Сначала приведи телефон к одному виду, потом ищи по нему запись, потом уже решай — обновление или создание. Когда дедупликация по телефону сделана нормально, вся остальная автоматизация ложится сверху очень бодро и уже не рассыпается от первой же повторной заявки.