SABSUS — единая модульная white-label operating system для бизнеса

Сегодня бизнесу уже недостаточно просто кассы, просто CRM или просто сайта. Когда заказы находятся в одном месте, клиенты в другом, склад отдельно, доставка отдельно, сообщения отдельно, а автоматизация вообще живёт в сторонних сервисах — бизнес начинает терять скорость, контроль и деньги. Именно для решения этой проблемы создан SABSUS. Если объяснять максимально точно: SABSUS — это единая модульная платформа, которая объединяет все процессы бизнеса в одну экосистему. Большинство компаний сегодня работают в разрозненной среде. Продажи — в одной системе. Клиенты — в другой. Переписки в социальных сетях — в третьей. Склад, поставки, доставка, сотрудники, лояльность, документы, аналитика — всё это обычно разбросано по разным сервисам. В результате бизнес постоянно живёт на стыках между системами. Где-то теряются заявки. Где-то дублируются данные. Где-то сотрудники делают одно и то же вручную. Где-то клиентский опыт ломается просто потому, что инструменты не связаны между собой. И самая большая проблема в том, что даже если у компании уже есть CRM, касса, сайт, мессенджеры, складской учёт и доставка — это ещё не значит, что у неё есть единая система бизнеса. Чаще всего у неё просто есть набор сервисов, между которыми приходится постоянно переключаться. SABSUS — это не просто ещё одна CRM. Это не просто POS. Это не просто доставка, склад или white-label приложение. SABSUS — это единая роль-ориентированная платформа, в которой бизнес может построить свою структуру, управлять продажами, сотрудниками, каталогом, клиентами, складом, производством, доставкой, маркетингом, коммуникациями и автоматизацией внутри одной экосистемы. Здесь каждая роль работает в своём интерфейсе, но все процессы соединены между собой в одной логике. Владелец управляет компанией. Кассир работает в POS. Менеджер ведёт лидов в CRM. Повар видит производство. Курьер получает маршруты. Поставщик работает в своём интерфейсе. Клиент оформляет заказ в приложении, на сайте, в электронном меню или на станции самообслуживания. И всё это — одна система. SABSUS подходит не только ресторанам. Платформа рассчитана на разные модели бизнеса. Это могут быть кафе, рестораны, бары, магазины, интернет-магазины, доставка, кейтеринг, услуги, бронирование, аренда, цифровые продукты, курсы, реселлерские модели и поставщики. То есть речь идёт не о локальном решении под одну задачу, а о платформе, которую можно адаптировать под очень разные сценарии работы. Главная сила SABSUS в том, что система построена не вокруг разрозненных модулей, а вокруг реальных объектов бизнеса. Например, один заказ здесь — это не просто чек. Это объект, который связывает клиента, товары, услуги, адрес, оплату, бонусы, депозит, чаевые, производство, курьера, статусы, документы, историю действий, склад и коммуникации. То есть когда бизнес работает в SABSUS, он работает не с набором несвязанных экранов, а с единой цепочкой процессов. Именно поэтому эта платформа позволяет не просто вести учёт, а реально управлять бизнесом от первого касания до исполнения и повторной продажи. Но на этом SABSUS не заканчивается. Помимо интерфейсов и операционных модулей, в платформе есть слой автоматизации и интеграций — Subsus Flow. Он позволяет компаниям строить собственные сценарии, реакции, API и автоматические процессы внутри системы. Это значит, что бизнес может не только работать в готовых интерфейсах, но и проектировать свою собственную логику. Новый лид может автоматически классифицироваться через AI. Новый заказ может запускать уведомления менеджеру или руководителю. Новая карточка товара может автоматически отправляться в нейросеть, получать описание, изображение и публиковаться в Instagram или другие социальные каналы. Сообщения, email, SMS, Instagram, WhatsApp, Telegram, Facebook и любые другие каналы могут быть встроены в общую логику компании. То есть SABSUS — это не просто система, где бизнес работает. Это платформа, в которой бизнес может сам собирать свои процессы. В этом видео я покажу SABSUS полностью — от и до. Мы начнём с того, как внутри платформы создаётся сам бизнес: компания, точки продаж, сотрудники, каталог, способы оплаты, доставка, бренд и интерфейсы. После этого посмотрим, как устроены товары, услуги, аренда, цифровые продукты, рецепты, ингредиенты и производство. Затем перейдём к реальной операционной работе: клиентский интерфейс, POS, заказы, оплата, кухня, склад, поставщики, доставка и исполнение. Дальше разберём CRM, маркетинг, коммуникации, лояльность, автоматизацию, интеграции, Flow и AI-сценарии. И в конце соберём всё в одну полную картину, чтобы было понятно, почему SABSUS — это одна платформа вместо хаоса из разных сервисов. И начнём мы не с заказа и не с клиента. Начнём с самого важного — с фундамента. Потому что прежде чем бизнес сможет продавать, доставлять, автоматизировать и масштабироваться, его нужно правильно собрать внутри системы. Давайте посмотрим, как в SABSUS создаётся бизнес с нуля.

Сейчас я покажу самый важный фундамент всей системы — как в SABSUS создаётся бизнес с нуля. Потому что прежде чем принимать заказы, вести CRM, строить доставку, подключать склад, маркетинг и автоматизацию, сначала нужно правильно собрать основу компании. И именно от этого зависит, насколько правильно дальше будут работать все остальные интерфейсы. Представим, что мы запускаем реальный бизнес внутри SABSUS. Для примера возьмём компанию Микеланджело Пицца. Это заведение, у которого есть продажи в зале, самовывоз, доставка, кейтеринг, кухня, сотрудники, склад, клиентский кабинет и дальнейшая автоматизация через Flow. Первое, с чего начинается работа, — это настройка компании. Здесь указывается логин компании. Логин нужен не просто как формальность, а как идентификатор внутри системы. По нему платформа понимает, какая это компания, какие данные к ней относятся, какие интерфейсы ей доступны, какая подписка подключена и какие интеграции у неё работают. Дальше загружается логотип компании. Это уже основа будущего бренда во всей системе. Логотип будет использоваться не только в панели управления, но и дальше в клиентских интерфейсах, в чеках, в уведомлениях, в приложении, в некоторых документах и в branded-среде компании. После этого указывается почтовый адрес компании и физический адрес компании. Адрес можно выбрать через карту или через поиск. Это важно, потому что адрес потом влияет не только на карточку компании, но и на доставку, на геолокацию, на отображение в клиентском интерфейсе, на зоны работы и на часть логики маршрутов. Следующий большой блок — это языки интерфейса. Компания может выбрать, какие языки будут использоваться в её системе и в приложении. Например, в нашем случае мы включим русский, английский, испанский и украинский. Это значит, что дальше названия, описания, тексты товаров, категории, интерфейсные элементы и часть коммуникаций можно показывать на нужном языке клиенту или сотруднику. После этого мы задаём название компании сразу на нескольких языках. Например: на русском — «Микеланджело Пицца», на английском — “Michelangelo Pizza”, на испанском — “Michelangelo Pizza”, на украинском — «Мікеланджело Піца». Дальше можно указать краткое описание компании и полное название компании тоже на всех языках. Это полезно и для отображения в приложении, и для клиентского кабинета, и для документов, и для дальнейших маркетинговых материалов. Следующий блок — юридические и контактные данные. Здесь можно указать налоговый номер, регистрационный номер, выбрать страну компании, добавить список телефонов и основной email. Например, если это ресторан в Калифорнии, мы можем указать США, налоговый номер компании, один рабочий email и несколько номеров — для офиса, для поддержки, для управляющего или для доставки. Дальше идут глобальные переключатели, которые реально влияют на поведение бизнеса внутри системы. Первый переключатель — учитывать налоги или нет. Если он включён, то система будет учитывать налоговую часть в заказах, способах оплаты, транзакциях и дальнейшем финансовом учёте. Если компания работает в юрисдикции, где налог обязателен, этот параметр должен быть включён с самого начала. Следующий переключатель — округлять сумму заказа или нет. Если он включён, сумма заказа будет округляться по заданной логике. Это может быть удобно в тех моделях бизнеса, где компания хочет упростить расчёт или подстроиться под свои правила оплаты. Дальше — быстрое переключение сотрудника в терминале. Это особенно важно для POS. Если параметр включён, сотрудники смогут быстро переключаться между своими заказами без постоянного повторного ввода PIN-кода. Для заведений с быстрым потоком это очень полезно, потому что экономит время на кассе. Следующий переключатель — производство с технологическими картами и полуфабрикатами. Если компания сама производит товары, если использует рецепты, ингредиенты, полуфабрикаты, упаковочные комплекты и цеха, этот параметр обязательно включается. Например, для пиццерии это критично, потому что одна пицца состоит из теста, соуса, сыра, начинки, упаковки и процессов производства. Дальше — отслеживать рабочее время сотрудников. Если включить этот параметр, система сможет учитывать смены, рабочее время, перерывы, закрытие смен, и это в дальнейшем влияет и на аналитику, и на зарплатную логику, и на дисциплину сотрудников. Следующий параметр — время пролистывания рекламных баннеров. Это глобальная настройка, которая влияет на клиентские интерфейсы, если отдельно не задано другое значение. Например, можно указать 5 секунд, и тогда баннеры в приложении или на сайте будут автоматически сменяться каждые 5 секунд. Дальше выбирается группа клиентов по умолчанию для новых клиентов. Это важная маркетинговая логика. Например, можно сделать группу «Новые клиенты» или «Стартовая группа». Тогда каждый новый клиент при регистрации автоматически попадёт в эту группу, и к нему можно будет применять нужные бонусы, скидки, промо-механики или правила лояльности. Дальше можно указать курс доллара или другой базовой валюты, если внутри бизнеса есть конвертация. Это полезно в международной модели или в компаниях, которые работают с несколькими валютами или закупками. И ещё один важный параметр — время разделения заказа для реселлеров. Это нужно, если компания работает по схеме, где заказы после определённого времени считаются уже заказами следующего дня. Например, если мы принимаем заказы только до 15:00 на текущий день, то всё, что пришло после 15:00, можно автоматически переносить на следующий день. После этого сохраняем компанию. И на этом этапе мы уже создали не просто карточку с названием, а базовую сущность бизнеса внутри SABSUS. Следующий важный раздел — безопасность. Здесь задаётся пароль администратора, который используется не для входа, а для подтверждения критических действий. Это очень сильная функция контроля. Например, можно включить подтверждение паролем при удалении товара, изменении скидки, удалении акции, закрытии чека, добавлении поставки или использовании бонусов клиента в терминале. И это очень полезно, потому что бизнес защищает себя от случайных или несанкционированных действий сотрудников. После этого переходим к точкам продаж. Точка продаж — это уже не просто адрес. Это конкретная операционная единица бизнеса. Например, у компании может быть один ресторан в Бёрбанке, вторая точка в Глендейле и отдельная точка только под доставку. Количество таких точек зависит от тарифного плана, но каждая точка внутри системы настраивается очень глубоко. В точке продаж сначала задаётся статус — доступна она или недоступна. Дальше можно загрузить неограниченное количество фотографий с улицы, один логотип и фотографии самой локации. Это важно для клиентского интерфейса, потому что человек может увидеть реальную точку, интерьер, вход, атмосферу. Потом указываем название точки на всех языках. Например: «Микеланджело Пицца Бёрбанк», “Michelangelo Pizza Burbank” и так далее. Добавляем телефон, email, выбираем тип локации: магазин, ресторан, бар, доставка или интернет-магазин. Можно добавить список социальных сетей, например Instagram и логин компании, или другие контакты. Дальше указывается адрес заведения и график работы. Можно настроить часы по дням недели, а можно включить режим 24 часа. Если включён режим 24 часа, клиент сможет оформлять заказы круглосуточно, если остальные настройки это позволяют. Потом добавляем описание заведения на всех языках. Например, можно написать, что это семейная пиццерия с доставкой, самовывозом, кейтерингом и кухней полного цикла. Дальше выбирается формат даты — американский или европейский — и указывается часовой пояс. Это очень важно, потому что потом от этого зависит отображение времени заказов, смен, доставки, расписаний, аналитики и клиентских уведомлений. Следующая настройка — язык чека. Например, если точка находится в США, можно выбрать английский язык чека, даже если внутри системы владелец работает на русском. Также здесь выбирается валюта, и именно она будет использоваться в карточках товаров, в оплате и в заказах этой конкретной точки. Дальше идёт один из очень важных параметров — максимальное время окончания рабочего дня сотрудников. Если точка работает после полуночи, это особенно важно. Например, если ресторан работает до 2 или 3 часов ночи, можно указать, что конец рабочего дня считается в 5 утра. Тогда статистика, кассовые смены и часть расчётов будут делиться не по календарной полуночи, а по логике бизнеса. После этого идут операционные переключатели точки. Первый — режим фастфуда. Если он включён, следующий заказ будет открываться автоматически после завершения текущего, без лишних нажатий. Для быстрого потока это очень удобно. Дальше — принимает ли заведение заказы в заведении. То есть это может быть ресторан со столами или магазин с покупкой на месте. Следующий переключатель — работа со столами. Если это ресторан, бар или кафе с залом, столы можно включить. И сразу рядом — бронь столов, если в заведении есть логика резервирования. Следом — доставка, самовывоз, кейтеринг, кухня / производство. Все эти параметры включаются в зависимости от реальной модели бизнеса. Например, для нашей Микеланджело Пиццы можно включить всё сразу: зал, доставка, самовывоз, кейтеринг и кухню. Дальше идёт важный параметр — печатать QR-код для онлайн-оплаты на чеке. Если его включить, клиент сможет сканировать код на чеке и сразу переходить к оплате. Следующий параметр — стандартный или нестандартный чек. Это даёт возможность задавать внешний вид чека в каждой точке отдельно. Потом — спрашивать количество гостей или нет. Это полезно для ресторанов, когда нужно понимать, на сколько человек готовить заказ, сколько приборов положить и как обслуживать гостей. Дальше — показывать кнопку “Связаться”. Если включить, в приложении и на сайте клиент увидит кнопку связи и сможет быстро открыть телефон, Instagram, WhatsApp и другие каналы компании. Следующий переключатель — автоматические налоги доставки. Если включено, система будет брать налоги по логике точки и применять их к доставке автоматически. Дальше переходим к финансовому блоку точки продаж. Здесь можно выбрать расчётный счёт компании, счёт для инкассации наличных, счёт кассы, доступные методы оплаты, настройки уведомлений об остатках, email для уведомлений, налог по умолчанию, сервисный сбор и минимальный возраст клиента для определённых товаров. Например, можно сделать так: кассовый счёт — “Burbank Cash Register”, счёт инкассации — “Daily Cash Deposit”, основной расчётный счёт — “Bank of America Main”, методы оплаты — наличные, карта, онлайн-оплата через Stripe. Если остатков становится мало, уведомления можно отправлять на email управляющего. Дальше настраиваются адреса самовывоза. У одной точки продаж может быть несколько адресов самовывоза. Это удобно, если у бизнеса, например, один основной ресторан, но несколько адресов выдачи. Следующий важный раздел — варианты доставки. Здесь можно создавать разные типы доставки. Например: быстрая доставка от 15 до 30 минут — 15 долларов, стандартная доставка от 30 до 60 минут — 8 долларов, эконом-доставка до 180 минут — 5 долларов. Можно использовать цену из интеграции, можно считать цену за километр, можно переключать формат срока доставки с минут на дни. Дальше — ограничения регистрации смен по API. Здесь можно указать, с каких сетей или API допустима регистрация смены сотрудников. Например, чтобы сотрудник мог открывать смену только внутри заведения, через корпоративную Wi-Fi сеть или через разрешённую точку. И ещё один важный раздел — пользовательское соглашение на получение товара. Компания может написать любое соглашение, и клиент увидит его при оформлении заказа или подписании документов. После настройки точки продаж переходим к разделу счета. Здесь добавляются финансовые счета компании. У счета есть название на всех языках, тип счёта — наличный или безналичный, валюта, стартовый баланс, комментарий. Если счёт безналичный, указываются банковские реквизиты: номер счёта, расчётный номер, код банка, название банка. Также можно включить параметр формирования счёта на оплату. Например, создадим три счёта: “Основная касса”, “Bank of America”, “Cash Deposit Account”. Так система будет понимать, куда идут деньги, откуда списываются расходы, как регистрируются оплаты и переводы. Следующий раздел — методы оплаты. И здесь логика очень глубокая. Сначала можно загрузить изображение метода оплаты, например иконку наличных, банковской карты или бренда сервиса. Потом задаётся название на всех языках. После этого выбирается тип — наличный или безналичный. Дальше система спрашивает: виден ли этот метод клиенту в мобильном приложении, виден ли на сайте, виден ли на станции самообслуживания. Это очень удобно, потому что можно ограничивать каналы. Например, наличные показывать только в POS, а онлайн-оплату — в приложении и на сайте. Потом можно указать, является ли этот метод оплатой прямо внутри приложения. Если да, выбирается интеграция. Если интеграция не выбрана, можно включить QR-код для оплаты вручную. Дальше задаются комиссии. Например, если метод работает как Stripe, можно указать 2.9 процента плюс фиксированная сумма 15 центов. Отдельно можно выбрать, оплачивает комиссию клиент или компания. Если комиссию оплачивает клиент, она автоматически добавится к сумме заказа. И ещё один важный параметр — учитывать налог или нет для этого метода оплаты. После этого переходим в налоги. Здесь указывается название налога на всех языках, процент налога, тип налога — налог с продаж, налог с оборота или НДС — и дальше выбирается, к каким типам заказов налог применяется. Например, можно сделать отдельный налог для доставки и другой для заказов в заведении. Следующий раздел — склады. У склада также есть название на всех языках, адрес и привязка к точке продаж. Например, можно сделать “Основной склад Бёрбанк” и привязать его к ресторану в Бёрбанке. Это важно, потому что дальше запасы, поставки, списания и производство будут работать именно с этим складом. Теперь переходим к разделу доставка уже как глобальному модулю. Здесь есть переключатель включить или выключить доставку. Дальше можно указать, какие статусы заказа будут использоваться: готовый, передан курьеру, доставлен. Можно включить загрузку фотографий со стороны курьера, чтобы он подтверждал факт доставки. Можно включить режим доставки только в зонах доставки. Если выбираем зоны доставки, нажимаем добавить зону доставки. Открывается карта. Задаём название зоны, например “Burbank West”. Дальше выбираем тип цены: фиксированная или за километр. Потом задаём время, стоимость, минимальную сумму заказа, налог, привязку к конкретной точке продаж и при необходимости к интеграции. Зону можно нарисовать прямо на карте или построить через zip-коды. Это очень удобно для реальной городской доставки. Дальше идёт раздел интеграции. Здесь компания может подключать платёжные и внешние сервисы. Например, North, Stripe, Stripe Terminal или кастомные интеграции для приёма оплат. Если выбирается Stripe, компания может подключить свой аккаунт. Также внутри системы может быть уже подготовлен встроенный платёжный слой. Следующий огромный блок — внешний вид приложения. Это уже часть white-label уровня. Если включена стандартная тема, система использует базовое оформление. Если выключить стандартную тему, компания может полностью настраивать свои цвета: первый фон, второй фон, цвет текста, второй цвет текста, цвет выбора, цвет кнопки, основной цвет, цвет цены на карточке товара, второстепенные цвета, радиус углов. Можно включить или выключить тёмную тему и отдельно настроить палитру для тёмного режима. И ещё здесь можно управлять главной страницей клиентского интерфейса. Если выключить стандартную главную страницу, система покажет поля для HTML-контента, и компания сможет подставить собственную веб-страницу через WebView. То есть это уже не просто цвет кнопки, а глубокая кастомизация клиентского опыта. Дальше раздел подписка. Здесь компания видит свой тарифный план, историю оплат и может менять тариф. А рядом есть программа лояльности для владельцев компаний — реферальная ссылка, бонусы за приглашение новых клиентов в платформу и разные варианты начислений. Теперь переходим к разделу персонал, потому что после настройки компании и точек нужно собрать команду. Сначала — сотрудники. Здесь можно добавить нового сотрудника: загрузить фотографию, указать имя, фамилию, email, телефон, дату рождения, персональную скидку, дисконтную карту, PIN-код для POS, дату начала работы, выбрать точку или заведение, выбрать должность, выбрать интерфейсы, которые доступны сотруднику. Например, мы можем создать кассира. Указать ему фото, имя Алексей, должность “Кассир”, назначить точку “Burbank Main”, задать PIN-код 1234, открыть ему интерфейс “Продажи”, но не открывать “Управление” и “Склад”. А для управляющего можно включить “Управление”, “Продажи”, “CRM”, “Маркетинг” и “Финансы”. Дальше есть переключатель заблокировать пользователя или нет, можно указать налоговый номер, регистрационный номер, комментарий. И очень важный блок — доступ к разделам. Можно включать и выключать для сотрудника конкретные области системы. То есть не просто дать роль, а реально ограничить, что он видит: персонал, маркетинг, меню, склады, финансы, каталог и так далее. Следующий раздел — должности. Здесь уже создаются роли как шаблоны. Например: кассир, менеджер зала, курьер, повар, складской сотрудник, маркетолог, CRM-менеджер, управляющий. У должности задаётся название и доступные интерфейсы. То есть мы можем заранее создать должность “Курьер” и открыть ей только курьерский интерфейс, или должность “Повар” и открыть только производство, рецепты и часть складских запасов цеха. Следующий раздел — зарплата. Его можно вынести в отдельный большой блок дальше, но уже здесь важно сказать, что зарплатная логика в SABSUS не живёт отдельно от бизнеса. Она связана с сотрудниками, сменами, точками, временем работы и процессами внутри системы. Итак, на этом этапе у нас уже создана компания, настроена безопасность, добавлены точки продаж, способы оплаты, счета, налоги, склады, доставка, внешний вид и сотрудники. То есть мы уже не просто зарегистрировали аккаунт. Мы собрали полноценный фундамент бизнеса внутри SABSUS. И это очень важный момент, потому что дальше всё, что мы будем показывать — каталог, CRM, POS, производство, склад, курьеров, маркетинг, клиентский кабинет, Flow и автоматизацию — уже будет работать не в воздухе, а на правильно собранной базе. Теперь, когда фундамент бизнеса готов, можно переходить к следующему большому блоку — к тому, что именно этот бизнес продаёт. И дальше я покажу, как в SABSUS создаются товары, услуги, аренда, цифровые продукты, ингредиенты, полуфабрикаты, рецепты, цеха, упаковка и всё, что потом превращается в реальные продажи, производство и клиентский опыт.

