Интеграция Авито с CRM: заявки, чаты, звонки и контроль менеджеров

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

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

Как должна выглядеть архитектура

Устойчивая схема состоит из четырёх слоёв: источник событий, интеграционный слой, CRM и контур мониторинга. Интеграционный слой принимает событие, проверяет его, ищет клиента, применяет правила и только после этого создаёт или обновляет сущность CRM.

Какие данные передавать в CRM

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

Три способа интеграции

Пример маршрута обращения с Авито

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

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

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

Как оценить объём и стоимость интеграции

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

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

Отказоустойчивость и сопровождение

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

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

Этапы внедрения

1. ИнвентаризацияФиксируем профили, категории, типы объявлений, каналы и объём обращений.
2. ПроектированиеОпределяем сущности CRM, ключи дублей, воронки, SLA, очереди и случаи повторного обращения.
3. ПилотПодключаем один профиль или группу объявлений, проверяем чаты, задачи, дубли и возврат ответов.
4. ПриёмкаСверяем выборку событий с кабинетом, измеряем доставку, время ответа и долю ошибок.
5. МасштабированиеПодключаем остальные профили, обучаем команду, документируем схему и создаём регламент сбоев.

Как избежать дублей и потерянных лидов

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