SABSUS: как я пришёл к идее одной системы вместо хаоса из десятков сервисов

С чего началось настоящее понимание проблемы

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

Особенно хорошо это видно в компаниях, где много ролей и каналов. Ресторан, магазин, dark kitchen, доставка, услуги, аренда, цифровые продукты — везде одна и та же беда. Сотрудники видят разные части одной реальности, но у бизнеса нет единого ядра, которое держит всё вместе.

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

Именно тогда для меня начал формироваться SABSUS.

Почему я не хотел делать очередную CRM или просто кассу

Я изначально не хотел идти по привычному пути. Сделать отдельную CRM было бы проще. Сделать отдельную POS-систему — тоже. Можно было выбрать один модуль, упаковать его красиво и продавать как готовое решение. Но это не решало главную проблему.

Реальный бизнес не живёт модулями. Он живёт ролями, событиями и процессами.

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

Поэтому идея SABSUS с самого начала строилась не вокруг набора модулей, а вокруг единой среды, где все эти роли получают свои интерфейсы, но работают внутри одной логики.

Как начала складываться архитектура SABSUS

Внутри себя я постоянно задавал один и тот же вопрос: что видит каждая роль и что ей реально нужно в моменте?

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

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

Самое важное здесь не количество экранов. Самое важное — связность. Всё это не существует параллельно. Всё это связано данными, событиями и общей логикой.

Почему для меня всё начинается не с товара, а с каркаса бизнеса

Одна из ранних мыслей, которая сильно повлияла на продукт, была очень простой: если у компании криво собран фундамент, никакой красивый интерфейс потом это не спасёт.

Поэтому в SABSUS бизнес не просто регистрируется. Он собирается.

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

Отдельно я много думал про точки продаж. В реальной жизни одна локация может быть рестораном с залом, доставкой и самовывозом. Другая — производством. Третья — интернет-магазином. Четвёртая — dark kitchen. И если система не понимает этого на уровне архитектуры, дальше начинаются компромиссы, костыли и бесконечные ограничения.

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

Каталог: место, где обычные системы обычно ломаются

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

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

Поэтому каталог в SABSUS изначально строился глубже.

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

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

Клиентский слой: не просто приложение, а продолжение всей платформы

Когда у тебя выстроено внутреннее ядро, следующий вопрос всегда один: а что на другой стороне видит клиент?

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

Клиент в SABSUS видит не только товары. Он видит бренд, свои активные заказы, статусы, бонусы, депозит, уведомления, адреса, историю, любимые позиции, цифровые продукты, документы и поддержку. У него может быть мобильное приложение, веб-интерфейс, self-service станция, QR-меню, экран статусов заказа и разные поверхности взаимодействия с одной и той же системой.

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

POS: не окно оплаты, а операционный центр точки

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

Но в реальной работе POS — это место, где пересекаются заказ, клиент, каталог, акции, склад, кухня, оплата, история и сотрудники. Ошибка здесь стоит дорого.

Поэтому POS в SABSUS я строил как полноценный центр управления заказом. Сотрудник входит по PIN, открывает смену, видит остаток наличных, работает с заказом, меняет состав, применяет акции и бонусы, использует депозит, добавляет комментарии, видит клиента, историю, статусы, может разбить оплату, принять частичный платёж, отправить позиции на производство, распечатать чек и вести заказ как живой объект до завершения.

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

Производство и кухня: заказ должен быть задачей, а не абстракцией

Ещё один блок, который я с самого начала не хотел делать поверхностно, — кухня и производство.

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

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

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

Склад: не остатки ради галочки, а реальный контроль

Если продажи и производство работают глубоко, но склад живёт как отдельная таблица, хаос просто приходит чуть позже.

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

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

Именно на этом уровне бизнес начинает чувствовать разницу между «мы что-то учитываем» и «мы действительно понимаем, что у нас происходит».

Поставщики и закупка: вынести их из серой зоны

У большинства компаний поставщики по-прежнему живут где-то снаружи. Цены — в переписке. Предложения — в PDF. Документы — в почте. Подтверждения — по звонку. Новые позиции — «скинем позже».

Это неудобно даже на маленьком масштабе. На серьёзном масштабе это просто опасно.

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

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

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

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

Для клиента это вообще один из самых чувствительных этапов. Всё, что происходило до этого внутри бизнеса, он оценивает по последним минутам взаимодействия. Поэтому доставка для меня никогда не была «дополнительной функцией».

CRM: не список карточек, а реальная машина продаж

Когда я пришёл к CRM-части, у меня уже было очень чёткое понимание, чего я точно не хочу. Я не хотел ещё одну красивую доску, где лиды просто двигают мышкой между колонками.

Настоящая CRM должна помогать продавать, а не только хранить контакты.

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

Плюс самое важное: связь с остальными каналами. Лид может прийти с сайта, из формы, из Instagram, из WhatsApp, из Telegram, из email, из рекламы, из комментариев. Система должна не просто сохранить его в карточке, а встроить в процесс продаж, не потеряв контекст.

Коммуникации и маркетинг: собрать разбросанные каналы в одну историю

Коммуникация — ещё один участок, где у большинства компаний всё разъезжается.

Почта отдельно. Соцсети отдельно. SMS отдельно. Push отдельно. История клиента отдельно. Маркетинг отдельно. Продажи отдельно.

Мне хотелось, чтобы в SABSUS это было собрано в единый слой. Чтобы бизнес мог работать с акциями, сегментами клиентов, бонусами, скидками, баннерами, рассылками и сообщениями не как с разрозненным набором сервисов, а как с одним контуром общения.

Отсюда и логика интеграций с email, SMS, Instagram, WhatsApp, Telegram, Facebook и другими каналами. Если человек уже был у бизнеса, писал ему, покупал, получал бонусы, участвовал в акции или оставлял заявку, всё это должно собираться в связанную историю, а не пропадать между разными кабинетами.

Flow: модуль, который соединил всё вместе

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

Именно поэтому Flow стал для меня одним из ключевых модулей SABSUS.

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

Это был очень важный шаг. Потому что без такой гибкости даже сильная система со временем начинает ограничивать. А мне хотелось обратного: чтобы бизнес мог не подстраиваться под платформу, а проектировать на её базе свою логику.

White-label: не про смену логотипа, а про право владеть своей средой

Отдельно для меня очень важна тема white-label.

Я никогда не воспринимал white-label как банальную замену цвета и логотипа. Для меня это про другое: у бизнеса должна быть возможность владеть своим цифровым пространством. Своим брендом. Своим клиентским опытом. Своими данными. Своими сценариями взаимодействия.

Когда компания зависит только от внешних агрегаторов и чужих платформ, она всегда в уязвимом положении. У неё нет полноценного контроля над клиентским путём, коммуникацией и маржой. Поэтому white-label в SABSUS — это часть более широкой идеи: дать бизнесу не чужой кабинет, а собственную инфраструктуру.

Какие боли SABSUS закрывает на практике

Если говорить прямо, SABSUS закрывает сразу несколько системных проблем, которые обычно идут пакетом.

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

Почему я продолжаю строить SABSUS дальше

Для меня SABSUS давно перестал быть просто программой. Я воспринимаю его как операционную систему для бизнеса. Как цифровую инфраструктуру, внутри которой можно собрать компанию, выстроить продажи, наладить производство, связать склад, доставку, коммуникации, маркетинг, документы, поставщиков, клиентов и автоматизацию.

Если сказать совсем по-человечески, SABSUS — это мой ответ на тот хаос, который я слишком часто видел в современном бизнесе.

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

И именно поэтому я продолжаю строить SABSUS дальше.