Доставка заказа в CRM: какие статусы нужны менеджеру и клиенту

Почему стадия сделки расходится с положением посылки

Неверный ответ о доставке заставляет клиента ждать посылку, которую перевозчик ещё не принял. Руководителю нужен порядок, при котором менеджер видит состояние отправления в CRM — системе работы с клиентами — и знает, кому поручить разбор задержки. Речь об отделе продаж на Битрикс24, передающем посылки внешнему перевозчику: здесь связывают сделку с отправлением, сохраняют ответ службы и определяют событие, после которого клиент получит сообщение о движении именно своей посылки. Одной стадии продаж для этого мало.

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

В истории сделки, то есть таймлайне, Битрикс24 показывает состояния доставки «успех», «ошибка» и «в процессе», согласно справке. На доске с карточками — канбане — видно ожидание или завершение доставки. До подключения уточните, какое событие выбранного решения стоит за этим отображением.

Три события, которые нельзя объединять

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

Если магазин использует заказы вместе со сделками, отдельно учитывайте внутреннюю обработку отгрузки. Настройка статусов, описанная в документации Битрикс24, относится к режиму «Сделки + Заказы». У доставки в этом режиме есть начальное состояние «Ожидает обработки». Успешный финал называется «Отгружен». Это название нельзя без уточнения трактовать как вручение посылки клиенту.

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

Карточка отправления и трек-номер

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

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

В обзоре приложений Битрикс24 для решения «Отправки – СДЭК» заявлена передача трек-номера и ссылки на накладные в сделку. Там же описана синхронизация текстового статуса и его истории. Это пример конкретного подключения, а не общее обещание одинаковых функций у всех служб и приложений.

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

Как переводить ответ перевозчика в понятный статус

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

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

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

Обновления с задержкой и без потери истории

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

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

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

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

Сообщение клиенту после нужного события

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

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

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

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

Приёмка на вручении, отмене и повторной отправке

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

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

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

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

Договорённости, с которых начнётся подключение

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

Зафиксируйте, что считается передачей груза, что завершает конкретное отправление и когда можно закрыть заказ целиком. Отдельно назовите допустимую задержку обновления, порядок повторной отправки и адрес отправителя уведомлений. Доступность приложения, его оплату и ограничения на вашем тарифе уточняют до подключения по условиям выбранного решения. Когда эти сведения собраны, специалист по доработке Битрикс24 сможет оценить передачу данных и показать результат по тем событиям, которые действительно нужны продавцам.