Laneo CRM — обзор заказа для сложных B2B-поставок

1. Контекст

Laneo — концепт B2B-CRM для крупного поставщика электроники, который снабжает офисы, девелоперов и корпоративных клиентов.

Корпоративный заказ почти никогда не идет по прямой. Десятки строк разбиваются на частичные отгрузки, уходят с разных складов или зависают в дозаказе, а оплата растягивается на несколько этапов. Обычные CRM схлопывают всю эту многомерную картину в один статус вроде «В работе». В итоге менеджер не понимает, зарезервирован ли товар, уехала ли партия и пришел ли платеж. Когда клиент спрашивает: «Что с моим заказом?», приходится вручную сверять данные по разным программам.

Успех я меряю на трех уровнях:

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

2. Ограничения

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

• Полный контур CRM + WMS + ERP: Решение работает поверху всего enterprise-стека. Отношения и сделка живут в CRM, физическое движение товара — в WMS, счета и платежи — в ERP. Обзор собирает три источника в один слой, не упрощая архитектуру.
• Надстройка, а не замена: Обзор заказа дает менеджеру необходимый контекст для разговора с клиентом, но глубокие действия остаются на страницах самих сущностей.
• Сохранение модели данных: Заказ, отгрузка, счет и платеж остаются отдельными связанными сущностями со своими жизненными циклами.

3. Кабинетное исследование

Без доступа к реальной системе я разбирал боли практиков на Reddit, G2, Capterra и в отраслевых разборах NetSuite, Odoo и QuickBooks. Из раза в раз повторялись пять проблем:

• Один статус скрывает несколько реальностей. За ярлыком «Pending fulfillment» может стоять и «ничего не собрано», и «часть уже уехала и выставлена к оплате».
• Сборка вручную. Данные об отгрузках и счетах автоматически не связываются — историю заказа менеджеры восстанавливают по крупицам.
• Разрыв между логистикой и финансами. Счет редко привязан к конкретной партии товара, из-за чего частичные поставки тяжело сверить с поэтапной оплатой.
• Проблема всплывает поздно. О сбое узнают, когда сорваны все сроки, и оперативно вмешаться уже нельзя.
• Доверие ломает неопределенность. Клиенты терпимо относятся к задержкам, но не прощают путаницы и невнятных ответов.

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

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

4. Допущения

• Разделение осей состояния: Заказ распадается на три рассинхронизированные оси — наличие, отгрузку и оплату.
  • На чем стоит: Стандартные модели данных в ERP и OMS из бенчмарка.
  • Как проверил бы: Анализом истории реальных корпоративных заказов.
• Главная точка трения: Сценарий «Где мой заказ?» — самый частый и болезненный для аккаунт-менеджеров.
  • На чем стоит: Обязанности менеджеров и структура обращений в поддержку.
  • Как проверил бы: Аналитикой входящих запросов и частотой открытия карточки заказа.
• Оценка в 12–18 минут на ответ: Столько уходит на ручной поиск и сверку данных между CRM, WMS и ERP.
  • На чем стоит: Аналитический расчет шагов и переключений между вкладками.
  • Как проверил бы: Хронометражем работы менеджеров на пилоте.
• Частичное исполнение как норма: Частичные отгрузки и поэтапные платежи — стандартная практика в B2B.
  • На чем стоит: Специфика оптовых поставок и работы по постоплате.
  • Как проверил бы: Статистикой по активным сделкам.

5. Сценарии

Клиент на линии — «Где мой заказ?» Менеджер отвечает на звонок: у клиента заказ на 200 позиций. Часть отгружена, часть зависла у поставщика, а оплачена только полученная партия. Пока клиент ждет, менеджер на ходу собирает данные из трех систем. Цена ошибки — ложное обещание по срокам и потерянное доверие.

Согласование отгрузок с логистикой. Менеджеру надо понять, какие партии готовы к отправке, а какие задерживаются. В CRM заказ виден целиком, и неясно, закроет ли эта партия поставку. Цена ошибки — срыв графика отгрузки.

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

6. Приоритизация

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

7. Постановка задачи

Аккаунт-менеджер не может быстро ответить на вопрос «Где мой заказ?», потому что данные о поставке разбросаны по CRM, WMS и ERP, и их приходится сверять вручную.

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