Теперь, когда у нас уже собран фундамент бизнеса, можно переходить к следующему большому этапу — к тому, что именно этот бизнес продаёт. Потому что любая сильная система начинается не только с компании, сотрудников и точек продаж, а с правильно собранного каталога. И в SABSUS каталог — это не просто список товаров. Это гораздо глубже. Здесь можно создавать обычные товары, услуги, арендные товары, технологические карты, ингредиенты, полуфабрикаты, упаковку, цифровые продукты, категории, расписания, производственные цеха и предложения от поставщиков. То есть здесь мы создаём не просто карточки, а всю логику того, что бизнес продаёт, производит, бронирует, выдаёт и доставляет. Для примера продолжим работать с нашей компанией Микеланджело Пицца. Но чтобы показать гибкость системы, я буду использовать не только примеры с пиццей, но и примеры с доставкой, арендой и цифровыми продуктами. Потому что SABSUS изначально рассчитан на очень разные модели бизнеса. Начнём с самого главного — с товаров. Когда мы открываем раздел каталога и создаём новый товар, первое, что видим, — это переключатель доступности. То есть товар можно сделать доступным или недоступным во всей системе. Это удобно, потому что товар можно не удалять, а просто временно скрыть, если он сейчас не продаётся. Дальше идут цифровые каналы. Мы можем отдельно выбрать, доступен ли товар в приложении, доступен ли на сайте, доступен ли на экране меню, доступен ли на станции самообслуживания. Это очень важный момент, потому что один и тот же товар не обязан показываться везде одинаково. Например, в ресторане можно продавать блюдо внутри заведения и на самовывоз, но не показывать его в киоске самообслуживания. Или наоборот, можно делать товары, которые доступны только онлайн. Следующий слой — доступность по типу заказа. Мы можем выбрать, доступен ли этот товар для кейтеринга, для доставки, для самовывоза или для заказа в заведении. Например, семейный сет можно продавать только на доставку и самовывоз, а бизнес-ланч — только в заведении. Или, к примеру, банкетное блюдо можно открыть только для кейтеринга. После этого переходим к общей информации о товаре. Здесь мы можем загрузить неограниченное количество фотографий или видео. Это очень важно для визуальной подачи. Для примера создадим товар Пицца Маргарита. Добавим красивую фотографию пиццы, короткое видео подачи и дальше укажем название сразу на четырёх языках. На русском — «Пицца Маргарита», на английском — “Margherita Pizza”, на испанском — “Pizza Margarita”, на украинском — «Піца Маргарита». Это значит, что в зависимости от языка клиента или сотрудника система будет показывать нужный вариант названия. Дальше выбираются локации, в которых доступен товар. Это важная бизнес-логика. Например, если у нас есть ресторан в Бёрбанке и в Глендейле, мы можем продавать эту пиццу в обеих точках. Но, например, десерт “Тирамису” может быть доступен только в одной локации, если вторая точка его не производит. То есть доступность товара можно очень точно привязать к конкретным точкам продаж. Следом выбираются категории товара. И важный момент в том, что товар можно привязать не к одной, а сразу к нескольким категориям. Например, “Пицца Маргарита” может одновременно находиться в категории “Пицца”, “Популярное”, “Сырные блюда” или “Акции недели”, если компания так решила выстроить каталог. Дальше можно указать бренд товара. Это особенно полезно для магазинов, реселлеров и поставщиков, но и в ресторане тоже может использоваться. Например, напитки можно привязывать к брендам Coca-Cola, Pepsi, San Pellegrino и так далее. А для магазина электроники это вообще критичная часть карточки. Следующее поле — теги. Теги помогают быстрее искать товар, группировать его и использовать для внутренней логики. Например, можно добавить теги “вегетарианское”, “популярное”, “сыр”, “без мяса”, “хит”. В дальнейшем это упростит и поиск, и маркетинг, и часть автоматизации. Теперь переходим к настройкам товара. Первое, что здесь можно выбрать, — налог. Например, если товар попадает под обычный налог с продаж, мы привязываем нужный налоговый шаблон, который уже создали ранее. Дальше выбираем цех. Например, для пиццы это будет горячий цех. Для напитков — бар. Для десертов — холодный цех. Это важно, потому that именно в этот производственный центр потом будут уходить задачи по приготовлению. Следующая настройка — единица измерения. Например, штука, килограмм, литр и так далее. Если выбрана штука, появляется поле вес одной единицы. Это полезно и для расчёта доставки, и для склада, и для некоторых производственных сценариев. Дальше мы можем включить режим услуги с записью. Если этот переключатель активен, то обычный товар сразу превращается в услугу, которая работает по расписанию. Например, если это не пицца, а “Аренда батута на детский праздник”, или “Маникюр”, или “Консультация”, то тут начинает работать логика записи. Если режим услуги включён, появляются дополнительные поля. Можно указать, требуется ли подписание соглашения. Например, для аренды оборудования или оказания услуги это очень важно. Также здесь появляется переключатель арендный товар или нет. Если это арендный товар, система понимает, что здесь есть не только дата начала, но и логика возврата. Дальше идут настройки записи. Шаг времени бронирования — например, каждые 30 минут. Это значит, что клиент или сотрудник будет видеть слоты в 10:00, 10:30, 11:00, 11:30 и так далее. Потом можно указать время на сборку и время на разборку. Например, если арендуется батут, то его нужно привезти, собрать, оставить клиенту, потом разобрать и забрать. И это уже влияет и на расписание, и на задачи курьера, и на маршруты, и на занятость оборудования. Следующий важный переключатель — учитывать или не учитывать остатки. Если это обычный товар или ингредиент, который есть на складе, остатки лучше учитывать. Если это условная услуга, где физического склада нет, учёт остатков может не понадобиться. Дальше можно задать номер в листе для сортировки. Это помогает выстроить порядок отображения товаров. Например, самые важные позиции можно поднять выше, а второстепенные опустить ниже. Следующий блок — размер товара в миллиметрах. Можно указать ширину, длину и высоту. Это очень полезно не только для физического склада, но и для расчёта доставки, особенно если речь идёт о коробках, оборудовании, декоре, аренде или крупных товарах. Теперь переходим к описанию товара. Здесь есть краткое описание и полное описание. Краткое описание показывается в превью карточки. Например: “Классическая пицца с томатным соусом, моцареллой и базиликом.” Полное описание уже раскрывает товар глубже. Например: “Пицца Маргарита готовится на тонком тесте, с фирменным томатным соусом, натуральной моцареллой и свежим базиликом. Идеальна для любителей классического итальянского вкуса.” И ещё одно очень важное поле — процесс подготовки или приготовления. Это уже инструкция для сотрудников. Например: “Раскатать тесто, нанести соус, добавить моцареллу, выпекать 6 минут, после выпечки добавить базилик.” То есть внутри одной карточки товара у нас уже есть и клиентская часть, и производственная логика. Дальше можно загрузить фон карточки товара в приложении клиента. Это уже элемент презентации. Например, можно поставить красивый фон с пламенем печи, мукой или ингредиентами, чтобы карточка выглядела сильнее. Теперь переходим к ценообразованию. Здесь можно указать обычную цену товара. Например, 14.99 долларов. Можно указать цену в бонусах, если товар можно получать за баллы. Можно указать, сколько бонусов начисляется за покупку этого товара. Например, за покупку пиццы клиент получает 15 бонусов. И дальше очень важная настройка — разные цены в локациях. Если включить этот режим, можно указать одну цену для Бёрбанка и другую для Глендейла. Например, в одной точке пицца стоит 14.99, а в другой 16.99. Это очень полезно, потому что в реальном бизнесе цены действительно могут отличаться в зависимости от точки. Потом можно указать штрих-код, артикул, а если нужно — и код акцизного товара. Дальше можно указать старую цену, если товар продаётся со скидкой. И если у нас разные цены по локациям, старую цену тоже можно задать по каждой локации отдельно. Теперь один из самых сильных блоков — наборы модификаторов. Если у товара есть модификации, сначала создаётся сам набор. Например, набор “Выберите размер”. Или набор “Добавьте ингредиенты”. У набора есть название, можно выбрать, является ли он спецификацией товара, можно ли привязать модификатор к товару, есть ли у этого набора фото, и самое главное — один товар можно выбрать или несколько. Для примера: если это выбор размера пиццы, клиент может выбрать только один вариант — 25 см, 30 см или 40 см. Если это добавки, например сыр, грибы, оливки, томаты, то тут можно разрешить выбрать несколько модификаторов и даже задать минимум и максимум. Например, минимум одна начинка, максимум три. Или, например, выбрать только две начинки из пяти. Это очень сильная логика, которая делает карточку товара реально гибкой. После этого внутри набора привязываются уже сами модификаторы. Например: “25 см”, “30 см”, “40 см”, или “дополнительный сыр”, “оливки”, “грибы”, “ветчина”. То есть именно здесь товар становится не просто позицией, а полноценной настраиваемой единицей продажи. Дальше идёт пищевая ценность. Можно выбрать, считать её за 100 грамм или за порцию, и указать белки, жиры, углеводы и калории. Это важно для пищевого бизнеса и для клиентов, которые следят за составом. Следующий красивый блок — лейбл продукта. Это тот самый ярлык, который можно показывать на карточке. Например: “Хит”, “Новинка”, “Эко”, “Острое”, “Скидка”. Здесь можно указать текст на всех языках, цвет лейбла и цвет текста. И это очень сильно усиливает визуальную подачу каталога. Дальше есть поле для интеграционных ID. Оно нужно для сопоставления товара с внешними системами и интеграциями. Например, если товар синхронизируется с Uber Eats, DoorDash или другой внешней платформой, здесь может храниться внешний ID товара. И ещё один важный раздел — упаковка. Это логика списания упаковочных элементов только при нужных типах заказа. Например, если пиццу едят в заведении, коробка не нужна. Но если заказ идёт на самовывоз или доставку, нужно списать коробку, салфетки, пакет и, возможно, соусницу. И это можно привязать именно к товару. Теперь перейдём к технологическим картам. Это уже не просто товар, а рецептурный или производственный объект. Например, мы создаём техкарту “Пицца Пепперони”. Внешне у неё много общих полей с обычным товаром, но появляется очень важный блок — состав. Здесь можно добавлять ингредиенты или полуфабрикаты. Например: тесто, томатный соус, моцарелла, пепперони. Для каждого элемента можно выбрать метод обработки: варка, жарка, тушение, чистка, запекание и так далее. Система автоматически может учитывать брутто, нетто, потери и считать себестоимость. То есть техкарта — это уже рабочий производственный инструмент, а не просто карточка. Теперь посмотрим на ингредиенты. Если создаётся ингредиент, там есть фотография, названия на языках, категории ингредиентов, бренд, теги, описание и процесс подготовки. Но у ингредиентов есть очень важная особенность — учёт остатков и минимальный остаток. Например, если у нас ингредиент “Моцарелла”, мы можем указать, что если на складе осталось меньше 2 килограммов, система должна предупредить ответственного. Также можно указать единицу измерения, вес одной штуки, если нужно, размеры, пищевую ценность и очень важные поля — проценты потерь при разных обработках. Например, при жарке, варке, тушении, чистке. Это нужно, чтобы система понимала, как из брутто получается нетто. Следующий тип — полуфабрикат. Полуфабрикат похож на техкарту, но его обычно нельзя продавать напрямую клиенту. Это промежуточный производственный объект. Например, тесто для пиццы, фирменный соус, крем для десерта, маринад, готовая начинка. Полуфабрикат собирается один раз, а потом может использоваться во множестве товаров. И это очень удобно, потому что не нужно каждый раз заново собирать один и тот же набор ингредиентов в каждом товаре. Теперь важный современный блок — цифровые продукты. Если мы создаём цифровой товар, то он почти повторяет логику обычного товара, но появляется новое поле — выбор цифрового продукта. К карточке можно привязать: файл, видео, HTML-страницу, ссылку, или целую модульную структуру курса. Например, ресторан может продавать кулинарный курс, PDF-книгу рецептов или подписку на контент. После покупки клиент увидит это в своём разделе “Мои продукты”. Дальше переходим к категориям товаров. Здесь создаётся фотография категории, название на всех языках и задаётся доступность по каналам: в приложении, на сайте, в киоске самообслуживания, на доставке, на самовывозе, в заведении, на кейтеринге. И ещё один важный переключатель — это категория услуги или категория товара. Например, “Пицца”, “Напитки”, “Десерты” — это товарные категории. А “Маникюр”, “Аренда”, “Бронирование” — это уже сервисные категории. Следующий раздел — категории ингредиентов. Они проще. Здесь в основном фотография и название. Например: “Сыры”, “Мясо”, “Овощи”, “Соусы”, “Тесто”. Это нужно для внутренней структуры склада и производства. Теперь очень важный блок — цеха. Цеха отвечают за производственные линии. Например: горячий цех, холодный цех, бар, мясной цех, упаковка. В настройках цеха задаётся название, выбирается заведение, привязывается склад, и можно включить автоматическую печать чеков в этот цех. Это значит, что официант или кассир не должен вручную передавать заказ на производство — система сразу отправит нужные позиции в нужный цех. Следующий полезный инструмент — упаковочные комплекты. Например, для доставки пиццы нужен набор: коробка, салфетки, пакет, вилка, соусница. Такой комплект можно один раз собрать и потом просто привязывать туда, где он нужен. И система будет автоматически списывать упаковку только на самовывозе и доставке, а не в зале. Теперь перейдём к расписаниям. Это отдельный мощный блок, особенно для услуг и аренды. Здесь можно создать расписание товара, услуги или сотрудника. Например, если это аренда батута, мы можем указать начало периода, конец периода, цену из карточки или кастомную цену прямо в расписании, перерыв между слотами, комментарии, доступные заведения и рабочие интервалы. То есть расписание — это уже слой управления доступностью и продажей по времени. Следующий раздел — предложения товаров. Это то, что предлагают поставщики в своём интерфейсе. Например, поставщик может зайти в платформу и предложить: новый сыр, новый соус, новый напиток, новую упаковку. Он указывает название, цену, валюту, артикул, штрих-код, комментарий, фотографии, сроки хранения и условия хранения. Это уже соединяет каталог компании с поставщиком. И вот теперь важно остановиться и понять, что мы только что сделали. Мы не просто добавили несколько карточек товаров. Мы собрали целую структуру того, что бизнес продаёт и как он это делает. У нас уже есть: обычные товары, модифицируемые товары, услуги, аренда, цифровые продукты, ингредиенты, полуфабрикаты, технологические карты, категории, цеха, упаковка, расписания и предложения поставщиков. И это крайне важный момент, потому что дальше, когда мы перейдём к POS, клиентскому приложению, производству, складу, доставке и CRM, всё это уже будет работать не на пустом месте, а на правильно собранной товарной и производственной базе. И теперь мы переходим к следующему огромному этапу — к тому, как весь этот каталог начинает жить в реальной работе бизнеса. То есть как клиент видит товары, как оформляет заказ, как работает корзина, как выглядит клиентский интерфейс, как устроена станция самообслуживания, электронное меню, а дальше — как этот заказ попадает в POS, на кухню, на склад и в доставку.

Теперь, когда у нас уже собрана компания, настроены точки продаж и создан весь каталог, пришло время посмотреть на систему глазами клиента. Потому что любая сильная платформа должна быть удобной не только для владельца бизнеса и сотрудников, но и для человека, который заказывает, покупает, оплачивает, отслеживает и возвращается снова. И сейчас я покажу, как выглядит клиентский путь в SABSUS. То есть как человек выбирает заведение, как видит каталог, как оформляет заказ, как использует бонусы, депозит, уведомления, как общается с компанией, как отслеживает доставку, как получает доступ к цифровым продуктам и как вообще живёт внутри клиентского интерфейса. Представим, что клиент открывает приложение или веб-версию компании Микеланджело Пицца. Первое, что его встречает, — это выбор типа заказа. Если в настройках заведения включены заказы в заведении, самовывоз и доставка, клиент сразу может выбрать нужный формат. Например, если он хочет заказать домой, он выбирает доставку. Если хочет сам заехать и забрать — выбирает самовывоз. Если хочет поужинать на месте — выбирает заказ в заведении. Если заведение ранее ещё не было выбрано, система сначала покажет список всех доступных заведений. Это особенно удобно, если у компании несколько точек продаж. Например, клиент может увидеть “Michelangelo Pizza Burbank”, “Michelangelo Pizza Glendale” и “Michelangelo Express Delivery”. Он выбирает нужную точку, и дальше весь интерфейс уже подстраивается именно под неё: по товарам, по ценам, по акциям, по доставке, по графику и по доступности. После выбора заведения человек попадает на главную страницу клиентского интерфейса. И здесь важно, что это не просто пустой каталог товаров. На главной странице есть поиск, рекламные баннеры, популярные товары, акции, информация о заведении, фотографии заведения, а также дополнительные блоки, которые компания хочет показать клиенту в первую очередь. Например, сверху можно видеть большой баннер с акцией “2 пиццы по цене 1 по будням с 14:00 до 16:00”. Ниже — популярные товары: “Пицца Маргарита”, “Пицца Пепперони”, “Комбо ужин”, “Тирамису”. Ещё ниже — блок с акциями, а потом уже информация о заведении, фотографии интерьера, кухни, витрины или команды. Если у клиента уже есть активные заказы или выставленные счета, система покажет их прямо в верхней части экрана. Это очень удобно, потому что человеку не нужно отдельно искать, где его текущий заказ. Он сразу видит, что заказ активен, в каком он статусе, сколько там позиций, и может быстро открыть карточку заказа. Если клиент проваливается внутрь заказа, он видит уже полноценную информацию. Он видит состав заказа, статус, историю, может посмотреть, где находится курьер, если это доставка, может скачать накладную, если по заказу есть документы, может подписать соглашение прямо внутри заказа, если это требуется, может связаться с менеджером через чат, может позвонить, может открыть детали, посмотреть количество элементов и все изменения по заказу. И здесь у системы есть очень интересная особенность — игровая галерея. Если компания включает этот раздел, клиент может открыть встроенные игры. Например, в системе уже есть несколько базовых игр, и компания может добавлять свои. Это не обязательная часть, но это хороший элемент удержания, вовлечения и брендового опыта, особенно если у бизнеса молодая аудитория, семейный формат или digital-ориентированная модель. Теперь переходим к самому важному разделу — каталог. В каталоге у клиента есть поиск и структура категорий. Если у компании есть и товары, и услуги, тогда каталог строится так, что сначала человек видит услуги, а ниже — товары. Например, если это не только ресторан, но и аренда оборудования для праздников, то вверху он может видеть услуги и аренду, а ниже — еду и напитки. Если это только ресторан, он будет видеть привычные категории: пицца, паста, салаты, десерты, напитки. Клиент может использовать поиск. И поиск работает не только по обычным товарам, но и по услугам. Например, человек может написать “пепперони” и сразу найти нужную пиццу. Или написать “аренда” и увидеть только арендные позиции. Или “тирамису” — и сразу перейти к десерту. Когда клиент открывает карточку товара, он видит всю визуальную и текстовую часть, которую мы ранее настроили в каталоге. Он видит фотографии, может видеть видео, видит название на своём языке, краткое и полное описание, цену, старую цену, если есть скидка, лейблы вроде “Хит”, “Новинка” или “Скидка”, а также может открыть модификаторы, если у товара есть вариации. Например, если человек открывает “Пиццу Пепперони”, система может показать выбор размера — 25, 30 или 40 сантиметров. Потом выбор теста. Потом дополнительные ингредиенты — сыр, оливки, грибы, соус. Если у товара есть ограничения по модификаторам, система их тоже соблюдает. Например, можно выбрать максимум три добавки. То есть клиент получает не просто карточку товара, а управляемый конфигуратор покупки. В карточке товара клиент также может добавить позицию в избранное. Это важно для возвратных клиентов. Например, если человек часто заказывает одну и ту же пиццу или один и тот же набор, он может быстро сохранить его в избранное и потом оформлять повторно без лишнего поиска. После выбора товаров человек переходит в корзину. В корзине он видит все выбранные позиции, может увеличить количество, уменьшить количество, удалить товар, проверить состав, посмотреть, какие модификаторы были выбраны, и сразу же переключить тип заказа. Например, человек сначала собирался на самовывоз, но потом решил заказать доставку. Он может переключить тип заказа прямо в верхней части интерфейса, и система сразу перестроит доступные параметры под этот тип. Если это доставка, появится выбор адреса. Если это самовывоз, появится выбор точки самовывоза. Если это заказ в заведении, система будет работать по своей логике. Если клиент выбирает доставку, система сразу показывает заранее добавленные адреса или адреса из истории заказов. Это очень удобно, потому что человек не должен каждый раз заново вводить один и тот же адрес. Он просто выбирает нужный адрес и продолжает оформление. Если подходящего адреса нет, можно добавить новый. Дальше клиент нажимает кнопку “Оплатить” или “Оформить заказ”, и система открывает интерфейс оплаты. И вот здесь SABSUS показывает, что это не просто стандартная форма оплаты, а продуманный клиентский путь. Сначала человек может выбрать, сколько чаевых он хочет оставить. Если компания включила эту функцию, клиент сам указывает чаевые. Дальше система предлагает использовать бонусы, если у клиента они есть. Например, если на счету 120 бонусов, человек может списать часть из них на заказ. После этого можно использовать депозитный счёт, если компания работает с депозитами. Например, если у клиента заранее внесено 200 долларов на баланс, он может оплатить заказ с депозита полностью или частично. Потом выбирается способ оплаты. Это могут быть наличные, банковская карта, онлайн-оплата, QR-оплата, другие подключённые методы. И после нажатия кнопки “Оформить заказ” заказ сразу создаётся, сохраняется в системе и переходит в дальнейший процесс обработки. В правом верхнем углу клиентского интерфейса обычно есть ещё несколько важных кнопок. Первая — это телефон или контакты. При нажатии человек видит, как связаться с компанией: телефон, Instagram, чат, другие каналы. Это очень важно, потому that клиент всегда может быстро выйти на контакт, не покидая интерфейс. Следующая кнопка — QR-код. Она нужна для нескольких сценариев. Например, если клиент оплачивает заказ через POS и хочет подтвердить списание с депозитного счёта, кассир может не делать это сам вручную, а клиент просто сканирует QR-код и подтверждает транзакцию со своей стороны. Также QR-код может использоваться для некоторых других действий — например, подтверждения операций, поиска товара, авторизации или действий внутри связанных процессов. Ещё одна важная кнопка — уведомления. Здесь клиент видит все push-уведомления и системные уведомления, которые пришли от компании. Например: “Ваш заказ принят”, “Ваш заказ передан на кухню”, “Ваш заказ уже в пути”, “Для вас доступна новая акция”, “У вас скоро сгорают бонусы”. То есть это уже полноценный коммуникационный слой между компанией и клиентом. Теперь откроем профиль клиента. В профиле человек может посмотреть и изменить свои данные, выйти из аккаунта, сменить заведение, посмотреть депозитный счёт, увидеть количество бонусов, а если у него есть другая роль внутри системы, даже переключить интерфейс. То есть один и тот же пользователь теоретически может быть и клиентом, и сотрудником, если у него есть доступ. Ниже в профиле есть раздел избранного. Здесь человек видит товары, которые он отметил как любимые. Дальше — раздел заказов, где хранится вся история покупок. Это очень важно, потому что клиент всегда может открыть прошлый заказ и, например, повторить его. Ещё ниже идёт раздел “Мои продукты”. Это как раз место для цифровых покупок. Если человек купил курс, видео, PDF-файл, HTML-страницу, подборку материалов или любой другой цифровой продукт, он увидит всё это именно здесь. И это очень сильная часть платформы, потому что клиентский кабинет становится не только местом для оформления доставки, но и местом для цифрового потребления. Дальше у клиента есть раздел оплаты, где можно видеть платёжную информацию, и раздел адреса, где можно добавлять, редактировать и удалять адреса доставки. Потом идёт раздел настроек. И здесь клиент уже может настроить собственный опыт использования системы. Он может переключить светлую и тёмную тему, может развернуть интерфейс на весь экран, если сидит с компьютера, может включить или выключить push-уведомления, SMS и email-уведомления. Также человек может подключить двухфакторную аутентификацию по номеру телефона, выбрать язык интерфейса, открыть условия обслуживания, написать в поддержку, самостоятельно удалить аккаунт или сменить email. То есть клиент получает полноценный контроль над своим профилем, а не просто кнопку “выйти”. Теперь отдельно покажу станцию самообслуживания. Это очень важный клиентский интерфейс для офлайн-точек. Если в настройках станции включено подключение аккаунта, то сначала система предлагает ввести номер телефона или подключиться через QR-код. Это нужно, чтобы привязать покупку к аккаунту клиента, начислить бонусы или использовать уже существующую лояльность. После этого открывается интерфейс выбора товаров. Слева категории, справа сами товары. Человек может выбрать тип заказа — например, самовывоз или кейтеринг, если они доступны. Можно переключать язык, настраивать чаевые, включать или выключать услуги, если бизнес использует не только товары. Система также может показывать баннеры в режиме ожидания. Например, если человек ничего не нажимает несколько секунд, станция начинает прокручивать рекламные баннеры, акции или брендовые ролики. И после успешной оплаты также можно показать брендированный экран “Спасибо за покупку”, номер заказа или рекламный баннер. Когда человек нажимает на товар в станции самообслуживания, он попадает в карточку товара, добавляет позиции, переходит в корзину и видит дополнительный блок рекомендаций. Например: “Не забудьте добавить напиток”, “Возьмите десерт со скидкой”, “Добавьте соус”. После этого он нажимает “Оформить заказ”, выбирает чаевые, способ оплаты и оплачивает. Если подключён принтер, система распечатает чек. Следующий важный клиентский слой — электронное меню. Это уже не обычный каталог, а специальный визуальный интерфейс, который компания может полностью собирать сама. Можно двигать элементы, добавлять фон, видео, изображения, тексты, кнопки, привязывать категории товаров и конкретные товары. Но главное преимущество в том, что электронное меню не живёт отдельно от системы. Оно синхронизировано в реальном времени. Если товара нет в наличии, если не хватает ингредиентов, если цена изменилась, если позиция выключена — всё это сразу отражается в электронном меню. То есть это не статичная витрина, а живая часть бизнеса. И здесь очень важно остановиться и понять, что клиент в SABSUS — это не просто человек, который нажал “Купить”. У него есть выбор типа заказа, выбор заведения, каталог, корзина, бонусы, депозит, уведомления, адреса, чат, документы, цифровые продукты, профиль, история, избранное, тёмная тема, многоязычие и разные формы взаимодействия — приложение, сайт, станция самообслуживания, электронное меню. То есть клиентский слой SABSUS — это уже полноценная среда взаимодействия между бизнесом и человеком. Не просто интернет-магазин, не просто приложение и не просто заказ еды. А именно управляемый клиентский опыт, который связан со всей остальной платформой. И теперь, когда мы посмотрели на систему глазами клиента, мы можем перейти к следующему большому этапу — к тому, как эти заказы попадают внутрь бизнеса. То есть дальше я покажу POS-интерфейс, открытие смены, создание и ведение заказа, работу кассира, оплату, чаевые, split payment, бонусы, депозит, задачи, доставку, комментарии на производство и всё, что происходит после того, как клиент уже нажал кнопку оформления заказа.

