Заявки из Telegram в Google Таблицу: как устроен путь заявки от клиента до менеджера

Q: Сколько стоит связка «форма → Google Таблица → уведомление в Telegram»?

Базовая связка стоит от 15 000 ₽ и делается за один рабочий день. С записью в CRM — от 30 000 ₽ и 2–4 дня. С распределением заявок по менеджерам и контролем просрочки — от 60 000 ₽ и около недели.

Q: Почему заявки теряются, если технически всё работает?

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

Q: Что делать, если клиент отправил заявку дважды?

Нужна идемпотентность: у каждой отправки есть ключ — например, контакт плюс окно в 10–15 минут или идентификатор сессии. Повтор с тем же ключом не создаёт новую строку, а помечает существующую. Иначе менеджеры звонят одному человеку дважды, а статистика по конверсии завышена.

Q: Что должно быть в уведомлении о заявке?

Имя, контакт в кликабельном виде, суть обращения, источник и прямая ссылка на строку в таблице или карточку в CRM. Уведомление вида «новая заявка» без данных бесполезно: оно заставляет открывать три вкладки и поэтому откладывается.

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

Схема потока: шесть шагов

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

Шаг	Что происходит	Чем обычно делается
1. Источник	Клиент оставляет данные	Форма на сайте, бот в Telegram, виджет, лендинг
2. Приём	Данные принимает обработчик	Серверная функция, вебхук, Apps Script
3. Валидация	Проверка полей и антиспам	Проверка формата телефона, обязательных полей
4. Хранение	Заявка сохраняется	Google Таблица, база, CRM
5. Уведомление	Ответственный узнаёт о заявке	Telegram, почта, задача в CRM
6. Отработка	С клиентом связались	Звонок, сообщение, статус в таблице

Главное наблюдение. Внутри каждого блока всё обычно работает. Форма умеет собирать данные, Google Таблица умеет хранить строки, Telegram умеет доставлять сообщения. Ломается передача между блоками: приём отработал, а запись не дошла; запись прошла, а уведомление не ушло; уведомление пришло, а отработки не случилось. Поэтому проектировать надо стыки, а не блоки.

Почему заявки теряются

Пять сценариев, которые встречаются чаще всего. Все — реальные, все — лечатся технически.

1. Уведомление ушло в общий чат и утонуло

Заявки падают в рабочий чат, где параллельно идёт обсуждение поставок и обед. Через сорок сообщений заявку никто не найдёт.

Лечится так: отдельный канал или чат только под заявки, без единого постороннего сообщения. Плюс дублирование в личку ответственного. Если поток больше 20 заявок в день — добавляется отметка «взял в работу» кнопкой прямо в сообщении, чтобы необработанные было видно глазами.

2. Заявка записалась, но ответственный не назначен

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

Лечится так: назначение по правилу — по очереди, по источнику, по региону или по типу услуги. Имя ответственного попадает и в строку, и в текст уведомления. Заявка без ответственного не должна существовать вообще: если правило не сработало, назначается дежурный.

3. Клиент отправил дважды — создалось два лида

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

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

4. Форма упала, но клиент увидел «спасибо»

Самый дорогой случай. Интерфейс показал успех, потому что успехом считалась отправка запроса, а не подтверждение записи. Клиент уверен, что его услышали, и ждёт. В таблице ничего нет, и никто не узнает, сколько таких было.

Лечится так: «спасибо» показывается только после подтверждения от хранилища. Если запись не удалась — клиент видит внятную ошибку с альтернативным способом связи, а событие уходит в лог и в алерт.

5. Менеджер в отпуске, заявки копятся

Правило распределения продолжает назначать заявки на человека, которого нет. Неделю никто этого не замечает.

Лечится так: контроль просрочки. Заявка без смены статуса дольше N часов создаёт напоминание, а потом эскалацию на руководителя. Плюс флаг «недоступен» у ответственного, который выключает участие в распределении.

Таблица или CRM: честный критерий

Распространённый совет «сразу берите CRM» чаще вредит, чем помогает. CRM требует внедрения, дисциплины и денег ежемесячно, а на первых сотнях заявок не даёт ничего, чего не даёт таблица.

Google Таблицы достаточно, пока выполняются все условия сразу:

до 100–150 заявок в месяц;
с заявками работают 2–3 человека;
цикл сделки короткий: связались, договорились, закрыли;
история переписки не нужна рядом с заявкой;
отчётность ограничена вопросом «сколько заявок и откуда».

Признаки, что таблица исчерпана:

появились стадии и по каждой нужен свой набор действий;
нужны напоминания «перезвонить через три дня», а не память менеджера;
двое правят одну строку и затирают правки друг друга;
вопрос «что мы обещали этому клиенту в мае» требует поднимать чаты;
руководитель просит конверсию по источникам и по людям за период.

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

Обязательный минимум надёжности

Четыре вещи, которые стоят несколько часов работы и снимают большую часть потерь.

Сохранение сырых данных до обработки

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

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

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

Дублирование уведомления в два канала

Telegram и почта, или Telegram и второй чат. Мессенджер может быть недоступен, приложение — выключено, сотрудник — вне сети. Второй канал стоит полчаса работы и закрывает целый класс отказов.

Идемпотентность

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

Честная ошибка вместо ложного «спасибо»

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

Что писать в уведомлении, чтобы им пользовались

Уведомление «Новая заявка с сайта» бесполезно. Чтобы отреагировать, надо открыть таблицу, найти строку, понять контекст — три действия, каждое из которых откладывается.

Рабочее уведомление содержит:

Имя — чтобы обращение началось нормально;
Контакт кликабельно — телефон ссылкой на звонок, Telegram ссылкой на диалог;
Суть — что именно спрашивают, первые строки комментария;
Источник — страница, кампания, бот: без этого не посчитать, что работает;
Ссылку на строку в таблице или карточку в CRM;
Ответственного — поимённо, а не «команда».

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

Сколько времени это занимает

Что делаем	Срок	Цена
Форма или бот → Google Таблица → уведомление	1 день	от 15 000 ₽
То же + запись в CRM, маппинг полей, обработка отказов	2–4 дня	от 30 000 ₽
Распределение по менеджерам, статусы, контроль просрочки, эскалация	около недели	от 60 000 ₽

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

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

Вопросы, которые задают чаще всего

Сколько стоит связка «форма → Google Таблица → уведомление в Telegram»?

Базовая связка — от 15 000 ₽ и один рабочий день. С записью в CRM, маппингом полей и обработкой отказов — от 30 000 ₽ и 2–4 дня. С распределением заявок по менеджерам, статусами и контролем просрочки — от 60 000 ₽ и около недели.

Таблицы хватит или сразу нужна CRM?

Таблицы обычно хватает примерно до 100–150 заявок в месяц и до 2–3 человек, которые с ними работают, при коротком цикле сделки. Признаки, что пора переходить: нужна история переписки рядом с заявкой, нужны напоминания и стадии, несколько человек правят одну строку, руководитель просит конверсию по источникам за период. Переходить стоит по двум-трём признакам сразу, а не по первому.

Почему заявки теряются, если технически всё работает?

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

Что делать, если клиент отправил заявку дважды?

Нужна идемпотентность: у каждой отправки есть ключ — контакт плюс окно в 10–15 минут либо идентификатор сессии. Повтор с тем же ключом не создаёт новую строку, а помечает существующую. Без этого менеджеры звонят одному человеку дважды, а отчёт по количеству обращений завышен.

Что должно быть в уведомлении о заявке?

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

Что будет, если Google Таблица окажется недоступна?

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