Интеграция Авито и amoCRM: как проверить передачу без дублей

Первое сообщение с Авито появилось в amoCRM. Теперь покупатель задаёт второй вопрос — и менеджер должен увидеть его в том же разговоре, ответить и понять, что делать дальше. Этот путь стоит пройти вместе с подрядчиком перед запуском.

Ниже разберём его на учебных данных: проследим связь разговора с карточками, отличим повтор события от нового вопроса и посмотрим, что должно остаться у сотрудника после сбоя. Такой разбор поможет обсудить конкретные расхождения, а не спорить о том, «работает интеграция» или нет.

Что проверять в интеграции Авито и amoCRM?

В интеграции Авито и amoCRM проверяйте весь путь сообщения: правильный контакт и сделку, полную переписку, ответ обратно покупателю, ответственного сотрудника и следующее действие. Отдельно испытайте повтор события и восстановление после сбоя. Появление текста в карточке подтверждает только часть этого пути.

amoCRM — система учёта клиентов и работы с обращениями. Авито остаётся площадкой, где покупатель начинает разговор. Между ними работает выбранное подключение: оно должно связать собеседника, переписку и рабочую карточку, сохранив понятный источник.

В этой статье я разбираю приёмку уже выбранного подключения глазами заказчика. Конкретный тариф, права аккаунтов и возможности поставщика нужно выяснить до испытания. Здесь нет подключения клиентского кабинета: все обозначения и диалоги ниже учебные.

Такой разбор нужен, когда подрядчик говорит «сообщения идут», а руководитель хочет понять, что именно получит менеджер. Проверка проходит с обеих сторон: покупатель видит свой разговор на Авито, сотрудник продолжает тот же разговор в CRM. На демонстрации должны быть видны оба результата: так понятен путь, который предстоит повторять менеджеру.

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

Одна беседа, контакт и сделка: почему это разные вещи

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

В документации amoCRM по беседам отдельно описаны идентификаторы контакта, чата и связанной сущности — например сделки. Идентификатор, или ID, — обозначение, по которому система различает записи. Одного совпавшего имени для проверки связи мало.

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

Но правило «у одного покупателя всегда одна сделка» тоже не подходит всем. Через некоторое время он может заказать другой товар для другого получателя. До испытания договоритесь, как команда различает продолжение беседы и новую заявку. Это решение бизнеса; его нельзя вывести только из одинакового имени.

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

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

Таблица передачи: что должно дойти до менеджера

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

Ниже учебная таблица. Обозначения A-CHAT-17 и CRM-LEAD-41 придуманы для объяснения; это не настоящие номера Авито или поля, которые любой поставщик обязательно отдаёт.

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

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

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

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

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

В пошаговом руководстве API чатов amoCRM указано: несколько сообщений с одинаковым payload[msgid] не принимаются, а неизвестный payload[conversation_id] создаёт новый чат. Это правило программного интерфейса amoCRM. То, как конкретное подключение сохраняет соответствие с Авито, нужно испытать отдельно.

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

В учебном примере событие E-101 содержит вопрос «Есть доставка?». Подключение получило его повторно после задержки. Ожидаемый результат: в истории осталось одно сообщение E-101, прежняя связь с карточкой сохранилась. Это проверка обработки повторной доставки.

Теперь покупатель сам ещё раз пишет «Есть доставка?». У этого сообщения другой идентификатор, E-102. Его нужно показать менеджеру: повтор слов может означать, что человек не получил ответа. Удалять такое сообщение только за одинаковый текст было бы ошибкой.

Для владельца разница видна в итоговой таблице:

Не стоит принимать объяснение «дубли иногда бывают» без конкретного сценария. Сначала выясните, что дублируется: сообщение, контакт или сделка. Затем проверьте одно принятое правило. Исправление одного объекта не доказывает, что остальные тоже сопоставляются верно.

Сбой и восстановление: где искать потерянный разговор

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

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

Затем проверьте продолжение работы. Допустим, в учебном сценарии после E-101 появилось E-102, но оно не дошло до CRM. После восстановления сотрудник должен увидеть недостающий вопрос в правильном разговоре. Уже принятое E-101 не должно размножиться при повторной обработке.

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

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

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

Что происходит после передачи человеку

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

