Особенности интеграции мобильного приложения по заказу доставки еды с 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. Например, для статистического учета.
• Точные данные для курьера. Как правило, сейчас никто не ограничивается улицей, домом и квартирой. При оформлении заказа гостю нужно еще указать номер подъезда, этаж, наличие домофона или код от него для удобства курьера.

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