Автоматизация заявок: от чата до учёта

У предпринимателя и самозанятого заявки редко «не приходят» — они приходят в пять мест сразу: личный Telegram, WhatsApp, Instagram, форма на сайте, звонок «на потом». Менеджер отвечает там, где успел; в таблицу переносят раз в день; ночные сообщения висят до утра. Потом заказчик просит «автоматизацию обработки заявок», а на столе нет даже списка каналов.

Типичная картина: владелец видит уведомление в личном чате, отвечает клиенту, но не создаёт запись в учёте. Через неделю тот же человек пишет снова — и кажется, что «мы его потеряли», хотя переписка была. Или администратор копирует заявку в таблицу вечером и забывает указать услугу — менеджер на следующий день звонит вслепую. Это не проблема «плохого CRM»; это отсутствие согласованной цепочки.

Я на разборе процесса начинаю с карты потерь: где сообщение было прочитано, но не стало записью; кто должен был ответить и не ответил; что считается «заявка принята». Без этого любая система автоматизации заявок — красивая обёртка над хаосом. На разборе мы фиксируем не только каналы, но и исключения: звонок вместо сообщения, повторный клиент, отказ после цены, перенос на другой день.

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

Рабочий минимум для автоматизации заявок клиентов — не «ИИ-агент», а четыре звена:

1. 01

   Канал — один основной вход (часто Telegram-бот или форма с webhook).

2. 02

   Квалификация — три–пять полей: имя, услуга, срок, бюджет или комментарий.

3. 03

   Учёт — строка в Google Sheets, Airtable, amoCRM или Bitrix24.

4. 04

   Человек — ответственный получает уведомление и забирает исключения.

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

Важно разделить приём и продажу. На этапе приёма задача — не закрыть сделку, а не потерять контакт и дать ответственному достаточно контекста. Скидки, сложные расчёты, спорные кейсы остаются за человеком. Автоматизация здесь — про дисциплину записи, а не про замену менеджера.

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

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

Запрос «система автоматизации заявок» часто тянет за собой ожидание, что бот сам поймёт любой текст. На практике для пилота хватает детерминированной логики:

• Кнопки «Запись / Вопрос / Жалоба» в первом сообщении.
• Обязательные поля: имя + телефон или @username.
• Таймаут: если клиент молчит 10 минут — черновик карточки и напоминание оператору.
• Явный выход «Позвать человека» без прохождения всей ветки.
• Короткое подтверждение клиенту: «Заявку приняли, ответим в течение …».

Я разделяю автоматизацию приёма заявок (сбор полей, запись, уведомление) и автоматизацию ответа (шаблоны, FAQ, позже — аккуратный ИИ с ревью). Второе подключают после того, как первое не теряет сообщения две недели подряд.

На разборе я прошу принести 10–15 реальных сообщений клиентов за последний месяц. По ним видно, сколько сценариев повторяется. Если 80% — «хочу записаться / узнать цену / перенести», хватит кнопок и трёх полей. Если каждый второй текст уникален — не усложняем бота, а сокращаем путь к человеку.

Правило для пилота: каждое новое поле должно отвечать на вопрос «зачем менеджеру это до первого контакта». Если ответа нет — поле убираем или переносим на этап после звонка.

Вопрос «таблица или CRM» решается не брендом инструмента, а тем, сколько людей касаются заявки и нужна ли история по этапам. Ниже — практические критерии без привязки к «успешным кейсам» с выдуманными цифрами.

Оставайтесь на таблице (Google Sheets, Airtable), если:

• Один ответственный или владелец сам ведёт заявки от начала до конца.
• До 30–50 заявок в месяц, и вы реально их просматриваете.
• Достаточно трёх статусов: новая, в работе, закрыта (иногда «отказ»).
• Не нужны напоминания по этапам сделки — хватает уведомления о новой строке.
• Команда уже смотрит в таблицу каждый день; дело не в инструменте, а в дисциплине.

Пора подключать CRM (amoCRM, Bitrix24 и аналоги), если:

• Два и больше менеджеров, и важно, кто владелец карточки.
• Заявка проходит несколько этапов: квалификация → КП → оплата → выполнение.
• Нужны напоминания «перезвонить завтра», «ждём документы», «сделка зависла».
• Руководитель смотрит воронку, а не только список новых строк.
• Переписка и звонки должны жить рядом с карточкой, а не в личных чатах.

