Интеграция Авито CRM: сообщения, объявление и передача менеджеру

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

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

Какую задачу решает этот процесс

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

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

1. принять входящее событие и сохранить его идентификаторы;
2. связать сообщение с аккаунтом, объявлением и диалогом;
3. найти существующий контакт или создать обращение по согласованному правилу;
4. назначить ответственного;
5. остановить автоматические ответы, когда разговор принимает менеджер;
6. показать отказ подключения как ошибку, а не как успешную запись.

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

Какие данные и правила подготовить

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

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

Синтетические учебные данные: account_id=AV-100, ad_id=A17, dialog_id=D31, message_id=M42, occurred_at=2026-10-08T10:00:00Z, crm_contact_id=C205, assignee_id=U7. Это условные значения, не данные клиента и не результат выполненного теста.

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

Как выбрать доступный способ интеграции

Есть два основных варианта.

Готовый или официальный коннектор. Сначала проверьте, поддерживает ли он сообщения для вашего аккаунта, какие поля переносит, как обновляет авторизацию и показывает ошибки. Официальная страница RetailCRM описывает партнёрское предложение с Авито и работу RetailCRM с чатами, включая Авито. Это подтверждает наличие предложения поставщика, но не доказывает доступность нужных прав, Messenger API или функций для любого аккаунта и тарифа.

Собственная API-связка. Она уместна, если доступный API разрешает нужные операции, а готовый инструмент не покрывает правила маршрутизации, дедупликации или передачи человеку. До разработки нужно установить способ авторизации, состав событий, ограничения чтения истории, доступные идентификаторы, лимиты и правила площадки.

Выбор можно оформить как короткую проверку:

Не выбирайте решение только по наличию слова «Авито» в списке каналов. Нужна проверка именно тех операций, которые входят в ваш маршрут.

Как связать объявление, диалог и карточку CRM

Храните идентификаторы раздельно. Тогда сотрудник сможет понять происхождение обращения, а система — отличить повтор события от нового сообщения.

Для учебного события составной ключ равен:

dedupe_key = account_id + ':' + dialog_id + ':' + message_id = AV-100:D31:M42.

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

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

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

Подробнее об общих правилах обработки и распределения заявок — в материале об автоматизации обработки лидов.

Когда передавать разговор менеджеру

Автоматический ответ стоит остановить, когда решение требует человека или система не может подтвердить безопасный ответ. Минимальный список причин передачи:

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

Одной команды «передать» недостаточно. Нужны состояния разговора:

1. BOT_ACTIVE — автоматические ответы разрешены;
2. HANDOFF_PENDING — бот остановлен, менеджеру отправлен запрос на приём;
3. HUMAN_ACTIVE — оператор подтвердил приём, за разговором закреплён ответственный.

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

Учебный пример: путь от входных данных до результата

Ниже приведён синтетический пример. Все идентификаторы, имена сущностей, дата и результаты условны. Это не клиентский кейс, не файл Switch On AI и не свидетельство живого подключения к Авито или CRM.

В канал дважды приходит одно событие M42 по объявлению A17. Оба входа имеют ключ AV-100:D31:M42. Затем приходит новое сообщение H43: человек просит передать разговор сотруднику. На просьбе человека бот сразу останавливает автоматические ответы; оператор затем подтверждает приём. Отдельно рассматриваем запрос чтения диалога без требуемого права.

Промежуточное решение для двух доставок M42:

created = count(distinct dedupe_key) = count({AV-100:D31:M42}) = 1.

Итоговые величины:

• доставок события M42: 2;
• уникальных ключей M42: 1;
• дублей: 2 − 1 = 1;
• новых обращений по M42: 1;
• назначенных ответственных: 1 (U7);
• дополнительных обращений из-за повтора: 0;
• ответов бота после подтверждённой передачи: 0.

Доставка события, сообщение и запись CRM — разные сущности. Две доставки одного сообщения не должны превращаться в два сообщения клиента или два лида. Отказ API_DENIED также не равен пустому диалогу: это отдельный результат, который должен увидеть человек.

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

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

Перед запуском отдельно убедитесь, что:

• повтор M42 не создаёт второй лид;
• история относится к нужному объявлению;
• отказ API заметен и отличается от успешной обработки;
• токены, личные сообщения и клиентские данные не публикуются;
• повторная обработка не меняет ответственного без правила;
• лимит запросов и реакция на его достижение согласованы после проверки канала.

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

Что согласовать для внедрения

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

Для проекта нужно согласовать:

• одну операцию и её границы;
• поля Авито и CRM, доступные фактически;
• ключ дедупликации и правила поиска контакта;
• назначение ответственного;
• момент остановки бота и подтверждение оператора;
• обработку отказов, повторов и лимитов;
• безопасное хранение доступов;
• проверочные сценарии и владельца приёмки.

Switch On AI может разработать ИИ-помощника, бота или обычную интеграцию для этой операции после проверки данных и API. ИИ-помощник нужен, если требуется отвечать по утверждённым материалам и распознавать момент передачи. Бот выполняет заранее заданный диалоговый сценарий. Обычная интеграция переносит и связывает данные без самостоятельного ведения разговора.

Подходящая задача для ИИ-помощника продаж формулируется так: сообщение связывается с объявлением, клиентом и ответственным в CRM, а спорные ситуации получает менеджер. Совместимость, тариф, права и доступные поля проверяются отдельно; статья не подтверждает выполненное внедрение Авито у Switch On AI и не обещает эффект или срок.

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