Zero-code. Продажа ботов и автоматизаций под ключ

Telegram

-конструктор

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

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

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

Пробная сборка перед обещанием

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

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

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

Глава 6. Рабочее окружение и доступы

Разделение учебной и рабочей среды

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

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

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

Кто владеет аккаунтами

Рабочий бот, CRM и подписки желательно оформлять на клиента. Интегратор получает роль с необходимыми правами. Это упрощает передачу: при завершении договора заказчик сохраняет систему, а не зависит от вашего личного аккаунта.

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

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

Секреты и подключения

Токен бота и API-ключ дают программе право действовать от имени соответствующей интеграции. Их хранят в предусмотренном платформой механизме credentials или connections, а не в тексте заметок, таблице заявок и скриншоте для портфолио.

Секрет может находиться не только в заголовке запроса. У входящего вебхука Битрикс24 чувствительная часть входит в адрес. Поэтому журналирование полного адреса способно раскрыть доступ. При демонстрации скрывайте и параметры авторизации, и такие адреса.

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

Реестр зависимостей

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

Добавьте сведения о сроке подписки и контакте администратора. Просроченная оплата платформы и программный дефект могут выглядеть одинаково для клиента: заявки перестали проходить. Без реестра вы потратите время на отладку исправного сценария.

Проверка готовности

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

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

Глава 7. Проект в

Make

от формы до сделки в Битрикс24

Результат и условия учебной сборки

Соберём сценарий, который получает заполненную заявку через вебхук, сохраняет её в журнал, создаёт сделку в тестовой CRM и возвращает номер созданного объекта. Это первый самостоятельный проект. Здесь нет нейросети и диалога: источник уже собрал необходимые сведения. Позже этот же вход можно подключить к конструктору бота.

Используйте отдельную тестовую воронку Битрикс24. Для первого запуска достаточно сделки с описанием и внешним номером; контакт будет подключён после освоения API в следующем техническом разделе. Такое разделение позволяет сначала проверить передачу заявки, затем добавить поиск человека и связь сущностей.

Понадобятся аккаунт Make с доступом к Webhooks, Data store и HTTP, тестовый портал CRM и REST-доступ с правом создания сделки. Доступность API, региональные ограничения и способы оплаты проверьте до сборки. Не подключайте учебную цепочку к рабочей форме компании.

Шаг 1. Подготовьте входные данные

Создайте новый сценарий и добавьте Webhooks — Custom webhook. Назовите вебхук «ТехСервис учебный вход». Полученный адрес храните в закрытых настройках источника. Он понадобится при отправке тестового POST-запроса, но не должен попадать в портфолио.

В HTTP-клиенте, например Postman, выберите POST, вставьте адрес вебхука и задайте заголовок Content-Type со значением application/json. В Body выберите raw и JSON. Отправьте следующий объект, предварительно включив ожидание данных через Run once:

{

"request_id": "FORM-001",

"source": "test_form",

"client_name": "Тестовый клиент",

"contact_phone": "TEST-PHONE-001",

"service_type": "washer",

"problem_text": "Не сливает воду",

"confirmed": true

}

TEST-PHONE-001 — специально не телефон. В этом проекте он передаётся как текст в описании, без звонков и создания телефонного поля. Когда подключите настоящий контакт, замените учебный маркер допустимым тестовым значением, согласованным владельцем CRM. Нельзя брать случайный реальный номер.

Откройте выход вебхука. Убедитесь, что request_id и problem_text определены как строки, confirmed — как логическое значение. Если вместо отдельных полей пришла одна строка, проверьте Content-Type и валидность JSON. Повторно определите структуру по корректному образцу, прежде чем подключать остальные модули.

Шаг 2. Сохраните заявку до обращения к

CRM

Создайте Data store с названием ts_requests. Ключ записи будет равен request_id. Добавьте текстовые поля state, source, client_name, contact_phone, service_type, problem_text, crm_id и last_error. Для учебного журнала crm_id удобно хранить как строку: пустое значение означает, что ID пока не получен.

После вебхука поставьте Router с двумя ветками. На допустимой ветке установите фильтр: request_id не пустой, problem_text не пустой, confirmed равен true. На второй ветке задайте обратное условие и Webhook response с кодом 400 и телом {"status":"invalid_input"}. Обе ветки не должны срабатывать одновременно; фильтр первой ветки не ставится перед Router, иначе недопустимые данные исчезнут до ответа.

В допустимой ветке добавьте Data store — Check the existence of a record. Выберите ts_requests и сопоставьте Key с request_id входного вебхука. Поставьте Router: новая запись идёт на создание, существующая — на чтение через Get a record. В новой ветке используйте Add/replace a record: Key равен request_id, state равен received, остальные поля берутся из входа, crm_id и last_error пустые.

