Интеграция amoCRM с заявками: где теряется запись клиента

Интеграция amoCRM нужна, когда одна система получает обращение, а другая хранит время записи или результат услуги. Сам факт подключения ничего не говорит о качестве маршрута. Клиент может получить подтверждение, а менеджер продолжит звонить ему как новому. Или реклама получит зачёт за заявку, которая так и не дошла до визита. Проверьте один путь от сообщения до подтверждения, затем повторите его на переносе и отмене.

Для клиники это особенно заметно: человек пишет в сообщество, обсуждает услугу, выбирает время и позже меняет его. В кейсе «AI‑продавец для косметолога» маршрут показан прямо: ВК, amoCRM, помощник, YClients, подтверждение. За 27 дней система получила 1169 входящих сообщений; помощник ответил на 995. Речь идёт о сообщениях. Число пациентов или записей из него вывести нельзя. Оно показывает нагрузку на связку, которую нужно проверять по событиям.

Какую правду хранит каждая система

До настройки назовите главный источник каждого факта. В канале переписки хранится исходное сообщение. В amoCRM удобно вести ответственного и историю обращения. Система расписания должна подтверждать свободное время и текущий статус визита. Если две программы одновременно считаются хозяевами даты, при переносе неизбежно появятся две версии. Запишите правило в одном листе и согласуйте его с администраторами.

Отдельно договоритесь, какие данные клиники вообще нужны в карточке продаж. Администратору достаточно видеть контакт, услугу, время и договорённость. Медицинские сведения и назначения не следует переносить в общий список заявок. Для устройства работы с пациентом есть страница CRM для клиники; здесь рассматриваем саму передачу событий между программами.

Проверьте маршрут на пяти событиях

Сделайте тестовое обращение с меткой «проверка». Убедитесь, что в CRM создана одна карточка, известен источник и назначен сотрудник. Затем запишите тестового клиента на свободное время: карточка должна получить подтверждённый статус и тот же идентификатор записи. Попросите перенести время, отменить запись, а потом создать новую. На каждом шаге смотрите обе системы и сообщение, которое получил клиент.

Проверяйте событие с задержкой, если обмен идёт не мгновенно. Важен согласованный предел ожидания и понятное предупреждение человеку, когда передача не удалась. Тихая ошибка опаснее видимой: администратор уверен, что запись появилась, а в расписании её нет. При сбое задачу должен получить человек, который умеет уточнить время вручную.

Как это выглядит в работе

Схема в кейсе показывает пять точек пути. Следующий экран показывает ответ помощника на возражение по цене и предложение записи. На нём виден разговор. Подтверждение визита нужно отдельно сверять в расписании.

Какие вопросы задать подрядчику до оплаты

Проведите тестовые события по порядку:

• Создайте тестовую заявку из рабочего канала.
• Запишите клиента и проверьте обе карточки.
• Перенесите время и найдите старое напоминание.
• Отмените визит и проверьте, кто увидел изменение.

Попросите показать пять тестов из таблицы выше на работающей связке. Спросите, что будет при повторной доставке одного сообщения. Будет ли новая сделка или прежняя карточка обновится? Кто увидит ошибку, если система записи временно недоступна? Как журналируется момент передачи, чтобы потом разобрать жалобу клиента? Подрядчик должен назвать источник статуса и способ ручной сверки.

Попросите также показать, что происходит при исправлении ошибочного телефона. Сообщение могло прийти в карточку человека с похожим номером, а запись создали на другое имя. До исправления нужно понять, в какой системе ошибка возникла впервые. Затем исправляют исходную запись и прослеживают обновление дальше по цепочке. Иначе на одном экране появится верный номер, а напоминание уйдёт по старому. Этот сценарий полезно повторить на тестовых контактах до включения реальных пациентов.

Перенос старых контактов, дубли и спорные совпадения разобраны в статье о базе клиентов. Здесь достаточно проверить, что повторное сообщение после интеграции попадает в правильную историю и не создаёт лишний визит.

После исправления контакта проследите один тестовый путь:

• Сверьте номер в исходном сообщении.
• Откройте контакт в amoCRM и в расписании.
• Проверьте адресата следующего напоминания.

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

Как читать отчёт после подключения

Не делайте вывод по числу созданных карточек. Сравните обращения, записи, подтверждения и визиты в одинаковом периоде. Для перенесённого визита сохраните историю двух дат, чтобы не посчитать один запрос дважды. В проекте «Операционная система сети» реклама в AmoCRM отчитывалась заявками, а салон смотрел выручку. Отчёт должен показывать оба этапа и даты их наступления, иначе расхождение останется незаметным. Где именно возникал разрыв между записью и визитом, разобрано в статье об узких местах.

В другом проекте сверка отчётов менеджеров с фактическими данными нашла 587 расхождений на 703 496 ₽. Речь о расхождениях в отчётах. Их нельзя называть потерянной выручкой или эффектом именно amoCRM. Пример показывает, почему после подключения нужно сверять исходные события с итогом, а не доверять красивой сводке без выборочной проверки.

Проверяйте отчёт от результата к источнику:

• Найдите фактический визит в расписании.
• Откройте связанную запись и историю переноса.
• Сверьте обращение с исходным сообщением.

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

Частые вопросы

Можно ли считать запись по стадии сделки в amoCRM?

Только если стадия обновляется после подтверждения расписанием. Ручной перевод карточки в «записан» сам по себе не резервирует время.

Что делать с повторным сообщением клиента?

Привязывайте его к существующей истории после сверки личности. Проверяйте, что повторная доставка сообщения не создаёт второй визит.

Нужна ли двусторонняя передача данных?

Нужны конкретные события в обе стороны: например, запись из расписания в CRM и отмена обратно в карточку. Полную копию всех полей передавать обычно нет смысла.

Кто отвечает за ошибку синхронизации?

Назначьте сотрудника для ручной сверки и канал уведомления. Ошибка должна иметь время, карточку и событие, которое не удалось передать.

Как проверить результат без доступа к настройкам?

Проведите тестовый путь и сравните исходное сообщение, карточку, расписание и подтверждение клиенту. Попросите подрядчика показать журнал по тестовому событию.

Если сегодня данные разъезжаются между CRM и расписанием, разберите один реальный путь заявки. Начните с последнего случая, где клиенту пришлось повторять уже сообщённые сведения.