Особенности интеграции мобильного приложения по заказу доставки еды с iiko, R-Keeper и 1С

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

Почему это важно?

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

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

С чем возможна интеграция?

В общепите 2 выделенных лидера - это системы iiko и R-Keeper. Намного реже клиенты пользуются 1С или СБИС.
Есть еще различные уникальные системы, однако встречаются крайне редко. Поэтому важно рассмотреть особенности интеграции именно с первыми двумя системами.

Что входит в объемный блок интеграции:

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

Возможно, дочитав до этого момента и представив объем работ, вы подумаете: "Да может и не нужно мне это все? Есть же колл-центр, пусть операторы принимают заказы. Зато сэкономлю на разработке". В качестве примера мы приведем вам кейс одной компании - какую выгоду им удалось получить благодаря мобильному приложению.

Некая компания "Х" готовит и доставляет еду. Имеет несколько ресторанов в разных районах города.Количество заказов в день: 200-300.

Было:
Сайт - заказ - оператор - кухня
4 оператора в штате, затраты (зарплата, налоги, прочие отчисления; содержание рабочего места): примерно 200 000 руб./мес.

Стало:
Приложение - заказ - кухня
2 оператора в штате, затраты (зарплата, налоги, прочие отчисления; содержание рабочего места): примерно 100 000 руб./мес.

Итого экономия: 100 000 руб./мес. или 1 200 000 руб./го

Внедрили приложение по сбору заказов:

Заказы отправляются сразу на производство. Операторы - на экстренный случай.
При этом на кухню того или иного ресторана они распределяются автоматически по территориальному признаку, в зависимости от адреса доставки.
Гость теперь может оформить предзаказ на доставку и самовывоз к определенному времени.
На каждый тип заказа (доставка, самовывоз) отображается свое меню.

Итак, какие нюансы следует учесть, если планируете разрабатывать приложение самостоятельно или отдать новичкам?

1

Плохое качество документации самих внутренних систем.
Мы неоднократно встречали случаи, когда какой-то параметр не был описан в документации и приходилось его искать методом научного тыка.
2

Разные конфигурации сервера.
У iiko есть общий сервер, и все подключение идет к нему. Плюсы этого в том, что при переносе исходного кода на другой проект, он почти всегда запускается без особых проблем, чего не скажешь о нашем опыте общения с R-Keeper. Там сервер как правило стоит непосредственно внутри организации и каждая система как новая.
3

Связь не всегда устойчивая.
К примеру, iiko.biz иногда становится недоступен. В этом случае делается несколько попыток отправить заказ в ресторан. Если это не удается, используется резервный канал - отправки заказа e-mail. Тут важно и с заказчиком проговорить, что такие ситуации возможны, чтобы они выполняли отдельный процесс обработки таких заказов.
4

Ввод адреса доставки.
У систем есть свой классификатор улиц и домов, и, если передавать название улицы, не совпадающее по названию (к примеру улица К.Маркса или Карла Маркса и множество прочих написаний), то заказ попадает в ошибку и не идет на производство. Наше решение: мы создали у себя дублирующий справочник улиц и предлагаем пользователю выбирать адрес исходя из этого списка.
5

Распределение заказов по географическому принципу.
Каждый заказ автоматически уходит на кухню того ресторана, который находится ближе всего к адресу доставки, а для отдаленных районов будет больше стоимость доставки или минимальный чек заказа.
6

Проверка онлайн-оплаты заказа.
Это относится к заказам с онлайн-оплатой. Если платеж не прошел, система не отправляет заказ на производство. Гостю приходит оповещение с просьбой предварительной оплаты заказа, и только оплаты заказ уходит на кухню.
7

Разные пути адресации заказов.
В зависимости от пожеланий заказчика заказы можно отправлять как на колл-центр для ручной обработки и перезвона клиенту, так и напрямую на производство.