До теста включите последовательную обработку вебхуков в настройках сценария. В разных версиях настройка может называться Sequential processing или Process data in order. Она нужна, чтобы две доставки не выполнили проверку отсутствия одновременно. Ограничение действует внутри этого сценария: второй сценарий, ручной запуск или иной записывающий процесс могут обойти его. Во время учебного опыта оставьте единственного исполнителя для ts_requests.

Шаг 3. Проверьте доступ к Битрикс24

Создайте входящий вебхук CRM с минимально необходимыми правами. Его базовый адрес содержит домен портала, пользователя и секрет. В HTTP — Make a request укажите POST к методу crm.item.fields, Content-Type application/json и тело {"entityTypeId":2}. Это запрос схемы полей сделки, без создания объекта.

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

В учебной записи адрес HTTP-модуля складывается из закрытого базового адреса REST-вебхука и имени crm.item.add. Не вставляйте секрет в названия модулей. У HTTP-модуля включите разбор JSON-ответа, если такая настройка доступна в его версии. Сначала добейтесь чтения схемы: создание сделки с неработающими правами только усложнит диагностику.

Шаг 4. Сформируйте тело запроса без ручной склейки

Добавьте JSON — Create JSON и создайте структуру по следующему образцу:

{

"entityTypeId": 2,

"fields": {

"title": "Учебная заявка FORM-001",

"comments": "Не сливает воду. Контакт TEST-PHONE-001",

"originatorId": "ts_form",

"originId": "FORM-001"

}

}

Затем замените образцы динамическими значениями: title собирается из текста «Учебная заявка» и request_id; comments содержит problem_text и контактный маркер; originId равен request_id. originatorId оставьте постоянным ts_form. JSON-модуль должен экранировать кавычки и переносы строк. Не собирайте тело обычной строкой с подставленным клиентским текстом.

В HTTP-модуле crm.item.add передайте выход Create JSON как тело application/json. Если используемая версия HTTP предлагает собственный конструктор JSON, можно сопоставить поля в нём вместо отдельного модуля. В обоих случаях массивы, числа и логические значения должны сохранить типы.

Пример сокращённого успешного ответа: {"result":{"item":{"id":104,"title":"Учебная заявка FORM-001"}}}. Число 104 вымышлено. Извлеките result.item.id из фактического ответа, затем обновите запись ts_requests: state равен crm_created, crm_id равен полученному ID. Перед обновлением поставьте Router: успешная ветка требует отсутствия поля error и непустого result.item.id. Другой ответ направьте в review_required, сохранив причину; в этой ветке подтверждение created не отправляется. При обновлении сохраните исходные поля заявки; не заменяйте их пустыми значениями.

Шаг 5. Верните подтверждённый результат

Последним модулем новой ветки добавьте Webhook response: код 200, Content-Type application/json. Тело сформируйте через JSON-модуль: status равен created, request_id берётся из входа, crm_id — из ответа CRM. Пример результата: {"status":"created","request_id":"FORM-001","crm_id":"104"}.

Откройте сделку вручную. Проверьте описание, внешний номер и воронку. Только после этого отправьте FORM-002 с другим текстом. В CRM должны появиться две разные заявки с соответствующими описаниями. Если текст совпал, значит где-то остался образец вместо сопоставления.

В ветке существующей записи Get a record должен получить сохранённый state и crm_id. Если ID есть, верните 200 со status already_created и прежним crm_id. При этом ветка не вызывает crm.item.add. Повторите FORM-001: число сделок не должно увеличиться.

Если запись существует, но crm_id пустой, верните 202 со status review_required и сохранённым request_id. Такой ответ означает необходимость проверки, а не создание сделки. В этой учебной версии незавершённые заявки восстанавливаются вручную по следующей процедуре. Нельзя отправлять их снова на создание только потому, что ID отсутствует в журнале.

Шаг 6. Обработайте неопределённый результат

На HTTP-модуль создания поставьте обработчик ошибки. При timeout либо неопределённом сетевом отказе обновите state до review_required и запишите короткую причину в last_error. Сначала убедитесь на отключённом тестовом подключении, что обработчик действительно выполняется и исходная запись сохраняется. После записи ошибки верните Webhook response с кодом 202 и телом {"status":"review_required","request_id":"[исходный номер]"}, сформированным через JSON. Завершите обработчик Retry с Automatically complete execution равным No; в прежних интерфейсах аналогичная директива называлась Break. В настройках включите Store incomplete executions. Сохранённое выполнение не запускайте повторно до сверки CRM: ручная кнопка повтора также может создать дубль. Не используйте Resume с вымышленным ответом CRM.

Для сверки создайте отдельный диагностический HTTP-запрос к crm.item.list. Тело: {"entityTypeId":2,"filter":{"=originatorId":"ts_form","=originId":"FORM-001"},"select":["id","title","originatorId","originId"]}. В filter подставьте номер восстанавливаемой заявки. В учебном запросе ожидается малый результат; для общего списка учитывайте пагинацию.

