Поставщик получил имя и телефон клиента. Через неделю он говорит, что этот покупатель уже был в его базе. Если у агента осталась только фраза «я отправлял контакт в мессенджере», доказать приоритет заявки и право на комиссию будет трудно.
У нормально зафиксированной заявки остаются три следа: карточка с обязательными полями, точное время отправки и ответ поставщика о принятии. Если роли агента и продавца пока смешиваются, сначала сверься с объяснением разницы между дропшиппингом и агентской моделью.
Источник: Закон о персональных данных относит передачу и предоставление персональных данных к их обработке.
Что считать передачей заявки поставщику
Сообщение «есть клиент на баню, позвоните ему» — ещё не запись. В нём нет идентификатора, времени, согласованной потребности и подтверждения второй стороны. Заявка передана, если она зарегистрирована в выбранном заранее канале, содержит обязательные данные и поставщик подтвердил приём.
Правило нужно согласовать до рекламы и записать в договоре или приложении к нему. Там же указывают, какое событие закрепляет клиента за агентом: отправка заполненной карточки, внесение лида в CRM или явное подтверждение поставщика. Подробный список договорных условий есть в статье о договоре с поставщиком для агентских продаж.
Проверка перед отправкой поставщику
- Клиент понимает, кто ему позвонит, и согласен на передачу контакта
- Имя, телефон и город записаны без догадок
- Потребность и следующий шаг сформулированы одним абзацем
- Источник и точное время обращения сохранены
- Поставщик должен подтвердить приём в согласованный срок
Согласие клиента — часть процесса
Телефон, имя, адрес объекта и другие сведения о человеке нельзя пересылать партнёру автоматически. Объясни клиенту, какой компании и зачем передаёшь данные, затем получи согласие способом, который подходит вашей схеме. Не собирай сведения «на всякий случай»: для расчёта кровли может понадобиться адрес объекта, а для первого звонка по серийному товару часто хватает имени, телефона и города.
Какие поля должны быть в карточке заявки
Форма должна быть короткой. Иначе агент начнёт пропускать поля, а поставщик будет читать по диагонали. Для большинства дорогих товаров и услуг хватает следующего набора:
| Поле | Что записать | Зачем |
|---|---|---|
| ID заявки | Уникальный номер, например AV-20260903-017 | Без путаницы ссылаться на одну запись |
| Дата и время | Время обращения и время передачи с часовым поясом | Определить порядок при дубле |
| Источник | Авито, конкретное объявление или телефон | Проверить качество канала |
| Клиент | Имя, телефон, удобный способ связи | Найти совпадение, связаться с клиентом |
| География | Город и место поставки или объекта | Отсеять недоступный регион |
| Потребность | Товар, объём, параметры, срок | Не просить клиента повторять всё заново |
| Квалификация | Что уже подтверждено, чего не хватает | Отделить запрос цены от готовой заявки |
| Следующий шаг | Звонок, расчёт, замер, счёт | Назначить конкретное действие |
| Ответственный | Сотрудник поставщика | Знать, у кого запросить статус |
Не вставляй в карточку свою оценку вроде «клиент сложный». Записывай наблюдаемый факт: «просит три варианта сметы», «сравнивает двух поставщиков», «готов принять звонок после 18:00». Такой текст полезен продавцу и не провоцирует спор о впечатлениях.
Квалифицированная заявка и сырой контакт
Стороны должны одинаково понимать слово «заявка». Сырой контакт — номер человека, который спросил цену. В квалифицированной заявке уже подтверждены задача, подходящая география и следующий шаг. Если комиссия зависит от качества лида, критерии перечисляют заранее, а не придумывают после отказа клиента.
Как подтвердить канал, время и получение
Выбирай канал, доступный обеим сторонам, где запись не потеряется незаметно. При небольшом объёме хватит общей таблицы с историей изменений и уведомления ответственному. Когда поставщиков, менеджеров или обращений становится много, удобнее CRM. Варианты учёта мы сравнили в статье о CRM для заявок с Авито.
Основная система должна быть одна. Если часть лидов лежит в таблице, часть в личном мессенджере, а часть записана голосовыми, никто не соберёт полную хронологию. Мессенджер годится для уведомлений, но сама карточка должна храниться в реестре.
Укажи часовой пояс и используй автоматическую отметку времени. Скриншот сообщения пригодится как дополнительный след, но единственный реестр из него плохой: скриншоты трудно сверять, искать и связывать со статусами сделки.
Как выглядит подтверждение
Ответ поставщика должен ссылаться на ID и содержать один из трёх результатов: «принято», «дубль» или «отклонено с причиной». Простого смайла или «ок» недостаточно, если одновременно переданы несколько клиентов. Назначь срок ответа, например один рабочий день, и правило эскалации на случай, если ответственный молчит.
Что делать, если поставщик нашёл дубль
Знакомый номер сам по себе ещё не означает дубль. До запуска определи, какое предыдущее действие поставщика лишает заявку статуса новой. Разовая запись двухлетней давности, открытый договор, незавершённый расчёт и недавний входящий звонок требуют разных решений.
В правиле нужны срок давности и доказательство активности. Например, поставщик может заявить дубль в течение одного рабочего дня и показать дату последнего содержательного контакта или активной сделки, не раскрывая агенту лишние данные клиента. Если срок прошёл без ответа, заявка считается принятой. Это пример регламента, а не универсальная юридическая формула. Сторонам нужно адаптировать его и закрепить письменно.
Отдельно опиши повторное обращение. Клиент мог впервые прийти через агента, затем через месяц позвонить поставщику напрямую или обратиться с другого номера. Для таких случаев полезны срок закрепления, правила сопоставления по телефону и объекту, а также обязанность поставщика связать повтор с исходным ID.
Какие статусы поставщик должен возвращать агенту
Подтверждение приёма фиксирует лишь факт передачи. Чтобы рассчитать комиссию, нужно видеть путь заявки до согласованного результата. Минимальная цепочка статусов выглядит так:
- Принято в работу.
- Первый контакт состоялся или клиент не ответил.
- Потребность подтверждена либо заявка дисквалифицирована с причиной.
- Расчёт или предложение отправлено.
- Договор заключён.
- Получена оплата, которая запускает начисление комиссии.
- Комиссия начислена и выплачена.
У каждого статуса должны быть дата и ответственный. Причины отказа лучше выбирать из короткого справочника: не подходит регион, нет бюджета, товар не нужен, не дозвонились после согласованного числа попыток, проиграли по сроку или цене. Тогда на еженедельной сверке видно, где теряются заявки. Спорить по памяти уже не придётся.
В агентской модели вознаграждение начисляют после события, указанного в договоре. Возьмём условный пример. Заказ поставщика составил 300 000 рублей, а согласованная комиссия равна 5% после поступления оплаты клиента. Агенту начислят 15 000 рублей до вычета его налогов и расходов, только если выполнены условия договора и заявка была принята.
Суммы приведены для примера и не гарантируют аналогичный результат. Размер, база и момент выплаты комиссии зависят от договора, ниши и фактической сделки.
Готовый регламент передачи заявки
Для первого теста отдел аналитики не нужен. Хватит одной последовательности, которой обе стороны следуют одинаково:
- Агент получает обращение, уточняет минимальные параметры и согласие на передачу данных.
- Создаёт карточку с уникальным ID и обязательными полями.
- Вносит её в основной реестр и отправляет уведомление ответственному поставщика.
- Поставщик в согласованный срок отвечает: принято, дубль или отклонено с причиной.
- При принятии назначает менеджера и следующий шаг с датой.
- После каждого значимого контакта обновляет статус в реестре.
- Раз в неделю стороны сверяют открытые заявки, оплаты и начисленные комиссии.
До запуска объявления проведи контрольный тест: внеси вымышленную техническую карточку без реальных персональных данных, отправь уведомление и попроси поставщика вернуть статус. Закрытый доступ к таблице, неверный часовой пояс и непонятное поле «результат» всплывут раньше, чем появится настоящий клиент.
Фиксация лида закрывает только один участок системы. Как устроены роли, комиссия и путь от предложения до оплаты, смотри в статье об агентском бизнесе на Авито.
Частые вопросы
Можно ли передавать заявку поставщику только в мессенджере?
Можно, если этот канал прямо согласован, у сообщений единый формат, а поставщик отвечает по ID заявки. Но при регулярном потоке искать, сверять и восстанавливать историю удобнее в таблице или CRM.
Достаточно ли скриншота переписки с клиентом?
Нет. Скриншот подтверждает отдельный разговор, но не показывает согласованный статус, ответственного и движение сделки. Его можно приложить к карточке как дополнительный материал после удаления лишних персональных данных.
Что считать временем передачи заявки?
Событие, которое стороны заранее указали в регламенте: создание карточки, запись в CRM или подтверждение поставщика. В любом варианте нужен автоматический штамп даты и времени с часовым поясом.
Что делать, если поставщик не подтвердил получение?
Напомнить ответственному по согласованному каналу. Не считай заявку принятой без ответа, если договор не устанавливает обратное. Если задержки повторяются, приостанови новые передачи и исправь регламент.
Как защитить комиссию, если клиент обратился к поставщику напрямую?
Заранее установить срок закрепления заявки и правило для повторных обращений. Поставщик должен сопоставлять контакт или объект с исходным ID, а не заводить новую карточку без проверки.
Нужно ли хранить все данные клиента бессрочно?
Нет. Срок и цель хранения определяют заранее, а доступ дают только тем, кому данные нужны для обработки заявки и сделки. Конкретную схему работы с персональными данными стоит проверить с юристом с учётом ваших ролей и документов.
Передачей заявки можно управлять, когда у неё есть ID, обязательные поля, отметка времени, согласие клиента, ответ поставщика и дальнейшие статусы. Согласуй правила до рекламы и проверь их на технической карточке. Тогда на еженедельной сверке перед глазами будет один реестр, а не разрозненные воспоминания участников.
Информация в статье носит ознакомительный характер и не является индивидуальной финансовой, инвестиционной, юридической или иной профессиональной рекомендацией. Результат зависит от ниши, рынка, поставщика и действий самого читателя, поэтому гарантировать его невозможно. Администрация сайта не несёт ответственности за убытки, упущенную выгоду или иные последствия, возникшие в результате использования этой информации.
Информация в статье носит ознакомительный характер и не является индивидуальной финансовой, инвестиционной, юридической или иной профессиональной рекомендацией. Результат зависит от ниши, рынка, поставщика и действий самого читателя — гарантировать его невозможно. Администрация сайта не несёт ответственности за убытки, упущенную выгоду или иные последствия, возникшие в результате использования этой информации.
