Telegram-бот и Google Таблицы: заказы без ручного ввода

Вместо ежедневного переноса заявок из переписки настройте связку Telegram-бота с Google Таблицами: бот собирает заказ, сервер проверяет поля и записывает строку через Google Sheets API. Ниже — порядок настройки для 2026 года: от доступа к таблице до защиты от повторных записей и уведомлений клиенту.

Зачем связывать бота с таблицей

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

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

Whomever разрабатывает Telegram-ботов и CRM-системы для бизнеса. Для этой интеграции сначала опишите рабочий процесс: что сообщает клиент, что проверяет сервер и что после этого делает менеджер. Выбор технологий идёт следом.

Перед началом

• Подготовьте доступы. Нужны аккаунт Telegram с доступом к BotFather, Google-аккаунт с правом управлять таблицей и проект Google Cloud с возможностью включить Google Sheets API и создать сервисный аккаунт.
• Подготовьте среду выполнения. Нужен постоянно работающий сервер или другой управляемый процесс, где разработчик разместит обработчик Telegram и секреты. Эта инструкция описывает заказную интеграцию, а не настройку исключительно внутри Google Таблиц.
• Проверьте ограничение заранее. Сервисный аккаунт — отдельный участник доступа. Создать его ключ недостаточно: таблицу нужно открыть именно его адресу. Политики вашей организации также могут запрещать создание ключей или внешний доступ.

Не передавайте подрядчику пароль от личного Google-аккаунта. Выдайте необходимые права на проект и рабочую таблицу, а владение ресурсами оставьте компании.

Выбор способа получения сообщений

Telegram поддерживает получение обновлений через getUpdates и webhook. Для первого запуска ниже используется getUpdates: сервер сам запрашивает новые события. Это убирает необходимость сразу настраивать публичный входящий HTTPS-адрес, но не отменяет сервер.

Для первого запуска выбирайте один способ получения событий. getUpdates не работает, пока у бота установлен webhook. При смене способа сначала проверьте текущую конфигурацию, иначе исправный обработчик будет выглядеть неработающим.

Ни один вариант не защищает от дублей автоматически на уровне вашего заказа. Идентификатор события и состояние заказа нужны в обоих случаях.

Таблица заказов

Создайте структуру до подключения API

1. Создайте отдельную рабочую таблицу и назовите лист Заказы. Это предлагаемое имя для примера, а не обязательное требование Google.
2. Добавьте заголовки: order_id, created_at, chat_id, customer_name, phone, items, comment, status.
3. Для телефона и идентификаторов установите текстовый формат через Формат, Число, Обычный текст. Названия относятся к русскоязычному интерфейсу Google Таблиц.
4. Выделите поля, которые заполняет интеграция, и поля менеджера. Например, сервер создаёт заказ со статусом Новый, а сотрудник дальше меняет status.
5. Скопируйте идентификатор таблицы из адресной строки: он расположен между /d/ и следующим /. Не путайте его с идентификатором отдельного листа.

Ожидаемый результат: у разработчика есть идентификатор документа, точное имя листа и согласованный порядок столбцов. Тестовый телефон сохраняется с начальным плюсом, а длинный идентификатор не превращается в округлённое число.

Определите единицу записи

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

Заранее решите, как записывать время. Например, храните момент создания в ISO 8601 с часовым поясом и настройте отображение для сотрудников. Иначе время сервера и время в таблице будут трудно сопоставимы при разборе ошибки.

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

Доступ к Google Sheets API

Настройте сервисный аккаунт

1. В Google Cloud выберите проект. В англоязычной консоли откройте APIs & Services, затем Library, найдите Google Sheets API и нажмите Enable.
2. Откройте IAM & Admin, затем Service Accounts. Через Create service account создайте отдельную учётную запись интеграции. Не выдавайте ей роль владельца проекта ради записи в таблицу.
3. Если используемая среда требует JSON-ключ, откройте сервисный аккаунт: Keys, Add key, Create new key, JSON, Create. Если политика организации запрещает ключи, используйте разрешённый администратором способ серверной авторизации.
4. Скопируйте email сервисного аккаунта. В Google Таблицах нажмите Настройки доступа, добавьте этот адрес и назначьте роль Редактор.
5. Сохраните секрет в защищённой конфигурации сервера. Не загружайте JSON-ключ в репозиторий, таблицу или общий чат.

Для серверной авторизации используйте официальную библиотеку Google и область доступа https://www.googleapis.com/auth/spreadsheets. Это идентификатор разрешения, а не адрес страницы для посетителя.

Ожидаемый результат: сервер под сервисным аккаунтом читает заголовки рабочего листа и записывает тестовую строку. Доступ проверен именно серверными учётными данными, а не браузером владельца документа.

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