Документация amoCRM отдельно связывает доступ к беседам с правами на контакт. Поэтому демонстрация только под администратором не отвечает на вопрос о рабочем месте сотрудника. Если менеджер не видит нужный разговор, сначала разберите доступ и назначение вместе с ответственным за систему.

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

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

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

Я завершаю этот маршрут обратным действием: сотрудник отвечает из своего рабочего места, а тестовый покупатель читает ответ на Авито. Сохранение исходящего текста в CRM и его фактическое получение — разные наблюдения. Если выбранный поставщик поддерживает не все действия, это должно попасть в условия приёмки.

Учебный протокол приёмки и разбор результата

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

Объект проверки: связка Авито → выбранное подключение → amoCRM.
Аккаунты и доступ: разрешённые тестовые учётные записи.
Версия подключения и дата: заполнить перед испытанием.
Правило продолжения разговора: записать согласованный вариант.

Сценарий А. Первое сообщение.
Действие: тестовый покупатель пишет вопрос о товаре.
Ожидаем: сообщение в правильной карточке, источник понятен.
Факт: заполнить после наблюдения с обеих сторон.

Сценарий Б. Продолжение и ответ.
Действие: покупатель уточняет условие, менеджер отвечает.
Ожидаем: история сохраняется, ответ получен на Авито.
Факт: заполнить после наблюдения.

Сценарий В. Повтор события и такое же новое сообщение.
Действие: поставщик показывает повтор доставки; затем покупатель пишет заново.
Ожидаем: повтор события не создаёт дубль, новое сообщение не теряется.
Факт: указать идентификаторы и место каждого сообщения.

Сценарий Г. Временный сбой и продолжение.
Действие: поставщик проводит безопасный согласованный тест.
Ожидаем: проблема видна, пропуск обработан по принятому правилу.
Факт: указать статус, ответственного и итог сверки.

Решение: принято / нужны исправления / сценарий не поддерживается.
Незакрытый вопрос: конкретное расхождение и способ повторной проверки.

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

Разберём учебный результат. В первом сценарии всё дошло в CRM-LEAD-41. Во втором уточнение оказалось в CRM-LEAD-42, хотя по принятому правилу это продолжение той же покупки. Такую связку нельзя принять как сохраняющую разговор: проверка нашла неверное сопоставление.

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

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

Частые вопросы об интеграции

Если сообщение видно в amoCRM, интеграция уже работает?

Входящая передача сработала для этого сообщения. Ещё нужно проверить правильную карточку, продолжение разговора, ответ обратно, работу сотрудника и восстановление при проблеме.

Почему одинаковое имя не подходит для поиска дублей?

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

Должен ли каждый новый вопрос создавать сделку?

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

Можно ли проверить всё без программиста?

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

Достаточно ли стандартного API чатов amoCRM для связи с Авито?

Документация описывает сторону amoCRM. Доступность конкретного подключения к Авито, поддерживаемые действия, права и условия нужно подтвердить у поставщика. Наличие программного интерфейса само по себе не создаёт готовой двусторонней связки.

Что делать, если менеджер отвечает одновременно с ИИ?

Сначала согласуйте, кто ведёт разговор после передачи и как меняется режим помощника. Затем воспроизведите передачу в тесте и проверьте ответы с точки зрения покупателя. Исправление считается подтверждённым после повторного испытания.

С чего начать прямо сейчас

1. За 10–15 минут выпишите путь одного обращения: вопрос на Авито, карточка, ответственный и следующий шаг. Для этого не нужны покупка сервиса или доступ к чужому кабинету.
2. Выберите цель. Если подключение ещё выбираете, передайте поставщику таблицу требований. Если уже принимаете работу, сопоставьте её с обещанным составом услуги.
3. Уточните правило: что продолжает прежнюю беседу, а что создаёт новую заявку. Без него нельзя правильно оценить дубли.
4. Согласуйте безопасные тестовые данные и роли участников. Подготовьте доступ к обеим сторонам разговора.
5. Пройдите сценарии, записывая фактический результат. Незавершённые пункты оставьте открытыми с ответственным и следующим действием.
6. После исправления повторите найденный переход и соседние случаи. Сохраните итоговую версию протокола вместе с условиями сопровождения.

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

Что сохранить после приёмки

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

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

О подходе Никиты и действующих направлениях можно прочитать на странице эксперта, а состав работы с входящими обращениями — на странице ИИ-продавца на Авито.