Мобильное приложение для HoReCa, которое делает заказы без интернета. Кейс «Меридиан»

Большинство B2B‑сервисов в сфере поставок продуктов для HoReCa выглядят как адаптированные интернет‑магазины: перегруженные каталоги, неудобная мобильная версия, отсутствие офлайн‑режима и слабая интеграция с внутренними системами. Формально такие решения позволяют оформлять заказы, но в реальной работе — на кухне, на складе или в условиях нестабильного интернета — они часто не справляются с задачей, замедляют процессы и создают риск ошибок.

Проблемы в сфере HoReCa и значимость их решения

Прежний магазин клиента он плохо соответствовал реальным сценариям использования:

• заказы оформлялись преимущественно со смартфонов, но сайт не был адаптирован под мобильную работу;
• отсутствовал офлайн‑режим;
• не было push‑уведомлений;
• пользователям требовался быстрый и функциональный интерфейс, а не классическая веб‑витрина.

Однако в процессе анализа стало понятно, что проблема шире, чем просто неудобный сайт — она лежит на уровне всей отрасли HoReCa и подходов к B2B‑заказам.

Мы выделили несколько системных проблем:

1. Несоответствие цифровых инструментов реальным условиям работы. В ресторане заказы оформляются «на ходу»: на кухне, на складе, в условиях нехватки времени и нестабильного интернета.
2. Зависимость от качества соединения. В реальности пользователи часто работают в помещениях с плохим сигналом (подвалы, склады), где оформление заказа через веб становится невозможным или крайне неудобным.
3. Сложная и нетиповая B2B‑логика. Индивидуальные цены, закрытые каталоги, работа с контрагентами и интеграция с 1С плохо ложатся на стандартные e‑commerce‑решения.
4. Избыточные интерфейсы. Классические сайты перегружены визуальными элементами, которые мешают быстро выполнять рабочие задачи — в отличие от требуемого «инструментального» подхода.
5. Высокая цена ошибки. Ошибка в заказе — это не просто неудобство, а реальные финансовые и операционные потери: срыв поставок, проблемы на кухне, недовольство гостей.

Эти проблемы напрямую влияют на эффективность бизнеса клиента: увеличивают время оформления заказов, создают риски ошибок и делают процесс зависимым от внешних факторов.

Поэтому задача проекта вышла за рамки «сделать удобный интерфейс». Мы взялись за более фундаментальную цель — переосмыслить сам подход к инструменту заказов в B2B‑сегменте HoReCa и устранить ключевые ограничения, с которыми ежедневно сталкиваются пользователи.

Методология и подход к разработке приложения

На этом этапе ключевой сложностью стала высокая зависимость процессов от 1С и отсутствие формализованного описания логики работы. Многие сценарии существовали «на практике», но не были задокументированы: как формируются заказы, каким образом применяются индивидуальные цены, как обрабатываются статусы.

Дополнительную сложность представляло разнообразие пользовательских сценариев. Один и тот же пользователь мог работать в разных условиях: оформлять заказ в спешке на кухне, проверять остатки на складе или повторять предыдущие заказы.

UX/UI‑дизайн. На этапе проектирования интерфейса основной проблемой стало несоответствие классических e‑commerce‑подходов реальным задачам пользователей.

Типовые решения перегружены визуальными элементами и рассчитаны на «просмотр каталога», тогда как в данном случае требовался инструмент для максимально быстрого выполнения действий.

Дополнительным ограничением стал контекст использования: пользователи работают в условиях нехватки времени, часто с мобильного устройства и не всегда при стабильном интернет‑соединении.

Для решения этих задач интерфейс был спроектирован с акцентом на скорость и функциональность:

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

Архитектура и интеграция с 1С. Ключевой технической задачей проекта стала интеграция с 1С, которая выступала основным источником данных и центром бизнес‑логики.

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

Обмен данными был настроен с учетом возможных задержек и повторных попыток синхронизации.

Нативная разработка. На этапе разработки ключевыми вызовами стали обеспечение стабильности работы приложения и корректная реализация офлайн‑сценариев.

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

Дополнительно требовалось обеспечить единое поведение приложения на iOS и Android, а также корректную обработку ошибок и сбоев соединения.

Это позволило устранить одну из ключевых проблем отрасли — зависимость процесса заказа от качества интернет‑соединения.

Ключевые особенности разработки

Персонализированное ценообразование и ограниченный доступ по ИНН. Каждому клиенту «Меридиана» отображается индивидуальный прайс, синхронизируемый напрямую с 1С. В системе предусмотрена сегментация цен — отдельно для розничных покупателей, а также для мелкого и крупного опта.

Доступ к приложению получают исключительно подтвержденные клиенты:

• сначала компания заводится в 1С;
• в системе фиксируются ИНН и контактный email;
• при регистрации происходит автоматическая сверка данных;
• после верификации доступ открывается без участия менеджера.

Офлайн‑режим для работы шеф‑поваров. Приложение поддерживает полноценную работу без подключения к сети:

• заказ можно собрать и оформить в офлайн‑режиме;
• все операции сохраняются локально на устройстве;
• при восстановлении соединения данные автоматически синхронизируются и отправляются.

Такой подход особенно критичен для ресторанной среды, где стабильное интернет‑соединение нередко недоступно или нестабильно.

Публикация в App Store как отдельный этап

Чтобы решить вопрос, потребовалось:

• напрямую обратиться в поддержку Apple;
• на английском языке подробно объяснить специфику B2B‑сценария;
• аргументировать необходимость ИНН как условия доступа к персонализированным данным и ценам.

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

Результат

В B2B‑сегменте HoReCa классические интернет‑магазины перестают быть эффективными по мере роста бизнеса и усложнения процессов: появляются индивидуальные условия, закрытые каталоги, зависимость от 1С, нестабильный интернет и высокая цена ошибки.

Приложение стало ключевым инструментом для клиентов «Меридиана»: заказы оформляются быстрее, стабильнее и с меньшим количеством ошибок — даже в условиях, где веб‑решения ранее не справлялись.

На основе опыта проекта можно выделить несколько практических рекомендаций для компаний с похожими задачами:

• проектировать решение как рабочий инструмент, а не как классический интернет‑магазин — в B2B важна скорость и простота действий;
• закладывать офлайн‑режим как базовый сценарий, если пользователи работают в условиях нестабильного интернета;
• учитывать сложную бизнес‑логику (индивидуальные цены, роли, интеграции с 1С) на уровне архитектуры, а не пытаться адаптировать типовые e‑commerce‑решения.

Клиент получил масштабируемый продукт, который не только закрывает текущие задачи, но и готов к дальнейшему развитию вместе с бизнесом.