Особенности интеграции мобильного приложения по заказу доставки еды с iiko, R-Keeper и 1С
В этой статье мы осветим большой блок интеграции мобильных приложений по заказу доставки еды с внутренними учетными системами заказчиков - сетями кафе и ресторанов от 3 точек. На самом деле, не все с самого начала обращают внимание на этот аспект, и интеграция упускается из виду, а зря.
Почему это важно?
Возможно, пока компания маленькая, вопрос интеграции вас не будет сильно волновать. На этом этапе вы можете получать заказы на электронную почту или мессенджер, и обрабатывает их не оператор в колл-центре, а администратор заведения.
Но как только сеть кафе или ресторанов начинает расти, очень важно, чтобы все элементы системы работали как единое целое. И мобильное приложение, как одна из составляющих экосистемы привлечения клиентов, также должно быть интегрировано со всеми внутренними элементами.
Казалось бы, надо всего-то, чтобы заказы уходили в нужное место и меню обновлялось. На самом деле, это только верхушка айсберга.
С чем возможна интеграция?
В общепите 2 выделенных лидера - это системы iiko и R-Keeper. Намного реже клиенты пользуются 1С или СБИС.
Есть еще различные уникальные системы, однако встречаются крайне редко. Поэтому важно рассмотреть особенности интеграции именно с первыми двумя системами.
Что входит в объемный блок интеграции:
- В первую очередь, автоматическое отправление заказов сразу во внутреннюю систему, а не на почту, чтобы оператору не приходилось перезабивать их руками - экономия трудозатрат.
- Меню, или каталог товаров, должно автоматически подтягиваться из общей системы с правильными ценами.
- Стоп-лист также должен подтягиваться автоматически вместе с меню, чтобы потребитель ненароком не заказал позицию из стопа.
- Бонусная система - начисление и списание бонусов на совершенные заказы.
- Акции, промокоды, скидки должны корректно срабатывать на нужные категории товаров.Статус заказа должен отображаться в режиме реального времени, чтобы гость мог отследить, едет ли уже к нему заказ или еще готовится.
- Мелкие детали, которые все же влияют на покупательскую активность и лояльность - интернет-банкинг, СМС-оповещения, время доставки, граммовка, КБЖУ, аллергены и прочее.
Возможно, дочитав до этого момента и представив объем работ, вы подумаете: “Да может и не нужно мне это все? Есть же колл-центр, пусть операторы принимают заказы. Зато сэкономлю на разработке”. В качестве примера мы приведем вам кейс одной компании - какую выгоду им удалось получить благодаря мобильному приложению.
Некая компания “Х” готовит и доставляет еду. Имеет несколько ресторанов в разных районах города.Количество заказов в день: 200-300.
Было:
Сайт - заказ - оператор - кухня. 4 оператора в штате, затраты (зарплата, налоги, прочие отчисления; содержание рабочего места): примерно 200 000 руб./мес.
Стало:
Приложение - заказ - кухня. 2 оператора в штате, затраты (зарплата, налоги, прочие отчисления; содержание рабочего места): примерно 100 000 руб./мес.
Итого экономия: 100 000 руб./мес. или 1 200 000 руб./год.
И это только на оформлении заказов!
Внедрили приложение по сбору заказов:
- Заказы отправляются сразу на производство. Операторы - на экстренный случай.
- При этом на кухню того или иного ресторана они распределяются автоматически по территориальному признаку, в зависимости от адреса доставки.
- Гость теперь может оформить предзаказ на доставку и самовывоз к определенному времени.
- На каждый тип заказа (доставка, самовывоз) отображается свое меню.
Итак, какие нюансы следует учесть, если планируете разрабатывать приложение самостоятельно или отдать новичкам?
- Плохое качество документации самих внутренних систем. Мы неоднократно встречали случаи, когда какой-то параметр не был описан в документации и приходилось его искать методом научного тыка.
- Разные конфигурации сервера. У iiko есть общий сервер, и все подключение идет к нему. Плюсы этого в том, что при переносе исходного кода на другой проект, он почти всегда запускается без особых проблем, чего не скажешь о нашем опыте общения с R-Keeper. Там сервер как правило стоит непосредственно внутри организации и каждая система как новая.
- Связь не всегда устойчивая. К примеру, iiko.biz иногда становится недоступен. В этом случае делается несколько попыток отправить заказ в ресторан. Если это не удается, используется резервный канал - отправки заказа e-mail. Тут важно и с заказчиком проговорить, что такие ситуации возможны, чтобы они выполняли отдельный процесс обработки таких заказов.
- Ввод адреса доставки. У систем есть свой классификатор улиц и домов, и, если передавать название улицы, не совпадающее по названию (к примеру улица К.Маркса или Карла Маркса и множество прочих написаний), то заказ попадает в ошибку и не идет на производство. Наше решение: мы создали у себя дублирующий справочник улиц и предлагаем пользователю выбирать адрес исходя из этого списка.
- Распределение заказов по географическому принципу. Каждый заказ автоматически уходит на кухню того ресторана, который находится ближе всего к адресу доставки, а для отдаленных районов будет больше стоимость доставки или минимальный чек заказа.
- Проверка онлайн-оплаты заказа. Это относится к заказам с онлайн-оплатой. Если платеж не прошел, система не отправляет заказ на производство. Гостю приходит оповещение с просьбой предварительной оплаты заказа, и только оплаты заказ уходит на кухню.
- Разные пути адресации заказов. В зависимости от пожеланий заказчика заказы можно отправлять как на колл-центр для ручной обработки и перезвона клиенту, так и напрямую на производство.
Здесь возникает нюанс: если заказ ушел сразу на производство и его начали готовить, а гость передумал или ошибся? Наше решение: создавать “черные” и “белые” списки пользователей.
Если у пользователя есть один удачный заказ - он попадает в “белый” список и заказ идет сразу на производство.
Если клиент чем-то не подходит - то его размещаем в “черный” список и заказ он может осуществить только по полной предоплате картой (смотри пункт 4).
- Внутренняя переадресация заказов. В каждом ресторане периодически случаются ЧП, при которых приготовление еды или доставка становится невозможным (отключили воду или электричество, нет курьеров и др.). В этом случае конкретному ресторану мы добавили возможность отключения самовывоза заказа, а заказы доставки переключать на отправку в колл-центр, чтобы они вручную переадресовывали их в другие рестораны сети.
- Время доставки. Один из важных параметров оформления предзаказа: гость может оформить предзаказ на доставку или самовывоз на любое желаемое время. Например, с вечера можно оформить предзаказ блюда на завтрак. А ужин запланировать днем, чтобы избежать долгого ожидания доставки в часы высокой загрузки.
- Статусы доставки. При нормальной интеграции клиент еще получает информацию и о том, в каком состоянии находится сейчас его заказ: передан на кухню, собран, передан курьеру. И приложение дополняет эту функцию push-уведомлением пользователю.
В ближайшем будущем еще будем реализовывать показ местонахождения курьера на карте, но об этом в другой статье.
- Разное меню. Нередко случается, что на доставку, на самовывоз и на заказ в зале у ресторана разные меню. Важно реализовать интеграцию так, чтобы пользователь не заказал случайно то, что не отправляется на доставку. Для этого мы сделали специальную надстройку: прямо из учетной системы можно задавать параметры для блюд, какие доступны на самовывоз, на доставку или другие способы подачи.
- Скидки на самовывоз. У многих ресторанов есть распространенная практика - предоставлять скидку на самовывоз заказа, чтобы не тратиться на курьеров. В большинстве случаев, скидки распространяются не на все позиции (например, не действует на комбо-наборы и акционные позиции). Доработали так, чтобы и эти категории можно было указывать напрямую из учетной системы.
- Размер порции. Например, в iiko размер блюда указан как “Порция”, так как это важно для других процессов. А потребителю при заказе еды важно знать вес блюда в граммах. Добавили еще одну надстройку для указания размера в граммах или миллилитрах.
- Типы оплат и типы доставки. Сейчас потребителю на выбор предоставляется, как правило, 3-4 типа оплаты заказа (курьеру наличными или картой и онлайн картой, плюс иногда Apple Pay или оплата с привязкой карты). А также - 2-3 способа доставки (доставка, самовывоз, доставка до подъезда, заказ из зала ресторана и др.). Все эти особенности также важно создать в iiko, чтобы шел правильный учет заказов.
- Сдача с купюры. Вытекает из предыдущего пункта. При оплате наличными, для удобства и быстроты расчетов клиент может указать, с какой купюры нужна сдача. Эти данные передаются в ресторан, и курьер выезжает с необходимым количеством денежных средств для сдачи.
- Количество персон. Еще один параметр, который важно выводить в корзине, чтобы данные попадали в iiko. Например, для статистического учета.
- Точные данные для курьера. Как правило, сейчас никто не ограничивается улицей, домом и квартирой. При оформлении заказа гостю нужно еще указать номер подъезда, этаж, наличие домофона или код от него для удобства курьера.
Мы считаем, что в ходе своей работы собрали много подводных камней, которые превратили в достаточно большой пул ценного опыта. Мы с радостью делимся своим опытом с читателями и думаем, что этот материал будет полезен как собственникам бизнеса, которые планируют запускать мобильное приложение по доставке, так и начинающим программистам в качестве неплохого чек-листа при интеграции с учетными системами.