Способы передачи заказов в систему

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

Пять путей внутрь

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

Что выбрать

• Свой трафик — выпустите ключ без вебмастера, в списке он будет помечен как внутренний, и подключите к нему лендинг. Формат запроса на выбор: нативный JSON или совместимый с LeadVertex.
• Партнёр с готовой интеграцией — не просите его переписывать код. Дайте ключ и адрес в формате LeadVertex: он меняет один домен в настройках и продолжает работать.
• Новая интеграция — нативный приём. Там больше полей, понятные ошибки и защита от повторной отправки по заголовку Idempotency-Key.
• Единоразовая заливка — файл. Настраивать ничего не нужно, но каждая загрузка делается руками, и как постоянный канал это не работает.

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

Куда попадает заказ

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

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

Проверить, что дошло

{"phones": ["0555123456"], "fio": "Асанов Азамат",
 "city": "Бишкек", "flow": "kg_tt_04", "ip": "91.108.4.12"}

Журнал пишется до решения о создании заказа, поэтому в нём есть и то, что не прошло. Колонка Результат принимает пять значений: принят, дубль, отклонён, спам, ошибка. Рядом с отказом стоит причина, а строка раскрывается: внутри сообщение, время обработки и исходный запрос целиком.

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

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

Один конвейер на все каналы

Заказ от CPA-партнёра, строка из Excel, заявка со своего лендинга и звонок проходят один и тот же путь:

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

Разные пути приёма — надёжный способ получить систему, где чёрный список работает в одном канале и не работает в другом. Здесь такого нет: правила настраиваются один раз и действуют везде. Подробности — в статьях Приём по API, Приём в формате LeadVertex, Загрузка заказов из файла и Антифрод.