«Доставка еды» - знакомо звучит, не так ли? С заказом и доставкой блюд сталкиваются практически все. У каждого большого магазина есть свои курьеры и интернет-магазин, взять например большой кейс MYBOX , о котором мы рассказывали ранее.
Так зачем же нужен еще один?
Особенность в том, что проект “Вкусно и быстро” направлен не на большие сети, а на локальные столовые, у которых может не быть ни курьеров, ни сайтов. Такие столовые продают обеды по доступной цене и найти их можно по всей Москве.
Работает это так: есть определенный набор обедов на день, все столовые могут их приготовить. При заказе обеда пользователем выбирается ближайшая доступная столовая. Заказ можно забрать самому, а можно получить курьером.
Поскольку огромному числу людей хочется обедать “вкусно и быстро” каждый день, авторы идеи рассчитывали на успех.
У ИНТЕРВОЛГИ есть опыт запуска подобных сервисов, и мы с удовольствием взялись за дело.
Дальше много подробностей, интриг, боли отладки и удивительных маркетинговых идей.
Итак...что же может понадобиться для работы сервиса доставки обедов?
Хоть основной принцип у таких сервисов похож, но нюансы всегда различаются. Иногда настолько, что за одинаковым “фасадом” сайтов может скрываться как тиражное решение, так и сложная система, на которую потрачено много времени и сил. Расскажем, что получилось в нашем случае.
Выбор адреса, расчет доставки
Как это должно работать
Город делится на зоны. На первоначальном этапе зона = район города. Столовая выбирает, в какие зоны она доставляет.
Пользователь заходит на сайт и пытается что-то положить в корзину или оформить заказ. Система спрашивает способ доставки: курьером или самовывоз, и если это курьер — спрашивает адрес доставки. По адресу определяется зона, выводится список столовых, обслуживающих эту зону. Пользователь может не выбирать столовую, тогда заказ выполнит случайная из списка.
Стоимость доставки входит в стоимость блюда, если выбрана доставка курьером. То есть при смене способа доставки пользователь должен видеть разные цены на сайте.
Здесь на помощь как всегда приходят Яндекс.Карты. О подобном кейсе уже было рассказано в статье Геозависимость доставки
Что мы использовали
Показ карты с зонами и ввод адреса — через API Яндекса.
Хранение городов и зон — highload-блоки, ресторанов — инфоблок.
Многоугольники, описывающие районы — взяты в свободном доступе и импортированы в highload-блок зон.
Разные цены — через стандартные для 1С-Битрикс типы цен с авторасчетом и ограничения на группы пользователей.
Нюансы и особенности
Как работает выбор доставки:
- Показываем попап с картой с зонами и ресторанами, и полем для ввода адреса. Нюанс: раскрашивать зоны в зависимости от активности ресторанов.
- Пользователь начинает вводить адрес. Нюанс: он может выбрать адрес кликом на карте.
- Сайт подсказывает ему варианты адресов, исходя из подсказок Яндекса. Нюанс: не показывать лишние объекты вроде сел, трасс и пр.
- Пользователь выбирает адрес. Нюанс: если ничего не выбрано, должен подставиться первый адрес. Адрес обязателен.
- По адресу определяем координаты через геокодер Яндекса. Ставим точку на карте.
- По координатам определяем зону. Нюанс: попадание точки в область считается яндекс.картами.
- Находим столовые, доставляющие в эту зону. Если столовых нет, показываем ошибку и не даем сохранить адрес. Нюанс: скрываем неподходящие столовые на карте.
- Пользователь выбирает столовую или вариант “любой”, сохраняет адрес. Нюанс: автоматически обновляются цены товаров на странице, если изменился способ доставки.
Что получилось
Блок доставки в шапке.
Адрес не выбран.
Адрес выбран.
Оплата онлайн
Сейчас практически у всех есть банковские карты или другие виды электронных денег, поэтому сервис рассчитан только на онлайн-предоплату.
Нюанс в том, что заказ выполняет не сам сервис, а столовая. Поэтому необходимо было разделить онлайн-оплату, чтобы определенный процент шел на счет Вкусно и быстро, а часть — на счет столовой.
Был выбран сервис Робокассы, которая как раз в то время собиралась вводить API для разделения оплат. Мы были одними из первых, кто решил им воспользоваться. Минус этого — документации практически не было и в итоге рабочее API пришлось выуживать напрямую у техподдержки.
Как это должно работать
Пользователь нажимает кнопку Оплатить, попадает в Робокассу, видит полную сумму заказа. При проведении оплаты часть денег переходит ВБ, часть — ресторану. На сайте заказ получает флаг Оплачен, ресторан получает информацию о заказе.
Что мы использовали
Платежные настройки задаются в административной части на специально созданной странице. В ней указываются проценты, логин ВБ и т.д.
В форму оплаты робокассы добавилось новое поле Split с частями оплаты.
Был написан свой обработчик приема информации из Робокассы.
Нюансы и особенности
Части оплаты проводятся не одновременно. То есть нужно ждать, пока Робокасса вернет положительный ответ о проведении всех частей оплаты, и только после этого ставить флаг Оплачено в заказе. В худшем случае это может занять несколько минут.
Для отслеживания оплат была добавлена orm-таблица со списком сплитов.
В качестве косметической меры ввели промежуточный статус, в который заказ переводится при переходе пользователя на Робокассу. Этот статус нужен, чтобы после оплаты в личном кабинете было видно, что оплата обрабатывается. Иначе в заказе был статус Не оплачен, пока Робокасса не вернет все успешные оплаты. Это нервировало пользователей.
Электронные чеки
Сервис мы запускали, когда ФЗ-54 вступил в силу.
Поэтому нужно было срочно добавлять взаимодействие с онлайн-кассами и выдачу электронных чеков.
К счастью, Битрикс в 17 версии добавил взаимодействие с несколькими сервисами касс “из коробки”, в нашем случае это был Атолл.
Правда, из-за нашего специфического разделения оплат нужно было выдавать два чека, один из которых на реальный заказ, второй — за использование сервиса ВБ.
Поэтому не обошлось без кастомизации модуля, отвечающего за взаимодействие с кассой. И снова мы почувствовали всю прелесть тестирования полусырого сервиса)
Зато сейчас пользователь получает свои чеки и все формальности соблюдены.
Промоакции
Как и любому новому сервису, ВБ нужно рекламировать себя.
Для этого заказчиком было придумано много разноплановых промоакций, техническая реализация которых легла на нас.
Практически все настройки были вынесены в административную часть сайта. Это позволяет заказчику самостоятельно изменять условия акций, либо создавать новые.
Перемещения и начисления баллов логируются, при несоответствии письмо с ошибкой отправляется на почту администратору.
Балльная система реализована через стандартный внутренний счет пользователя 1С-Битрикс, купоны и скидки — также с помощью Битрикса, насколько это возможно.
Программа лояльности
Промокоды: Каждый пользователь и каждый ресторан имеют свой уникальный промокод, которым они могут поделиться через ссылку или непосредственно номер промокода.
Если по вашему коду пришли, вы получаете баллами % от оплаченных заказов приглашенного вами пользователя.
Начисление баллов: за ввод определенного промокода, регистрацию и некоторые другие действия пользователь может получить баллы на свой личный счет. Баллы могут быть фиксированные или процент от суммы заказа; только на первый заказ или любой; если пользователь ввел промокод или нет. Можно настраивать разное количество баллов на разные шаблоны промокодов.
Скидки и баллы за активность: в зависимости от настроек можно получить баллы или скидку, если вы уже заказывали обед в течение недели или делаете предзаказ хотя бы за час.
Купоны на скидку: можно выдать одноразовый купон на определенную скидку на заказ. Купоны являются стандартным механизмом битрикса.
Система для промоутеров
Промоутеры - это люди, которые раздают листовки на улицах. У промоутеров есть супервайзер, который координирует их работу.
Специальные группы для пользователей-промоутеров: сделана возможность создавать группы со своими префиксами для промокодов.
Кроме того, нужно отслеживать, в какой зоне находился человек, когда он регистрировался на сайте по промокоду Это потребовалось, чтобы отслеживать работы промоутеров на точках.
Для нескольких промогрупп были созданы отдельные страницы регистрации
Генерация уникальных промокупонов: заказчику нужно было напечатать листовки с уникальными одноразовыми промокодами, которые мог понимать сайт. Причем все эти промокупоны должны привязываться через программу лояльности к одному основному промоутеру.
Для этого была сделана форма генерации промокупонов по шаблону и таблица, в которой промокупоны сохранялись и отмечались при использовании.
За ввод промокупона тоже начисляются баллы.
Личный кабинет промоутера и супервайзера: промоутеры и супервайзеры должны видеть, сколько пользователей пришло по их промокодам, и иметь возможность отметить, получили ли они деньги за свою работу.
Лендинги акций
На сайте был добавлен отдельный раздел с посадочными страницами акций.
Первый экран каждой акции имеет свой текст и картинку, блоки ниже одинаковые. Общие блоки можно включать и выключать для конкретного лендинга. Таким образом, получился простой конструктор лендингов.
Каждой акции соответствует свой промокод.
Особенность этих промокодов в том, что они позволяют заказать N обедов бесплатно или за определенную сумму. Причем это N может быть растянуто на несколько заказов, а также пользователь может сам решить, использовать эту скидку в данном конкретном заказе или нет.
Например акция - 5 обедов по 111 рублей.
В корзине это выглядит так
Личный кабинет ресторана
Поскольку наш сервис агрегатный, то для столовых в нем должна быть возможность зарегистрироваться, заполнить и изменить свои данные, выбрать зоны и обеды на день. Добавление и изменение данных должно проходить модерацию у администраторов магазина.
Из интересного можно отметить график работы, от которого зависит возможность покупать обеды и время заказа
И собственно выбор меню на день.
На очередной итерации доработок заказчиком была придумана схема, где ресторан составляет расписание на цикл из шести недель. Этот цикл накладывается на календарный месяц так, чтобы 1ое число приходилось на первую неделю.
Поскольку изначально обеды привязывались к конкретным датам, то решено было оставить две возможности привязки — к дню цикла и к конкретному числу.
Для напоминания была добавлена автоматическая рассылка ресторанам о том, что у них не выбрано меню на следующий день.
Статистика и бухгалтерия
После начала реальной работы сайта выяснилось, что заказчику нужны различного вида отчеты, в основном для проведения сумм в бухгалтерии.
Для этого появился кабинет модератора — он позволяет просматривать выборки различных данных, фильтровать и сортировать их, получать таблицу себе на почту.
Также можно загружать на сайт таблицы с результатами операций, которые проводились вне сайта, но влияют на его работу.
Что там можно увидеть:
- список заявок ресторанов на перевод баллов, полученных из лояльности или за участие в промоакциях, в реальные рубли (результат выполнения заявки можно потом загрузить на сайт);
- сводка оплат заказов баллами;
- отчет по зонам - где есть активные рестораны, а где нет на 4 следующих дня;
- сводка регистраций пользователей по промокодам;
Мобильное приложение
Битрикс позволяет создавать мобильные приложения с помощью модуля “Мобильная платформа”. По сути Битрикс предоставляет усеченный браузер, который открывает только ваш сайт. Есть специальная тестовая платформа, где вы можете проверять свое приложение в процессе разработки.
Для сайта это означает отдельный шаблон и публичку сайта, а также отдельное мобильное меню. Чтобы навигация работала корректно, все прямые ссылки должны быть заменены на соответствующий вызов js-функции, которая получает контент новой страницы.
Плюс такого подхода — если у вас адаптивный сайт, то можно сказать, что полдела сделано, осталось только правильно скопировать публичку и добавить меню. Никаких времени и денег на мобильных разработчиков… В идеале. Но нюансы есть везде — например открытие сайта платежной системы, которое должно происходить в приложении, и возвращение из этой платежной системы. Опять-таки придется менять все ссылки, в том числе в контенте. Конечно, мы делаем это автоматически, но забывать об этом не стоит.
И главный минус — скорость работы. Теперь ко времени работы вашего сайта прибавляется время открытия браузера-обертки. На сайте сложнее простого набора контентных страниц это очень заметно.
Для этого проекта мы сделали мобильное приложение и оно работает. Но по итогам сделали вывод: если нужно действительно быстрое и удобное для пользователя решение - стандартная Мобильная платформа не подойдет.
Нужно делать нативное приложение и использовать возможности устройства.
В статье приведены только самые значимые и интересные подробности проекта. Конечно, поработать пришлось еще над многим - дизайн, адаптивная версия, каталог со списком и детальной, личный кабинет пользователя, корзина и оформление заказа с возможностью отдельно заказывать на сегодня и завтра, письма и т.д.
