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