У демонстрационной заявки есть пометка — «Сайт». У соседней может стоять «Бот». В коде @millerpro_demo_bot эти слова записываются рядом с именем и сообщением, чтобы потом попасть в веб-таблицу. Пометка сообщает, откуда пришёл человек, и на этом умолкает.
А человеку ещё надо ответить.
Вот с этого места я предлагаю выбирать, что должен делать Telegram-бот с Google Таблицами. Не с уведомления, которое приятно увидеть на телефоне, и даже не с появления новой строчки. С того, как владелец откроет журнал обращений и поймёт, кому обещал перезвонить. Иначе получится аккуратная коллекция чужих просьб (иногда очень аккуратная).
Сразу договоримся о предметах. Выгрузка в Google Таблицы есть среди функций, которые можно заказать на моём сайте. Публичное демо показывает другой предмет — собственную веб-таблицу. По коду она получает записи из локальной базы SQLite, а не из Google Sheets. Видимая строка в этом примере не подтверждает подключение к вашему Google-аккаунту. У неё пока другой адрес.
В разделе «Сайт и таблица» предусмотрены форма и кнопка добавления обращения прямо из бота. В обработчике формы источником становится «Сайт»; у записи, созданной кнопкой, — «Бот». По коду данные сходятся в одном наборе строк, привязанном к посетителю демонстрации.
Ответ бота после нажатия короткий — «Строка добавлена в таблицу».
У кнопки есть небольшая условность. По коду она берёт имя из Telegram-профиля, а текст подставляет готовый — «Заявка из Telegram». В этой ветке человек не рассказывает боту о своей работе. Считать её сборщиком подробных анкет было бы ошибкой. Она нужна, чтобы рядом со строкой из формы появилась запись другого происхождения (вот и вся её биография).
В выдаче для веб-страницы находятся дата, имя, источник и текст. Записи идут в порядке добавления. Ни ответственного сотрудника, ни отметки о завершённом разговоре среди этих полей нет. Демо доводит обращение до журнала. О том, что произойдёт с ним дальше, придётся договариваться отдельно.
Возьмём условную мастерскую. Это пример, не история моего заказчика. Посетитель просит починить шкаф, оставляет сообщение на сайте, потом вспоминает про петлю и пишет в Telegram. В будущем журнале могут появиться отдельные обращения. Пометки источника помогут понять их происхождение, но сами по себе не объяснят, один ли это человек, продолжение ли это разговора и стоит ли готовить два выезда.
Шкаф при этом один.
Для такой мастерской я бы сначала набросал будущую строку. Имя, способ связи, что сломалось, кто ответит, когда связаться снова. Рядом — состояние обращения, например новое, принято в работу, завершено. Это предлагаемый состав заказа, а не описание возможностей нынешней демонстрационной таблицы. Если срок звонка прячется внутри длинного сообщения о перекошенной дверце, старой петле и времени, когда дома будет хозяин, сотруднику придётся перечитывать всю эту домашнюю историю всякий раз, когда он возвращается к заявке.
Не знаю, кто отвечает на обращения в вашем деле. Вы сами, мастер между выездами, администратор за стойкой? От этого зависит, нужна ли отдельная графа с именем ответственного. Когда отвечает один человек, она может оставаться лишней; когда заявку передают другому, имя в этой графе уже сообщает, у кого сейчас находится обещание позвонить. Мне хочется видеть там именно обещание, а не украшение отчёта.
У статуса тоже должна быть работа. В условной мастерской отметка о принятии означает, допустим, что мастер договорился о времени, а завершение — что ремонт закончен. Если один сотрудник считает завершением звонок, а другой — починенный шкаф, одинаковые слова в ячейках будут скрывать разные события. Я бы записал значение каждого состояния до настройки выгрузки, чтобы человек, пришедший на смену, не гадал, можно ли убрать обращение из очереди или хозяин по-прежнему ждёт мастера, которому всего лишь удалось дозвониться. Без торжественного документа.
Дальше возникает вопрос, куда писать изменения. Добавлять новые обращения в Google Sheets и возвращать изменённые в таблице статусы в Telegram — разные требования. Наличие в прайсе слова «выгрузка» ещё не обещает обратного пути. Для заказа стоит отдельно описать, должен ли бот узнавать об изменениях в ячейках, кто вправе их вносить и где сотрудник увидит результат. В разобранном демо такого обмена с Google нет.
В образце будущего журнала я бы оставил место и для номера обращения. В нашем примере мастер может попросить показать петлю, хозяин пришлёт ещё сообщение, а сотруднику нужно будет привязать уточнение к прежней работе. Как именно это сделать — отдельное решение для заказа. Одинаковое имя в соседних строчках само по себе не даёт права склеить их в одну заявку.
С пометкой «Сайт» похожая история. Она отличает обращение из формы от строки, созданной внутри Telegram. Но по этим двум словам я не стал бы судить об отдаче рекламы. Здесь нет сведений, какое объявление увидел человек и сколько стоило его обращение. Если нужны такие ответы, придётся согласовать дополнительные данные и способ их получения. Короткое поле не обязано знать всю дорогу посетителя.
У выгрузки есть своя строка в прайсе. На 9 ноября 2026 года там указаны 600 рублей по обычной цене и 300 рублей по предложению для первых 30 клиентов. Пример базового бота с таблицей показан за 1500 рублей с этой скидкой. Наличие места в льготной группе из одного прайса неизвестно. Ответственные, обратная передача статусов и поиск повторных обращений здесь обсуждаются как возможные требования; я не включаю их молча в цену строки «выгрузка».
Самому демо долгую службу поручать нельзя. По коду для таблицы установлен предел в 30 строк, а записи старше суток попадают под фоновую очистку. Это границы учебного примера. Для рабочего журнала срок хранения надо определить отдельно — вместе с тем, кому он нужен после завершения заявки. Вымышленные сведения для знакомства со сценарием подойдут; переносить туда очередь настоящих заказов я не советую.
Перед заказом можно прислать через форму на сайте образец желаемого журнала без чужих данных. Подробное техническое задание по условиям сайта не обязательно. Полезнее показать одну условную заявку и её продолжение — что появляется при обращении, что меняет сотрудник после разговора, что остаётся после выполнения работы. Для проверки готовой Google-интеграции я предлагаю смотреть уже в согласованную таблицу заказчика. Появилась ли запись там, сохранились ли нужные поля, можно ли продолжить работу. Публичная демонстрация такой приёмки не заменяет.
В нашем условном журнале у просьбы починить шкаф останется пометка «Сайт». Возле неё — имя того, кто договорился приехать. А у шкафа всё та же петля.