Что значит «доставка внутри своего приложения»
С самого начала проекта доставка была заложена как основной способ получения заказа, и технически — через Яндекс. Это не означает, что пользователь оформляет два заказа или переходит в стороннее приложение. Весь путь — выбор блюд, расчёт стоимости доставки, оформление, оплата, отслеживание статуса — происходит в интерфейсе приложения сети. Запрос цены у Яндекса, создание доставки — это происходит на стороне бэкенда платформы, пользователь с сервисом доставки напрямую не взаимодействует.
Расчёт и фиксация стоимости до оформления заказа
Технически интеграция построена на обсчёте стоимости доставки до того, как пользователь завершил оформление. Яндекс предоставляет тариф с ограниченным сроком действия — по договорённости с сервисом это конкретное окно, в течение которого зафиксированная стоимость доставки не меняется. Платформа запрашивает и фиксирует этот тариф, и дальше, пока действует окно, пользователь может продолжать донастраивать заказ — добавлять модификаторы, увеличивать количество позиций, — а стоимость доставки, которая уже была рассчитана и зафиксирована, не пересчитывается заново.
Данные о том, где находится курьер, на каком он этапе маршрута, приходят от Яндекса и транслируются в приложение в виде понятных пользователю статусов — заказ готовится, курьер в пути, курьер прибыл. Сама логистика — маршрутизация, назначение конкретного курьера — остаётся полностью на стороне сервиса доставки; платформа сети эти данные только получает и показывает.
Как платформа определяет, кто обслуживает заказ
Прежде чем обратиться к Яндексу за расчётом доставки, платформе нужно понять, какой конкретно ресторан сети обслуживает адрес пользователя. Это определяется по зонам доставки, привязанным к каждому ресторану: адрес попадает в одну зону — заказ автоматически уходит в соответствующий ресторан; зоны нескольких ресторанов пересекаются — пользователю предлагается выбрать точку самому. Это тот же механизм, что используется и для самовывоза: платформа либо предлагает список точек и карту, либо предлагает адрес и автоматически подбирает ближайший подходящий ресторан.
Гибкость архитектуры под разные способы доставки
Интеграция с Яндексом — не единственный сценарий, который заложен в архитектуру. Один из франчайзи сети организовал доставку собственными силами, без привлечения агрегатора, — и держит долю онлайн-продаж в 30–40%, заметно выше среднего по сети. Архитектура рассчитана на то, чтобы подключать разные варианты доставки, включая собственных курьеров конкретного франчайзи, не переписывая логику заказа с нуля под каждый новый вариант. Рассматривается и подключение роботизированной доставки — тот же Яндекс на уровне интеграции почти не будет отличаться от текущей модели, разница в том, что маршрут вместо курьера-человека будет выполнять робот; это вопрос готовности решения со стороны самого Яндекса, а не архитектуры платформы.
На что обратить внимание при похожей интеграции
Из практики этого проекта стоит явно закладывать несколько вещей заранее, а не добавлять их постфактум:
- Окно фиксации тарифа — ограничение самого агрегатора, а не то, что можно продлить на своей стороне; интерфейс должен явно показывать пользователю, сколько времени у него есть на донастройку заказа по зафиксированной цене.
- Пересекающиеся зоны доставки — не редкий случай, а закономерное следствие роста сети; логику выбора ресторана при пересечении зон стоит проектировать сразу, а не по факту первой жалобы пользователя.
- Архитектура заказа не должна знать о конкретном агрегаторе жёстко — если на одном из этапов роста сети понадобится подключить второго партнёра по доставке или собственных курьеров конкретного франчайзи, замена или добавление варианта не должны требовать переписывания логики оформления заказа.
