Заявка отправлена с сайта, уведомление появилось в Telegram. Но кто должен ответить клиенту? Где хранится история обращения? Как понять, что заявка действительно принята в работу?
Автоматизацию стоит начинать с этих вопросов, а не с выбора бота. Ниже — возможный сценарий процесса, а не описание уже выполненного внедрения INTOR TECH.
Сайт: подтвердить приём обращения
Форма должна не просто реагировать на нажатие кнопки. Нужно проверить, что данные дошли до системы, которая принимает обращение, и предусмотреть понятное сообщение при ошибке.
Клик по кнопке или открытие почтового приложения не подтверждают отправку заявки. Поэтому при проверке маршрута важно проследить тестовое обращение до места его регистрации.
CRM: сохранить заявку
В предлагаемом сценарии CRM становится основным местом учёта обращения. До настройки нужно согласовать обязательные поля, источник заявки, статусы и правила обработки повторных обращений.
Для первого этапа достаточно одного маршрута. Например, одна форма создаёт карточку с контактами и описанием задачи. Состав данных определяют под процесс и требования к их обработке.
Telegram: уведомить, а не заменить учёт
Сообщение в чате помогает заметить новое обращение. Но само по себе оно не отвечает на вопросы: назначен ли исполнитель, связался ли он с клиентом, что делать дальше?
Поэтому уведомление можно связать с карточкой в CRM. Какие данные допустимо передавать в Telegram и кому доступно сообщение, нужно определить заранее. Необязательно дублировать в чат всё содержимое заявки.
Порядок событий тоже важен: уведомление о новой карточке логично отправлять после подтверждения её создания, чтобы сообщение не создавало ложного ощущения успешной регистрации.
Ответственный: закрепить следующий шаг
До запуска нужно определить правило назначения: кто получает заявку, кто подхватывает её при отсутствии сотрудника и как обнаружить обращение без ответственного.
У заявки должны быть понятный статус и следующий шаг. У исключений — свой порядок обработки: что делать, если CRM недоступна, данные неполные или обращение пришло повторно.
Как проверить первый этап
Для пилота можно ограничиться одной формой, одной CRM и одной группой ответственных. До оценки нужны владелец процесса, доступные API или выгрузки, права доступа, требования к размещению и безопасности.
Проверять полезно весь маршрут: фактическое получение обращения, полноту карточки, корректность уведомления и назначение ответственного. Время регистрации и долю исправлений можно измерять, но обещать улучшения до замеров нельзя.
Цель первого разговора — определить задачу, ограничения и границы первого этапа. Возможность конкретной интеграции подтверждается после обследования.
Напишите «ПРОЦЕСС» — разберём одну повторяющуюся операцию.