CRM для курьерской службы

Почему одной CRM курьерской службе мало

CRM создавалась для продаж: карточка клиента, воронка, сделки, задачи менеджеров, история переписки. Для этого AmoCRM и Bitrix24 подходят хорошо. Но у курьерской службы основная работа начинается после того, как сделка выиграна, — и здесь стандартная CRM быстро упирается в ограничения.

• Нет карты и маршрутов. CRM не видит, где находится курьер, и не умеет выстроить порядок адресов с учётом окон доставки.
• Нет рабочего места исполнителя. Курьеру нужен простой экран «куда ехать, что везти, как отметить результат», а не интерфейс менеджера по продажам.
• Нет подтверждения на месте. Фото, чек-лист, отметка о вручении — всё это приходится собирать в мессенджерах и потом переносить вручную.
• Статусы грубые. Этап воронки «Передано в доставку» не показывает, в пути заказ, у двери или возвращается на склад.

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

Как распределить роли между CRM и системой доставки

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

• CRM владеет клиентом и сделкой: контакты, реквизиты, состав заказа, сумма, договорённости менеджера.
• Система управления курьерами владеет исполнением: кому назначен заказ, в каком порядке едет курьер, фактическое время, фотоотчёт, подтверждение выполнения.
• 1С или другая учётная система владеет деньгами и остатками: документы, оплаты, складские движения.

При таком разделении менеджер продолжает работать в привычной CRM, диспетчер — на карте с заявками и маршрутами, а курьер — в мобильном веб-интерфейсе без обязательной установки приложения. Каждый видит своё, но данные не дублируются: заказ создаётся один раз и дальше только меняет статус.

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

Обмен заявками с CRM: что и когда передавать

Обмен заявками с CRM удобно проектировать как два потока: заявка идёт из CRM в доставку, результат — обратно.

Из CRM в систему доставки передаётся то, без чего курьер не выполнит заказ:

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

Из системы доставки в CRM возвращается то, что нужно менеджеру и клиенту:

• смена статуса: назначен, в пути, доставлен, не доставлен;
• причина отказа или переноса;
• фактическое время выполнения и ссылка на фотоотчёт или подтверждение.

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

Как выбрать решение: чек-лист для курьерской службы

Выбирая CRM для доставки и систему, которая будет с ней работать, проверяйте не список функций, а ваш реальный день. Возьмите десяток типичных заказов и пройдите их от сделки до подтверждения.

• Готовая связка с вашей CRM. Есть ли интеграция с AmoCRM или Bitrix24 из коробки, или обмен придётся писать с нуля.
• Работа с учётом. Если деньги и документы живут в 1С, нужна связь и с ней — иначе сверка останется ручной.
• Распределение и маршруты. Умеет ли система предложить порядок адресов с учётом окон доставки и ограничений, а не только показать точки на карте.
• Экран исполнителя. Сможет ли курьер начать работу с телефона в первый же день, есть ли фотоотчёты и чек-листы.
• Обратные статусы. Видит ли менеджер результат доставки в карточке сделки без звонка курьеру.
• Выгрузка. Можно ли забрать данные в Excel для разборов и отчётности.
• Срок запуска. Сколько времени уйдёт до первой рабочей смены и нужен ли долгосрочный контракт.

Под эти требования и собран itlogist: приём и распределение заявок, маршруты на карте в реальном времени, оптимизация на движке OR-Tools с учётом окон доставки, мобильный интерфейс исполнителя и интеграции с 1С, AmoCRM, Bitrix24 и Excel. Подробнее — в разделе Возможности itlogist.

Внедрение без остановки работы

Связку CRM и доставки лучше запускать поэтапно, чтобы служба продолжала возить заказы, пока настраивается обмен.

• Шаг 1. Один поток. Выберите один тип заказов или одну зону и настройте передачу заявок из CRM. Курьеры этой группы работают уже в новой системе.
• Шаг 2. Обратные статусы. Когда заявки приходят стабильно, включите возврат статусов и причин отказа в CRM. Проверьте, что менеджеры перестали звонить диспетчеру за информацией.
• Шаг 3. Маршруты и окна. Подключите оптимизацию маршрутов и сравните план с тем, как диспетчер распределял заказы вручную.
• Шаг 4. Масштаб. Переведите остальные типы заказов и зоны, добавьте личный кабинет для клиентов.

Типичные ошибки на этом пути: заводить заказ вручную «на всякий случай» в обеих системах, не определить ключ соответствия (и получать дубли), разрешать менять адрес в CRM после отправки в доставку. Эти правила стоит закрепить письменно до запуска. itlogist рассчитан на команды от 5 до 100 исполнителей и запускается за 7 дней без долгосрочных контрактов — первые результаты видны уже на пилотном потоке.