Теперь переходим к одному из самых важных интерфейсов всей системы — к интерфейсу продаж, то есть к POS-системе. Именно здесь заказ попадает внутрь бизнеса, именно здесь сотрудники работают с клиентом, добавляют товары, принимают оплату, отправляют позиции на производство, подключают доставку, используют акции, бонусы, депозит и ведут заказ дальше по всей цепочке. Первое, что нас встречает в POS-интерфейсе, — это ввод PIN-кода. Если в компании включён режим быстрого переключения сотрудников, каждый сотрудник может быстро войти в свой рабочий режим, не выходя из системы полностью. Это особенно важно для ресторанов, магазинов и точек с быстрым потоком, где одним терминалом пользуются несколько человек. После ввода PIN-кода система открывает кассовую смену. И здесь смена не стартует автоматически — сотрудник должен её подтвердить. Система показывает остаток наличных с предыдущей смены, а сотрудник указывает, сколько денег реально находится в кассе на момент открытия. Для этого есть удобный калькулятор наличных. Например, сотрудник может указать: пять купюр по 20 долларов, десять купюр по 10 долларов, восемь купюр по 5 долларов, монеты по 1 доллару и так далее. Система сама всё считает и автоматически подставляет итоговую сумму. После этого сотрудник нажимает “Открыть смену”, и только тогда начинается полноценная работа в POS. Дальше нас встречает главный экран POS. Сверху можно увидеть дату, погоду, информацию по смене и быстрые управляющие элементы. В общем списке заказов есть кнопка “Заблокировать систему”, чтобы сотрудник мог быстро защитить экран, не выходя полностью из аккаунта. Также можно переключать внешний вид списка — например, показывать заказы в виде списка или плиток. Рядом есть кнопка статистики по текущей смене, чтобы быстро видеть рабочую ситуацию. Основной раздел — это активные заказы. Здесь отображаются все текущие заказы, с которыми работает терминал. Сотрудник может сортировать их, фильтровать, смотреть по периоду, по статусу, по типу заказа, по каналу продаж. И именно отсюда начинается вся живая работа с заказом. Чтобы создать новый заказ, сотрудник нажимает кнопку “Новый заказ”. Система сразу спрашивает: какой это тип заказа? Заведение, самовывоз, доставка или кейтеринг. И этот список зависит от того, что включено в настройках конкретной точки продаж. Если заведение не работает на кейтеринг, кейтеринг тут не появится. Если выключена доставка, нельзя будет выбрать доставку. Для примера выберем сначала заказ в заведении. Система открывает рабочий интерфейс выбора товаров. Слева или сверху категории, рядом поиск, ниже сами карточки товаров. Если у товара есть модификаторы, система сразу показывает окно модификаций. Например, кассир выбирает пиццу, и сразу открывается выбор размера, теста и дополнительных ингредиентов. Если это напиток, можно выбрать объём. Если это набор или комбо, можно выбрать состав. У каждого элемента в заказе можно менять цвет. Это удобно в реальной работе. Например, один цвет может означать, что позиция уже отправлена на производство, другой — что уже готова, третий — что её пока только добавили. То есть сотрудники визуально быстрее ориентируются в заказе. Внутри заказа есть поиск товаров, категории и быстрый доступ к каталогу. Сотрудник может быстро найти позицию по названию, по штрих-коду или через визуальный выбор по категориям. Например, выбрать категорию “Пицца” и увидеть все пиццы. Потом перейти в “Напитки” и добавить напиток. Потом в “Десерты” и добавить тирамису. Ниже или рядом есть поле комментария на производство. Это очень важный момент. Например, клиент говорит: без лука, без острого, разрезать на восемь кусочков, упаковать отдельно. Сотрудник вписывает этот комментарий, и дальше он уже уйдёт в производство или упаковку. После этого можно нажать кнопку “Отправить на производство”. Это значит, что заказ или отдельные позиции переходят в производственный интерфейс. Если кнопку удержать или отменить действие, можно изменить поведение, в зависимости от сценария работы. То есть кассир контролирует не только сбор заказа, но и момент передачи его дальше. В верхней части интерфейса заказа есть отдельные вкладки. Первая — это каталог, где выбираются обычные товары. Следующая — услуги. И это очень важная часть, потому что POS в SABSUS умеет работать не только с товарами, но и с услугами. Если сотрудник переходит во вкладку “Услуги”, система показывает список всех доступных услуг. Например, аренда оборудования, бронирование, запись на сервис, кейтеринговая услуга или любая другая услуга компании. При выборе услуги можно указать сотрудника, если услуга привязана к конкретному специалисту. Например, мастер маникюра, парикмахер, консультант, монтажник, инструктор. Дальше выбирается дата, время, длительность, и система показывает список доступных слотов. Если товар или услуга арендные, система дополнительно попросит указать время возврата оборудования. Например, клиент хочет арендовать батут на субботу с 12:00 до 18:00. Сотрудник выбирает слот, система понимает, сколько времени займёт доставка, сборка, использование, разборка и возврат, и после этого позволяет добавить услугу в заказ. Если к услуге привязаны модификаторы, например тип покрытия, комплект шариков, дополнительный декор, они также будут доступны для выбора. Следующая вкладка — клиент. Здесь заказ связывается с человеком. Сотрудник может выбрать клиента из списка, найти по поиску, открыть по штрих-коду или создать нового прямо на месте. Например, если это новый клиент, можно сразу указать: имя, фамилию, номер телефона, email, дату рождения, группу клиента, максимальную скидку. Это очень важно, потому что заказ сразу связывается с CRM, историей клиента, бонусами, депозитом и дальнейшей маркетинговой логикой. Дальше идёт вкладка акции. Здесь сотрудник может либо выбрать акцию из списка, либо ввести промокод, либо даже отсканировать штрих-код акции. Например, если в системе есть акция “Купи две пиццы — получи напиток в подарок”, кассир может применить её прямо здесь. Если есть промокод от клиента, его можно ввести вручную и нажать “Применить”. Следующая вкладка — цифровые продукты. Если в заказе есть товар, к которому привязан цифровой продукт, здесь можно выбрать, какой именно цифровой контент будет начислен клиенту. Например, если компания продаёт курс, PDF-файл, видеоурок или цифровой абонемент, после оплаты он автоматически появится у клиента в его разделе “Мои продукты”. Дальше идёт вкладка задачи. Это очень сильная функция. Прямо из заказа можно ставить задачи сотрудникам. Например: отправить документы, уточнить адрес, сделать повторный звонок клиенту, отправить email, подготовить встречу, сделать видеозвонок, организовать доставку, забрать оборудование после аренды. Здесь можно указать заголовок задачи, комментарий, цвет, приоритет, срок выполнения, ответственного и тип задачи. То есть заказ в POS становится не просто продажей, а ещё и рабочей точкой постановки внутренних процессов. Следующая вкладка — история заказа. Здесь фиксируются все действия по заказу. Когда был добавлен товар, когда применили акцию, когда изменили статус, кто удалил позицию, кто изменил оплату, кто отправил на производство. Это очень важно и для контроля, и для прозрачности, и для разбора спорных ситуаций. Если выбран тип заказа доставка, появляется отдельный раздел адрес. Здесь сотрудник выбирает: доставляет наш курьер или агрегатор. Если выбирается агрегатор, нужно указать интеграцию. Если наш курьер — можно назначить курьера вручную или оставить автоматическое распределение. Дальше выбирается адрес доставки. Если клиент уже привязан, система может подтянуть адреса из его истории. Если подходящего адреса нет, сотрудник нажимает “Найти адрес” и вводит новый. Как только адрес выбран, система сразу может рассчитать стоимость доставки, налоги и доступные варианты доставки. Например: быстрая доставка от 15 до 30 минут — 15 долларов, стандартная доставка от 30 до 60 минут — 8 долларов, экономичная доставка — 5 долларов. Также можно оставить комментарий курьеру. Например: “Код от двери 4589”, “Подъезд сзади”, “Позвонить за 5 минут до приезда”, “Не звонить в домофон, ребёнок спит”. Сразу здесь же система может предложить поставить задачу курьеру, потому что в интерфейсе курьера работа может идти как через заказы, так и через задачи. В верхней части карточки заказа есть ещё несколько важных управляющих элементов. Здесь отображается номер заказа, текущий статус, кнопка печати накладной или документа, кнопка очистки заказа, выбор цвета заказа для визуальной навигации. То есть заказ можно визуально помечать, чтобы сотрудники быстрее ориентировались в потоке. Теперь посмотрим на список самих товаров в заказе. Здесь можно увеличивать количество через плюс, уменьшать через минус, удалять товар, менять параметры. Если у компании включена защита критических действий, система попросит пароль администратора для удаления определённых позиций или скидочных элементов. И здесь есть очень интересная функция — заехать ли курьеру купить товар перед доставкой. Например, если компания работает в модели, где некоторые товары можно докупать по дороге, сотрудник может включить этот параметр. Тогда курьер в своём интерфейсе увидит, что перед доставкой нужно заехать в магазин, купить определённый товар, отчитаться по чеку и после этого отвезти заказ клиенту. Это очень необычная и сильная функция для гибких бизнес-моделей. Дальше можно установить время крайней оплаты. Например, если клиенту отправляют счёт, можно указать, что он действителен только до 18:00 текущего дня. Если срок не указан, счёт считается бессрочным. Теперь переходим к самому важному — оплате. Сотрудник нажимает кнопку “Оплатить”, и система открывает окно оплаты. Здесь можно либо отправить счёт клиенту по email, либо принять оплату прямо внутри POS. Сначала система может спросить, хочет ли клиент оставить чаевые. Потом можно использовать бонусы, если они есть у клиента, или сумму с депозитного счёта. После этого выбирается метод оплаты. Если это наличный способ оплаты, система показывает удобный калькулятор сдачи. Например, сумма заказа 47 долларов, клиент дал 60, система сразу показывает, сколько нужно вернуть. Если выбран банковский метод, запускается соответствующий сценарий с терминалом или онлайн-платежом. Также в системе можно включить режим минимального депозита. Например, если это аренда батута, можно указать, что клиент должен внести минимум 50 долларов заранее, а остальную сумму оплатит потом. Тогда сотрудник в POS может принять только этот обязательный депозит. Следующий важный параметр — фискальный чек или нет. Если чек фискальный, налоги и транзакции регистрируются как полноценная фискальная операция. Если не фискальный — можно провести оплату без фискального учёта в определённых сценариях. Дальше идёт очень сильная функция — распределение чека. Например, если заказ на 135 долларов, клиент хочет сейчас оплатить только 100 долларов, а остальное позже. Сотрудник может разделить платёж. Причём если у метода оплаты есть комиссия, система может пересчитать итог с учётом этой комиссии. Например, если клиент хочет оплатить ровно 100 долларов с учётом комиссии, можно нажать “Переконвертировать”, и система пересчитает чистую сумму заказа так, чтобы после комиссии итоговая списанная сумма была ровно 100. После этого нажимается большая кнопка “Оплатить”. Если к устройству подключён принтер и включен режим автоматической печати, чек сразу печатается. Если в настройках включён QR-код на чеке, он будет добавлен снизу, и клиент сможет использовать его для дальнейшей оплаты, подтверждения или перехода по ссылке. Также можно распечатать предчек. Теперь возвращаемся в общий список заказов. Каждый заказ можно раскрыть и быстро увидеть детали, историю, кнопки оплаты, изменения статуса, отправки на производство, печати чека и редактирования. То есть сотрудник не обязан каждый раз проваливаться глубоко внутрь — основные действия доступны уже на уровне списка. Сверху в POS есть ещё несколько отдельных режимов. Первый — активные заказы. Второй — календарь обслуживания. Третий — архив. Четвёртый — доступные слоты. Пятый — маршруты. Календарь обслуживания особенно полезен для услуг и аренды. Например, если компания работает не только с едой, но и со слотами, доставкой оборудования или сервисами, сотрудник может выбрать дату и увидеть все будущие заказы и бронирования по расписанию. Архив — это уже история заказов, которая подтягивается из более глубокой базы хранения. То есть активная работа идёт в живом режиме, а архив позволяет возвращаться к старым заказам. Раздел доступные слоты нужен для быстрого понимания, какие услуги или арендные товары реально доступны на определённую дату и на определённое время. Например, можно выбрать субботу с 10:00 до 22:00 и посмотреть, какие батуты, какие сотрудники, какие услуги доступны именно в этот промежуток. Раздел маршруты — это отдельная сильная часть системы. Здесь можно заранее построить маршруты для курьеров, особенно если заказов много. Например, компания работает с арендой и доставкой батутов. Оператор может выбрать сразу нескольких курьеров, выбрать заказы, которые нужно развезти, и нажать “Сформировать задачи”. Тогда система сама создаст цепочку действий: доставить оборудование, собрать оборудование, позже забрать его у клиента, разобрать и вернуть обратно. Здесь есть карта, текущие локации, логика маршрутов и возможность вручную добавлять задачи, например “заехать в магазин” или “забрать документы”. Теперь откроем меню POS. Это отдельный слой быстрых функций для сотрудников. Первый раздел меню — товары. Здесь можно просто посмотреть товары и их остатки. Следующий раздел — остатки, где через поиск можно быстро проверить наличие товара или ингредиента. Дальше — смены. Здесь сотрудник может посмотреть кассовые смены, начать собственную смену, если пропустил её открытие, взять перерыв, вернуться с перерыва или закрыть свою смену. Если сотрудник закрывает смену, система показывает, когда она началась, сколько длилась, какие были операции. Если у сотрудника есть права менеджмента, он может закрыть смену сразу всем сотрудникам. Следующий пункт меню — создать транзакцию. Это очень полезно для реальной жизни. Например, из кассы нужно срочно взять 20 долларов, чтобы купить недостающие продукты в магазине. Сотрудник открывает раздел транзакций, выбирает расход, категорию, сумму, комментарий и загружает фотографию чека. То есть касса продолжает быть частью общего финансового контура бизнеса. Следующий пункт — оформить поставку от поставщика. Если в данный момент нет отдельного складского сотрудника, поставку можно зарегистрировать прямо из POS. То есть касса в SABSUS может быть не просто кассой, а реальным оперативным центром точки. Дальше идёт раздел устройство и оборудование. Здесь можно подключать принтеры через Bluetooth, выбирать, где этот принтер стоит, в каком цехе он печатает, на каком языке должны печататься задания. Например, на кухне могут работать сотрудники, которым удобнее испанский язык, а кассир работает на английском. Это можно настроить отдельно. Следующий блок — настройка терминала. Это уже настройка конкретного устройства. Здесь можно задать ширину категорий, размер карточек, спрашивать чаевые или нет, автоматически отправлять заказ на производство после оплаты или нет, ограничить методы оплаты на данном терминале, подключить экран клиента, настроить статусы заказов. То есть даже на уровне отдельного терминала SABSUS даёт очень гибкий контроль. Дальше есть раздел депозиты. Здесь сотрудник может пополнить клиентский депозит. Например, клиент хочет внести 500 долларов на баланс. Сотрудник находит клиента, указывает сумму, выбирает способ оплаты, принимает деньги, и они сразу попадают на депозитный счёт клиента. Это очень удобно для постоянных гостей, корпоративных клиентов или любых сценариев предоплаченного обслуживания. Также в меню есть кнопка вернуться в панель управляющего, если у сотрудника есть соответствующий доступ, и кнопка обновить данные, которая помогает пересинхронизировать систему. И ещё один очень важный момент — POS работает офлайн. То есть если пропадает интернет, система продолжает работать на локальном кэше. Понятно, что если нужна банковская транзакция через терминал, без связи с банком это не пройдёт. Но сама логика работы терминала, заказов и локальных действий не останавливается. Для реального бизнеса это огромный плюс. И ещё одна очень сильная функция в общем списке заказов — массовая сборка. Если заказов много, сотрудник может долгим нажатием выделить несколько заказов галочками. После этого сверху появляется кнопка “Собрать вместе”. Это особенно удобно, если нужно быстро собрать несколько заказов на складе, в магазине или для экспедитора. То есть POS помогает не только продавать, но и организовывать физическую сборку потока заказов. Также заказы можно сортировать по периодам, по каналам продаж, по дате, по дате доставки, по статусу, по сумме. Например, можно быстро отфильтровать только доставку, только кейтеринг, только заказы на сегодня, только неоплаченные, только самые дорогие или только заказы с определённым статусом. И вот здесь важно остановиться и понять, что POS в SABSUS — это не просто кассовое окно. Это полноценный операционный центр точки. Через него проходит: создание заказа, работа с клиентом, акции, бонусы, депозиты, услуги, аренда, адреса, доставка, курьеры, задачи, производство, печать, транзакции, поставки, оборудование, смены и даже офлайн-работа. То есть POS в этой системе — это не только место, где пробивают товар. Это место, где заказ начинает жить внутри бизнеса. И теперь, когда заказ уже создан, оформлен, оплачен и отправлен дальше, мы можем перейти к следующему этапу — к тому, как этот заказ показывается клиенту и сотрудникам на специальных экранах, а потом уходит в производство, на склад и дальше по цепочке исполнения.