8. Решение

Заказ — это не строчка со статусом, а контейнер для связанных сущностей. Товары, отгрузки, счета, платежи и проблемные позиции должны лежать на одном экране, чтобы менеджер отвечал за секунды.

Заказ как контейнер сущностей

Сначала я разложил заказ на сущности и их связи. Заказ ведет свою жизнь в CRM, отгрузка — в WMS, счет и платёж — в ERP. Между ними работают четкие связи: позиции формируют отгрузки, отгрузки собираются в упаковки, счет закрывает отгрузку или заказ целиком, а платёж погашает счет. Обзор делает эти связи видимыми.

Гипотеза: Если вывести три оси заказа — наличие, отгрузку и оплату — на один экран, менеджер ответит клиенту, не выходя из CRM.

Три оси вместо одного статуса

Обзор заказа работает как единое окно над CRM, WMS и ERP. Верхний блок отвечает на три главных вопроса с помощью осей: наличие, отгрузка и оплата. У каждой оси есть свой прогресс-бар с процентами и абсолютными цифрами, чтобы сразу видеть масштаб.

Ниже расположились связанные отгрузки, счета, платежи и проблемные позиции. Для длинных заказов есть фильтр по проблемным строкам — он появляется только тогда, когда в заказе есть сбои.

• Три оси вместо общего статуса: Детализация не дает важным нюансам потеряться за общими словами. Наличие показывает, можно ли собрать заказ; отгрузка — реальное движение товара; оплата — финансовое состояние.
• Раннее предупреждение: Индикатор дозаказа подсветит нехватку товара за недели до того, как сорвется дата поставки. У менеджера появляется время, чтобы исправить ситуацию.

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

Связь с другой стороны

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

Страница отгрузки сфокусирована на логистике: какие позиции вошли в партию, сколько единиц уехало, какой перевозчик отвечает за доставку и какими счетами она закрыта.

Страница счета показывает финансовую изнанку: выставленную сумму, статус оплаты и подкрепляющие отгрузки.

Статусы и цвет

Цвет работает строго по делу, чтобы не перегружать интерфейс:

• Красный: Сорванное обязательство (просрочен платеж, упущена дата доставки).
• Янтарный: Риск срыва, когда еще есть время вмешаться (дозаказ, нехватка на складе).
• Серый: Штатный ход работы, завершение процесса или отмена.

Индиго вынесен за пределы статусной шкалы — он отвечает за интерактивные элементы, ссылки, выделение и заливку прогресс-баров.

Главные сущности обозначаются текстовыми статусами, а позиции внутри таблиц — точкой с текстом.

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

9. Компромиссы

Где развернуть блок клиента

• Из чего выбирал: Отдельная четвертая колонка, сворачиваемый сайдбар с иконками (в стиле HubSpot) или интеграция данных клиента в шапку заказа.
• Что теряю: Данные о клиенте перестают быть отдельным блоком и зрительно подчиняются заказу.
• Почему это нормально: В сценарии проверки статуса данные клиента нужны лишь для сверки контекста. Объединение с шапкой бережет место на экране, сохраняя главное перед глазами.

Плотность данных против чистоты экрана

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

10. Как измерял бы успех

• Главная метрика: Сокращение времени ответа на запрос с оценочных 12–18 минут до нескольких секунд.
• Операционные индикаторы:
  • Число сторонних программ, открываемых при звонке (Цель: ноль, все данные есть в CRM).
  • Доля вопросов клиентов, закрытых без перехода на другие страницы.
• Метод проверки: Пилот с продуктовой аналитикой (время от открытия карточки до закрытия) и наблюдением за реальными звонками в поддержку.

11. Что дальше

План подготовки к запуску:

• Запуск пилота: Запустить решение на ограниченную группу, чтобы снять реальный базовый замер и проверить время ответа.
• Детальная проработка состояний: Дорисовать ошибочные, пустые и загрузочные экраны, а также проверить интерфейс на реальных данных.
• Стресс-тест синхронизации: Проверить скорость обновления данных при высокой нагрузке на CRM, WMS и ERP.

Кроме того, стоит проверить на реальном потоке обращений ключевое допущение — действительно ли сценарий с частичными отгрузками и поэтапной оплатой является самым частым.