Передача лидов подрядчиком: API, CRM или таблица

Способ передачи заявок определяет, за сколько секунд лид доедет до менеджера, а это напрямую влияет на дозваниваемость: контакт в первые 5 минут удаётся примерно вдвое чаще, чем через 4-6 часов. Схем всего 3 - прямая интеграция по API или вебхуку (доставка за секунды, настройка 1-3 дня), готовая интеграция с CRM (минуты, 1-5 дней) и выгрузка в таблицу (часы, настройка за 1 час).

I. Почему способ передачи влияет на деньги

Заявка - товар с очень коротким сроком годности. Человек оставил запрос, потому что решает вопрос прямо сейчас, и через несколько часов он уже разговаривает с конкурентом. Поэтому разница между доставкой за 10 секунд и за 3 часа - это разница в конверсии, а не в удобстве.

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

II. 3 схемы передачи

• API и вебхук. Подрядчик отправляет данные напрямую в вашу систему в момент создания заявки. Плюс - скорость и полный контроль состава полей. Минус - нужен разработчик или готовый коннектор.
• Готовая интеграция с CRM. Настраивается через штатные модули популярных систем. Плюс - быстро и без программиста. Минус - состав полей ограничен возможностями коннектора.
• Таблица или почта. Заявки попадают в общий документ или приходят письмом. Плюс - запускается за час на старте теста. Минус - задержки, ручные ошибки, потери строк.
• Мессенджер как дублирование. Не самостоятельная схема, но полезное дополнение: уведомление менеджеру приходит сразу, даже если он не в CRM.
• Двойная доставка. Оптимальный вариант на практике - основная схема плюс резервная выгрузка, чтобы сверять объёмы.

III. Состав полей заявки

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

Отсутствие поля с id и временем создания - самая частая причина неразрешимых споров. Без них нельзя ни сверить объёмы, ни доказать, что заявка обрабатывалась с задержкой. Как это связано с оплатой, подробно разобрано в материале про валидную заявку.

IV. Где теряются заявки

1. Сбой интеграции без уведомления. Вебхук перестал доходить, а узнают об этом через 3-5 дней по падению потока.
2. Дубликаты. Повторная отправка при ошибке создаёт две карточки, и одна и та же заявка попадает в акт дважды.
3. Фильтры почты. Письма с заявками уходят в спам, особенно при однотипных темах и вложениях.
4. Ручное копирование. Перенос строк из таблицы в CRM даёт ошибки в номерах в 1-3% случаев.
5. Разные часовые пояса. Время создания и время получения расходятся, и спор о скорости обработки становится бессмысленным.

V. Как выбрать схему под объём

Разброс в этой таблице объясняется не столько объёмом, сколько ценой одной заявки и длиной цикла сделки. При лиде за 500 ₽ и коротком цикле потеря пяти обращений в месяц стоит 2500 ₽, и таблица терпима дольше. При лиде за 4000 ₽ и среднем чеке 200 000 ₽ те же пять потерянных строк - это 20 000 ₽ прямых расходов и одна несостоявшаяся сделка, поэтому интеграцию имеет смысл настраивать уже на 20-30 заявках. Второй фактор - число людей в цепочке: если заявку до менеджера доносит администратор вручную, каждая передача добавляет и задержку, и вероятность ошибки.

Отдельно про тестовый период. На первые 1-2 недели допустимо начать с таблицы, чтобы проверить сам канал и качество запросов, а интеграцию настроить после решения о продолжении. Главное - не задержаться в этом режиме на несколько месяцев.

Порядок перехода на автоматику стоит спланировать заранее, иначе он растягивается. Рабочая последовательность: согласовать состав полей и формат телефона, поднять тестовую отправку на 5-10 заявок, сверить их с таблицей по id, включить боевой поток и оставить резервную выгрузку минимум на месяц. На каждом шаге фиксируйте, кто отвечает за проверку: чаще всего интеграция ломается не в момент запуска, а через 2-3 недели, когда одна из сторон меняет структуру полей и никого об этом не предупреждает.

VI. Когда это нужно вам

Разбираться в схемах передачи стоит перед стартом работы с новым подрядчиком: это один из четырёх-пяти вопросов, которые определяют, будет ли поток управляемым. Если подрядчик готов работать только через таблицу при объёме от 100 заявок в месяц, это само по себе сигнал о зрелости процессов.

У нас схема согласуется до первой поставки: в лидах с оплатой за результат заявки уходят в систему заказчика в момент создания, состав полей фиксируется заранее, а сверка объёмов идёт по id. Как оценивать не только доставку, но и содержание потока, описано в разборе качества лидов.

VII. Короткий итог

Три схемы передачи различаются скоростью и риском: API и вебхук доставляют заявку за секунды при настройке 1-3 дня, готовая интеграция с CRM - за секунды-минуты при настройке 1-5 дней, таблица запускается за час, но теряет заявки и время. Порог перехода на автоматику - примерно 50 заявок в месяц. Состав полей с id и временем создания согласуют до старта, иначе спорные заявки разобрать нечем. И почти всегда стоит держать резервную выгрузку плюс контроль тишины на 6-12 часов - это дешевле, чем узнать о сбое через неделю.

Не хотите терять заявки на передаче?

Согласуем схему доставки и состав полей до первой поставки, чтобы поток был управляемым с первого дня.

Получить расчёт заявок →

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

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