Теперь, когда заказ уже создан в POS, собран, проверен и, если нужно, оплачен, он начинает двигаться дальше по системе. И здесь очень важно понять одну ключевую вещь: в SABSUS заказ не останавливается в кассе. После кассы он начинает жить сразу в нескольких направлениях. Его видит клиент. Его могут видеть сотрудники в зале. Его видит производство. Его может видеть упаковка. Его видит экран статусов заказов. А если используется экран клиента, то человек прямо у кассы видит, что происходит с его заказом в момент оплаты. Именно в этот момент становится особенно заметно, что SABSUS — это не просто касса и не просто учёт, а единая живая система исполнения. Начнём с экрана клиента. Это тот интерфейс, который обычно расположен рядом с кассой и направлен в сторону гостя. Он нужен для того, чтобы клиент в реальном времени видел, с каким заказом сейчас работает кассир, какую сумму нужно оплатить, какие позиции добавлены, какие чаевые указаны и что вообще происходит на этапе оформления. Чтобы экран клиента заработал, в POS нужно открыть интерфейс оплаты и включить привязку клиентского экрана. После этого всё, что делает кассир в текущем заказе, начинает отображаться на втором экране. Например, кассир добавляет пиццу, напиток и десерт — клиент это видит. Кассир применяет акцию — клиент это видит. Кассир вводит чаевые, бонусы или депозит — всё это тоже можно показывать на клиентском экране. И когда клиент завершает оплату, этот экран не просто остаётся открытым. После успешной оплаты окно кассы для клиента закрывается и система показывает благодарность. Например: “Спасибо за покупку. До встречи.” То есть клиентский экран становится частью красивого и прозрачного офлайн-опыта, где человек не только отдаёт деньги, а понимает, что именно сейчас происходит. Это особенно важно в ресторанах, кофейнях, магазинах и точках с живым потоком, потому что повышает доверие и делает сам процесс оплаты чище и понятнее. Следующий важный интерфейс — экран заказов, или экран статусов. Это тот экран, который можно поставить в заведении, чтобы клиенты и сотрудники видели статусы готовности заказов. По сути, это современный формат табло заказов. Например, как в сетях быстрого питания, где человек получает номер, потом смотрит на экран и видит, готов ли его заказ, находится ли он в процессе или уже можно забирать. В SABSUS этот экран можно очень гибко настраивать. Можно показывать или не показывать номер заказа. Можно вместо номера показывать имя клиента, если компания хочет работать в более персонализированном формате. Можно менять размер номера заказа. Можно менять размер текста. Можно показывать или скрывать тип заказа — например, доставка, самовывоз, заказ в заведении. Можно показывать или скрывать время. Можно показывать или скрывать сам текст статуса. То есть компания может собрать именно тот визуальный стиль, который ей нужен. Например, для ресторана быстрого питания можно оставить только крупные номера заказов и статус “Готов”. А для более премиального заведения можно показывать имя клиента, время и чуть более мягкую визуальную подачу. Если компания хочет минималистичный интерфейс, можно вообще скрыть статусный текст и оставить только красивые крупные номера с динамикой по времени. И это кажется простой вещью, но на самом деле очень важно. Потому что экран статусов разгружает кассу, снижает количество вопросов “а мой заказ уже готов?”, улучшает клиентский опыт и делает процесс выдачи намного более организованным. Теперь переходим к следующему этапу — производству, или интерфейсу кухни. Как только кассир отправляет заказ на производство, нужные позиции попадают в производственный центр. И здесь начинается уже другая часть жизни заказа — не финансовая и не клиентская, а исполнительная. В интерфейсе кухни или производства сотрудник видит не просто список заказов, а рабочее пространство по приготовлению и сборке. На карточке заказа сразу видно: номер заказа, дату, статус, количество товаров, сумму, тип заказа, и очень важный элемент — заметку на производство, которую оставил кассир. Например: “Без лука”, “Соус отдельно”, “Разрезать на 8 кусочков”, “Упаковать отдельно”, “Не класть салфетки”, “Сначала приготовить пасту, потом пиццу”. Также на карточке заказа может отображаться, кто именно владелец заказа внутри бизнеса — менеджер, официант, кассир или другой сотрудник. Это помогает быстрее понять контекст, если нужно что-то уточнить. На карточке производства есть кнопка “Начать заказ”. Когда сотрудник нажимает её, система понимает, что данная позиция или заказ взяты в работу. Дальше может появляться статус “В процессе”, а потом “Готово”. Если нужно, сотрудник может завершить не отдельную позицию, а сразу весь заказ, если всё полностью приготовлено. То есть производство работает уже не в бумажном режиме и не в криках между залом и кухней, а в живой цифровой очереди. Отдельно очень важна кнопка-колокольчик — уведомить официанта или ответственного сотрудника, что заказ готов. Например, в ресторане официант сразу получает сигнал, что блюдо можно выносить. В формате выдачи заказов касса или упаковка понимают, что позиция готова к дальнейшему этапу. Если нажать на конкретный товар внутри производственного интерфейса, можно открыть его технологическую карту и инструкцию. И вот тут видно силу системы. Повар может посмотреть: как должен выглядеть товар, какие фотографии есть у блюда, какая рецептура у позиции, какая калькуляция, какой процесс приготовления, какая логика упаковки. То есть сотрудник не просто видит название “Пицца Маргарита”, а получает все данные, необходимые для правильного исполнения. Это особенно важно для новых сотрудников, для стандартизации качества и для бизнеса, где важно повторяемое качество продукта. Например, если в карточке указано: “Тесто раскатать до 30 см, нанести 80 грамм соуса, добавить 120 грамм моцареллы, выпекать 6 минут, после выпечки добавить 4 листа базилика”, то повар прямо внутри системы видит эту инструкцию и работает по ней. Если это не кухня, а упаковка, сотрудник может увидеть: “Положить товар в коробку, отдельно добавить соус, салфетки, вилку и наклейку бренда”. То есть один и тот же интерфейс подходит не только кухне, но и любому производственному цеху. И вот здесь появляется следующий важный момент: цеха. Производственный интерфейс можно использовать не только для горячей кухни. Он работает для разных линий. Например: горячий цех, холодный цех, бар, упаковка, мясной цех, зона десертов, производственный участок. Сотрудник может выбирать конкретный цех, в котором он работает, и видеть только свои задачи. Это очень важно для разделения нагрузки и правильной маршрутизации внутри бизнеса. Например, напитки уходят в бар, салаты — в холодный цех, пицца — в горячий, а упаковка видит уже те позиции, которые нужно собирать и комплектовать на доставку. То есть заказ внутри бизнеса не просто “готовится”, а проходит через правильные участки. В производственном интерфейсе есть ещё отдельный раздел “Рецепты”. Это очень полезно, потому that сотрудник может в любой момент через категории или поиск открыть рецепты товаров, ингредиентов, полуфабрикатов и других позиций. То есть даже если сейчас нет активного заказа, повар или производственный сотрудник может быстро открыть нужную карточку и посмотреть, как правильно работать с позицией. Следующий раздел внутри производства — запасы. Это особенно сильная часть, потому что кухня или цех не оторваны от склада. Сотрудник может открыть свои текущие запасы, посмотреть, что есть на складе его цеха, найти товар через поиск, открыть историю перемещения. Если товар или ингредиент есть в наличии, но его нужно списать, это можно сделать прямо отсюда. Например, сотрудник видит, что в цехе осталось мало моцареллы, открывает карточку и проверяет остаток. Или, например, один продукт испортился. Тогда он может выбрать причину списания — срок годности, повреждение, нарушение хранения, брак — добавить комментарий, загрузить фотографию и провести списание. То есть кухня становится не только местом приготовления, но и местом реального оперативного контроля за ресурсами. Также здесь есть кнопка “Отсканировать”. Если сотруднику нужно быстро найти товар или ингредиент, он может не искать его вручную, а просто отсканировать код. Для реального производства это очень полезно, потому что ускоряет работу. Теперь важно показать ещё одну вещь: в производстве можно фильтровать заказы по типам заказа. Например, посмотреть только доставку, только самовывоз, только кейтеринг или увидеть всё вместе. Это очень удобно, потому что, например, кейтеринговый заказ требует другого уровня внимания и другой очередности, чем обычный кофе на вынос. Также здесь можно смотреть статистику по цеху, по потоку задач, по текущей загрузке, если компания использует это в своём сценарии работы. И, как и другие рабочие интерфейсы, кухня или производство поддерживают открытие и закрытие смен. То есть сотрудники фиксируют начало своей работы, время, завершение смены, и это уже не живёт отдельно от всей остальной платформы. Теперь важно сделать паузу и зафиксировать, что происходит в целом. Клиент оплатил заказ или оформил его. POS зарегистрировал этот заказ, привязал клиента, способы оплаты, акции, бонусы и комментарии. Экран клиента показал прозрачный процесс оплаты. Экран заказов показал заказ гостям и сотрудникам. Производство получило конкретную задачу с рецептами, комментариями и статусами. То есть заказ уже живёт одновременно в нескольких слоях бизнеса. И это ключевая вещь, которая отличает SABSUS от простых систем. Здесь касса не живёт отдельно от кухни. Кухня не живёт отдельно от экрана статусов. Экран статусов не живёт отдельно от клиента. А клиент не живёт отдельно от заказа. Всё связано. Но на этом исполнение заказа ещё не заканчивается. Потому что дальше заказ очень часто упирается в реальные ресурсы: ингредиенты, поставки, остатки, перемещения, инвентаризацию, возвраты, печать ценников и работу склада. И поэтому следующий большой этап — это то, как в SABSUS работает складской интерфейс, как принимаются поставки, как движутся товары, как проходят списания, перемещения и инвентаризация, и как всё это связано с заказами, производством и поставщиками.

Теперь переходим к следующему очень важному этапу — к складскому интерфейсу. Потому что в реальном бизнесе заказ не существует отдельно от товара, ингредиентов, упаковки, поставок и остатков. Если система не умеет связывать продажи с реальным складом, значит рано или поздно бизнес начнёт терять деньги, путаться в наличии, забывать о закупках, допускать ошибки в списаниях и работать вслепую. В SABSUS склад — это не просто таблица с количеством товара. Это полноценный рабочий интерфейс, через который сотрудник принимает поставки, проверяет остатки, делает заявки поставщикам, перемещает товары между складами, оформляет возвраты, проводит инвентаризацию и даже печатает ценники. Перед началом работы складской сотрудник, так же как и другие сотрудники системы, может открыть свою смену. После этого первое, что он делает, — выбирает склад, на котором работает. Это важно, потому что в одной компании может быть несколько складов. Например, основной склад ресторана, склад бара, склад упаковки, склад второй точки, склад центрального хранения или производственный склад. И после выбора склада сотрудник попадает в основной интерфейс склада. Первый крупный раздел — это приёмка поставки. Именно отсюда начинается реальный вход товара в систему. Например, в наш ресторан приехала поставка: мука, сыр, соус, салфетки, коробки для пиццы и напитки. Сотрудник склада открывает приёмку и первым делом выбирает поставщика, который делает поставку. Дальше система предлагает несколько сценариев работы. Первый — сканировать. Это очень удобно, если поставщик тоже работает внутри системы SABSUS. В этом случае он может заранее оформить накладную в своём интерфейсе, распечатать её с QR-кодом или штрих-кодом, а складской сотрудник просто сканирует этот код, и система автоматически подтягивает всю поставку. То есть не нужно вручную заново собирать документ — всё уже приходит в готовом виде. Рядом есть кнопка список. Здесь сотрудник может посмотреть все заявки и поставки, связанные с этим поставщиком, и выбрать нужную поставку из списка. Например, поставщик заранее прислал несколько документов, и можно выбрать именно тот, который сейчас физически приехал. Если сотрудник не использует сканирование, есть второй сценарий — добавить вручную. Тогда он открывает форму, выбирает товар, указывает количество, цену, сумму и пишет комментарий. Например: моцарелла — 10 килограммов, томатный соус — 12 упаковок, коробки для пиццы — 50 штук, салфетки — 100 упаковок. То есть поставку можно собрать вручную, как обычный приходный документ. Третий сценарий — один из самых сильных — фото накладной. Если у сотрудника есть бумажная накладная, он просто фотографирует её, а система автоматически распознаёт товары и пытается внести их в поставку. Если в системе уже есть такие товары, они связываются автоматически. Если каких-то позиций не хватает, платформа предлагает добавить их. Это очень удобно, потому что резко ускоряет приёмку и уменьшает объём ручного труда. Например, приехала накладная от нового поставщика сыров. Сотрудник фотографирует документ, система распознаёт, что там есть моцарелла, пармезан, сливки и упаковка, подтягивает известные позиции, а неизвестные предлагает создать. То есть складской интерфейс здесь работает не только как журнал, но и как ускоритель реальной складской работы. Ниже по приёмке показывается количество позиций, сумма, галочки проверки и возможность загрузить дополнительные фотографии. Например, можно добавить фотографии коробок, товара, состояния упаковки или любых подтверждений. И здесь же внизу есть большая кнопка сканера, чтобы добавлять товары в поставку по штрих-коду, не ища их вручную через поиск. Когда всё проверено, сотрудник нажимает продолжить, и поставка добавляется в систему. С этого момента товары уже появляются в складском контуре бизнеса, могут участвовать в производстве, в расчёте остатков, в продажах и в дальнейших движениях. Следующий раздел — поставки. Здесь хранится список всех уже созданных поставок. Сотрудник может открыть старую поставку, посмотреть детали, отредактировать её, если у него есть доступ, или распечатать документы. И это очень важно, потому что поставка в SABSUS — это не просто одноразовая операция. Это полноценный документ, к которому можно возвращаться. Кроме этого, отсюда можно печатать не только документ поставки, но и ценники на товары, которые пришли в этой поставке. Например, приехали новые напитки или десерты, и после приёмки нужно сразу распечатать ценники для витрины. Система позволяет сделать это прямо из контекста поставки. В этом же разделе также есть сканер. То есть если сотруднику нужно быстро открыть уже существующую поставку по QR-коду или штрих-коду, он может сделать это без долгого поиска. Следующий огромный раздел — запасы. Именно здесь сотрудник видит реальные остатки по выбранному складу. Здесь можно искать товары и ингредиенты через поиск, можно фильтровать по категориям, можно быстро оценивать наличие. Интерфейс можно адаптировать под экран: показать один товар в строке, два товара в строке, три и так далее. Это особенно полезно на мобильных устройствах и планшетах, когда сотрудник работает прямо на складе и быстро просматривает фактическое наличие. Например, кладовщик открывает раздел “Запасы”, выбирает категорию “Сыры” и сразу видит: моцарелла — 18 кг, пармезан — 4 кг, сырный микс — 7 упаковок. Потом переключается в категорию “Упаковка” и видит: коробки 30 см — 82 штуки, коробки 40 см — 29 штук, салфетки — 300 упаковок, соусницы — 48 штук. То есть это быстрый реальный снимок текущего состояния склада. Следующий раздел — заказы поставщику, или заявки поставщикам. Это уже не приёмка, а противоположный сценарий — когда компания понимает, что ей нужно заказать что-то новое. Например, запас моцареллы подходит к концу, упаковка заканчивается, томатный соус почти на минимуме. Сотрудник или менеджер открывает заявки поставщикам, создаёт новую заявку, указывает поставщика, добавляет товары, количество, комментарии и дату. После этого заявку можно либо отправить по email, либо поставщик увидит её в своём интерфейсе, если работает через SABSUS. Также такую заявку можно распечатать как PDF и передать вручную. Это очень важно, потому что закупка здесь не живёт отдельно от остатков и поставок. Система позволяет пройти путь: мы увидели, что товара мало → создали заявку → отправили поставщику → приняли поставку → товары попали на склад. Следующий раздел — перемещение. Это уже логика перемещения между складами. Например, у нас есть основной склад и склад точки в Бёрбанке. На основном складе есть 20 килограммов муки, а на точке осталось только 2. Сотрудник открывает перемещение, выбирает, с какого склада и на какой нужно передвинуть товар, добавляет позиции, указывает причину перемещения, пишет комментарий, при необходимости добавляет фотографии. Товары можно добавить через поиск или через сканер. Например, мы перемещаем: мука — 10 килограммов, моцарелла — 5 килограммов, коробки для пиццы — 40 штук. После подтверждения система фиксирует это движение, и остатки корректно меняются на обоих складах. Это крайне важно для компаний с несколькими точками, несколькими складами или разными зонами хранения. Следующий раздел — списания. Здесь сотрудник оформляет всё, что нужно убрать из товарного контура. Например: просроченные ингредиенты, испорченные продукты, повреждённая упаковка, списание по браку, списание по возврату, списание по нарушению условий хранения. Сотрудник выбирает склад, выбирает причину списания, оставляет комментарий, при необходимости добавляет фотографию и указывает товары. Например, если часть томатов испортилась, можно выбрать причину “истечение срока годности”, указать количество, сделать фото и провести списание. Если разбились бутылки напитков — указать причину “повреждение”. То есть списание в системе — это документированное действие, а не просто уменьшение цифры в остатке. Следующий раздел — возврат товаров поставщику. Это очень важный сценарий, который многие системы не прорабатывают достаточно глубоко. Например, приехала поставка, но часть товара не соответствует качеству. Или поставщик прислал неправильную позицию. Или товар оказался повреждён. Сотрудник открывает возврат, выбирает поставщика, причину возврата, пишет комментарий, добавляет нужные товары. Причём можно не возвращать всю поставку целиком, а только часть. Например, из 20 упаковок вернуть 3. Если нужно, можно даже сначала отсканировать поставку, а потом уже выбрать, какие позиции из неё реально возвращаются. Следующий крупный раздел — инвентаризация. Это уже контрольная проверка склада. И именно здесь система показывает себя как реальный инструмент учёта, а не просто журнал операций. Во время инвентаризации сотрудник видит, сколько система ожидает товара по базе, и рядом указывает, сколько товара фактически находится на складе. Есть поиск, есть удобная логика отметок, есть возможность ставить галочку, что товар уже проверен. Когда карточка проверена, она становится визуально выделенной, например зелёной, чтобы сотрудник понимал, что уже прошёл эту позицию. Например, система ожидает: моцарелла — 18 кг, по факту нашли 17.4 кг; коробки — 82 штуки, по факту — 81; салфетки — 300 упаковок, по факту — 300. После завершения инвентаризации система обновляет остатки и фиксирует расхождения. Это очень важно, потому что бизнес наконец-то получает реальную картину склада, а не просто теоретический учёт. Следующий важный инструмент — печать. И здесь SABSUS снова показывает, что это не просто система учёта, а рабочий инструмент для офлайн-бизнеса. В разделе печати можно собрать собственный шаблон ценника. Например, выбрать, что именно будет напечатано: название товара, цена, единица измерения, QR-код, штрих-код, вес товара, дата, название заведения, изображение, свободный текст. Можно настраивать размер, цвет, расположение блоков, язык печати, принтер и даже скачивать всё это как PDF. Например, если в поставке приехали новые десерты, сотрудник выбирает их, указывает, что нужно напечатать по 10 ценников на каждый, задаёт шаблон с названием, ценой и QR-кодом, выбирает принтер — и система сразу готовит нужное количество этикеток. То есть печать ценников встраивается прямо в складской процесс. Сверху в складском интерфейсе также может отображаться сводка по операциям: сколько сегодня было приёмок, сколько перемещений, сколько возвратов, сколько списаний. И так же, как в других рабочих интерфейсах, сотрудник завершает свою смену в конце работы. И здесь важно зафиксировать ключевую мысль. Склад в SABSUS — это не изолированный модуль. Он связан с каталогом, с поставщиками, с производством, с точками продаж, с заказами, с упаковкой, с инвентаризацией, с ценниками и с финансовыми документами. То есть когда бизнес принимает поставку, двигает товар, списывает позиции или делает инвентаризацию, он работает не “где-то отдельно”, а прямо внутри общей экосистемы компании. Но склад — это только одна сторона товарного контура. Вторая сторона — это те, кто эти товары вообще предлагает бизнесу, продаёт компании ингредиенты, отправляет коммерческие предложения, работает как поставщик или даже как реселлер. И поэтому следующий важный этап — это интерфейс поставщика, где я покажу, как в SABSUS работает сторона внешнего партнёра: баланс, офферы, заказы поставщику, каталог, предложения новых товаров, документы, сообщения и настройки поставщика.

