Перейти к содержанию
Кейс · GROCERY-EU

// 11 — Кейс

Доставка · DE

Заказы из мессенджеров — в доставку со слотами и заменами

Сеть супермаркетов в среднем городе Германии: 4 магазина, ~12 000 SKU. Заказы принимали в WhatsApp и по телефону, ассортимент жил на бумаге, слоты доставки — в тетради. Мы построили доставку поверх кассы: живые остатки, слоты по районам, замены в один тап.

каталог → слот → сборка → замена → дверь · без тетради

CASE.11 — ЗАЛПОЛКИ

// Остаток на витрине — из кассы · обновление 10 мин

LIVE
Роль
Сайт доставки + PWA сборщика и курьера
Ядро
Живые остатки из кассы, слоты и матрица замен
Срок
12 недель до запуска · пилот одного магазина на 8-й
Команда
4 роли TO-DEV + администратор магазина со стороны клиента
Статус
В продакшне · опубликовано с обезличением

// Полный паспорт кейса — в главах ниже: стек, сроки, метрики

01Задача

Заказы из мессенджеров переписывали в тетрадь, а цены расходились с кассой

Сеть локальных супермаркетов в среднем городе Германии: 4 магазина, ~12 000 SKU. Доставку запускали без сайта — заказы шли в WhatsApp и по телефону, менеджер переписывал их в тетрадь. Не хватало товара — звонили клиенту и ждали ответа, пока корзина таяла

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

  • Заказ в WhatsApp — ручной перенос в тетрадь; отсутствующий товар = звонок клиенту и ожидание ответа
  • Цены «визитки» и кассы расходились — спор с клиентом на дверях, скидка на месте как единственный выход
  • Слоты в тетради: два курьера в одном районе, третий район пустой — топливо и время в никуда
  • Оплата на месте всеми способами — карты, PayPal, наличные — со сверкой вручную в конце дня

Специфику немецкого ритейла заложили в задачу сразу: цены в витрине — с VAT, весовые товары — с шагом 100 г, Pfand (залог за тару) — отдельной строкой чека. Именно на этих трёх пунктах самодельные магазины обычно ломаются

KPI зафиксировали до старта, чтобы не спорить о результатах потом: 200+ заказов в неделю к четвёртому месяцу, замен без звонка ≥ 70%, ноль расхождений цен на дверях

02Что построили

Витрина и слоты поверх кассы — без замены учётной системы

Кассовая система осталась источником правды: каждые 10 минут остатки и цены уходят в витрину пакетом. Магазины работают как работали, а клиент видит то, что реально стоит на полке, — по цене из кассы, с VAT

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

  • Каталог с живыми остатками из кассовой системы — синхронизация каждые 10 минут, цены из кассы, с VAT
  • Поиск по 12 000 SKU с опечатками: «Joghurrt» находит «Joghurt»
  • Слоты доставки с пропускной способностью по районам — перегруженный слот просто не показывается
  • Корзина с весовыми товарами (шаг 100 г) и Pfand отдельной строкой
  • Оплата онлайн — карты и PayPal — или при получении, как удобнее клиенту
  • Матрица замен: сборщик сканирует товар — нет в наличии → система предлагает разрешённую замену, клиент подтверждает в пуше
  • PWA сборщика: маршрут по полкам магазина, сканер, статусы; PWA курьера: маршрут по адресам, подтверждение доставки
  • Личный кабинет с повторными корзинами «в один клик» — прошлый заказ возвращается двумя нажатиями

// Галерея кейса · клик открывает кадр крупно

FIG.G.01 — КАТАЛОГОСТАТКИ · VAT
FIG.G.02 — СЛОТЫРАЙОНЫ · PFAND
FIG.G.03 — ЗАМЕНАОДИН ТАП
FIG.G.04 — МАРШРУТКУРЬЕР
FIG.G.05 — СИНК КАССЫКАЖДЫЕ 10 МИН

03Технологии и интеграции

Инструменты подбирали под слоты и кассу — не наоборот

Требования диктовал предмет: слоты — конкурентный ресурс с гонками, касса — единственный источник правды по ценам и остаткам, а приложения зала не имеют права зависеть от Wi-Fi между стеллажами

Бэкенд

PHP 8.3Laravel 11PostgreSQLRedis

Слоты — конкурентный ресурс «район × время»: бронирование под блокировкой, иначе два курьера уедут в один район. Матрица замен — таблица правил с приоритетами, а не «сборщик сам решит»

Интеграции

Кассовая система · RESTПлатёжный шлюз · карты, PayPalE-mail · пуш

Касса — единственный источник правды по ценам и остаткам: пакет данных каждые 10 минут. Спор «на дверях» исключается самим контуром, без сверок и таблиц

Фронтенд

SSR-витринаНативный JSПоиск Meilisearch

