Пятница, вечерний пик. Оператор принимает звонок, одновременно вбивает адрес в один экран, состав заказа в другой, а свободного курьера ищет в рабочем чате. Один заказ уезжает не по тому адресу, второй остывает на подоконнике диспетчерской, клиент ждёт на двадцать минут дольше обещанного. На следующей неделе этот клиент заказывает уже у соседнего проекта. Причём не потому, что там вкуснее, а потому, что там просто быстрее и без нервов.
Такая картина знакома почти каждой службе доставки, которая выросла из десятка заказов в день до нескольких сотен, но так и осталась на таблицах, мессенджерах и памяти самого опытного диспетчера. До определённого оборота это работает. А потом начинает стоить денег: в потерянных заказах, в оттоке клиентов, в курьерах, которые крутят лишние километры.
Ниже разбор того, из чего на самом деле состоит CRM для доставки еды, где такая система даёт измеримую отдачу, а где превращается в дорогую игрушку с красивым дашбордом. Материал рассчитан на владельцев и руководителей служб доставки, ресторанов с собственной доставкой и dark kitchen, которые выбирают между коробочным решением, работой через агрегатор и собственной разработкой.
Что такое CRM для доставки еды и почему это не просто «база клиентов»
Обычная CRM решает одну задачу: помнить о клиенте и вести сделку по воронке. Для доставки еды этого мало. Здесь сделка живёт от силы час, а ценность клиента складывается не из одной покупки, а из частоты возвратов. Система управления доставкой еды должна одновременно держать три контура: продажи и клиентскую базу, операционную логистику (кто, куда и когда везёт), и финансовый учёт с фискализацией.
Поэтому под словами «CRM для курьерской доставки еды» на практике почти всегда понимают связку из нескольких блоков, а не одну программу. Есть модуль приёма заказов. Есть кабинет диспетчера. Есть мобильное приложение курьера. Есть касса. И есть аналитика, которая всё это сшивает в понятные цифры. Разрозненные инструменты дают тот же хаос, только в электронном виде. Ценность появляется там, где заказ проходит весь путь внутри одной логики, без ручного переноса данных между окнами.
Ключевая мысль для тех, кто принимает решение: CRM в доставке это не про то, чтобы «хранить телефоны клиентов». Это про то, чтобы клиент возвращался, а каждый заказ обходился дешевле в обработке. Всё остальное вторично.
Как устроен путь заказа внутри системы
Чтобы оценить любую платформу, полезно мысленно провести через неё один заказ. Клиент оформляет его на сайте, в приложении или по звонку. Заказ попадает в единый пул, где к нему привязаны состав, адрес, желаемое время и способ оплаты. Диспетчер (или алгоритм автоназначения) распределяет заказ на курьера с учётом района и загрузки. Курьер видит адрес, маршрут и комментарий («передать через консьержа», «позвонить за 15 минут»), доставляет, принимает оплату и пробивает чек на месте.
Дальше начинается то, ради чего всё и затевалось. Данные о заказе не исчезают. Они ложатся в клиентский профиль, в отчёт по выручке курьера, в статистику по товарам и по времени доставки. Из этих данных потом собираются повторные продажи, программа лояльности и решения о том, где служба теряет время и деньги. Опыт проектов BPA Develop показывает: как только владелец впервые видит эти цифры в разрезе, а не «в среднем по больнице», картина приоритетов у него меняется за один вечер.
Теперь по модулям. Ниже разложено, из чего собирается рабочая CRM для доставки еды, и что каждый блок реально даёт бизнесу.
Из каких модулей состоит CRM для доставки еды
Это точка входа, где формируется весь дальнейший порядок или весь дальнейший беспорядок. Хорошая система собирает заказы из всех источников в один пул: сайт, мобильное приложение, звонки в колл-центр, выгрузки от агрегаторов. Оператор при этом работает в одном окне, где сразу видны состав, адрес, время и комментарий, а не переключается между тремя вкладками и блокнотом.
Здесь же живёт логика распределения. Заказ можно назначить конкретному курьеру, а можно бросить в «свободные», чтобы курьеры одного района сами разобрали ближайшие адреса. На пиках именно скорость распределения определяет, уложится ли служба в обещанное время. По наблюдениям в проектах BPA Develop, переход от ручного назначения в чате к пулу с автораспределением стабильно снимает несколько минут с обработки каждого заказа, а на объёме это часы работы оператора в день.
Кабинет диспетчера это командный пункт. Отсюда видно, кто из курьеров свободен, кто в пути, а кто уже отчитался и готов взять следующую доставку. На карте отображается перемещение курьеров с их статусами, и диспетчер сортирует людей по признаку «доставил» или «оплатил», чтобы понимать, кому отдать новый адрес.
Маршрутизация здесь не роскошь, а прямая экономия. Когда курьеру одновременно приходит несколько адресов, система (или он сам) выстраивает приоритетный маршрут, а не гоняет человека зигзагами по городу. Отдельно важен контроль времени: просроченные заказы подсвечиваются, и диспетчер видит риск опоздания заранее, а не постфактум от недовольного клиента. Именно этот блок чаще всего окупается первым, потому что бьёт по двум самым дорогим статьям: пробегу курьеров и опозданиям, за которые платят скидками и оттоком.
Курьер не работает за компьютером, поэтому вся система для него сводится к приложению в телефоне. В рабочем виде это выглядит так: вкладка «принять в работу», вкладка «доставить», вкладка «отчитаться». Курьер видит время до дедлайна по каждому заказу, может связаться с клиентом или диспетчером в один клик и настроить push-уведомления, чтобы не забыть позвонить за десять минут до адреса.
Важная деталь, которую недооценивают на старте: приложение должно уметь редактировать заказ на месте. Клиент отказался от одной позиции, продукт оказался испорчен, человек передумал. Курьер отмечает это прямо в приложении с указанием причины, и сумма к оплате пересчитывается автоматически. Если такой функции нет, начинаются звонки диспетчеру, ручные пересчёты и расхождения в кассе к концу смены. Мелочь, которая на потоке превращается в ежедневную головную боль.
Это тот блок, который в российской доставке нельзя вынести за скобки. По 54-ФЗ приём оплаты у клиента требует пробития чека на месте, и для доставки это означает, что курьер возит с собой фискальный регистратор или работает на кассовом терминале со встроенным приложением. Отдельная позиция в чеке, корректная работа платёжного агента, чек на услугу доставки, если она платная: всё это система должна закрывать без ручных костылей.
Соблазн «принимать только по предоплате и не связываться с кассами» выглядит рационально ровно до первого подсчёта. Часть аудитории по-прежнему предпочитает платить при получении, в том числе картой курьеру. По данным опроса Яндекс.Маркета и GfK середины 2010-х, значительная доля покупателей выбирала оплату наличными или картой уже на руках у курьера, и полный переход на предоплату отсекал этих людей. Цифры с тех пор менялись, но принцип остался: чем меньше способов оплаты вы даёте, тем больше клиентов уходит туда, где им удобнее. Плюс несоблюдение кассовой дисциплины это прямые штрафы и риск приостановки деятельности, а не абстрактная угроза.
Здесь и прячется главная экономика доставки еды. Первый заказ клиента почти всегда убыточен или околонулевой: реклама, скидка новичку, стоимость привлечения. Прибыль начинается со второго, третьего, десятого заказа. Значит, задача системы не столько «продать», сколько «вернуть». Для этого нужна нормальная база с историей заказов, средним чеком и частотой покупок по каждому клиенту.
На этих данных строится сегментация и лояльность. Идентификация клиента по номеру телефона при звонке, бонусы, персональные предложения тем, кто давно не заказывал, реактивация «спящих». Разница между службой, которая просто отдаёт еду, и службой, которая системно работает с удержанием, видна в показателе повторных заказов и в LTV (совокупной выручке с одного клиента за всё время). В проектах BPA Develop именно недоинвестированный блок лояльности чаще всего оказывается самым дешёвым источником роста выручки, потому что вернуть своего клиента в разы дешевле, чем купить нового.
Служба доставки почти никогда не живёт в одной программе. Есть сайт и приложение для заказов, есть агрегаторы, есть учётная система и бухгалтерия. CRM для доставки еды ценна ровно настолько, насколько бесшовно она связывает эти источники. Открытый API и готовые модули интеграции (например, с 1С или с CMS сайта) определяют, будет ли заказ автоматически падать в общий пул или его придётся переносить руками.
Отдельная боль это агрегаторы. Они дают поток, но забирают заметную часть маржи: по рынку комиссия обычно оценивается в диапазоне 20–35% с заказа, а иногда и выше. Здоровая стратегия обычно гибридная: агрегаторы как канал привлечения, собственная доставка и своя база как канал удержания и прибыли. Чтобы такую стратегию вообще можно было вести, заказы из всех каналов должны сходиться в одной системе, иначе вы не видите реальную юнит-экономику по каждому источнику.
Финальный модуль, который превращает всю операционку в управленческие решения. Отчёты по выручке в целом и по каждому курьеру, статистика по товарам, по времени доставки, по районам, по способам оплаты. Без этого руководитель управляет службой на ощупь и узнаёт о проблеме тогда, когда она уже стоила денег.
Ценность аналитики не в количестве графиков, а в том, отвечает ли она на конкретные вопросы бизнеса. Какие блюда тянут средний чек вниз. В каких районах доставка систематически опаздывает. Какие курьеры дают брак и возвраты. Какая доля выручки приходит от повторных клиентов. Хорошая система даёт эти ответы за несколько кликов, а не за неделю выгрузок в Excel. Именно поэтому аналитику стоит закладывать в требования сразу, а не «когда-нибудь потом».
Что изменилось к 2026 году
Рынок доставки еды за последние годы сильно повзрослел, и требования к системам сместились. Три сдвига стоит держать в голове при выборе.
Первое: борьба идёт не за первый заказ, а за удержание. Стоимость привлечения выросла, органика подорожала, и выигрывает тот, кто умеет возвращать клиента. Поэтому блоки лояльности и работы с базой из «приятного дополнения» превратились в ядро.
Второе: формат dark kitchen и dark store перестал быть экзотикой. Кухни без зала, заточенные под доставку, предъявляют к системе свои требования: несколько виртуальных брендов на одной кухне, быстрая передача заказа на производство, жёсткий контроль времени сборки. Универсальные коробки под это часто не заточены.
Третье: зависимость от агрегаторов стала осознанным риском. Проекты, которые полностью сидят на чужом трафике, отдают маржу и не владеют своей клиентской базой. Отсюда встречный тренд на собственные каналы заказа и на системы, которые дают контроль над данными о клиентах. Это, к слову, одна из причин, почему тема собственной разработки снова стала актуальной.
Типичные ошибки при выборе CRM для доставки еды
Классика: руководитель сравнивает системы по таблице возможностей и берёт ту, где галочек больше. Через месяц выясняется, что половина функций не используется, а той единственной, что нужна именно этой службе (например, работа нескольких брендов на одной кухне), как раз и нет. Функции без привязки к вашему реальному потоку заказов это балласт, за который вы платите. Правильный вход в выбор это описанный процесс: как заказ приходит, кто его трогает, где теряется время. И только потом сопоставление с системой.
Соблазн отложить вопрос касс и оплаты «на потом» велик, потому что это скучная и дорогая часть. Итог предсказуем: система выбрана, внедрена, а на этапе запуска оказывается, что она не умеет корректно работать с онлайн-кассой у курьера или с несколькими способами оплаты. Переделка на этом этапе стоит и денег, и сорванных сроков. 54-ФЗ это не та область, где можно импровизировать, и требования к фискализации нужно закладывать в первый же список критериев, а не докручивать после запуска.
Обычная CRM отлично ведёт длинные сделки, но захлёбывается на потоке коротких заказов с жёстким таймингом и логистикой. Попытка приспособить её под доставку заканчивается кучей самописных доработок, которые ломаются при каждом обновлении. По опыту BPA Develop, такие «франкенштейны» обходятся в итоге дороже, чем сразу взятое профильное решение, потому что вы платите не за лицензию, а за бесконечную поддержку костылей. Инструмент должен соответствовать характеру задачи, а доставка это в первую очередь логистика, а не воронка.
Отдельная система для сайта, отдельная для агрегаторов, отдельная для учёта, а между ними живой человек, который переносит заказы руками. Это не автоматизация, это её имитация. Каждый ручной перенос это точка ошибки и потерянные минуты, а на пике именно они превращаются в опоздания и жалобы. Если система не связывается с вашими ключевыми источниками заказов через API или готовые модули, её ценность резко падает, каким бы красивым ни был интерфейс.
Их часто откладывают как «второй этап», потому что на старте важнее «просто чтобы заказы доезжали». Логика понятна, но именно в аналитике и удержании прячется прибыль. Служба без этих блоков управляется вслепую и живёт от одного нового клиента к другому, теряя старых. Возврат клиента почти всегда в разы дешевле привлечения нового, и отказ от работы с базой это не экономия, а недополученная выручка каждый месяц.
Коробка, агрегатор или своя разработка: сравнение подходов
Перед тем как переходить к внедрению, полезно честно сравнить три пути. У каждого своя логика и свои риски.
| Критерий | Коробочное решение | Работа через агрегатор | Индивидуальная разработка |
|---|---|---|---|
| Скорость запуска | Быстро, недели | Очень быстро, но чужие правила | Медленнее, месяцы |
| Гибкость под процесс | Ограничена рамками продукта | Практически нулевая | Полная, под ваш поток |
| Владение клиентской базой | Частичное | Базы фактически нет | Полное |
| Маржа с заказа | Своя, минус лицензии | Минус комиссия 20–35% | Своя, максимальная вдолгую |
| Риск | Упереться в потолок функций | Зависимость от площадки | Выше на старте, ниже вдолгую |
| Результат через год | Работает, но тесно | Поток есть, прибыли меньше | Актив, который растёт с бизнесом |
Вывод из таблицы не в том, что один путь «правильный», а остальные «плохие». Малому проекту на старте коробка или агрегатор часто разумнее: быстро, дёшево на входе, без больших вложений. Но по мере роста ограничения начинают стоить всё дороже, и вопрос собственного решения встаёт не из-за амбиций, а из-за экономики.
Что это значит для бизнеса
Если перевести всё вышесказанное на язык денег и решений, получается три простых тезиса. Скорость обработки и маршрутизация напрямую бьют по себестоимости заказа: меньше пробег, меньше опозданий, меньше нагрузка на диспетчера. Работа с базой и лояльностью бьёт по выручке: тот же клиент приносит больше за счёт повторных заказов. Аналитика бьёт по управляемости: решения принимаются по цифрам, а не по интуиции самого опытного сотрудника, который однажды уволится и унесёт всё «в голове» с собой.
Сколько это стоит и когда окупается
Точная цифра зависит от масштаба, каналов и того, что уже автоматизировано, поэтому корректнее говорить диапазонами. Коробочные решения обычно продаются по лицензиям на приложение курьера и на кабинет диспетчера, и на небольшую службу вход измеряется десятками тысяч рублей в год. Индивидуальная разработка это принципиально другой порядок вложений на старте, зато без комиссий и без потолка по функциям.
Окупаемость считается не по стоимости системы, а по тому, что она возвращает: сокращённый пробег курьеров, снятая нагрузка с операторов, выросшая доля повторных заказов, отсутствие штрафов по кассам. В проектах, где до внедрения служба теряла заказы на ручном распределении и почти не работала с удержанием, эффект от системной автоматизации становится заметен в горизонте нескольких месяцев. Но честная оговорка: если объём заказов небольшой и процесс в целом справляется, тяжёлая автоматизация может и не окупиться, и это нормальный ответ.
Что проконтролировать при выборе и внедрении
Для руководителя, который не будет настраивать систему сам, а будет контролировать команду или подрядчика, полезен короткий набор проверочных вопросов и метрик.
Вопросы к подрядчику или продукту стоит задавать такие: как система работает с 54-ФЗ и онлайн-кассами у курьера; с какими источниками заказов она интегрируется из коробки, а что придётся дорабатывать; кому принадлежит клиентская база и можно ли её выгрузить; что происходит при росте в несколько раз по объёму.
Метрики, которые стоит держать на дашборде после запуска: среднее время доставки и доля опозданий, доля повторных заказов и LTV, себестоимость обработки одного заказа, расхождения в кассе по сменам.
Красные флаги: подрядчик обещает «сделаем всё что угодно» без уточняющих вопросов о вашем процессе, нет ответа про фискализацию, нет внятного плана по интеграциям.
Цена бездействия
Оставить всё как есть тоже стоит денег, просто эти потери не попадают в отчёт отдельной строкой. Каждый месяц на ручном распределении это заказы, ушедшие не туда, и клиенты, которые не вернулись. Каждый месяц без работы с базой это упущенные повторные продажи, которые достаются тем, кто эту работу ведёт. Статус-кво выглядит бесплатным ровно потому, что его цену никто не считает.
Преимущества индивидуальной разработки CRM для доставки еды
Коробочные решения хороши скоростью старта, но их логика написана под усреднённую службу доставки. Как только у проекта появляется своя специфика (несколько брендов на одной кухне, нестандартная логистика, собственное приложение, особая программа лояльности), начинается борьба с рамками чужого продукта. Индивидуальная разработка снимает эту борьбу, и вот в чём её сильные стороны для растущего бизнеса.
Первое: система строится под ваш процесс, а не процесс подгоняется под систему. Это значит, что операторы и курьеры работают так, как удобно именно вашей службе, без обходных путей и ручных костылей. Экономия здесь не разовая, она накапливается на каждом заказе каждый день.
Второе: полное владение данными и клиентской базой. Вы не арендуете свою же аудиторию у площадки и не рискуете потерять её при смене условий агрегатора. База это актив, и в собственном решении он остаётся вашим, со всей историей, сегментацией и возможностью строить лояльность так, как вы считаете нужным.
Третье: интеграции без ограничений. Своя разработка связывается с сайтом, приложением, учётной системой, кассами и любыми внешними сервисами ровно так, как нужно вашему бизнесу, а не так, как позволил вендор коробки. Заказы из всех каналов сходятся в одной логике, и вы видите реальную юнит-экономику по каждому источнику.
Четвёртое: масштабируемость. Коробка рано или поздно упирается в потолок, и переход на новое решение на большом объёме это болезненный проект. Собственная система растёт вместе с бизнесом: новые бренды, новые города, новые каналы добавляются как развитие, а не как переезд с нуля. В горизонте нескольких лет это часто оказывается дешевле, чем цепочка миграций между чужими продуктами.
Пятое: система становится частью актива компании, а не строкой расходов на подписку. При продаже бизнеса, привлечении инвестиций или выходе в новые регионы собственная технологическая база работает в плюс. Это уже не «программа для курьеров», а инфраструктура, на которой стоит вся операционка.
Разумная оговорка: индивидуальная разработка оправдана не всем и не всегда. Небольшому проекту на старте она чаще всего избыточна, и здесь честнее коробка. Смысл в своей системе появляется тогда, когда ограничения готовых решений начинают стоить дороже, чем разработка, а специфика процесса уже не влезает в стандартные рамки. BPA Develop подходит к этому именно так: сначала разбор процесса и экономики, а решение о разработке только там, где оно действительно окупается.
Частые вопросы
Итог
CRM для доставки еды окупается не там, где красивый интерфейс, а там, где заказ проходит весь путь в одной логике: приём, распределение, доставка, оплата по 54-ФЗ, возврат клиента и аналитика. Малому проекту на старте разумнее коробка или агрегатор. Растущему бизнесу со своей спецификой чужие рамки рано или поздно начинают стоить дороже собственного решения, и тогда вопрос индивидуальной разработки это вопрос экономики, а не амбиций.
Если вы на этой развилке, начать стоит не с выбора программы, а с разбора своего процесса и цифр. BPA Develop проектирует и разрабатывает системы для доставки под конкретный бизнес: от разбора юнит-экономики до готового решения, которое остаётся вашим активом. Обсудить вашу задачу можно через форму на сайте.
