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