Теперь переходим к следующему очень важному интерфейсу — к интерфейсу поставщика. И это один из тех блоков, который особенно хорошо показывает, что SABSUS — это не просто внутренняя система компании, а полноценная экосистема, в которой могут работать не только сотрудники бизнеса, но и его внешние партнёры. Потому что в реальной жизни поставщик — это не просто название в справочнике и не просто номер телефона в заметках. Это отдельный участник процесса. Он предлагает цены. Он получает заказы. Он работает с документами. Он отправляет товары. Он может общаться с компанией. Он может показывать, что у него есть в наличии. А если это реселлерская модель, он может даже работать по товарам, которые потом продаются клиенту дальше. Именно поэтому в SABSUS поставщик получает не просто запись в базе, а собственный рабочий интерфейс. Для примера представим, что у нашей компании Микеланджело Пицца есть поставщик, который поставляет сыр, соусы, упаковку и некоторые дополнительные продукты. А ещё есть второй партнёр, который работает как реселлер и предлагает готовые позиции под заказ. Система умеет поддерживать оба формата. Если поставщик является именно реселлером, тогда в его интерфейсе появляется раздел баланс поставщика. Это значит, что компания может начислять деньги этому партнёру, учитывать взаиморасчёты и видеть финансовую картину работы с ним. Если это просто поставщик сырья, без реселлерской логики, этот раздел можно не использовать. Дальше идёт очень важный раздел — офферы, или предложения цен. Именно здесь поставщик показывает компании, по какой цене он готов предложить ту или иную позицию. Например, поставщик открывает раздел офферов и создаёт предложение: моцарелла — 6 долларов за килограмм, томатный соус — 3.2 доллара за упаковку, коробки для пиццы 30 см — 0.45 доллара за штуку, салфетки — 1.1 доллара за упаковку. Если это реселлер, он может предлагать не ингредиенты, а уже готовые товары. Например: смартфон — 320 долларов, наушники — 45 долларов, кофемашина — 180 долларов. То есть система поддерживает как поставку сырья, так и товарную модель. И здесь важно, что офферы — это не просто “прайс где-то в переписке”. Это живые предложения внутри платформы. Компания может видеть, какие цены предлагает тот или иной поставщик, сравнивать их, выбирать наиболее выгодные, использовать эти предложения в закупках и связывать с дальнейшими действиями. Например, если у нас есть два поставщика сыра, один может предлагать моцареллу по 6 долларов за килограмм, а другой по 5.7. Система позволит компании видеть это не вручную в Excel, а прямо в рабочем процессе. А если речь идёт о реселлерской модели, то можно увидеть, кто из партнёров предлагает выгоднее конечный товар и в каком объёме. Следующий раздел — заказы. И вот здесь начинается уже настоящая рабочая связка между компанией и поставщиком. В интерфейсе поставщика этот раздел может называться заказы поставщику или заказы реселлеру — в зависимости от модели работы. Например, компания создала заявку на поставку: 10 килограммов моцареллы, 20 упаковок томатного соуса, 50 коробок для пиццы, 100 упаковок салфеток. Если поставщик работает внутри SABSUS, он открывает свой интерфейс и видит этот заказ у себя. То есть ему не нужно получать это в стороннем мессенджере, искать письмо, переписывать в блокнот или уточнять по телефону. Он уже видит заказ внутри платформы. Если это реселлер, ситуация может выглядеть так: компания хочет получить 10 единиц определённого товара. Один реселлер предлагает 5 штук по одной цене, другой — ещё 5 по другой. Система позволяет учитывать такие сценарии. То есть поставщик или реселлер работает не как абстрактный контакт, а как активный участник цепочки снабжения. Следующий раздел — каталог. Здесь важно понимать одну вещь: поставщик не обязательно должен менять основной каталог компании. Чаще всего он просто видит каталог, чтобы понимать, какие товары, ингредиенты или позиции уже существуют в системе, и от этого отталкиваться в своих предложениях. Например, поставщик открывает каталог и видит, что у компании уже есть категории: сыры, соусы, упаковка, напитки, ингредиенты для пиццы. Он может посмотреть, какие позиции уже используются, и дальше делать более точные предложения. То есть каталог внутри интерфейса поставщика — это не хаос и не отдельный мир, а часть общей структуры данных компании. Следующий раздел — предложения товара. И это один из самых сильных блоков интерфейса поставщика. Потому что здесь поставщик может не просто выбрать существующую позицию, а предложить новый товар, которого ещё нет в системе. Например, поставщик хочет предложить новый итальянский соус для пиццы. Он нажимает “Добавить предложение товара” и указывает: название, цену, артикул, штрих-код, комментарий, фотографии, сроки хранения, условия хранения, сертификаты, PDF-файлы, дополнительные документы. То есть поставщик не просто пишет: “У меня есть новый соус, хотите?” Он отправляет компании полностью оформленное предложение в структурированном виде. Например, можно сделать так: “Соус Pomodoro Premium”, цена 4.2 доллара за банку, срок хранения 12 месяцев, условия хранения — сухое прохладное место, сертификаты качества приложены, фото упаковки приложены, штрих-код указан. Компания получает это предложение прямо в системе и может принять решение — добавить позицию, отклонить или запросить дополнительную информацию. То же самое работает и для реселлеров. Если это не поставщик ингредиентов, а реселлер товаров, он может предложить новую позицию для продажи. Например, если это не ресторанный бизнес, а магазин техники, реселлер может добавить: название товара, цену, артикул, штрих-код, фото, срок гарантии, сертификаты, комментарий по поставке. Таким образом SABSUS поддерживает не только классическую закупку сырья, но и очень гибкие модели товарного партнёрства. Следующий раздел — сообщения. И это ещё одна очень важная часть интерфейса поставщика. Потому что любая работа с поставками почти всегда сопровождается вопросами: когда приедет товар, есть ли замена, можно ли увеличить объём, какой статус заказа, почему изменили цену, есть ли другой размер упаковки, какие документы приложены. Вместо того чтобы уводить всё это в сторонние чаты, почту или мессенджеры, поставщик может общаться с менеджерами компании прямо внутри системы. Например, менеджер компании пишет: “Подтвердите, пожалуйста, что моцарелла будет доставлена завтра до 10:00.” Поставщик отвечает внутри интерфейса: “Да, поставка подтверждена, машина выезжает в 7:30, ориентировочное прибытие — 9:15.” Или: “Из 20 упаковок соуса сейчас можем дать только 15, остальные 5 будут через два дня.” То есть переписка живёт внутри рабочего процесса, а не отдельно от него. Следующий раздел — документы. Это ещё один очень сильный слой. Поставщик может отсюда распечатывать накладные, смотреть свои поставки, выгружать документы, скачивать PDF-файлы и в целом работать с документальным контуром. Например, если поставщик оформил поставку, он может распечатать накладную прямо из системы. Если компания попросила пакет документов за месяц, поставщик может подготовить выгрузку. Если нужно поднять старую поставку, открыть её и распечатать подтверждение — всё это тоже делается здесь. И это очень важно, потому что документы не живут отдельно от поставок, офферов, сообщений и заказов. То есть снова вся логика собирается в одном месте. Теперь переходим к разделу настройки поставщика. Здесь уже настраивается сама карточка и поведение этого внешнего партнёра внутри системы. Можно загрузить логотип компании, указать название компании, контакты, адрес, номера телефонов, email и другие данные. То есть поставщик внутри платформы выглядит не как безымянный контрагент, а как реальный цифровой партнёр со своей полноценной карточкой. И здесь есть очень важный параметр — до какого времени принимаются заказы. Например, поставщик может указать, что приём заказов заканчивается в 16:00. Это значит, что всё, что компания отправит после 16:00, уже не пойдёт в поставку на текущий день и будет считаться заказом на следующий. Также поставщик может указать, сколько времени у него есть на загрузку товаров или подтверждение поставки. Например, можно настроить так: приём заказов до 15:00, подтверждение поставки в течение 2 часов, загрузка документов не позднее 18:00. И тогда компания работает уже не в хаосе и не в режиме “а вы точно увидели наше сообщение?”, а в понятной логике бизнес-правил. Теперь приведу несколько реальных примеров, чтобы было ясно, как это работает в жизни. Первый пример. У компании заканчивается сыр. Менеджер или складской сотрудник видит в системе, что остаток моцареллы упал ниже минимального. Создаётся заявка поставщику. Поставщик открывает свой интерфейс и видит новый заказ. Он подтверждает, что может поставить 10 килограммов завтра утром. Если нужно, он пишет сообщение: “Часть объёма будет из новой партии, сертификаты загружены в документы.” На следующий день складской сотрудник открывает поставку, сканирует QR-код с накладной или выбирает её из списка, принимает товар — и всё это замыкается внутри одной платформы. Второй пример. Поставщик хочет продвинуть новый товар. Он заходит в предложения товара и добавляет новый соус для пиццы. Загружает фото, сертификаты, срок хранения, цену и комментарий. Компания видит предложение, анализирует, принимает решение и, если товар подходит, добавляет его в каталог и закупочную логику. То есть поставщик становится не пассивным исполнителем, а частью развития ассортимента. Третий пример. Реселлер предлагает конечный товар. Компания хочет закрыть заказ клиента на 10 единиц определённой позиции. Один реселлер предлагает 5 штук по одной цене, второй — оставшиеся 5 по другой. Система позволяет учитывать это в логике предложений, цен и дальнейшего исполнения. То есть SABSUS подходит не только для ресторанных поставщиков, но и для более сложных торговых моделей. Четвёртый пример. Менеджер компании хочет быстро уточнить статус поставки. Вместо звонков, поиска переписок и пересылки скриншотов он просто открывает сообщения поставщика внутри системы и задаёт вопрос в контексте нужного заказа. То есть коммуникация не вырывается из процесса. И вот здесь очень важно понять, что интерфейс поставщика в SABSUS — это не декоративное дополнение. Это реальный внешний рабочий слой платформы. Он позволяет выводить поставщиков и реселлеров в одну цифровую среду с компанией, заказами, документами, каталогом и сообщениями. То есть компания в SABSUS работает не только со своими сотрудниками и клиентами. Она может встроить в систему и свою внешнюю цепочку снабжения. И это очень сильный момент. Потому что большинство систем заканчиваются на складе компании. А здесь логика идёт дальше — к тем, кто поставляет товары, ингредиенты, упаковку, документы и цены. Но даже на этом цепочка исполнения ещё не заканчивается. Потому что после того, как товар принят, произведён, упакован и готов к отправке, его нужно ещё доставить клиенту. А доставка — это уже отдельный большой мир: транспорт, маршруты, face verification, пакетные маршруты, приём оплаты курьером, фотографии подтверждения, задачи и работа в режиме заказов или в режиме задач. И поэтому следующий большой этап — это интерфейс курьера, где я подробно покажу, как в SABSUS работает последняя миля и как заказ доходит до клиента.

Теперь переходим к следующему очень важному этапу — к интерфейсу курьера. И здесь начинается уже та часть бизнеса, где заказ выходит за пределы точки продаж и должен реально доехать до клиента. Для большинства компаний именно последняя миля становится одним из самых сложных этапов. Потому что здесь уже мало просто принять заказ и приготовить его. Нужно назначить исполнителя, построить маршрут, не потерять адрес, учесть оплату, подтвердить доставку, иногда купить что-то по дороге, иногда забрать оборудование обратно, а иногда ещё и работать сразу с несколькими заказами в одном рейсе. Именно поэтому в SABSUS интерфейс курьера — это не просто список доставок. Это полноценная рабочая среда для курьера, где есть транспорт, маршруты, карта, статусы, оплата, чат, задачи, доказательство доставки и контроль смены. Прежде чем курьер начнёт использовать этот интерфейс, сначала нужно пройти настройку курьера. И первый важный раздел здесь — это гараж. Что такое гараж? Это место, где курьер добавляет свои способы передвижения. Например, автомобиль, велосипед или пешую доставку. Курьер нажимает “Добавить новый” и выбирает тип транспорта. Если выбран автомобиль, система попросит указать: марку автомобиля, модель автомобиля, госномер, цвет автомобиля, а также расход топлива на 100 километров. Например, можно указать: Toyota Corolla, 2021, белый цвет, номер такой-то, расход 7.5 литров на 100 километров. Если выбран велосипед или пешком, тогда всё проще — достаточно выбрать тип транспорта и сохранить. Дальше в настройках курьера можно указать текущую цену топлива, выбрать единицу измерения — литры или галлоны, а также задать параметры уведомлений, выбрать тип навигации — например Google Maps или Apple Maps — и выбрать единицы измерения расстояния: километры или мили. То есть уже на этом этапе система понимает не просто кто доставляет, а в каком формате он реально работает. После того как транспорт добавлен, курьер переходит к началу смены. На главной странице перед стартом он видит список транспортов и выбирает, на каком именно транспорте будет работать сегодня. Например, утром он может выйти на машине, а в другой день — на велосипеде. Это важно, потому что от этого зависят маршруты, время доставки и часть расчёта затрат. После выбора транспорта начинается очень сильный с точки зрения безопасности и контроля этап — регистрация смены по лицу. Курьер должен пройти проверку через камеру. Система просит посмотреть прямо в камеру, потом повернуть лицо влево, вправо, поднять голову, опустить, моргнуть глазами. Когда система убеждается, что перед ней живой человек, а не фото или подмена, она подтверждает регистрацию. Если всё совпадает и проверка пройдена успешно, курьер получает доступ к началу смены. Это очень важно для компаний, которые хотят реально контролировать, кто именно вышел на линию, кто принял смену и кто дальше будет везти заказ клиенту. После этого курьер попадает в список доставок. И здесь система может работать по двум сценариям. Первый сценарий — заказ уже назначен конкретному курьеру. Тогда он просто видит этот заказ в своём списке. Второй сценарий — заказ пока никому не назначен. И тогда курьер может увидеть кнопку “Принять заказ”. То есть система позволяет работать не только по ручному назначению, но и по модели, где курьеры сами берут свободные заказы. Например, в системе появляется новый заказ на доставку пиццы. Курьер открывает свой интерфейс, видит: номер заказа, адрес, расстояние, предварительное время, и нажимает “Принять заказ”. С этого момента заказ уже привязан к нему. Если курьер открывает карточку заказа, система показывает карту и маршрут. Сначала маршрут может строиться от заведения до клиента. На экране видно: сколько минут займёт путь, сколько километров или миль, примерную загрузку по пробкам, точку отправления и точку назначения. Курьер видит название заказа, кнопки действий и может сразу ориентироваться, что делать дальше. На карточке заказа есть важные кнопки: “Забрать заказ”, “Чат”, “Позвонить клиенту”, а также возможность открыть подробности заказа, отказаться от него или отменить, если на это есть права и логика процесса позволяет. Например, курьер открывает заказ и видит: адрес доставки, состав заказа, комментарий клиента, способ оплаты, сумму, которую ещё нужно принять, заметки по дому или подъезду. То есть это не просто “вези заказ”, а вся рабочая информация, которая нужна на последней миле. Когда курьер нажимает “Забрать заказ”, система понимает, что сейчас он едет до точки, чтобы реально получить заказ у компании. После этого статус меняется. Когда заказ забран, кнопка превращается в “Отвезти”. И в этот момент маршрут уже строится не от заведения, а от текущей геолокации курьера до адреса клиента. То есть SABSUS ведёт курьера пошагово: сначала принять заказ, потом доехать и забрать, потом поехать к клиенту, потом подтвердить доставку, потом завершить заказ. Когда курьер приезжает на адрес, он нажимает “Доставлено”. Если заказ полностью закрыт и всё в порядке, дальше появляется финальный статус завершения. Но если по заказу ещё не была принята оплата или осталась часть суммы, система сразу открывает окно приёма оплаты. Например, заказ был оформлен с частичной предоплатой, а остаток нужно взять наличными у двери. Курьер видит сумму, принимает её. Если подключён терминал, он может инициировать оплату через терминал. Если клиент платит наличными — система фиксирует наличную оплату. То есть курьер не просто “доставил коробку”, а завершил полноценный финансовый цикл по заказу. После оплаты система может открыть следующий важный шаг — загрузка фотографии подтверждения. Например, курьер оставил заказ у двери. Система просит сфотографировать доставку. Это очень полезно как доказательство выполнения. Если у заказа есть подписание документов или соглашение, это также может открываться здесь же. Например, если это аренда оборудования или передача товара, который требует подписи, клиент может подписать документ прямо на этапе вручения. После завершения всех шагов система показывает курьеру подтверждение завершения работы. Например: “Поздравляем, доставка завершена. Отличная работа. Вы заработали столько-то.” И заказ переходит в доставленный статус. Теперь очень важный блок — пакетный маршрут. Это одна из самых сильных возможностей интерфейса курьера. Она нужна, когда курьеру нужно везти не один заказ, а сразу несколько. Курьер может выбрать несколько заказов, и внизу появится кнопка “Маршрутная доставка”. После нажатия система спрашивает, нужно ли добавить адрес заведения в маршрут. Если да, маршрут строится с учётом точки, где надо забрать заказы. Дальше система показывает все точки маршрута, сортирует их по логике расстояния, а курьер может вручную менять порядок, если ему так удобнее. Например, у курьера есть три заказа: один в Бёрбанке, второй в Глендейле, третий по пути в соседнем районе. Система показывает их на карте, строит последовательность, а курьер может поменять порядок, если знает локальную ситуацию лучше или если один клиент попросил привезти раньше. Рядом с каждым адресом можно поставить отметку, что точка уже посещена. Такие адреса начинают отображаться другим цветом, и система больше не строит к ним маршрут как к активным. Это очень удобно, потому что курьер видит, что уже выполнено, а что ещё впереди. Также внутри пакетного маршрута можно добавлять любой дополнительный адрес. Например, если по пути нужно заехать в магазин, забрать что-то ещё, заехать на склад или выполнить отдельную задачу, этот адрес тоже можно встроить в маршрут. И здесь вспоминаем важную функцию из POS: кассир или оператор может указать, что курьеру нужно заехать купить определённый товар по дороге. Например, клиент заказал что-то, чего нет прямо сейчас в наличии на точке, но компания готова докупить это в магазине-партнёре. Тогда в карточке заказа курьера будет отображаться, сколько позиций нужно купить. Курьер нажимает на это поле и видит: что именно надо купить, в каком магазине, какой у него бюджет, какие позиции нужно отметить галочкой после покупки. Дальше он может указать фактическую цену, за которую купил товар, загрузить чек и завершить этап покупки. После этого уже продолжает маршрут и доставляет заказ клиенту. Например, клиент заказал набор, в котором не хватило одного конкретного напитка. Кассир отметил, что напиток можно докупить у определённого поставщика рядом. Курьер в своём интерфейсе видит адрес магазина, список покупки и лимит суммы. Он заезжает, покупает, фотографирует чек, отмечает покупку и только потом везёт всё клиенту. Это очень гибкая бизнес-логика, которой нет в большинстве стандартных курьерских систем. Внизу интерфейса курьера есть сканер. Он нужен для того, чтобы быстро идентифицировать заказ по QR-коду или штрих-коду. Например, если заказ маркируется кодом, курьер может просто отсканировать его и сразу открыть нужную карточку без ручного поиска. Следующий раздел — статистика. Здесь курьер видит свои показатели: рейтинг, количество выполненных заказов, доход, отзывы, результаты работы. Это полезно и самому курьеру, и компании, потому что формирует прозрачную картину эффективности. Есть также раздел профиль. В нём можно открыть: мой гараж, настройки, помощь, связь с поддержкой, условия использования. То есть у курьера есть не просто рабочий экран заказов, а полноценный личный рабочий кабинет внутри системы. Теперь ещё один важный режим интерфейса курьера — режим задач. Он отличается от режима заказов. То есть курьер может работать не только с доставками как таковыми, но и с отдельными задачами, которые ему ставят сотрудники из POS или других интерфейсов. Например, курьеру можно поставить задачу: заехать в магазин, отвезти документы, забрать оборудование, привезти товар между точками, сделать доставку ланча, вернуть арендное оборудование, поехать по адресу без классического заказа. Все эти задачи можно видеть отдельным списком. Там указывается адрес, описание, приоритет, связанный заказ, если он есть, и дедлайн. Например, если компания работает с арендой батутов, один заказ может включать сразу несколько действий: доставить батут, собрать, потом вечером забрать, потом разобрать, вернуть на склад. Это не один “курьерский заказ”, а целая связка задач. И именно поэтому режим задач в курьерском интерфейсе настолько важен. Когда курьер завершает рабочий день, он нажимает “Закрыть смену”. Система показывает: во сколько началась смена, сколько она длилась, какие были выполнены действия, и после подтверждения смена закрывается. После этого интерфейс снова возвращается к стартовому состоянию: выбор транспорта, проверка лица, отправка на проверку, начало новой смены. И теперь важно сделать главный вывод по этому интерфейсу. Курьер в SABSUS — это не человек, которому просто скинули адрес в мессенджер. Это полноценный участник экосистемы. У него есть: транспорт, карта, геолокация, маршруты, принятие заказов, статусы, оплата, чат, звонки, доказательство доставки, пакетные маршруты, задачи, покупки по дороге, статистика, профиль и смены. То есть последняя миля доставки здесь встроена в общую логику бизнеса, а не живёт отдельно. И если сейчас посмотреть на всю цепочку, то она уже становится очень сильной: клиент оформил заказ, POS его принял, производство начало готовить, склад учёл товар, поставщик встроен в цепочку снабжения, а курьер довозит заказ до клиента и закрывает его в системе. Но на этом SABSUS не заканчивается. Потому что после того, как бизнес научился принимать, исполнять и доставлять заказы, появляется следующий уровень — уровень продаж, работы с лидами, общения с клиентами, контроля повторных касаний, скриптов, KPI и воронок. И поэтому следующий большой этап — это CRM-интерфейс, где я подробно покажу, как в SABSUS строятся воронки продаж, как создаются лиды, как работают скрипты, ветки, шаблоны сообщений, обучающие материалы, AI-рекомендации и всё, что превращает систему из операционной платформы ещё и в полноценную машину продаж.