Здесь возникает нюанс: если заказ ушел сразу на производство и его начали готовить, а гость передумал или ошибся? Наше решение: создавать "черные" и "белые" списки пользователей.

Если у пользователя есть один удачный заказ - он попадает в "белый" список и заказ идет сразу на производство.

Если клиент чем-то не подходит - то его размещаем в "черный" список и заказ он может осуществить только по полной предоплате картой (смотри пункт 4).
8

Внутренняя переадресация заказов.
В каждом ресторане периодически случаются ЧП, при которых приготовление еды или доставка становится невозможным (отключили воду или электричество, нет курьеров и др.). В этом случае конкретному ресторану мы добавили возможность отключения самовывоза заказа, а заказы доставки переключать на отправку в колл-центр, чтобы они вручную переадресовывали их в другие рестораны сети.
9

Время доставки.
Один из важных параметров оформления предзаказа: гость может оформить предзаказ на доставку или самовывоз на любое желаемое время. Например, с вечера можно оформить предзаказ блюда на завтрак. А ужин запланировать днем, чтобы избежать долгого ожидания доставки в часы высокой загрузки.
10

Статусы доставки.
При нормальной интеграции клиент еще получает информацию и о том, в каком состоянии находится сейчас его заказ: передан на кухню, собран, передан курьеру. И приложение дополняет эту функцию push-уведомлением пользователю.
В ближайшем будущем еще будем реализовывать показ местонахождения курьера на карте, но об этом в другой статье.
11

Разное меню.
Нередко случается, что на доставку, на самовывоз и на заказ в зале у ресторана разные меню. Важно реализовать интеграцию так, чтобы пользователь не заказал случайно то, что не отправляется на доставку. Для этого мы сделали специальную надстройку: прямо из учетной системы можно задавать параметры для блюд, какие доступны на самовывоз, на доставку или другие способы подачи.
12

Скидки на самовывоз.
У многих ресторанов есть распространенная практика - предоставлять скидку на самовывоз заказа, чтобы не тратиться на курьеров. В большинстве случаев, скидки распространяются не на все позиции (например, не действует на комбо-наборы и акционные позиции). Доработали так, чтобы и эти категории можно было указывать напрямую из учетной системы.
13

Размер порции.
Например, в iiko размер блюда указан как "Порция", так как это важно для других процессов. А потребителю при заказе еды важно знать вес блюда в граммах. Добавили еще одну надстройку для указания размера в граммах или миллилитрах.
14

Типы оплат и типы доставки.
Сейчас потребителю на выбор предоставляется, как правило, 3-4 типа оплаты заказа (курьеру наличными или картой и онлайн картой, плюс иногда Apple Pay или оплата с привязкой карты). А также - 2-3 способа доставки (доставка, самовывоз, доставка до подъезда, заказ из зала ресторана и др.). Все эти особенности также важно создать в iiko, чтобы шел правильный учет заказов.
15

Сдача с купюры.
Вытекает из предыдущего пункта. При оплате наличными, для удобства и быстроты расчетов клиент может указать, с какой купюры нужна сдача. Эти данные передаются в ресторан, и курьер выезжает с необходимым количеством денежных средств для сдачи.
16

Количество персон.
Еще один параметр, который важно выводить в корзине, чтобы данные попадали в iiko. Например, для статистического учета.
17

Точные данные для курьера.
Как правило, сейчас никто не ограничивается улицей, домом и квартирой. При оформлении заказа гостю нужно еще указать номер подъезда, этаж, наличие домофона или код от него для удобства курьера.

Кажется, мы достаточно убедили вас в том, что разработка мобильного приложения для сервиса по доставке еды - вещь намного более сложная и многогранная, чем кажется на первый взгляд. При выборе разработчика, доверяйте только профессионалам, которые имеют богатый опыт и знают все подводные камни. Такой объем работы просто невозможно сделать быстро и очень дешево. Так что, если небольшая компания обещает сделать все быстро и почти бесплатно - это повод насторожиться.

Другие новости по теме