Практический материал / ИИ и автоматизация
Заявки из формы и бота в CRM: как избежать потерь и дублей
Как отличать повторную доставку от нового обращения, проверять получение заявки и сохранять рабочий порядок при сбое CRM.
Клиент отправил форму, увидел сообщение об успехе и закрыл страницу. Менеджер открыл CRM, но обращения там нет. Другой клиент нажал кнопку повторно, и в работе появились две одинаковые карточки. Такие условные ситуации полезно разбирать до запуска: успешный экран ещё не показывает, что происходит с заявкой дальше.
Здесь разберём приёмку конкретного процесса для компании в Казахстане: заявки поступают с сайта и из бота, а сотрудники работают в CRM. Если сам процесс ещё не выбран, начните с материала о первой автоматизации. Следующий шаг — договориться, как доказывать сохранность каждого обращения.
Назначьте источник истины для каждого состояния
Определите, где сотрудник проверяет факт приёма, результат передачи и текущую работу с клиентом. Это могут быть разные места: журнал принятых обращений подтверждает получение, а карточка CRM хранит назначенного менеджера и статус обработки. Важно связать записи, чтобы по одной заявке можно было восстановить весь путь.
Запишите значения состояний простыми словами: «сохранена», «ожидает передачи», «создана в CRM», «требует проверки». Уведомление в чате команды не должно быть единственным свидетельством получения. Если сообщение удалено или сотрудник его пропустил, исходная заявка должна оставаться доступной в согласованном месте.
Разделите повтор доставки и новое обращение
Каждому принятому обращению нужен устойчивый идентификатор. Повторная попытка доставить ту же заявку должна сохранять этот идентификатор, чтобы система могла обнаружить уже выполненное действие. Попросите показать его и в исходной записи, и рядом с результатом передачи. Это понятнее, чем искать совпадения по времени и имени.
Одинаковый телефон сам по себе не означает дубль: клиент может заказать другой товар или обратиться по новому объекту. Отдельно согласуйте повторное нажатие кнопки, технический повтор доставки и самостоятельную новую заявку. Если человек написал сначала через форму, затем в бот, спорное совпадение лучше направить на проверку, сохранив оба обращения.
Сохраните смысл запроса при переносе
Проверьте карточку глазами менеджера. В ней должны быть согласованные сведения: источник, контакт, выбранный товар или услуга, текст запроса и необходимые уточнения. Если человек выбирал вариант в каталоге, полезно сохранить его название или ссылку, чтобы сотруднику не пришлось восстанавливать выбор по переписке.
Для русских и казахских сообщений проверьте сохранность букв, переносов и исходного смысла. Если автоматизация делает краткое резюме, оставьте путь к исходному тексту. Не заменяйте неизвестное значение догадкой: отсутствие количества или удобного времени связи должно быть заметно как вопрос для уточнения.
Подтверждайте только достигнутый результат
Текст для клиента должен соответствовать состоянию заявки. Если обращение надёжно сохранено и ожидает передачи, можно подтвердить его приём. Нельзя называть его назначенным менеджеру, пока назначение не подтверждено. Не обещайте время ответа, которое команда не согласовала и не может контролировать.
Проверьте и неуспешную отправку: понятное сообщение должно объяснять доступное действие. Например, повторить попытку или связаться другим указанным способом. Само подтверждение на экране не должно появляться раньше сохранения заявки. Если предусмотрен номер обращения, убедитесь, что сотрудник действительно может найти по нему запись.
Разберите недоступность и неопределённый ответ
При недоступности CRM заявке нужен видимый статус ожидания и согласованный порядок дальнейших попыток. Отдельный случай — запрос ушёл, но ответ не вернулся. Карточка могла уже появиться. До повторного создания нужно проверить результат по идентификатору; если проверить нельзя, обращение требует ручного разбора, а не молчаливого решения.
Договоритесь, когда ожидание становится проблемой и кто получает уведомление. После восстановления проверьте весь накопившийся список: какие обращения дошли, какие остаются в очереди, какие разобраны вручную. Порядок восстановления важнее одного сообщения «сервис снова работает».
Назначьте владельца исключений и ручной резерв
У необработанной заявки должен быть ответственный, включая отсутствие основного сотрудника. Укажите, где он видит очередь, как связывается с клиентом и как фиксирует ручное действие. После ручного создания карточки сохраните связь с исходным идентификатором, чтобы восстановившаяся автоматизация не создала ещё одну запись.
Резервный порядок должен быть выполнимым для команды. Доступ к принятым обращениям, отметка о выполненном действии и понятная передача смены полезнее инструкции «при сбое сообщить разработчику». Проверяйте этот путь с сотрудником, который действительно будет им пользоваться.
Примите процесс по проверяемому шаблону
Для каждого сценария запишите: исходные данные, идентификатор, ожидаемое состояние, фактическую карточку, ответственного и подтверждение проверки. Используйте вымышленные контакты, согласованные для тестирования. Включите в протокол:
- Обычную отправку из формы и бота: содержание сохранилось, карточка доступна сотруднику.
- Повтор доставки: одна заявка не создала вторую рабочую карточку.
- Новое обращение того же клиента: самостоятельная задача не исчезла как дубль.
- Недоступность и потерю ответа: заявка видна, дальнейшее действие определено.
- Ручное восстановление: результат связан с исходной записью, повторная обработка исключена.
В конце сверяйте уникальные принятые обращения с переданными, ожидающими и требующими разбора. Необъяснимых пропусков оставаться не должно. Обсудить такую проверку можно в разделе ИИ и автоматизации GIFS: пришлите текущую цепочку обработки и примеры исключений без реальных персональных данных.
Каждый проект начинается с конкретной задачи. Объём работ, сроки и критерии результата согласуем перед запуском.