Теперь переходим к следующему огромному и очень важному блоку — к CRM-системе. И если до этого мы говорили в основном про операционную часть бизнеса — заказы, кассу, производство, склад, доставку, — то теперь мы переходим к уровню, где компания уже не просто исполняет входящие заказы, а системно работает с продажами, с заявками, с новыми клиентами, с повторными касаниями, с воронками, со скриптами и с контролем всей коммерческой команды. Очень важно понять одну вещь. В SABSUS CRM — это не просто список контактов и не просто карточка лида. Это полноценная система управления продажами. Здесь компания может создавать неограниченное количество воронок, выстраивать этапы, задавать правила распределения лидов, контролировать скорость первой реакции, строить чек-листы, сценарии общения, ветки вопросов, обучать сотрудников, подключать AI и отслеживать KPI. И сейчас я покажу, как это работает. Представим, что мы запускаем воронку продаж для компании SABSUS или для любого другого бизнеса, который работает не только на входящих заказах, но и на активных продажах. Например, это может быть: продажа подписки, продажа white-label решения, продажа оборудования, обработка лидов из Instagram, обработка заявок с сайта, работа с тёплыми и холодными лидами, или даже отдельная воронка под кейтеринг и корпоративные заказы. Первое, что мы видим в CRM, — это кнопка “Создать воронку продаж”. И здесь очень важно, что воронок может быть сколько угодно. То есть компания не ограничена одной общей воронкой на всё подряд. Можно сделать отдельную воронку: для B2B клиентов, для корпоративных продаж, для аренды, для входящих заявок с сайта, для Instagram, для повторных продаж, для партнёров, для франчайзи, для дилеров, для VIP клиентов. То есть CRM в SABSUS изначально рассчитана не на одну “воронку для всех”, а на очень гибкую бизнес-структуру. Когда мы создаём новую воронку, первое, что задаём, — это название сразу на четырёх языках. Например: на русском — “Продажа white-label платформы”, на английском — “White-label Sales Funnel”, на испанском — “Embudo de ventas White Label”, на украинском — “Воронка продаж White Label”. Это важно, потому что система поддерживает многоязычную среду, и даже внутренние бизнес-процессы можно адаптировать под языковую логику команды. Дальше выбирается режим воронки. И здесь уже видно, что CRM продумана очень глубоко. Можно выбрать: ручное назначение, автоматическое назначение, распределение лидов по очереди, режим колл-центра, распределение по приоритету, распределение с поддержкой AI. Например, если это небольшая компания, можно использовать ручное назначение, и руководитель сам решает, кому дать лида. Если это активный отдел продаж, можно включить распределение по очереди, чтобы система честно раздавала лиды менеджерам по кругу. Если это колл-центр, можно включить режим колл-центра, где логика уже заточена под массовые звонки и быструю обработку потока. Если есть приоритетные сотрудники или специальная логика сегментации, можно использовать распределение по приоритету. А если компания хочет усилить процесс интеллектом, можно использовать AI-поддержку. Дальше идёт описание воронки. Это можно использовать, чтобы объяснить, для чего она нужна. Например: “Эта воронка используется для обработки входящих заявок на white-label платформу, поступающих с сайта, Instagram, email и партнёрских каналов.” Следующий важный блок — период работы воронки и рабочее окно сотрудников. Здесь можно задать дату начала, а дальше — время, в которое сотрудники вообще имеют право или должны связываться с клиентами. Например, если отдел продаж работает только с понедельника по пятницу с 9 утра до 7 вечера, это можно зафиксировать. То есть система понимает не просто “есть лид”, а когда по этому лиду реально можно и нужно работать. Дальше выбираются рабочие дни воронки. Например, понедельник, вторник, среда, четверг, пятница. Это важно для внутренних SLA и логики касаний. Потому что, если лид пришёл в пятницу вечером, система должна понимать, нужно ли считать субботу и воскресенье как рабочее время или нет. Теперь один из самых сильных блоков — время первого касания. Можно указать, что первое касание должно быть, например, в течение 5 минут, 15 минут, 30 минут или любого другого периода. Это уже не просто “менеджеры должны быстро звонить”. Это формализация скорости продаж внутри системы. Дальше можно указать, через сколько часов или дней должно происходить следующее касание. Например: если клиент не ответил, сделать повторный контакт через 4 часа, или на следующий день, или через 2 дня. То есть система поддерживает реальную структуру follow-up процесса, а не хаотичную работу “если вспомним — позвоним”. Следующий параметр — после скольких дней лид считается неактивным. Например, если по лиду не было действий 7 дней, он автоматически может перейти в неактивный статус. Это помогает чистить воронку, видеть реальные активные сделки и не жить в иллюзии, что “у нас тысяча лидов”, если половина из них уже месяц без движения. Дальше выбирается список менеджеров, которым доступна эта воронка. Например, в воронке white-label работают только два сильных продажника и один руководитель. А воронка быстрых входящих заказов может быть доступна уже другому составу команды. Следующий очень важный блок — цели и KPI. И это одна из тех функций, которые сразу переводят CRM из уровня “просто воронка” в уровень системы управления продажами. Можно выбрать период цели: день, неделя, месяц. И дальше задать целевые показатели. Например: 30 новых лидов в день, 10 закрытых сделок в неделю, 15 000 долларов выручки в месяц. То есть у каждой воронки появляется своя измеримая цель, а не просто этапы ради этапов. После создания самой воронки мы переходим к её внутренней структуре — к этапам. И это уже сердце CRM. Каждый этап воронки имеет тип: первый этап, промежуточный этап, завершённый этап. Например, можно построить такую воронку: Новый лид, Первичный контакт, Выявление потребности, Презентация, Обсуждение условий, Ожидание решения, Сделка закрыта, Сделка потеряна. Или, если это более короткий процесс: Новый, Связались, Квалифицирован, Отправлено предложение, Оплачен. Каждый этап получает название на всех языках, описание и визуальное оформление. Можно выбрать цвет самой колонки, цвет этапа, и это помогает быстрее ориентироваться внутри интерфейса. Например: новые лиды — синий, этап общения — жёлтый, важные сделки — оранжевый, успешно закрытые — зелёный, потерянные — серый или красный. То есть менеджер визуально сразу понимает, где находится заявка. Но здесь начинается самое интересное. У каждого этапа можно задать чек-лист. Например, на этапе первичного контакта чек-лист может быть таким: уточнил имя клиента, уточнил компанию, уточнил потребность, узнал бюджет, понял источник заявки, назначил следующее действие. Менеджер прямо внутри лида может отмечать галочками, какие действия реально выполнены. И это сильно дисциплинирует работу команды. Дальше — ещё сильнее — скрипт этапа. То есть на каждый этап можно написать полноценный сценарий общения с клиентом. Не просто заметку, а реальный рабочий скрипт. Например, на этапе “Первичный контакт” можно прописать: “Здравствуйте, меня зовут Алексей, спасибо за интерес к нашей платформе. Подскажите, пожалуйста, для какого типа бизнеса вы рассматриваете систему?” Дальше можно создать вопрос: “Сколько у вас сейчас точек продаж?” Следующий вопрос: “Есть ли у вас уже действующая CRM или POS?” Следующий: “Что для вас сейчас является самой большой проблемой — хаос между сервисами, потеря клиентов, слабый контроль или отсутствие автоматизации?” И это не просто текстовый сценарий. В каждом вопросе можно задать: заголовок, описание, цвет, обязательность, и главное — тип ответа. Например, ответ может быть: да / нет, поле ввода, один вариант из списка, несколько вариантов, количество, цена, способ контакта. То есть CRM позволяет создавать не просто заметки, а реальные интерактивные скрипты общения. Например, если менеджер задаёт вопрос: “У вас уже есть собственное приложение?” И выбирается ответ “да”, система может перевести его по одной ветке. Если ответ “нет” — по другой. То есть в скрипте можно создавать ветвление. И это уже очень серьёзная логика. Например: если клиент ответил, что у него нет приложения, следующий вопрос — “Хотели бы вы запустить приложение под своим брендом?” Если ответил, что уже есть приложение, следующий вопрос — “Планируете ли вы заменить текущую систему или интегрировать новую платформу поверх существующей?” То есть разговор становится живым, структурированным и управляемым. Ещё одна сильная часть — обработка возражений. Например, можно заранее прописать возражения: “Нам это дорого”, “У нас уже есть система”, “Сейчас не время”, “Мы не понимаем разницу между вашим решением и обычной CRM”. И для каждого такого возражения можно добавить готовый блок аргументации, который менеджер увидит прямо внутри этапа и не будет импровизировать вслепую. После этапов следующий важный блок — шаблоны сообщений. Это позволяет компании создавать заранее подготовленные сообщения для разных этапов воронки. Например: после первого контакта, после отправки предложения, после демонстрации, после оплаты, при отсутствии ответа, при повторном касании. У шаблона сообщения можно указать: название, тему, текст, HTML-содержимое, и главное — к какому этапу это сообщение относится. То есть, например, если лид находится на этапе “Отправлено предложение”, у менеджера может быть сразу готов красивый шаблон письма с презентацией. Или если это этап “Нет ответа 2 дня”, можно дать короткий follow-up: “Здравствуйте, хочу уточнить, удалось ли вам ознакомиться с предложением. Если удобно, я могу коротко ответить на вопросы или показать демо.” Если компания хочет делать не просто plain text, а красивые письма, здесь же можно использовать HTML. Это особенно полезно для email-коммуникации, коммерческих предложений и брендированных follow-up сообщений. Следующий очень сильный блок — обучающие материалы для сотрудников. И это то, что делает CRM не только инструментом работы, но и инструментом стандартизации команды. Для каждой воронки можно прикрепить обучающие материалы: инструкции, видео, тексты, ссылки на документы, презентации, примеры обработки возражений, схемы общения. Например, для новой воронки white-label продаж можно прикрепить: презентацию продукта, видео о платформе, документ с конкурентными преимуществами, таблицу с тарифами, разбор частых вопросов клиента. Это значит, что новый менеджер не остаётся один на один с пустой колонкой лидов, а сразу получает среду, где есть и логика, и обучение. Теперь отдельно очень важный момент: в SABSUS многие такие сущности можно создавать не только вручную, но и голосом или через AI-промпт. То есть человек может буквально сказать: “Создай мне воронку продаж для white-label решения для ресторанов в Лос-Анджелесе.” И система или AI-слой поможет сгенерировать саму структуру воронки, этапы, тексты, скрипты, а иногда и переводы на разные языки. То же самое можно делать для категорий, карточек товаров, некоторых описаний и других объектов системы. И это очень сильное ускорение настройки. Теперь, когда воронка создана, в ней можно начинать работать с лидами. Внутри первого этапа всегда можно добавить лид. Есть быстрый способ: краткое добавление. Например: имя, фамилия, телефон, email, краткое описание, комментарий, бюджет. Этого уже достаточно, чтобы не потерять входящую заявку и сразу дать её в работу. Но если нужна более глубокая карточка, в правом верхнем углу есть полноценная кнопка “Добавить лид”. И вот там уже открывается расширенная структура. Можно указать: название сделки, название компании, бюджет, отрасль, контактное лицо, имя, фамилию, адрес, email, должность. Дальше можно добавить неограниченное количество контактов: Instagram, Telegram, WhatsApp, Facebook, дополнительный телефон, дополнительный email. То есть лид может быть очень подробно структурирован. После этого задаётся источник. Например: сайт, Instagram, реклама, email, рекомендация, вебинар, лендинг, партнёрский канал. И если источник Instagram, можно отдельно вписать логин, ссылку или другую детализацию. Если это сайт — указать форму или страницу. Если это реклама — кампанию. То есть CRM помогает не просто хранить лид, а понимать, откуда он вообще пришёл. Дальше идёт сегментация лида. Например: горячий, тёплый, холодный, новый, успешно закрытый. Можно выбрать язык клиента, адрес, часовой пояс, дату согласия на обработку персональных данных, приоритет — низкий, средний, высокий, срочный. Также можно выбрать, какие продукты или подписки интересуют клиента. Например, клиенту может быть интересен: SaaS тариф, white-label, buyout, CRM, Flow, клиентское приложение, доставка, интеграции. Можно указать теги и комментарии. И ещё один очень важный слой — дополнительные поля. То есть CRM не жёстко ограничена только стандартной карточкой. Если компании нужно собирать специфичные данные, например: количество филиалов, месячный оборот, используемая POS-система, тип кухни, источник интеграции, интерес к white-label, интерес к подписке, — всё это можно добавлять как дополнительные поля. Это особенно важно, если CRM подключается к сайтам, лендингам, формам и сторонним системам. Теперь сам лид попадает в воронку. И дальше с ним можно работать уже вживую. Менеджер может перетаскивать лид по этапам. Например: новый → первичный контакт → выявление потребности → предложение → ожидание решения → закрыто. И при открытии лида внутри мы видим уже не просто карточку, а целую рабочую панель. Там есть: вся информация о клиенте, контакты, источник, сегментация, приоритет, задачи, скрипт текущего этапа, чек-лист, история касаний, заметки, коммуникации, AI-рекомендации. Например, менеджер открывает лид и сразу видит: этап — “Первичный контакт”, чек-лист — “уточнить бизнес”, “уточнить количество точек”, “уточнить текущую систему”, скрипт — подготовленные вопросы, AI-рекомендация — “лид похож на тёплого клиента с высоким потенциалом, сделать повторный звонок сегодня до 18:00”. То есть внутри одного окна уже есть всё, что нужно для реальной продажи. Внутри лида можно: поставить задачу себе, поставить задачу другому сотруднику, оставить заметку, переписываться с клиентом, отправить email, отправить SMS, позвонить, провести следующий follow-up, изменить статус, изменить сегментацию, изменить приоритет. То есть лид в SABSUS — это уже живая рабочая единица, а не мёртвая запись в таблице. Есть также полная фильтрация. Можно искать лиды по имени, компании, номеру телефона, этапу, источнику, сегменту, менеджеру, статусу, дате создания, приоритету и другим полям. Это особенно важно, когда объём лидов большой. И ещё очень важный блок — архив и очистка. Если лид был потерян, отклонён, не принят или ушёл в неактивный контур, его можно найти в центре архива. Там его можно либо полностью очистить, либо восстановить обратно в рабочую воронку. То есть система не заставляет жить либо в хаосе, либо в вечном захламлении активной CRM. Теперь приведу несколько живых примеров, чтобы этот блок воспринимался не как абстрактная функция, а как реальный инструмент. Первый пример. Лид приходит с сайта на white-label платформу. Система автоматически создаёт лид, записывает источник как “сайт”, сегментирует как “новый”, ставит в первую колонку. Менеджер получает задачу сделать первый контакт в течение 15 минут. Открывает лид, проходит по скрипту, узнаёт, что клиент хочет платформу для трёх заведений. Переводит лид в следующий этап. Отправляет шаблон сообщения с краткой презентацией. Через два дня делает follow-up по заданному правилу воронки. Второй пример. Лид приходит из Instagram. Через интеграцию в систему попадает комментарий или сообщение. Flow может автоматически создать лид, отправить его в AI на классификацию, AI напишет комментарий, определит, тёплый это лид или холодный, и лид уже в готовом виде попадёт в нужную воронку. Менеджер не тратит время на ручную сортировку, а работает уже с подготовленным объектом. Третий пример. Компания создаёт отдельную воронку под корпоративный кейтеринг. В ней свои этапы: новая заявка, уточнение даты, уточнение количества гостей, согласование меню, отправка коммерческого предложения, предоплата, закрытая сделка. Для каждого этапа есть свои чек-листы и шаблоны сообщений. Например, на этапе “согласование меню” менеджер обязан уточнить: дату, время, адрес, количество гостей, формат обслуживания, наличие аллергий, способ оплаты. То есть CRM становится не просто продажным инструментом, а реально управляет процессом. И вот здесь очень важно остановиться и зафиксировать главный вывод. CRM в SABSUS — это не просто “раздел для лидов”. Это полноценная среда продаж, где соединены: воронки, этапы, распределение, чек-листы, скрипты, ветвления, обработка возражений, обучение сотрудников, шаблоны сообщений, AI-помощь, карточка клиента, коммуникации, задачи, архив и контроль KPI. То есть если до этого мы видели SABSUS как сильную операционную систему бизнеса, то здесь видно, что платформа умеет ещё и системно продавать. Но продажи — это только часть роста. Потому что дальше бизнесу нужно не только работать с лидами, но и удерживать клиентов, запускать акции, управлять группами клиентов, отправлять баннеры, делать рассылки, отправлять push, email и SMS, объединять чаты и коммуникации из разных каналов. И именно поэтому следующий большой этап — это маркетинг и коммуникации, где я подробно покажу, как в SABSUS работают акции, группы клиентов, программа лояльности, рекламные баннеры, маркетинговые рассылки, push-уведомления, чаты и омниканальная коммуникация с клиентом.

Теперь переходим к следующему огромному блоку — к маркетингу и коммуникациям. И здесь начинается уже тот уровень системы, где бизнес не просто принимает заказы и обрабатывает лидов, а начинает системно влиять на повторные продажи, удержание клиента, частоту покупок, средний чек и качество общения. Потому что если компания умеет только принять заказ — этого уже недостаточно. Нужно уметь вернуть клиента. Нужно уметь дать правильную акцию. Нужно уметь отправить сообщение в нужный момент. Нужно уметь разделять аудиторию. Нужно уметь работать не только через один канал, а сразу через email, SMS, push, Instagram, WhatsApp, Telegram, Facebook и любые другие интеграции. И в SABSUS всё это собрано в единую маркетинговую и коммуникационную среду. Начнём с одного из самых сильных и глубоких разделов — с акций. Когда компания создаёт новую акцию, первое, что задаётся, — это её доступность. То есть акция может быть включена или выключена. Это удобно, потому что можно заранее подготовить механику, не удалять её и включить в нужный момент. Дальше задаётся название акции на всех языках. Например: на русском — “2 пиццы по цене 1”, на английском — “Buy 2 Pizzas, Get 1 Free”, на испанском — “Compra 2 pizzas y recibe 1 gratis”, на украинском — “Купуй 2 піци та отримай 1 безкоштовно”. Это важно, потому что акция должна корректно отображаться клиенту на его языке и в приложении, и на сайте, и в других точках контакта. После этого загружаются фотографии акции. Можно добавить основной визуал, а также фоновое изображение для карточки акции. Например, для акции на пиццу можно использовать яркий баннер с двумя большими пиццами и подписью “Только по будням с 14:00 до 16:00”. Дополнительно можно указать цвет фона карточки, чтобы акция визуально выделялась. Дальше заполняется описание акции в приложении. Например: “Закажите любые две большие пиццы и получите третью в подарок. Акция действует с понедельника по пятницу с 14:00 до 16:00 во всех точках Michelangelo Pizza.” То есть у акции есть не только логика расчёта, но и полноценная маркетинговая подача. Следующий шаг — период действия акции. Мы задаём начало и окончание акции. Например, с 1 июня по 30 июня. После этого выбираем, в каких точках продаж она доступна. И это очень важно. Акция может работать только в одном заведении, только на доставке, только в центре города, только в новой точке, или сразу в нескольких точках. Дальше можно задать промокод. Если промокод указан, акция будет доступна только при вводе этого кода. Например, код SUMMER25 может давать 25 процентов скидки на второй товар. Если промокод не нужен, можно строить акцию без него. Следующий важный параметр — начислять ли бонусы на товары, участвующие в акции. То есть бизнес может решить, должен ли клиент получать бонусы, если товар уже куплен со скидкой или по промо-механике. Это очень важно для тонкой настройки экономики лояльности. Дальше идёт параметр применять акцию автоматически или нет. Если этот переключатель включён, система сама видит, что условия выполнены, и применяет акцию без участия клиента или кассира. Если выключен, тогда акцию можно использовать по промокоду, вручную через POS или через другую логику. Следующий параметр — можно ли применять эту акцию вместе с другими. Например, компания может запретить совмещение двух скидок. Или наоборот — разрешить, если это часть стратегии удержания. После этого можно задать часы действия акции. Например, акция работает не весь день, а только с 14:00 до 16:00. И отдельно можно указать дни недели, в которые она активна. Например, только по будням, только в выходные или только по вторникам и четвергам. Это особенно полезно для управления потоком клиентов. Например, если бизнес хочет подтянуть трафик в “мёртвые часы”, акции можно делать именно туда. Дальше указывается, сколько раз акция может применяться в одном заказе. Например, только один раз. Или до трёх раз, если речь о больших корзинах. Теперь начинается самый важный слой — условия акции. Система позволяет выбрать, должны ли выполняться любые из условий или все условия одновременно. Это очень мощно, потому что даёт гибкость. Например, если указано “любое из условий”, клиент может заказать кофе или чай и получить бонус. А если “все условия”, он должен заказать и кофе, и чай, и десерт. Следующий блок — участники акции. То есть кто вообще может ей пользоваться: все посетители, только незарегистрированные посетители, только зарегистрированные клиенты, или клиенты отдельных групп. Например, можно сделать акцию только для новых клиентов. Или только для VIP-группы. Или только для тех, у кого есть депозитный счёт. После этого указываются конкретные товары или модификаторы, которые участвуют в акции. Например, можно выбрать бургер и сказать, что условие срабатывает, если заказано ровно 2 бургера. Или не менее 5 бургеров. Или можно построить акцию на сумму — например, при заказе определённых товаров на сумму от 100 долларов. То есть здесь можно строить механику и по количеству, и по сумме. А теперь — результат акции. И именно здесь видно, насколько глубоко SABSUS умеет работать с промо-механиками. Результатом может быть: фиксированная сумма скидки на каждый акционный товар, процент скидки на акционные товары, фиксированная цена на акционные товары, бонусные товары, фиксированная сумма скидки на весь заказ, процент скидки на весь заказ. Например, если выбрана фиксированная скидка на каждый акционный товар, можно указать 3 доллара скидки на каждую пиццу из списка. Если выбран процент — например, 20 процентов на все выбранные товары. Если фиксированная цена — можно сказать, что любая из выбранных пицц стоит сегодня 9.99. Если выбраны бонусные товары, то можно указать, что при покупке двух пицц клиент получает в подарок напиток, соус или десерт. Причём можно ограничить количество подарков, можно задать условия скидки на бонусные товары, фиксированную цену на бонусный товар или вообще сделать его полностью бесплатным. Например, акция может выглядеть так: при заказе двух больших пицц клиент получает один напиток бесплатно; или при заказе на сумму от 50 долларов клиент получает десерт за 1 доллар; или при заказе набора для кейтеринга клиент получает бесплатную доставку; или при первом заказе через приложение клиент получает 10 долларов скидки на весь чек. То есть акции здесь — это не просто “процент скидки”, а полноценный промо-движок. Теперь переходим к следующему разделу — группы клиентов. Это очень важная основа всей персонализации. Потому что не все клиенты одинаковые. Есть новые клиенты, постоянные, VIP, корпоративные, сотрудники, партнёры, клиенты с депозитами, клиенты определённых сегментов. И в SABSUS это можно формализовать. Когда создаётся группа клиентов, сначала задаётся её название. Например: Новые клиенты, VIP, Corporate, Delivery Club, Loyal Customers, Birthday Segment. После этого можно включить или выключить депозитные счета для этой группы. Например, VIP-клиентам можно разрешить работать с депозитами, а обычным — нет. Дальше задаётся тип бонусной программы — скидочная или бонусная. Если выбрана скидочная система, можно указать размер скидки и максимальный процент оплаты этой скидкой. Например, VIP-клиент получает 10 процентов скидки на все заказы, но не более определённого лимита. Если выбрана бонусная система, тогда настраивается: процент начисления бонусов, приветственные бонусы за регистрацию, бонусы за рекомендацию приложения или системы, бонусы на день рождения, курс пересчёта бонусов — например, 1 балл равен 1 доллару или 1 балл равен 0.1 доллара, а также максимальный процент заказа, который можно оплатить бонусами. Например, можно настроить группу “Новые клиенты” так: 5 процентов начисления бонусов, 10 приветственных бонусов за регистрацию, 20 бонусов за рекомендацию друга, 25 бонусов на день рождения, максимум 30 процентов заказа можно оплатить бонусами. А для VIP-группы — выше проценты и более выгодные условия. Следующий раздел — клиенты. Это уже сама база клиентов. Здесь компания видит всю клиентскую базу, сегменты, контакты, статусы, историю и может работать с ней через маркетинг, CRM и другие модули. Теперь переходим к рекламным баннерам. Это один из самых ярких визуальных инструментов внутри клиентских интерфейсов. В баннер можно загрузить фото или видео, задать период показа, время суток, в которое он должен показываться, выбрать точки продаж и даже указать, на какой товар должен вести переход при нажатии. Например, можно создать баннер: “Новая Пицца Тартуфо — попробуйте сегодня со скидкой 20%” и привязать его прямо к карточке товара. Тогда клиент нажимает на баннер и сразу попадает в карточку новой пиццы. Если баннер — это видео, система сама понимает длительность. Если это фото, можно указать время показа каждого слайда. То есть баннеры здесь — не просто статическая картинка, а управляемый промо-инструмент. Следующий сильный раздел — маркетинговые рассылки. Здесь владелец компании или маркетолог может создавать полноценные рассылки. Можно загрузить фотографию, указать заголовок уведомления, текст, выбрать способ отправки: email, номер телефона, push-уведомление. Потом выбрать аудиторию: все пользователи, определённая группа клиентов, несколько пользователей, один конкретный пользователь. Например, можно сделать рассылку: “Сегодня только для VIP-клиентов — бесплатный десерт к любому заказу от 40 долларов.” Выбрать группу “VIP”, выбрать способ отправки push + email и указать отправку в 11:30, чтобы сообщение пришло перед обедом. Также можно настроить тип отправки: один раз, каждый день, каждую неделю, каждый месяц, каждый год, или каждые N дней. Например, напоминание каждые 30 дней для клиентов, которые давно не заказывали. Или поздравление с днём рождения каждый год. Или еженедельный оффер по пятницам в 17:00. Теперь следующий раздел — чаты. И это очень важная часть. Потому что в современном бизнесе коммуникация давно ушла за пределы просто звонков. Клиенты пишут в email, в Instagram, в WhatsApp, в Telegram, в Facebook, в SMS, на сайт, в форму заявки. И если это всё разбросано по разным сервисам, компания теряет скорость и контроль. В SABSUS есть собственная система чатов и коммуникаций. Клиенты могут общаться с компанией внутри системы, сотрудники могут писать клиентам, менеджеры могут вести переписку. Но самое важное — сюда можно подключать внешние каналы. Например: Google почта, Instagram, WhatsApp, Telegram, Facebook, SMS, email, и любые другие каналы через интеграции и Flow. Это означает, что сообщения из разных платформ могут попадать в одно место. То есть менеджер не должен открывать пять разных приложений и десять вкладок браузера. Он работает внутри единой коммуникационной среды. Например, человек написал в Instagram компании: “Здравствуйте, а у вас есть доставка после 11 вечера?” Сообщение попадает внутрь системы. Его можно обработать вручную, а можно через Flow и AI. Другой клиент пишет в WhatsApp: “Хочу заказать кейтеринг на 25 человек.” Это сообщение тоже попадает в систему. Третий клиент ответил на email по коммерческому предложению — письмо тоже видно. То есть компания получает реальную омниканальную коммуникацию, а не набор разрозненных входящих сообщений. И здесь особенно важно то, что ответы можно строить через Flow. То есть на комментарии и сообщения можно делать не просто ручные ответы, а полноценные сценарии. Например: пришёл комментарий в Instagram → отправить в AI → сгенерировать ответ → отправить комментарий или сообщение → при необходимости создать лид в CRM. Или: пришёл новый email → распознать тему → создать задачу менеджеру → отправить шаблонный ответ. То есть коммуникации внутри SABSUS могут быть не только централизованными, но и автоматизированными. Следующий блок — push-уведомления. Да, часть этого уже есть в рассылках, но здесь вынесен отдельный интерфейс именно под push. Можно загрузить изображение уведомления, написать заголовок, текст, выбрать получателей, выбрать контекст. Например, контекстом может быть: страница товара, страница акции, страница заказа, другая внутренняя логика. И указать точное время отправки. Например, можно сделать push: “Ваш любимый десерт снова в наличии — нажмите, чтобы заказать.” И привязать его прямо к карточке товара. Или: “Только сегодня бесплатная доставка после 19:00.” И привязать к акции или к странице оформления заказа. То есть push здесь — это не просто текстовое уведомление, а управляемый переход в нужный контекст системы. Теперь давай зафиксируем, что именно мы сейчас увидели. Маркетинг в SABSUS — это не просто одна кнопка “скидка”. Это целая среда, где компания может: создавать акции с очень гибкой логикой, управлять бонусами и скидками, сегментировать клиентов по группам, строить программу лояльности, показывать баннеры, запускать email, SMS и push-рассылки, объединять коммуникации из разных каналов, подключать Instagram, WhatsApp, Telegram, Facebook, Google почту и другие каналы, строить автоматические ответы и сценарии через Flow и AI. Именно здесь бизнес начинает не просто продавать, а выстраивать отношения с клиентом. То есть человек может сначала увидеть баннер, потом получить push, потом оформить заказ, потом получить follow-up, потом снова увидеть персонализированную акцию — и всё это внутри одной системы. Приведу несколько очень живых примеров. Первый пример. Компания хочет увеличить продажи в тихие дневные часы. Создаётся акция: “С понедельника по пятницу с 14:00 до 16:00 — 2 пиццы по цене 1.” Делается баннер. Настраивается push-рассылка по группе “Постоянные клиенты”. И в 13:45 система автоматически рассылает уведомление тем, кто живёт рядом и уже заказывал пиццу ранее. То есть акция становится не просто пассивной записью в системе, а реальным механизмом возврата клиента. Второй пример. Компания хочет удерживать новых пользователей. Создаётся группа “Новые клиенты”. Для неё задаются: приветственные бонусы, скидка на первый заказ, автоматическая рассылка после регистрации, ещё одна рассылка через 7 дней, если заказ не был сделан. То есть весь путь нового клиента может быть заранее выстроен. Третий пример. Человек пишет в Instagram: “Здравствуйте, хочу узнать про white-label и приложение под бренд.” Комментарий или сообщение попадает в систему. Flow отправляет его в AI. AI определяет, что это потенциальный B2B лид, создаёт карточку лида в CRM, пишет комментарий, предлагает шаблон ответа. Менеджер тут же видит всё внутри одной системы и продолжает работу. То есть маркетинг, коммуникация, CRM и автоматизация работают как одно целое. И вот это и есть главный вывод по этому блоку. SABSUS умеет не только вести продажи и заказы. Он умеет выстраивать полный контур удержания, коммуникации и роста. Но на этом мы ещё не закончили. Потому что до этого мы уже несколько раз упоминали один очень важный слой платформы — Flow. Мы говорили о том, что через него можно автоматизировать ответы, строить интеграции, запускать действия, подключать AI, публиковать контент, отправлять уведомления и даже строить свои API. И теперь мы подошли к блоку, который связывает всю платформу вместе. К блоку, где SABSUS перестаёт быть просто системой с модулями и становится программируемой бизнес-платформой. И поэтому следующий большой этап — это Subsus Flow, интеграции, автоматизация, AI и построение собственных сценариев внутри платформы.

