Клиент принял предложение со ставкой и сроком. Сотрудник открыл бронирование — там другая дата. В карточке стоит «в пути», но последнее событие пришло вчера. Ответить клиенту нужно сейчас, а какая версия заказа действительно принята и что произошло после старого события, непонятно.
Предметное предложение начинается с данных о грузе
Нельзя рассчитать и согласовать логистическую услугу по одной фразе «нужно доставить груз». Нужны точки или адреса, даты либо окна, характеристики груза и особые условия.
В клиентских инструментах DHL и DSV встречаются маршрут, количество мест, тип упаковки, вес, объём или габариты и требования к обработке. Это хорошие примеры категорий данных, но не универсальная форма для любой логистической услуги.
Один оператор организует доставку палет между двумя точками. Другой работает со сборным грузом и несколькими этапами. Третий включает дополнительные услуги. Поэтому в Битрикс24 разумно хранить не «все поля логистики», а тот набор, без которого конкретная компания не может подготовить предметное предложение и ответить на вопрос клиента.
Если данных не хватает, результат шага — не пустая стадия «Расчёт». У запроса должен появиться конкретный вопрос, ответственный и срок следующего ответа.
Принята должна быть конкретная версия предложения
Предложение связывает несколько вещей:
- исходные данные о грузе и точках;
- состав услуги;
- ставку;
- даты или окна;
- срок действия предложения;
- решение клиента.
Срок действия берут из самого предложения оператора. Нельзя переносить условия одного сервиса на всю отрасль.
После ответа клиента сотрудник должен видеть, какую версию тот принял. Если ставка обновилась, состав услуги изменился или предложение уже потеряло силу, прежний файл не должен выглядеть рабочим рядом с новым.
В Битрикс24 можно сохранить версию, ссылку на предложение, результат разговора и следующее действие. Но сама стадия «Предложение принято» не проверяет содержание файла. Команде всё равно нужно правило, по которому одна версия считается актуальной.
Принятое предложение ещё не означает принятый заказ
В клиентских инструментах DSV принятую котировку можно превратить в бронирование. В технической документации DSV отдельно различаются черновое и финальное бронирование и используется Booking ID. Это пример конкретной компании, но он хорошо показывает сам разрыв.
Клиент уже сказал «да». Операционная сторона ещё могла не получить заказ, вернуть его на уточнение или не подтвердить финальную передачу.
Поэтому передача заканчивается не кнопкой «Создать бронирование», а проверяемым результатом:
- есть номер или ссылка на операционный заказ;
- понятно, какая версия предложения стала основанием;
- согласованные точки, даты и состав услуги переданы;
- операционная сторона подтвердила приём либо вернула конкретный вопрос.
Способ передачи может быть ручным, через кабинет, импорт или интеграцию. Выбирать его заранее нельзя. Сначала нужно понять, где реально создаётся операционный заказ и какое событие означает, что его приняли.
Для ответа клиенту нужен не статус, а событие
Фраза «груз в пути» быстро устаревает. Она не говорит, какое событие произошло, откуда пришла информация и когда её проверяли.
Рабочий клиентский статус содержит пять элементов:
- Номер заказа или отправки.
- Последнее подтверждённое контрольное событие.
- Источник события.
- Дату и время обновления.
- Ответственного за следующий ответ клиенту.
DSV и DHL в своих инструментах показывают события, идентификаторы и время. Это не означает, что любая логистическая компания обязана использовать те же названия. У конкретного оператора будут свои события и свой источник.
Главное — не переносить в CRM придуманный статус. Если профильная система ещё не подтвердила следующий шаг, сотрудник честно говорит клиенту, какое событие известно и когда будет новая проверка.
Как провести узкое изменение после бронирования
После передачи заказа клиент может попросить перенести дату доставки или обновить адрес либо контактное лицо. Такие примеры подтверждены в материалах DHL и DSV.
Условный сценарий выглядит так. Клиент просит другую дату. Сотрудник фиксирует запрос, передаёт его операционному участнику и получает решение. Только после этого клиенту сообщают новую подтверждённую дату или объясняют, что изменение невозможно.
В клиентском контуре должны остаться:
- исходный запрос;
- кто его получил;
- срок решения;
- ответ операционной стороны;
- следующий ответ клиенту.
Эту логику нельзя автоматически расширять на объём груза и любые другие условия. Доступные источники подтверждают только узкие примеры даты и адреса/контакта. Остальные изменения зависят от услуги и правил оператора.
Завершение заказа не закрывает открытый вопрос клиента
Для некоторых услуг подтверждением завершения может быть proof of delivery — подтверждение доставки. DSV и DHL показывают такой документ в своих сервисах. Но POD не является обязательным документом любой логистической услуги.
Компания сама определяет, какое событие или документ завершает конкретный заказ. После этого нужно отдельно проверить, остался ли открытый вопрос: документ, расхождение, претензия или обещанный ответ.
Если основная операция завершена, а вопрос клиента остался без владельца, клиентская работа не закончена. В Битрикс24 этот вопрос можно связать с заказом, назначить ответственного и срок. Новый цикл создаётся только при новой потребности, а не автоматически ради «повторной продажи».
Битрикс24 — окно клиентской команды, а не TMS
Расчёт ставки, планирование перевозки, маршрут, транспорт, склад, себестоимость и операционное исполнение должны оставаться в профильных системах компании.
В Битрикс24 клиентской команде нужны:
- запрос и принятая версия предложения;
- ставка и состав услуги;
- номер или ссылка на бронирование;
- последнее подтверждённое событие с временем;
- изменение и решение по нему;
- открытый вопрос;
- ответственный и следующий ответ клиенту.
Эти данные могут появляться вручную, по ссылке или через проверенный обмен. Вебхуки и REST API Битрикс24 дают техническую основу для интеграции, но не доказывают готовую совместимость с конкретной TMS, WMS, ERP или 1С.
Если нужно настроить Битрикс24 для клиентской работы логистической компании, начинать стоит с одного типа заказа и нескольких событий, по которым команда действительно отвечает клиенту.
Что проверить на 3–5 недавних заказах
Возьмите несколько обычных заказов и хотя бы один с изменением или задержанным ответом. Для каждого восстановите:
- Какая версия предложения была принята?
- Какие ставка и состав услуги в ней зафиксированы?
- Есть ли номер или ссылка на бронирование?
- Подтвердила ли операционная сторона приём заказа?
- Какое последнее событие подтверждено, из какого источника и когда?
- Кто должен следующим ответить клиенту?
- Остался ли после завершения открытый вопрос?
Если сотрудник не может ответить без звонков коллегам и поиска по перепискам, место разрыва уже найдено. Следующий шаг — не добавлять ещё один общий статус, а связать конкретную версию, заказ и событие.
Частые вопросы
Какие данные о грузе обязательно хранить в Битрикс24?
Только те, которые нужны клиентской команде для предложения, передачи и ответа. Конкретный набор зависит от услуги. Операционные и расчётные данные не нужно дублировать в CRM без понятной задачи.
Почему принятой ставки недостаточно для начала исполнения?
Решение клиента подтверждает предложение, но операционный заказ может ещё не быть создан или принят. Нужен номер или ссылка и подтверждение со стороны исполнения.
Что считать свежим статусом?
Это правило компании. Статус должен быть связан с конкретным событием, источником, датой и временем. Допустимый срок актуальности зависит от услуги и ожиданий клиента.
Можно ли менять заказ после бронирования?
Нельзя обещать изменение любых условий. Источники подтверждают отдельные примеры переноса даты и обновления адреса или контакта. Остальные случаи проверяются по правилам конкретной услуги.
Обязательно ли интегрировать Битрикс24 с TMS?
Нет. Первая версия может использовать номер, ссылку и ручную проверку. Интеграцию проектируют после определения источника, событий, данных, прав и поведения при ошибке.
Следующий шаг
Для начала достаточно выбрать один тип логистического заказа и ответить на три вопроса: какая версия предложения считается принятой, чем подтверждается приём операционного заказа и какое событие позволяет ответить клиенту.
Когда эти правила понятны, Битрикс24 можно настроить вокруг реальной работы. До этого автоматизация будет только быстрее переносить неопределённость из одной системы в другую.