Один найденный объект позволяет перенести его id в журнал и завершить обработку. Несколько объектов требуют ручного разбора. Если ничего нет, проверьте правильность фильтра на заведомо существующей FORM-002, затем повторите чтение после паузы. Решение о повторном создании принимает человек после проверки CRM и журнала. originId помогает поиску, но сам по себе не объявляется уникальным ограничением CRM.

Проверки проекта: новая заявка, повтор прежнего номера, другой номер с тем же текстом, неподтверждённые данные, кавычки в описании и отказ CRM. Сохраните результат каждого опыта. После этого у вас есть воспроизводимая передача формы в CRM с ограниченным режимом восстановления, а не только схема на экране.

Глава 8. Проект

Telegram

-бота в

n

8

n

с журналом и передачей менеджеру

Что делает первая версия

Второй проект принимает одно текстовое обращение, сохраняет его в таблице, отправляет сотруднику и подтверждает получение клиенту. Бот отвечает на /start отдельным пояснением. Фотографии и прочие неподдерживаемые сообщения получают просьбу написать текстом. Нейросеть подключается после проверки этого маршрута.

Здесь одно обычное текстовое сообщение считается отдельным обращением. Это сознательно простой режим: бот не собирает многошаговую анкету, не обещает выезд и не создаёт запись клиента в CRM. Если пользователь отправил три отдельных сообщения, получится три обращения. Для объединения сообщений потребуется состояние диалога, которое рассматривается дальше.

Шаг 1. Создайте бота и получите чат сотрудника

В BotFather создайте отдельного учебного бота командой /newbot. В n8n добавьте Telegram credentials и сохраните токен там. Создайте Telegram Trigger, выберите событие Message и эти credentials. Отправьте боту /start, запустив ожидание тестового события.

Откройте JSON-выход триггера. Запишите message.chat.id вашего тестового сотрудника: это получатель служебных уведомлений. Сотрудник должен сам открыть бота и отправить сообщение до первой попытки отправки ему. Для клиента chat_id всегда извлекается из его события, а служебный получатель задаётся отдельной конфигурацией.

Во время учебного опыта не используйте один токен одновременно в SendPulse, Make и n8n. У бота одна регистрация webhook, и новое подключение может заменить прежнее. Для собственного хостинга n8n должен иметь корректный публичный HTTPS-адрес, доступный Telegram.

Шаг 2. Разделите типы входа

После триггера добавьте Switch с режимом Rules. Первое правило: message.text равно /start. Второе правило: message.text существует и не равно /start. Для остальных данных используйте fallback output. Назовите выходы «Начало», «Обращение» и «Другой формат». Настройте отправку только в первый совпавший выход, если редактор предлагает вывод во все совпавшие.

В «Начало» добавьте Telegram — Message — Send Message. Chat ID задайте выражением {{ $json.message.chat.id }}. Текст: «Опишите проблему одним сообщением. Бот передаст обращение менеджеру. Дату и стоимость ремонта подтверждает сотрудник». Отключите разметку сообщения либо используйте обычный текст.

В fallback поставьте такой же узел ответа с текстом «Для этой версии нужна текстовая заявка. Напишите описание одним сообщением». В этой ветке таблица обращений не пополняется. Убедитесь, что сообщение с фотографией не попало в правило текста; подпись фотографии обрабатывается отдельно только после сознательного расширения входа.

Шаг 3. Нормализуйте обращение

На текстовой ветке добавьте Edit Fields с именем «Нормализация». В ручном сопоставлении создайте четыре строки: request_id, chat_id, problem_text и state. Для request_id используйте выражение {{ 'tg_' + String($json.update_id) }}, для chat_id — {{ String($json.message.chat.id) }}, для problem_text — {{ $json.message.text }}, для state задайте received.

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

После нормализации поставьте IF: длина problem_text после trim больше нуля и не превышает учебный предел 1000 символов. Для второго условия можно использовать {{ $json.problem_text.length }}. В false-ветке попросите сократить описание, не записывая заявку. Предел выбран для упражнения; рабочий предел согласуйте с бизнесом.

Шаг 4. Создайте постоянный журнал

В разделе Data tables создайте ts_telegram_requests. Добавьте строковые столбцы request_id, chat_id, problem_text, state и manager_message_id. Системные id и даты таблицы не заменяют request_id. Пустой manager_message_id означает, что подтверждённого результата уведомления пока нет.

После IF добавьте Data Table: Resource Row, Operation Get, таблица ts_telegram_requests. Conditions: request_id Equals {{ $json.request_id }}; Limit поставьте 1. В настройках узла включите Always Output Data, чтобы отсутствие строки не остановило новую заявку. После него поставьте IF с проверкой существования id возвращённой строки.

В true-ветке прочитайте state. Для notified верните клиенту прежний request_id и остановите маршрут. Для остальных состояний отправьте обращение на ручную сверку: повтор создания записи и автоматическая повторная отправка менеджеру в этой версии запрещены. Так потеря подтверждения не становится причиной серии одинаковых уведомлений.