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