Приём заказов в Telegram

Создайте бота и сценарий диалога

1. Откройте официальный BotFather в Telegram, отправьте /newbot и выполните его инструкции. Полученный токен сохраните в секретах серверной среды.
2. Для выбранного режима getUpdates проверьте состояние webhook через getWebhookInfo. Если webhook установлен и больше не нужен, удалите его методом deleteWebhook, затем запускайте опрос.
3. Реализуйте последовательность: имя, телефон, состав заказа, комментарий, итоговое подтверждение. Это поля предлагаемого сценария; Telegram не создаёт такой диалог автоматически.
4. Перед отправкой показывайте клиенту собранные данные и действия Подтвердить заказ и Изменить данные. Эти подписи нужно добавить в собственном боте.
5. После подтверждения проверяйте обязательные поля на сервере. Не считайте телефон достоверным только потому, что пользователь ввёл строку подходящей длины.

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

Разделите черновик и заказ

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

Не формируйте заказ из каждого нового сообщения. Иначе исправление телефона превратится в отдельную строку, а комментарий после подтверждения — в ещё одну заявку. Определите отдельное действие для изменения уже принятого заказа.

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

Запись и проверка результата

Свяжите подтверждение с сохранением

1. Получите событие Telegram и проверьте, обрабатывалось ли оно раньше. Для событий используйте update_id, для бизнес-заявки — собственный order_id.
2. Сохраните подтверждённый заказ в постоянном хранилище со статусом передачи в таблицу. Зафиксируйте позицию получения событий так, чтобы перезапуск не терял уже принятые заявки.
3. Подготовьте значения в согласованном порядке столбцов. Передайте их через метод Google Sheets API spreadsheets.values.append в диапазон 'Заказы'!A:H.
4. Для пользовательских значений выберите параметр valueInputOption=RAW. Так текст клиента не будет интерпретироваться как формула при записи через этот запрос.
5. После успешного ответа отметьте передачу как завершённую и отправьте клиенту подтверждение с order_id. Если результат запроса неизвестен из-за обрыва связи, сначала проверьте наличие этого заказа в таблице.

Ожидаемый результат: одна подтверждённая заявка появляется в правильных колонках, а повторное событие не создаёт дополнительную строку. Ошибка Google не превращается в ложное сообщение клиенту об успешном приёме.

Проведите приёмочный тест

Для запуска в 2026 году подготовьте 5 тестовых заявок: обычную, с пустым обязательным полем, с исправлением телефона, с повторным подтверждением и с временно отключённым доступом к таблице. Это предложенный набор проверки, а не показатель производительности.

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

Повторный запуск — обязательная часть проверки. Успешная запись при первом нажатии ничего не говорит о поведении системы после сетевого сбоя.

Второй сценарий: уведомление при изменении статуса

После записи заказа можно добавить обратное направление: менеджер меняет status, бот сообщает клиенту результат. Это отдельный процесс, а не автоматическое свойство подключения таблицы.

1. Согласуйте разрешённые статусы и тексты уведомлений. Не отправляйте клиенту внутренние комментарии менеджера.
2. Для первого варианта настройте серверную проверку изменений, например раз в 1 минуту. Это выбранный интервал, не обещание мгновенной доставки.
3. Храните последний отправленный статус отдельно от текущего значения. Отправляйте сообщение только при разрешённом переходе и сохраняйте результат доставки.
4. Проверяйте соответствие order_id и chat_id. Не ищите получателя только по имени или номеру строки.

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

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

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

• Google возвращает 403. Проверьте включение Google Sheets API, адрес сервисного аккаунта, роль в документе и политики организации. Доступ вашего личного аккаунта не подтверждает доступ сервера.
• Бот не получает сообщения. Проверьте webhook, токен и количество запущенных обработчиков. При опросе не запускайте конкурирующие процессы с одним токеном без согласованной архитектуры.
• Заказы дублируются. Проверьте сохранение update_id, повторное использование order_id и поведение после сетевого тайм-аута. Простого повторения append недостаточно: предыдущая запись уже могла сохраниться.
• Значения попадают не в те колонки. Сверьте имя листа, диапазон и порядок полей. Закрепите структуру и проверяйте заголовки перед записью; не исправляйте ошибку перестановкой значений вручную.
• Строка есть, уведомления нет. Отделите результат записи от результата отправки сообщения. Повторяйте уведомление по сохранённому заказу, а не создавайте заказ заново.

Как расширить процесс

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

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

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

FAQ

Последняя проверка

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

Материалы по теме

• Telegram-бот для интернет-магазина
• Как подключить Payme и Click к Telegram-боту
• CRM-системы для малого бизнеса