інструкція
Заявки із сайту в Google Sheets і Telegram: що робити з повторами та збоями
Щоб передавати заявки із сайту в Google Sheets і Telegram, потрібен серверний обробник форми та workflow в n8n. Обробник присвоює заявці сталий ідентифікатор, а workflow перевіряє повтор, записує заявку й надсилає повідомлення. Найважливіше — розрізняти збереження даних і підтвердження доставки. Якщо виконання обірвалося між цими кроками, автоматичний повтор може створити дубль. Такий випадок потрібно зберегти для звірки, а не вважати успішним або починати заново з іншим ідентифікатором.
- Опубліковано
- 12 жовтня 2026 р.
автор Максим Бадзюнь — засновник Patterneo
- Для однієї заявки зберігайте один request_id при повторних спробах.
- Рядок у таблиці ще не означає, що Telegram прийняв повідомлення.
- Невизначений результат потребує звірки: повтор із новим ID приховає зв'язок із першою спробою.
- Описаний пакет працює на окремому self-hosted n8n з одним записувачем; це суттєва умова, а не дрібне налаштування.
- Підтвердження Telegram API не доводить, що людина прочитала повідомлення.
Кому підходить такий маршрут
Маршрут підходить власнику невеликого сайту та інтегратору, якому потрібно зібрати звернення в одній таблиці й повідомити відповідальну людину. Google Sheets стає журналом заявок, Telegram — сигналом перевірити цей журнал. Це ще не CRM: призначення менеджерів, історію переговорів і нагадування про відповідь доведеться організувати окремо.
| Підходить | Потрібне інше рішення або доопрацювання |
|---|---|
| Є серверний обробник форми та окремий n8n | Є лише HTML-форма без серверної частини |
| Один workflow послідовно записує заявки | Кілька серверів чи workflow одночасно змінюють журнал |
| Оператор може розібрати невизначені випадки | Потрібна повністю автоматична доставка без ручної звірки |
| Достатньо сповіщення з ID заявки | Потрібні повна CRM, розподіл завдань і контроль строків |
Як налаштувати маршрут
Спочатку визначте, де живе оригінал заявки і хто відповідає за повтор після збою. У нашому варіанті сервер форми зберігає заявку та її ID до відправлення в n8n. Якщо браузер закриється, ці дані не повинні зникнути разом із вкладкою.
- Підготуйте серверний обробник. Він приймає поля
name,email,topic, створює UUID v4 у поліrequest_idі стійко зберігає їх. Email тут є контактним текстом, а не підтвердженою адресою. - Підготуйте журнал Google Sheets. Для готового пакета використайте заголовки з
sheet-header.txtбез перейменування. Обмежте доступ до таблиці людьми, які працюють зі зверненнями. - Підключіть Google і Telegram у n8n. Облікові дані зберігайте в credentials. Не вставляйте секрет webhook у код публічної сторінки.
- Імпортуйте workflow неактивним. Налаштуйте таблицю, чат і автентифікацію. У n8n тестовий та production webhook мають різні адреси; production-маршрут реєструється після публікації workflow. Це пояснює, чому успішна тестова відправка ще не перевіряє робочу адресу. Документація Webhook.
- Обмежте паралельне виконання. Для цього пакета потрібен окремий self-hosted n8n у regular mode, один процес і
N8N_CONCURRENCY_PRODUCTION_LIMIT=1. Обмеження n8n стосується production-запусків, але не всіх ручних виконань. Тому не запускайте вузли вручну паралельно з прийманням заявок. Документація concurrency control. - Перевірте нову заявку, її точний повтор і конфлікт. Лише після цього підключайте реальну форму. Покрокові команди та поля конфігурації є в інструкції пакета.
Саме додавання рядка не вирішує всю задачу: метод Google Sheets append дописує значення після знайденої таблиці. Пошук уже відомого ID та правила повтору належать до логіки workflow. Опис методу append.
Приклад: три відправлення, одна заявка
Уявімо тестову заявку з темою «Налаштувати форму консультації». Це навчальний приклад, а не статистика клієнтів. Сервер створив ID, записав дані й відправив запит. Відповідь затрималася, тому йому потрібно перевірити результат першої спроби.
| Спроба | Що передаємо | Очікувана поведінка пакета |
|---|---|---|
| Перша | Новий ID і початкові поля | Запис та повідомлення; при підтвердженому завершенні — 200 sent |
| Друга, після завершення першої | Той самий ID і ті самі поля | 200 already_sent, без нового повідомлення |
| Третя | Той самий ID, але інша тема | 409 request_id_conflict: потрібна звірка, а не перезапис |
Не змінюйте ID лише тому, що минуло кілька секунд. Для нового ID система вже не може визначити, що це повтор тієї самої заявки.
Що відбувається, коли виконання обірвалося
Найскладніший випадок — Telegram уже міг прийняти повідомлення, а workflow ще не записав підтвердження в таблицю. Відправляти ще раз навмання небезпечно: менеджер може отримати дубль.
У випробуванні Patterneo від 10 жовтня 2026 року ми примусово зупиняли процес у двох точках: перед надсиланням у Telegram і після нього, до завершального запису. Після перезапуску повтор повертав 409 needs_review і не надсилав повідомлення повторно. Це перевірка контрольованих збоїв на нашому стенді, а не гарантія для будь-якої інфраструктури.
Для заявки, щодо якої окремо підтвердили відсутність відправлення, виконали контрольоване ручне відновлення. Після нього повтор повернув already_sent. Висновок: зупинка для звірки іноді корисніша за автоматичне «спробувати ще раз».
| Результат | Що робить сервер або оператор |
|---|---|
200 sent / already_sent |
Фіксує завершення за протоколом workflow |
400 invalid_request |
Виправляє вхідні поля; не запускає безкінечні повтори |
409 request_id_conflict |
Зіставляє ID і дані в джерелі |
202 або 409 needs_review |
Звіряє журнал і Telegram; це не підтвердження доставки |
Таймаут або 5xx |
Зберігає початковий ID, перевіряє журнал; результат невідомий |
Telegram повертає об'єкт повідомлення при успішному sendMessage. Це підтвердження API, а не прочитання одержувачем. Telegram Bot API.
Помилки, яких варто уникнути
Заново запускати лише вузол Telegram. Так можна обійти перевірку ID. Для цього пакета не використовуйте Retry failed execution або Execute step як універсальне відновлення; дотримуйтеся процедури з TROUBLESHOOTING.md.
Очищати журнал ID без плану. Видалений запис перестає захищати від старого повтору. Архівування має зберігати можливість перевірити попередні заявки.
Переносити конфігурацію на кілька виконавців без перевірки. Приймання пакета стосується одного процесу та одного записувача. Воно не доводить придатність для n8n Cloud, queue mode чи кількох worker-процесів.
Надсилати в Telegram усі контактні дані. У нашому пакеті повідомлення містить лише ID заявки. Деталі залишаються в таблиці з обмеженим доступом.
Що знадобиться, крім workflow
Потрібні серверна частина форми, окремий n8n, Google-акаунт із доступом до таблиці та Telegram-бот. Готовий пакет не містить хостингу, CAPTCHA, самої форми чи її серверної черги. Їхня підготовка й підтримка потребують часу; вартість файлів не дорівнює вартості всього впровадження.
Пакет перевірено на n8n 2.42.3 і Node.js 24.21.0 в описаному локальному середовищі. Окремий імпорт пройшов у чистій базі n8n, але це не замінює встановлення незалежним покупцем. Ми не обіцяємо налаштування за кілька хвилин і не називаємо систему гарантією доставки «рівно один раз».
З чого почати
Візьміть одну тестову заявку. Перевірте її звичайну доставку, точний повтор і відповідь на той самий ID зі зміненими даними. Зафіксуйте, хто розбиратиме needs_review. Якщо на ці питання вже є відповіді, можна переходити до підключення форми.
Для описаної конфігурації є пакет «Заявка → Google Sheets → Telegram»: workflow, приклад запиту, заголовки таблиці, інструкції та ліцензія. Перед купівлею звірте вимоги середовища зі своїм n8n.