Mary Ai

FoodTechERPB2Bweb

Mary Ai

FoodTechERPB2Bweb

Mary AI — restaurant management platform design

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

Role: Product Designer
Team: 1 Designer3 DevelopersManager

01 — Контекст

Mary AI — SaaS-платформа для управления ресторанами, ориентированная на рынок Узбекистана и Центральной Азии. Рынок занят: iiko, Clopos, Jowi, NEON ALISA — зрелые продукты с устоявшимися паттернами. Ключевое отличие Mary AI — встроенный AI-ассистент Mari AI, который должен быть частью того модулей

Нужно было спроектировать архитектуру продукта с нуля для 11 модулей: Dashboard, Касса, Склад, Меню, CRM, Отчёты, Сотрудники, Book a Table, QR-меню, Настройки, Биллинг.

02 — Задача

Полный цикл UX/UI: информационная архитектура, структура модулей, продуктовые решения, интерактивные прототипы — в связке с продакт-менеджером, с которым согласовывались ключевые развилки

03 — Вводные данные

Рынок фрагментирован по способам оплаты: нал, безнал, Click, Payme, Uzum — это отражается до структуры Кассы

Доставка в регионе идёт в основном через агрегаторы (Yandex, Uzum Tezkor), а не собственные курьерские службы — это меняет логику Бронирование стола и QR-меню

Продукт уже прошёл MVP: мультифилиальность и базовые модули были готовы — новые решения нужно было встраивать в существующую систему, а не проектировать в вакууме

04 — Процесс и решения

Касса

Проблема: денежный поток, отчётность и учёт смен были логически смешаны в разных местах интерфейса. Решение: четыре вкладки (Кассы · Транзакции · Группы транзакций · Отчёт по кассе), Cash Flow как отдельная сущность убран — поглощён Отчётом по кассе. Смены привязаны к конкретной кассе, а не к филиалу. В отчёте разделены кассовый поток и «расчётная прибыль» (accrual vs cash) — это разные вещи, и путать их нельзя.

Склад

Проблема: остатки могли дублироваться между Складом и Меню, что создаёт риск рассинхрона данных. Решение: Склад → Остатки — единственный источник правды; Меню → Ингредиенты просто отражает те же данные. Оплата накладной — inline-действие внутри карточки, создающее транзакцию в Кассе в фоне, без перехода в другой модуль.

Проблема: калькуляция себестоимости обычно живёт отдельно от карточки блюда, что усложняет ценообразование. Решение: в drawer добавления блюда — вкладка «Калькуляция» с единой таблицей ингредиентов и полуфабрикатов и live-расчётом себестоимости, цены, маржи и наценки прямо по ходу ввода.

CRM

Проблема: нужно было решить, создавать ли клиентские профили вручную или встраивать в существующие потоки. Решение: клиенты создаются автоматически из бронирований, POS и предзаказов с дедупликацией по номеру телефона. Сегменты — это уровни лояльности (New/Infrequent/Regular/VIP) без отдельного раздела программы уровней — чтобы не плодить лишние сущности.

Бронирование стола

Проблема: бронирования и предзаказы на самовывоз — разные по природе процессы, но их часто силой сводят в одну таблицу. Решение: tab-based разделение Reservations / Pre-orders. Reservations — список + схема зала; Pre-orders — full-width таблица со статусной моделью New → Preparing → Ready → Picked up.

Отчёты, Сотрудники, QR-меню, Настройки, Биллинг

Коротко: единый паттерн периодов (чипы Сегодня/Неделя/Месяц/Год/Произвольный) — по всей платформе; QR-меню синхронизирует зоны и столы из бронирований вместо дублирования; Биллинг — отдельная зона доступа только для владельца.

05 — Результат

Сейчас платформа работает в ресторанах Friends

11 модулей спроектированы с единой логикой и общими паттернами; ключевые архитектурные решения по Кассе, Складу, Меню, CRM и Бронированием приняты и провалидированы с продактом.