Getir и Gorillas по-русски: мини-дарксторы мгновенной доставки в жилых районах

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

Коротко: Getir и Gorillas доставляют продукты за 10-15 минут за счёт сети маленьких складов без витрины — дарксторов, — разбросанных прямо по жилым районам, с узким, но продуманным ассортиментом и коротким плечом доставки. В крупных российских городах похожие сервисы уже есть, а в средних и малых городах такой плотности мини-складов почти нет. Для запуска нужны приложение с картой ближайшего даркстора, учёт остатков и управление курьерами, но сама аренда точек и закупка товара — задача заказчика.

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

Что это за модель за рубежом

Getir появился в Стамбуле, Gorillas — в Берлине, но суть у обеих компаний одна и та же. Вместо одного большого распределительного центра на весь город они строят сеть маленьких складов — их называют дарксторами, «тёмными» магазинами, потому что туда не пускают покупателей. Это, по сути, небольшое помещение размером с квартиру или гараж, заставленное стеллажами с самыми ходовыми товарами: молоко, хлеб, яйца, средства гигиены, снеки, напитки, что-то из готовой еды. Никакой витрины, никакой кассы для посетителей — только сборщик заказа и курьер.

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

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

Почему такого нет у нас

В крупных российских городах быстрая доставка продуктов уже давно не редкость — есть сервисы, которые обещают доставку за 15-30 минут, и в Москве или Санкт-Петербурге это работает достаточно неплохо благодаря высокой плотности населения и уже выстроенной логистике крупных игроков. Но если отъехать от городов-миллионников, картина резко меняется. В средних и малых городах такой скорости и, что важнее, такой плотности мини-складов почти нет: доставка либо идёт из одного централизованного магазина на весь город, либо занимает час и больше, либо её просто не существует за пределами пары крупных сетей.

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

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

Как это могло бы выглядеть здесь

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

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

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

Что нужно для запуска

Если смотреть с чисто технической стороны — а это то, чем я занимаюсь, — для запуска такого проекта нужно несколько связанных друг с другом частей. Во-первых, клиентское приложение или бот для заказа, который умеет определять или запрашивать адрес, показывать карту с зоной покрытия и автоматически привязывать пользователя к ближайшему открытому даркстору. Без этой привязки вся идея скорости теряет смысл — заказ должен физически уходить туда, откуда его быстрее всего довезти.

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

Здесь стоит сказать прямо: всё перечисленное — это цифровая часть, и её вполне реально спроектировать и собрать как техническую платформу. Но сама операционная модель — аренда и оснащение помещений под дарксторы, закупка и хранение товара, найм и обучение курьеров, договорённости с поставщиками, ежедневное управление точками — это уже бизнес-задача заказчика, а не часть разработки. Хорошая техническая платформа облегчает и ускоряет операционную работу, но не заменяет её: без реальных складов и живых курьеров даже самое отточенное приложение останется красивой оболочкой без содержимого. Если вы прикидываете такой проект и хотите обсудить, что именно нужно на стороне технологии, можно обсудить проект отдельно, чтобы сразу разделить зоны ответственности.

Риски и сложности

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

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

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

Частые вопросы

Чем это отличается от обычной доставки из магазина? Обычная доставка обычно идёт из одного центрального склада или магазина на весь город, и время в пути зависит от того, как далеко находится покупатель. Модель дарксторов строится вокруг множества маленьких складов внутри жилых районов с коротким плечом доставки — именно за счёт этого удаётся сократить время до 10-15 минут вместо часа и больше.

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

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

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

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

Коротко о главном

Модель Getir и Gorillas построена на простой, но требовательной к исполнению идее: множество небольших складов внутри жилых районов, короткое плечо доставки и узкий, но продуманный ассортимент дают скорость, которую не может обеспечить один центральный магазин. У нас в стране такая плотность мини-складов пока встречается редко за пределами крупных городов, и это ниша, а не занятая территория. Технически для запуска нужны приложение или бот с картой ближайшего даркстора, система управления заказами и курьерами и учёт остатков склада — но всё это работает только поверх реальной операционной модели: аренды, товара и штата курьеров, за которые отвечает уже сам заказчик. Если вы присматриваетесь к такому формату и хотите понять, какая техническая платформа под него нужна и с чего разумно начать пилот, — можно обсудить проект и разложить его на конкретные шаги.