Каталог на 12 000 SKU обязан искать с опечатками («Joghurrt» → «Joghurt») и отвечать мгновенно — поэтому серверный рендер и опечаткоустойчивый поисковый движок без тяжёлых фреймворков

PWA сборщика и курьера

Офлайн-режимСканерМаршруты

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

Инфраструктура

Hetzner · Германия, GDPRDockerБэкапыЖурналы доступа

Данные клиентов из ЕС — в контуре Германии: хостинг Hetzner, журналы доступа, бэкапы. Для немецкого ритейла это не опция, а входной билет

04Результат

Через четыре месяца — 340 заказов в неделю и NPS 68

340/нед

Заказов через сайт

Было ~120 в мессенджерах — цель «200+ к четвёртому месяцу» перевыполнена

84%

Замен в один тап

Подтверждаются в пуше, без звонка сборщика клиенту

76%

Слотов загружено на ≥80%

Районы распределены ровно — без пустых рейсов и дублей

0

Расхождений цен с кассой

С момента запуска синка каждые 10 минут

Средний чек — €63: повторные корзины «в один клик» и подсказки замен поднимают его без скидок. NPS доставки — 68 по опросам после первых поставок. Администратор магазина перестала быть «диспетчером WhatsApp»: телефон остался для сложных случаев

Метрики — за первые 4 месяца, значения округлены. Название сети не раскрываем — см. главу 08

05Сроки

12 недель до запуска — пилот одного магазина на 8-й

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

Недели 01–02

Дискавери

День из жизни сборщика и курьера, карта районов доставки, договорённость с вендором кассовой системы об API — день 1

Недели 03–05

Каталог и корзина

Синк остатков из кассы, цены с VAT, весовые товары с шагом 100 г, Pfand отдельной строкой чека

Недели 06–07

Слоты и оплаты

Пропускная способность по районам, карты и PayPal онлайн, оплата при получении

Неделя 08

Пилот одного магазина

Живые заказы и правки матрицы замен: 14 правил из 40 переписаны после первой недели

Недели 09–10

PWA сборщика и курьера

Приложение зала с маршрутом по полкам и сканером, приложение курьера с маршрутной логикой — оба с офлайн-режимом

Недели 11–12

Роллаут на все 4 магазина

Обучение персонала, купоны и повторные корзины, мониторинг слотов и остатков

Итого: 12 недель · пилот на 8-й · без остановки работы магазинов

06Экспертиза

Четыре роли — правила весили больше кода

Системный аналитик~25% часов

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

Бэкенд-разработчик~35% часов

Синк кассы каждые 10 минут, блокировки слотов против гонки «два заказа — один слот», платежи картами и PayPal, очередь пушей

Фронтенд / PWA~30% часов

SSR-витрина с поиском по 12 000 SKU и два приложения с офлайн-режимом: сборщик в зале и курьер на улице

QA и запуск~10% часов

Пилот одного магазина, сценарии «товар кончился на глазах у клиента», обучение персонала всех четырёх точек

Матрицу замен переписали после пилота вместе с администратором магазина: «чем можно заменить масло» знает магазин, не разработчик. Наша задача — дать правилам интерфейс, а не придумывать их за полку

07Ориентир для повторения

Что нужно, чтобы повторить такой результат

Нужно от заказчика

01Договор с вендором кассовой системы на API — или хотя бы стабильный экспорт остатков; без этого проект не стартует
02Администратор магазина, который решает спорные случаи за двое суток, — правила замен и слотов меняются еженедельно
03Матрица замен от мерчендайзеров: что чем заменять можно и нельзя — этот список не напишет разработчик

Артефакты старта

04Карта районов доставки с реальными сроками — не «от 30 минут», а по районам и часам
05Прайс-политика доставки: пороги бесплатности, зоны, правила Pfand в чеке
06Топ-500 товаров для первичного контента и фото — остальное добьёт синк из кассы

Вилки сроков и команды

07Без API кассы — плюс 2 недели на файловый импорт и ручную сверку на переходный период
08Своя курьерская служба или партнёр — маршрутная логика проектируется под это решение, его лучше принять до старта
09Команда — 4 роли выше; пилот одного магазина обязателен: правила замен на бумаге не пишутся

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

08Честно оговорим

Что обезличено — и что не показываем

01

Сеть не названа, город обезличен: объём публикации согласован с владельцем — метрики без идентификации сети

02

Метрики показаны за первые четыре месяца и округлены до целых; сырые дашборды не публикуем

03

Фотография — временный плейсхолдер до согласования съёмки; интерфейсы показаны схемами, а не скриншотами, — по той же причине

04

Хотите доставку для своего магазина — расскажите о задаче в форме ниже

// CTA — Разбор задачи

Доставка для своего магазина — расскажите

Двух коротких вопросов и контакта хватит для первого ответа. Если задачу закрывает готовое решение — скажу об этом первым делом

Развернуть полный бриф — на главной

Достаточно контакта — задачу обсудим в ответ. Имя и подробности не обязательны: это минимум данных