Теперь мы переходим к одному из самых сильных, самых глубоких и самых стратегически важных модулей всей платформы — к Subsus Flow. И если до этого момента мы смотрели на SABSUS как на большую экосистему интерфейсов, ролей, заказов, CRM, склада, кухни, доставки, маркетинга и клиентского кабинета, то сейчас мы переходим к тому слою, который всё это связывает, оживляет и позволяет бизнесу строить собственную логику поверх готовой системы. Потому что любая даже очень сильная платформа рано или поздно упирается в один и тот же вопрос. Хорошо, у нас есть заказы. Хорошо, у нас есть клиенты. Хорошо, у нас есть CRM, склад, курьеры, Instagram, сообщения, почта и маркетинг. Но что делать, если бизнес хочет, чтобы система реагировала именно по его правилам? Что делать, если компания хочет не просто пользоваться готовыми кнопками, а сама собрать свои процессы, свои реакции, свои связки между событиями и своими внешними сервисами? И вот именно здесь начинается Subsus Flow. Subsus Flow — это не просто “ещё один раздел автоматизации”. И это очень важно понять правильно. Это не маленькое дополнение к CRM. Не набор триггеров для галочки. Не просто “если пришёл заказ, отправить уведомление”. Subsus Flow — это внутренний движок сценариев и оркестрации, который позволяет компании строить собственную логику внутри SABSUS и связывать платформу с любыми внешними сервисами, AI-инструментами, каналами коммуникации и API. Если говорить просто, то все предыдущие блоки показывали, что умеет система сама по себе. А Flow показывает, как компания может заставить систему работать именно так, как ей нужно. Здесь очень важно сделать паузу и объяснить разницу. Обычная система автоматизации бизнеса чаще всего устроена так: у неё есть фиксированные функции, фиксированные кнопки, фиксированные экраны, и если тебе нужно что-то нестандартное, ты упираешься в потолок. Либо заказываешь дорогую доработку, либо подключаешь внешний сервис, либо начинаешь жить на костылях из таблиц, мессенджеров, почты и ручного контроля. В SABSUS логика другая. Здесь у компании уже есть готовая мощная инфраструктура: компания, точки, товары, заказы, CRM, доставка, поставщики, клиенты, маркетинг, чаты, уведомления, оплаты, цифровые продукты. И Flow позволяет поверх этой инфраструктуры выстраивать любые сценарии. То есть Flow работает не в пустоте. Он работает с живыми данными бизнеса. С лидами. С заказами. С товарами. С клиентами. С документами. С платежами. С сообщениями. С задачами. С событиями во всей экосистеме. И именно поэтому я говорю, что здесь SABSUS перестаёт быть просто системой и становится программируемой бизнес-платформой. Теперь давайте глубоко разберёмся, что именно умеет Flow. Первое — это триггеры, то есть события, с которых вообще начинается сценарий. И здесь вариантов очень много. Сценарий может запускаться, когда создаётся новый лид. Когда создаётся новый заказ. Когда обновляется заказ. Когда создаётся новый клиент. Когда создаётся товар. Когда обновляется карточка товара. Когда создаётся документ. Когда сотрудник меняет статус. Когда курьер завершает доставку. Когда наступает определённое время. Когда приходит определённая дата. Когда наступает период — например, раз в день, раз в неделю, раз в месяц. Когда приходит внешний webhook. Когда кто-то вручную запускает сценарий. Когда приходит сообщение из внешней системы. Когда приходит комментарий из Instagram. Когда приходит email. Когда приходит SMS. Когда приходит сообщение в WhatsApp, Telegram, Facebook или любом другом канале, который компания подключила. То есть Flow умеет запускаться как от внутренних событий платформы, так и от внешнего мира. И вот здесь уже видно, почему этот модуль настолько сильный. Потому that он позволяет соединять внутреннюю жизнь бизнеса и внешнюю жизнь бизнеса. Теперь второй слой — что Flow может делать после запуска. Он может читать данные системы. Например, если пришёл новый заказ, он может получить: номер заказа, тип заказа, список товаров, сумму, клиента, адрес, точку продаж, способ оплаты, статус, комментарии, связанные задачи. Если пришёл новый лид, он может получить: имя, контакт, источник, этап, сегмент, бюджет, комментарий, язык, дополнительные поля. Если создали товар, он может получить: название, описание, категории, фото, цены, локации, бренд, теги. То есть первый важный принцип такой: Flow не оторван от платформы. Он видит реальные объекты системы и работает с ними как с полноценными данными. Следующее, что он умеет, — это преобразовывать данные. И это очень важный момент. Потому что бизнес-логика почти никогда не выглядит как “получили заказ — переслали его без изменений”. Почти всегда данные нужно подготовить, собрать, переименовать, отфильтровать, объединить, пересчитать, преобразовать, дописать или классифицировать. Например, приходит новый заказ, а компании нужно отправить его не в виде полного сырого JSON-объекта, а в виде короткого отчёта: номер, имя клиента, сумма, тип доставки, время, комментарий. Или наоборот, нужно собрать очень подробную структуру: товары, модификаторы, ингредиенты, налоги, комиссии, сумма после бонусов, депозит, адрес, контакты. Flow умеет это делать. Дальше он умеет вызывать действия. Например: создать задачу, отправить уведомление, изменить статус, записать комментарий, сформировать результат, вызвать внешний API, запустить другую логику внутри системы. То есть Flow — это не просто “посмотреть данные”. Это полноценная исполнительная среда. Теперь давайте разберём реальные сценарии. И здесь я хочу показать не один-два примера, а целую палитру того, как это можно использовать в живом бизнесе. Первый сценарий — новый лид и автоматическая квалификация через AI. Представим, что в систему пришёл новый лид с сайта или из Instagram. Обычно менеджер должен вручную открыть заявку, прочитать текст, понять, это вообще серьёзный клиент или нет, горячий он или холодный, о чём с ним говорить, к кому его назначить. Это занимает время. А время — это один из самых дорогих ресурсов в продажах. С Flow это можно выстроить иначе. Приходит новый лид. Flow автоматически забирает все его данные. После этого отправляет их в ChatGPT или любую другую AI-платформу. AI анализирует текст заявки, классифицирует лид, например: горячий, тёплый, холодный, партнёрский, нецелевой. Дальше AI может сгенерировать краткое резюме: “Клиент — владелец трёх ресторанов в Лос-Анджелесе, интересуется white-label приложением и CRM, уже использует POS, нужен быстрый созвон.” Потом Flow записывает этот комментарий обратно в карточку лида, меняет его сегмент, может назначить приоритет, поставить задачу менеджеру и даже отправить уведомление в нужный канал. То есть менеджер получает не “сырой лид”, а уже предварительно обработанный объект. Это не просто удобно — это меняет скорость и качество работы отдела продаж. Второй сценарий — новый заказ и уведомление руководителю или менеджеру. Представим, что компания хочет мгновенно узнавать о крупных заказах. Приходит новый заказ. Flow смотрит сумму заказа. Если сумма выше 300 долларов, автоматически отправляется персонализированное уведомление руководителю: “Поступил крупный заказ №10528 на сумму 426 долларов. Точка: Burbank. Тип: доставка. Клиент: John Carter.” Если заказ стандартный, уведомление может уйти только менеджеру смены. Если это кейтеринг — отдельному отделу. Если это заказ на аренду — курьерской команде и менеджеру логистики. То есть одна и та же система может по-разному реагировать на события в зависимости от логики бизнеса. Третий сценарий — автоответы в социальных сетях. Это особенно важно для Instagram, WhatsApp, Telegram, Facebook и других каналов. Например, в Instagram компании приходит комментарий: “Сколько стоит ваше white-label приложение?” Или: “У вас есть доставка после 11 вечера?” Или: “Можно ли заказать кейтеринг на 30 человек?” Flow может автоматически забрать этот комментарий или сообщение, отправить его в AI, определить намерение пользователя, сгенерировать корректный ответ в нужном стиле и отправить его обратно. Если система понимает, что это не просто вопрос, а потенциальный лид, она может сразу создать карточку лида в CRM, поставить задачу менеджеру и записать всю переписку в коммуникационную историю. Например, человек пишет в Instagram: “Мне нужна система для сети кафе, можно узнать подробнее?” Flow понимает, что это B2B-запрос, создаёт лид, пишет: “Источник: Instagram. Потенциальный клиент. Вероятно, сеть кафе. Интерес к платформе.” Потом отправляет в ответ: “Здравствуйте. Да, конечно. Наша система подходит для сетей кафе, ресторанов и магазинов. Я могу коротко рассказать о возможностях или передать вашу заявку менеджеру. Сколько у вас сейчас точек?” То есть соцсети перестают быть хаотичной входящей перепиской и становятся полноценным входным каналом в CRM и продажи. Четвёртый сценарий — автоматическая публикация нового товара в социальные сети. И вот это один из самых сильных и самых “вау” сценариев. Представим, что компания создала новую карточку товара в каталоге. Например, новый десерт, новый напиток, новый курс, новая акция, новая услуга. Flow отслеживает событие создания новой карточки. Дальше он берёт название, фотографии, категорию, краткое описание. Если описания нет или оно слабое, отправляет данные в AI и просит: сгенерировать продающее описание, придумать текст поста, адаптировать под тон бренда, сделать короткий вариант для Instagram, длинный вариант для Facebook, отдельную версию для Telegram. Дальше можно вызвать генерацию изображения, если нужно. Например, AI создаёт промо-изображение или улучшает визуал. После этого Flow публикует пост в Instagram, Facebook, Telegram или других подключённых каналах. Представь, насколько это мощно. Компания добавляет новый товар в систему. И автоматически запускается цепочка: создан товар → сгенерирован текст → сгенерировано изображение → опубликован пост → отправлено push-уведомление клиентам → товар появился в каталоге. То есть маркетинг начинает жить не отдельно от каталога, а прямо внутри общей логики платформы. Пятый сценарий — отправка ссылки на оплату в нужный канал. Например, клиент оформил заказ, но хочет оплатить позже. Или менеджер выставляет счёт вручную. Flow может взять ссылку на оплату и автоматически отправить её: по email, по SMS, в WhatsApp, в Telegram, в чат внутри системы, в Instagram Direct, или в любой другой подключённый канал. И не просто отправить “сухую ссылку”, а сформировать нормальное сообщение. Например: “Здравствуйте, ваш счёт по заказу №10528 готов. Оплатить можно по ссылке ниже до 18:00 сегодняшнего дня.” Или: “Спасибо за ваш интерес. Чтобы подтвердить бронирование, пожалуйста, внесите предоплату по этой ссылке.” То есть компания может строить очень аккуратную и персонализированную коммуникацию вокруг денег и подтверждения заказа. Шестой сценарий — выгрузка в Google Sheets или любые таблицы. Например, бизнес хочет собирать отдельную аналитическую таблицу по заказам, лидам, сотрудникам, поставкам или маркетинговым кампаниям. Flow может при каждом новом заказе отправлять строку в Google Sheets. Например: дата, номер заказа, тип заказа, сумма, точка, канал, клиент, способ оплаты. То же самое можно делать с лидами, с новыми товарами, с подписками, с выплатами, с любыми объектами системы. Это очень удобно, потому что бизнес может строить свои отдельные таблицы, отчёты или интеграции без ручной выгрузки и без разработчиков на каждую мелочь. Седьмой сценарий — автоматический отчёт по расписанию. Например, владелец хочет каждый вечер в 22:00 получать сводку по дню. Flow запускается по времени. Собирает: количество заказов, сумму выручки, средний чек, самые продаваемые товары, активные заказы, отмены, возвраты, новые лиды, закрытые сделки, остатки ниже минимума. После этого формирует красивое сообщение и отправляет его на email, в Telegram, в WhatsApp или в любой другой канал. То есть руководителю не нужно каждый вечер вручную собирать данные. Платформа делает это сама. Восьмой сценарий — реакция на изменение документов. Например, создана новая поставка. Flow видит это событие и автоматически: отправляет уведомление бухгалтеру, сохраняет данные в таблицу, прикрепляет документ в нужный архив, отправляет сообщение менеджеру точки, или запускает проверку на отклонение по цене. То есть документы внутри системы тоже могут быть частью автоматизированной логики. Девятый сценарий — брендированная персонализированная коммуникация после заказа. Представим, что после завершения заказа компания хочет отправлять не просто сухое “Спасибо”, а умное сообщение. Flow получает данные о заказе, клиенте, времени, типе заказа и может отправить их в AI. AI генерирует индивидуальное сообщение в стиле компании. Например: “Спасибо, что заказали у Michelangelo Pizza. Надеемся, Маргарита и Тирамису вам понравились. Если захотите повторить — в приложении уже доступен ваш заказ в истории, а сегодня до полуночи для вас действует бонус на следующий заказ.” Это уже не просто сервисная коммуникация, а мягкий маркетинг и удержание. Десятый сценарий — построение собственного API на данных системы. И вот это очень важная часть Flow. Потому что компании часто нужны не только внутренние сценарии, но и свои внешние точки доступа к данным. Например, бизнес хочет сделать собственный сайт или подключить внешнее приложение и получать из SABSUS: список товаров, категории, акции, остатки, клиентов, заказы, статусы, лидов, или любые другие данные. Flow позволяет выстраивать такие API-сценарии. То есть компания может не ждать, пока кто-то отдельно напишет серверную логику, а построить собственный сценарий доступа и выдачи данных из системы. Например, есть кастомный лендинг. Человек нажимает “Показать каталог”. Лендинг обращается не в хаотичный внешний источник, а к сценарию Flow, который формирует именно те данные, которые нужны: только активные товары, только определённая точка, только доставка, только на английском языке. И это уже очень серьёзный уровень гибкости. Одиннадцатый сценарий — сценарии с Google Calendar и Gmail. Например, если в CRM создана встреча или задача на созвон, Flow может автоматически создать событие в Google Calendar. Если клиент подтвердил участие — обновить событие. Если встреча отменена — удалить или изменить её. То есть продажи и календарное планирование начинают жить вместе. С Gmail логика может быть такой: пришёл новый email → создать лид → классифицировать → назначить менеджера → отправить автоответ → поставить задачу. Или наоборот: при переходе лида на этап “Отправлено предложение” → автоматически отправить email с коммерческим предложением из шаблона. То есть почта перестаёт быть отдельным миром, который менеджер должен обрабатывать руками. Двенадцатый сценарий — многоуровневые цепочки действий. И это очень важно. Flow хорош не только в простых “если А, то Б”. Его сила в длинных цепочках. Например: пришёл заказ → если это новый клиент → создать карточку клиента → начислить приветственные бонусы → отправить push → если сумма выше 100 долларов → уведомить менеджера → если доставка → поставить задачу курьеру → если заказ содержит цифровой продукт → начислить цифровой доступ → если это арендный товар → сформировать задачу на возврат оборудования через 24 часа. То есть одна цепочка может связать сразу несколько подсистем. Тринадцатый сценарий — автоматическая сегментация клиентов. Например, компания хочет автоматически переводить клиентов в разные группы. Если клиент сделал первый заказ — перевести в “Новые клиенты”. Если сделал 5 заказов — в “Постоянные”. Если сумма заказов превысила 500 долларов — в “VIP”. Если клиент давно не заказывал — в “Риск оттока”. И дальше на эти группы уже можно вешать отдельные акции, push, email, бонусы и follow-up сценарии. То есть Flow становится мостом между операционной активностью и маркетинговой логикой. Четырнадцатый сценарий — автоматизация контента и маркетинга. Например, у компании есть правило: каждую пятницу в 17:00 нужно публиковать подборку выходных акций. Flow по расписанию запускается, собирает активные акции, отправляет их в AI, получает текст под Instagram, текст под Telegram, короткий текст под push, красивый subject под email, а потом всё это публикует и рассылает по нужным каналам. То есть маркетинг перестаёт быть ручным и начинает жить как управляемый поток. Пятнадцатый сценарий — реакция на отзывы и обратную связь. Например, клиент оставил негативный комментарий в соцсетях или плохую оценку после доставки. Flow видит это событие, определяет негативную тональность, срочно ставит задачу менеджеру поддержки, может отправить автоматическое извинение, пометить клиента как приоритетный случай и даже отправить руководителю уведомление. То есть система начинает не просто хранить обратную связь, а активно на неё реагировать. И вот здесь очень важно проговорить главный принцип: Flow в SABSUS — это не просто автоматизация ради автоматизации. Это слой, через который компания может проектировать свою бизнес-логику. Причём проектировать не в отрыве от данных, не в абстрактной диаграмме, а прямо внутри живой платформы, где уже есть реальные заказы, реальные клиенты, реальные лиды, реальные сообщения, реальные товары и реальные сотрудники. Если посмотреть глубже, то до этого момента мы видели, как SABSUS умеет: создавать бизнес, строить каталог, принимать заказы, вести клиента, готовить, доставлять, работать со складом, продавать через CRM, удерживать через маркетинг. А теперь мы видим, как всё это можно соединить в собственные сценарии. Именно поэтому Flow нельзя воспринимать как обычный вспомогательный раздел. Flow — это нервная система платформы. Это место, где компания перестаёт быть ограниченной только готовым интерфейсом и начинает реально настраивать своё цифровое поведение. Очень важно и то, что здесь нет жёстких ограничений по идеям. Компания может использовать SABSUS в очень разных целях. Для ресторанов — одни сценарии. Для магазинов — другие. Для аренды — третьи. Для цифровых продуктов — четвёртые. Для B2B продаж — пятые. Для социальных сетей — шестые. Для интеграций с любыми сервисами — седьмые. И это делает платформу не просто широкой, а реально адаптируемой. Приведу большой комплексный пример, чтобы показать всю силу этого блока. Представим, что компания добавляет новый товар — например, новый праздничный сет. Как это может выглядеть через Flow? Карточка товара создаётся в каталоге. Flow видит событие “создан новый товар”. Проверяет, есть ли описание. Если описание короткое или слабое — отправляет данные в AI и получает: полное описание, короткое продающее описание, текст для карточки, текст для push, текст для Instagram, текст для Telegram. Если нет хорошего изображения — запускает сценарий генерации или подготовки визуала. Потом автоматически: публикует пост в Instagram, отправляет анонс в Telegram, создаёт баннер в маркетинговом разделе, отправляет push группе “Постоянные клиенты”, добавляет товар в специальную витрину на главной странице, и если нужно — отправляет уведомление менеджеру о том, что запуск нового продукта завершён. То есть один товар проходит путь: каталог → AI → маркетинг → соцсети → push → клиент → заказ. И всё это внутри одной платформы. Другой большой пример. Клиент пишет в WhatsApp: “Здравствуйте, хочу заказать кейтеринг на 40 человек на субботу.” Сообщение попадает в SABSUS. Flow считывает его. AI понимает, что это лид на кейтеринг. Создаётся лид в CRM. Сегмент — тёплый. Приоритет — высокий. Назначается ответственный менеджер. Клиенту автоматически уходит аккуратный ответ: “Здравствуйте. Спасибо за обращение. Мы можем помочь с кейтерингом. Подскажите, пожалуйста, адрес мероприятия, желаемое время и предпочтительный формат меню?” Дальше менеджер уже открывает готовую карточку лида с AI-комментарием и продолжает продажу. То есть один мессенджер автоматически превращается в полноценный вход в коммерческий контур бизнеса. И вот это и есть “бомба” этого модуля. Потому that Flow не добавляет одну-две удобные функции. Он меняет сам класс продукта. До Flow SABSUS — это очень сильная операционная система бизнеса. С Flow SABSUS — это программируемая операционная система бизнеса. Платформа, где бизнес может не только работать, но и сам конструировать своё поведение, свои реакции, свои интеграции, свои отчёты, свои каналы, свои API и свой AI-слой. Именно поэтому этот блок — один из самых сильных во всей презентации. Потому что здесь становится окончательно понятно: SABSUS — это не просто готовый набор экранов. Это среда, где бизнес может создавать свою собственную цифровую архитектуру. И после такого модуля логично перейти к следующему этапу — к тому, как всё это подаётся на уровне бренда, внешнего вида, white-label, подписки, масштабирования и общей ценности платформы для владельца бизнеса. Потому что после того, как мы увидели всю операционку, продажи, маркетинг, коммуникации и Flow, нужно собрать финальную картину: что именно получает владелец бизнеса, зачем ему это всё в одной системе и почему SABSUS — это одна платформа вместо хаоса из разных сервисов.