Гибрид на время пилота — нормальная схема: автоматизация пишет в тестовый лист, команда привыкает к полям и SLA, потом меняется только узел «учёт» на CRM без переделки канала и квалификации. Так снижается страх «сломать» рабочую CRM до того, как сценарий проверен.

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

Не смешивайте учебный шум Wordstat («какой системе направляются заявки на автоматизацию») с вашей задачей — вам нужен ваш канал и ваш ответственный, не абстрактная «система».

Антипаттерны, которые я вижу чаще всего — когда хочется «сразу всё», а процесс ещё не описан.

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

2. Мультиканал без одного входа. Подключить Telegram, Instagram, сайт и WhatsApp одновременно — значит отладить четыре сценария и четыре типа сбоев. На пилоте — один канал, остальные ведут сюда автоответом или ссылкой.

3. CRM «на вырост» до согласования полей. Десять кастомных полей, воронка из семи этапов, отчёты для директора — а заявок 15 в месяц и один менеджер. Упростите до того, что реально заполняется.

4. Автоответы с ценами и обещаниями без ревью. Шаблон «стоимость от …» без контекста услуги создаёт конфликт ожиданий. На пилоте — нейтральное «приняли, уточним детали», цену даёт человек.

5. Интеграция оплаты до учёта заявки. Клиент оплатил, а карточки в учёте нет — спор «мы не видели заказ». Сначала заявка в системе, потом ссылка на оплату.

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

7. Полная автоматизация жалоб и конфликтов. Жалоба — всегда человек с полномочиями извиниться или исправить. Бот может принять текст и создать срочную карточку, но не «отбивать» клиента шаблоном.

Если узнаёте себя в двух и более строках — на разборе сначала сужаем контур, потом обсуждаем разработку.

Автоматизация заявок на оплату или на услугу ломается не в интеграции, а в дисциплине ответа. Фиксирую простой SLA для пилота:

• Уведомление ответственному — не позже 2 минут после записи заявки.
• Первый ответ клиенту — в рабочие часы, согласованный срок (например, 30 минут).
• Эскалация: если статус «новая» висит 2 часа — второе уведомление или смена ответственного.
• В нерабочее время — автоответ с ожидаемым временем ответа, заявка всё равно в учёте.

Канал уведомления — тот, где человек реально сидит. Для многих клиентов это Telegram, не email. Текст уведомления содержит: откуда заявка, имя, услуга, ссылку на строку CRM или таблицу. Без ссылки менеджер снова ищет заявку вручную — и автоматизация теряет смысл.

Хороший тест перед запуском: отправить тестовую заявку в 22:00 в пятницу. Должны сработать автоответ клиенту, запись в учёт и уведомление (или отложенное правило, если так договорились). Если что-то из этого не происходит — не включать рекламу на бота.

Чеклист перед включением автоматизации обработки заявок:

• Именованный ответственный на каждый день недели
• Резервный, если основной недоступен
• Тестовая заявка проходит до строки учёта
• Тестовое уведомление доходит
• Понятно, кто правит ошибочную карточку
• Зафиксировано, что писать клиенту при задержке ответа

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

• 15–25 заявок за две недели через основной канал.
• 100% попадают в учёт с меткой времени.
• Уведомление уходит в SLA (≤ 2 мин).
• Не более 1 ручного доработания полей на 5 заявок.
• Ноль «потерянных» сообщений по журналу канала.

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

Если критерий не выполнен — не масштабируем бота на новые каналы и не добавляем ИИ. Упрощаем сценарий или возвращаемся к разбору. Если выполнен — обсуждаем пилот разработки: CRM, второй канал, шаблоны ответов.

Срок 1–2 недели выбран специально: за это видно, держит ли процесс реальный поток и не сыпется ли на исключениях («клиент позвонил вместо бота», «оплатил без заявки»). Ведите простой журнал исключений: что случилось, как решили, нужно ли менять сценарий. Пять–десяь таких записей часто важнее, чем очередная интеграция.

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

По теме в блоге:

• Внедрение ИИ в бизнес — куда ИИ уместен после стабильного контура заявок.
• Чат-бот для бизнеса — если канал приёма — бот с одним сценарием.
• Интеграция Telegram и CRM — когда таблицы мало и нужна карточка лида.
• ИИ-агенты для бизнеса — после стабильного учёта, если нужен шаг с моделью.
• Разработка проектов — если сценарий нужно собрать и встроить в текущую работу.

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

Автор: Пашкуров Пётр Сергеевич. Справка по API: Telegram Bot API.