Теперь мы переходим к следующему очень важному этапу — к тому слою, где SABSUS перестаёт быть просто внутренним рабочим инструментом и превращается в полноценную платформу под брендом компании. До этого момента мы уже увидели, как внутри SABSUS строится компания, как создаются точки продаж, товары, услуги, рецепты, как работает POS, CRM, склад, поставщики, курьеры, маркетинг, коммуникации и Flow. Но теперь важно посмотреть на систему с другой стороны. Не с точки зрения кассира. Не с точки зрения курьера. Не с точки зрения менеджера. А с точки зрения владельца бизнеса, который задаёт себе один очень важный вопрос: Это просто программа для работы внутри компании или это уже цифровая платформа, на которой я могу строить собственный бренд и собственную экосистему? И вот здесь SABSUS раскрывается особенно сильно. Потому что SABSUS — это не только интерфейсы для сотрудников. Это ещё и возможность для компании построить свою цифровую среду: со своими цветами, со своим стилем, со своим логотипом, со своим приложением, со своими интерфейсами для клиента, со своими точками продаж, со своей логикой коммуникации, со своими уведомлениями, со своим каталогом, со своими сценариями и автоматизацией. И начнём с самого первого визуального слоя — внешнего вида приложения и клиентской среды. В SABSUS каждая компания может настроить собственный брендбук внутри системы. То есть если раньше мы говорили просто о логотипе и названии, то здесь речь уже идёт о глубокой визуальной настройке всей платформы. Если включена стандартная тема, система использует базовое оформление. Это удобно для быстрого старта, когда компании важно запуститься быстро и без лишней настройки. Но как только бизнес хочет более сильную идентичность, стандартную тему можно отключить и открыть детальную настройку интерфейса. Дальше можно выбрать: первый цвет фона, второй цвет фона, основной цвет текста, второй цвет текста, цвет выбора и выделения, цвет текста на кнопках, основной брендовый цвет, цвет основных кнопок, цвет цены на карточке товара, второстепенный цвет, второстепенный цвет номер два, радиус углов и общий характер интерфейса. Например, если у компании бренд построен на тёплых ресторанных цветах, можно сделать: тёмно-бордовый основной цвет, тёплый светлый фон, золотистые акценты, мягкие радиусы карточек, контрастные кнопки заказа. Если это современный tech-бренд, можно уйти в глубокий графит, холодный синий, минимализм и строгие формы. Если это семейная пекарня — наоборот, сделать мягкие бежевые оттенки, уютную палитру и более дружелюбный интерфейс. И важный момент в том, что это не просто косметика. Когда компания настраивает цвета, радиусы, контраст и стили, она формирует ощущение бренда на всём клиентском пути. Клиент открывает приложение, сайт, электронное меню, карточку товара, экран оплаты — и везде чувствует именно эту компанию, а не абстрактный стандартный сервис. Дальше можно включить или выключить тёмную тему. Причём если тёмная тема активна, для неё можно отдельно задать свою палитру. То есть это не просто автоматическое затемнение интерфейса, а полноценная самостоятельная тема. Это особенно полезно для брендов, которые хотят поддерживать премиальный вид, ночной режим, контрастный стиль или просто сделать систему более удобной в вечернее время. Но SABSUS идёт ещё дальше. Компания может не ограничиваться только цветами и кнопками. Если выключить стандартную главную страницу, система позволяет подставить кастомную веб-страницу через HTML и WebView. И вот здесь начинается уже совершенно другой уровень гибкости. Например, компания может сделать не просто обычную главную страницу каталога, а полноценный брендированный landing-вход: с видео, с анимированным первым экраном, с историями о бренде, с сезонными предложениями, с персональными баннерами, с дизайнерскими секциями, с wow-эффектом. И при этом всё равно дальше этот клиент будет жить внутри общей экосистемы SABSUS: оформлять заказы, видеть свои акции, получать уведомления, входить в профиль, работать с бонусами, открывать цифровые продукты. То есть главная страница может быть очень кастомной, но сама логика бизнеса при этом не отрывается от платформы. И это очень сильный момент. Потому что обычно у бизнеса есть два мира: отдельный красивый маркетинговый сайт, и отдельно — скучная операционная система. А здесь эти два мира могут быть соединены в одно пространство. Теперь давай посмотрим на это шире. White-label в SABSUS — это не просто смена логотипа. И это очень важно проговорить правильно. У многих продуктов white-label означает: заменили иконку, подменили название, может быть, сменили пару цветов. Но ядро продукта, его поведение и клиентский опыт всё равно остаются чужими. В SABSUS white-label глубже. Потому что компания получает не просто “обёртку”, а возможность выстроить: свою визуальную систему, свои клиентские экраны, свои баннеры, свои тексты, свои языки, свои интерфейсы, свои типы заказов, свои способы оплаты, свои акции, свои депозиты, свои push-уведомления, свои цифровые продукты, свои Flow-сценарии, свои коммуникационные каналы. То есть на базе SABSUS бизнес может строить уже не просто внутренний кабинет, а собственную цифровую инфраструктуру под своим именем. Теперь очень важный блок — многоязычность. И здесь её нельзя воспринимать просто как приятное дополнение. Когда компания может задать: названия, описания, категории, акции, лейблы, тексты, внутренние воронки, названия интерфейсных сущностей сразу на нескольких языках, это означает, что система становится не локальной, а масштабируемой. Например, если бренд работает в Лос-Анджелесе, где аудитория говорит на английском, испанском и русском, он может использовать один и тот же SABSUS как платформу для разных сегментов клиентов. Один клиент видит всё на английском. Другой — на испанском. Сотрудник внутри кухни работает на испанском. Владелец смотрит панель управления на русском. Чек печатается на английском. Письма уходят на языке клиента. И всё это не развалено по разным системам, а живёт внутри одной среды. Именно это делает платформу зрелой. Теперь переходим к ещё одному важному уровню — подписка и модель использования платформы. Внутри SABSUS есть раздел подписки, где компания видит: свой текущий тариф, историю оплат, возможность изменить план, и всю экономику взаимодействия с платформой. И это важно не только для расчёта стоимости. Это важно для позиционирования самой платформы. Потому что у клиента есть ощущение, что он не просто “купил программу”, а подключил себе собственную операционную экосистему. Например, компания может начать с одной точки продаж. Потом открыть вторую. Потом подключить третью. Потом включить white-label. Потом добавить клиентское приложение, kiosk, курьеров, склад, CRM и Flow. То есть SABSUS можно масштабировать вместе с ростом бизнеса. Именно поэтому раздел подписки внутри такой системы — это не “формальность”, а отражение логики роста компании внутри платформы. Ещё один интересный блок — реферальная программа для владельцев компаний. Если компания уже использует SABSUS, она может рекомендовать платформу другим бизнесам и получать за это бонус. Например: месяц бесплатного использования, фиксированный денежный бонус, или другую форму вознаграждения. И здесь снова видно, что SABSUS мыслится не как одиночный инструмент, а как развивающаяся платформа с экосистемной логикой. Теперь давай посмотрим на вопрос глубже: что вообще получает владелец бизнеса на уровне бренда и стратегии, если выбирает SABSUS? Первое — он получает одну цифровую среду вместо хаоса из разрозненных сервисов. Не отдельную кассу. Не отдельную CRM. Не отдельное приложение. Не отдельный склад. Не отдельную доставку. Не отдельные чаты. Не отдельные таблицы. А одну связанную платформу. Второе — он получает собственный клиентский опыт, а не жизнь на чужих правилах. Клиент видит именно этот бренд. Именно эти акции. Именно эту систему коммуникации. Именно эту программу лояльности. Именно этот стиль приложения и интерфейсов. Третье — он получает роль-ориентированную среду. То есть не просто “всем один кабинет”, а разные рабочие пространства под реальные роли: владелец, кассир, менеджер продаж, поставщик, курьер, повар, клиент, сотрудник производства, сотрудник склада. Четвёртое — он получает масштабируемость. Потому что SABSUS не заканчивается на одном сценарии. Сегодня это одна точка и простая доставка. Завтра это сеть. Послезавтра — своя white-label платформа, свои каналы, свои AI-сценарии и автоматизация. Пятое — он получает гибкость без потери центра управления. И это, возможно, один из самых сильных моментов. Потому что часто у бизнеса есть выбор: либо жёсткая коробка, где всё стандартно и ничего нельзя менять, либо кастомная разработка, которая стоит дорого, долго и больно поддерживается. SABSUS даёт третью модель: есть сильное готовое ядро, и при этом есть глубокая настройка, white-label, Flow, интеграции, AI и свои сценарии. Теперь приведу несколько примеров, чтобы этот слой почувствовался не абстрактно, а как реальная ценность. Первый пример. Есть ресторанный бренд, у которого раньше были: отдельная касса, отдельная CRM, отдельный Instagram, отдельная таблица по складу, отдельные мессенджеры для сотрудников, и отдельный сайт, не связанный с логикой заказов. После перехода в SABSUS владелец получает единый брендированный контур: сайт и клиентский интерфейс под своим стилем, POS в общей системе, акции и баннеры в одном месте, курьеров в одном месте, склад в одном месте, клиентов в одном месте, Flow-сценарии под свои правила. То есть бренд получает не просто “удобнее работать”, а цифровой порядок. Второй пример. Есть сеть заведений, которая хочет запустить своё приложение под своим брендом, а не зависеть только от агрегаторов. Они настраивают в SABSUS: свои цвета, свои фотографии, свои точки продаж, свои способы доставки, свои баннеры, свою программу лояльности, свои уведомления, свои правила бонусов. И в результате клиент пользуется приложением бренда, а не чужой экосистемой агрегатора. Для бизнеса это означает: свои данные о клиентах, свои правила общения, свои повторные продажи, своя маржинальность, свой канал удержания. Третий пример. Компания продаёт не только товары, но и цифровые продукты, подписки и услуги. Через SABSUS она выстраивает: брендированный каталог, многоязычные карточки, клиентский кабинет, свои темы и оформление, автоматические рассылки, CRM, Flow, интеграции с внешними сервисами. То есть фактически на базе одной платформы строит собственный цифровой бизнес. И вот именно здесь мы подходим к очень важной формулировке. SABSUS — это не просто система, где бизнес работает. И даже не просто система, где бизнес продаёт. SABSUS — это платформа, на которой бизнес может выглядеть как самостоятельный цифровой продукт. То есть владелец бизнеса получает не только внутреннюю эффективность, но и внешнюю силу бренда. Теперь давай зафиксируем главный смысл этого блока. White-label и визуальная настройка в SABSUS — это не косметический бонус. Это стратегическая возможность для бизнеса: уйти от чужих интерфейсов, уйти от ощущения “мы просто используем какую-то программу”, и перейти к состоянию “у нас есть собственная цифровая система под нашим брендом”. И это очень сильный сдвиг мышления. Потому что когда компания начинает воспринимать платформу не как расход, а как часть своей инфраструктуры и актива, меняется и ценность продукта, и готовность в него инвестировать, и глубина интеграции в сам бизнес. И теперь, когда мы уже посмотрели на: фундамент компании, каталог, клиентский путь, POS, экраны, производство, склад, поставщиков, курьеров, CRM, маркетинг, Flow, и white-label-слой, нам остаётся собрать всё в одну финальную картину. То есть следующий этап — это уже не “ещё один модуль”, а итоговая большая сборка всего смысла платформы: как это всё соединяется для владельца бизнеса, что он получает на практике, почему это одна система вместо хаоса из разных сервисов, и почему после такого обзора становится понятно, что SABSUS — это не набор функций, а полноценная бизнес-инфраструктура. Если хочешь, следующим сообщением я напишу финальный завершающий блок всего большого видео — мощный, цельный, с правильной логикой окончания, чтобы после него можно было уже закрывать master-видео и потом спокойно нарезать его на части.

Итак, мы прошли весь путь полностью. Мы начали не с кнопок и не с таблиц, а с самой главной проблемы современного бизнеса — с хаоса из разрозненных сервисов. Когда CRM живёт отдельно. Касса отдельно. Склад отдельно. Доставка отдельно. Клиенты отдельно. Сообщения в социальных сетях отдельно. Автоматизация вообще в сторонних инструментах. А сотрудники при этом постоянно работают на стыках между системами, теряют время, допускают ошибки и живут в ручном режиме. И всё это видео было нужно для того, чтобы показать одну простую, но очень важную мысль: SABSUS создан именно для того, чтобы собрать весь этот хаос в одну систему. За это время мы увидели, как в SABSUS создаётся сам фундамент бизнеса. Как настраивается компания. Как добавляются точки продаж. Как задаются языки, бренд, способы оплаты, налоги, доставка, безопасность, сотрудники, доступы и структура компании. То есть мы увидели, что система начинается не с продажи, а с правильно собранной базы бизнеса. Потом мы перешли к каталогу и увидели, что SABSUS работает не просто с товарами. Платформа умеет работать с: обычными товарами, услугами, арендой, цифровыми продуктами, ингредиентами, полуфабрикатами, технологическими картами, упаковкой, расписаниями, цехами и производственной логикой. То есть здесь создаётся не просто карточка товара, а весь реальный контур того, что бизнес продаёт, производит, выдаёт и доставляет. После этого мы посмотрели на систему глазами клиента. Увидели клиентский интерфейс, каталог, корзину, заказы, уведомления, бонусы, депозит, избранное, цифровые продукты, профиль, настройки, электронное меню и станцию самообслуживания. И стало очевидно, что SABSUS — это не просто внутренний кабинет для сотрудников. Это ещё и полноценная клиентская среда, где человек покупает, отслеживает, общается, оплачивает и возвращается снова. Дальше мы перешли в POS и увидели, как заказ живёт внутри бизнеса. Как открывается смена. Как кассир работает с заказом. Как добавляются товары, услуги, акции, бонусы, депозит, как принимается оплата, как работает split payment, как заказ передаётся на производство, как создаются задачи, как подключается доставка, как система работает офлайн и как POS становится не просто кассой, а полноценным операционным центром точки. Потом мы увидели экраны клиента и экран статусов заказов. Увидели, как заказ становится прозрачным для гостя. Как клиент видит свою оплату. Как зал видит статусы готовности. И как визуальный слой тоже становится частью общего бизнес-процесса. После этого мы перешли в производство и увидели, что кухня, упаковка и цеха в SABSUS — это не просто таблицы с заданиями. Это живая исполнительная среда, где есть: рецепты, заметки, статусы, калькуляции, инструкции, фотографии, запасы, списания, уведомления и смены. То есть заказ в системе не просто “меняет статус”, а реально проходит этап исполнения. Дальше мы ушли на склад. Увидели поставки, сканирование, фото накладных, распознавание документов, заявки поставщикам, перемещения, списания, возвраты, инвентаризацию и печать ценников. И стало очевидно, что SABSUS контролирует не только продажу, но и реальное движение товара внутри бизнеса. Потом мы посмотрели на интерфейс поставщика и увидели, что экосистема выходит за пределы самой компании. Поставщик может работать внутри платформы, видеть заказы, делать офферы, предлагать товары, отправлять документы, общаться с менеджерами, участвовать в цифровом контуре компании. То есть SABSUS связывает бизнес не только с клиентом, но и с внешними партнёрами. После этого мы перешли к курьерскому интерфейсу и увидели всю последнюю милю. Гараж, транспорт, маршрут, карта, face verification, пакетные доставки, задачи, чат, звонок, подтверждение доставки, фотографии, оплата, покупки по дороге, статистика и смены. И стало ясно, что доставка здесь — это не отдельная надстройка, а полноценная встроенная часть платформы. Затем мы перешли в CRM и увидели, что SABSUS умеет не только исполнять входящий поток, но и системно продавать. Неограниченные воронки, этапы, SLA, KPI, чек-листы, скрипты, ветки вопросов, обработка возражений, шаблоны сообщений, обучающие материалы, AI-рекомендации, лиды, фильтрация, архив. То есть платформа умеет не просто принимать заказ, а вести клиента ещё до момента покупки и дальше после неё. После этого мы посмотрели на маркетинг и коммуникации. Акции, группы клиентов, лояльность, баннеры, email, SMS, push, чаты, коммуникация из Instagram, WhatsApp, Telegram, Facebook и других каналов. И здесь стало видно, что SABSUS умеет не только продавать и исполнять, но и удерживать клиента, возвращать его, строить повторные продажи, работать с сегментами и выстраивать омниканальную коммуникацию внутри одной среды. Потом мы перешли к одному из самых мощных слоёв всей системы — к Subsus Flow. Именно там стало окончательно понятно, что SABSUS — это не просто система с готовыми экранами. Это программируемая бизнес-платформа. Потому что Flow позволяет: строить свои сценарии, свои триггеры, свои API, свои интеграции, свои реакции на события, свои сценарии с AI, свои сценарии с email, SMS, Instagram, Google, таблицами, уведомлениями и любыми внешними сервисами. То есть бизнес в SABSUS может не только пользоваться готовой платформой, но и проектировать собственную цифровую логику. И после этого мы посмотрели на white-label слой и увидели, что SABSUS — это не просто внутренняя программа. Это возможность для компании построить собственную брендированную цифровую инфраструктуру: со своими цветами, со своим стилем, со своим клиентским опытом, со своими интерфейсами, со своими баннерами, со своими правилами, со своим приложением, со своей системой коммуникации и своим цифровым лицом. И вот теперь, после всего этого, можно сформулировать самый главный вывод. SABSUS — это не POS. Хотя внутри есть очень сильный POS. SABSUS — это не CRM. Хотя внутри есть полноценная система продаж. SABSUS — это не складская система. Хотя внутри есть сильный склад, поставки, перемещения и инвентаризация. SABSUS — это не система доставки. Хотя внутри есть курьеры, маршруты, задачи и последняя миля. SABSUS — это не просто маркетинговая платформа. Хотя внутри есть акции, сегменты, баннеры, push, email и омниканальные коммуникации. SABSUS — это не просто white-label решение. Хотя на его базе можно строить собственную цифровую среду под брендом компании. SABSUS — это не просто автоматизация. Хотя внутри есть Flow, AI, интеграции и любые сценарии. Правильнее сказать так: SABSUS — это единая модульная role-based white-label operating system для бизнеса. Это платформа, в которой компания может: создать свой бизнес, настроить его, продавать через него, вести клиентов, управлять сотрудниками, обрабатывать заказы, контролировать склад, работать с поставщиками, готовить и производить, доставлять, удерживать клиента, автоматизировать процессы, подключать AI, строить свои интеграции и масштабировать всё это внутри одной системы. И вот здесь важно сказать самую честную вещь. Главная ценность SABSUS не в том, что у него “много функций”. Потому что функций может быть много у многих систем. Главная ценность в том, что все эти функции соединены между собой в одну живую бизнес-экосистему. Заказ связан с клиентом. Клиент связан с CRM. CRM связана с коммуникациями. Коммуникации связаны с маркетингом. Маркетинг связан с каталогом. Каталог связан со складом. Склад связан с поставщиками. Заказ связан с производством. Производство связано с доставкой. Доставка связана с клиентом. И всё это связано с Flow, AI и интеграциями. То есть SABSUS — это не история про “много модулей”. Это история про единый цифровой организм бизнеса. Именно поэтому владелец бизнеса получает не просто удобство. Он получает: контроль, структуру, скорость, прозрачность, масштабируемость, собственные данные, собственный бренд, и самое главное — выход из хаоса разрозненных сервисов. Если говорить совсем коротко, то SABSUS позволяет бизнесу перейти от модели: “у нас есть куча разных инструментов, которые кое-как живут рядом” к модели: “у нас есть одна платформа, в которой работает весь бизнес”. И именно в этом заключается настоящая сила SABSUS. Если вы смотрите это видео как владелец бизнеса, руководитель, партнёр, инвестор или компания, которая ищет сильную инфраструктуру для роста, то главный вопрос после этого обзора должен звучать не так: “Есть ли здесь ещё какая-то функция?” А так: “Сколько отдельных сервисов и ручных процессов я смогу заменить одной системой?” Потому что именно это и делает SABSUS по-настоящему ценным. И на этом большой полный обзор SABSUS завершён. Мы прошли путь от самого начала до полного масштаба платформы. От компании и точек продаж — до клиентов, POS, CRM, склада, доставки, маркетинга, Flow, AI, white-label и общей бизнес-инфраструктуры. И если смотреть на всё это целиком, то становится понятно: SABSUS — это одна платформа вместо хаоса из разных систем. Спасибо за просмотр.