Большинство операционной деятельности в организациях - это не то, ради чего организация существует. Компания приносит пользу, оказывая услуги, производя продукт, решая задачи клиентов. А операционка - сбор документов, согласования, маршрутизация обращений, контроль дедлайнов - это инфраструктура, которая обеспечивает основную деятельность. Hublix автоматизирует именно эту часть.
Идея
Практически любой операционный процесс можно описать в терминах конечного автомата (finite state machine, FSM). Конечный автомат - это модель, в которой система в каждый момент времени находится в одном из определённых состояний. Из каждого состояния возможны переходы в другие состояния - но только при выполнении заданных условий. Переходы могут запускать действия: отправку письма, формирование документа, вызов внешнего API, эскалацию на менеджера.
Пример: обращение клиента в сервисную компанию. Состояния: «новое обращение» → «квалификация» → «сбор документов» → «проверка комплектности» → «передача специалисту» → «выполнено». Условия переходов: «все документы собраны», «бюджет согласован», «клиент не отвечает 3 дня - эскалация». Действия: отправить напоминание, сформировать чеклист, уведомить специалиста.
Но автоматизировать можно не только маршрутизацию и координацию. Часть работы, которая традиционно считалась интеллектуальной, по сути ей не является: валидация входных документов на соответствие требованиям, скоринг заявок по формальным критериям, reasoning по набору правил, базовые консультации по регламентам и процедурам. Раньше для этого нужен был специалист. Сейчас LLM справляется с этими задачами на уровне, достаточном для автоматизации.
Системы предыдущего поколения - BPM, CRM, конструкторы ботов - по сути реализовывали именно конечные автоматы. Но значительная часть сложности и стоимости этих систем приходилась не на сам автомат, а на UI/UX: создание понятного и контролируемого интерфейса для всех участников процесса. Формы, валидации, подсказки - всё это нужно было проектировать, чтобы пользователь мог взаимодействовать с автоматом строго определённым образом.
С появлением LLM открылась возможность строить нечёткие интерфейсы. Пользователь пишет обычным текстом, присылает фото документа, отвечает голосом - и система понимает, что он имел в виду. Не нужны ни формы, ни обучение пользователя. LLM переводит человеческий ввод в структурированные данные, с которыми работает автомат. А на шагах, где раньше требовался специалист для проверки или оценки, LLM выполняет эту работу в рамках сценария - валидирует, оценивает, консультирует.
Hublix совмещает оба подхода: FSM контролирует flow процесса, LLM обеспечивает нечёткий интерфейс и берёт на себя задачи, которые раньше требовали человека. Автомат решает, куда идти. LLM решает, что пользователь сказал и что делать с данными.
Архитектура: FSM + LLM
Ключевое архитектурное решение - разделение ответственности между детерминированным движком и языковой моделью.
| Слой | Отвечает за | Пример |
|---|---|---|
| State Engine (FSM) | Порядок шагов, переходы, guard-условия, SLA | «Если документы собраны - переходим к проверке» |
| LLM | NLU, extraction, генерация ответа | «Пользователь прислал скан паспорта материала» |
Зачем так:
- Предсказуемость. FSM гарантирует, что процесс не перепрыгнет через шаг и не застрянет в цикле. Каждый переход - явное правило с условием.
- Стоимость. LLM вызывается только там, где нужен естественный язык. В decision-состояниях (проверка guard-условий) LLM не задействован вообще.
- Отладка. Каждый turn записывается: какое состояние было, какой intent классифицирован, какой переход сработал. Полный audit trail процесса.
- Устойчивость. Если LLM недоступен, FSM продолжает работать в режиме fallback - с эскалацией на оператора, шаблонными ответами или переключением на упрощённые модели.
Сценарии описываются декларативно - как набор состояний с типами:
- INPUT - ожидание сообщения от пользователя
- PROCESSING - LLM классифицирует и извлекает данные
- ACTION - вызов внешнего API или обновление контекста
- DECISION - ветвление по guard-условиям (без LLM)
- TERMINAL - завершение процесса
Точки интеграции
Ядро платформы не привязано к конкретному интерфейсу. Агент работает с абстрактным потоком сообщений - откуда они приходят, определяется адаптером.
- Мессенджеры. Telegram, MAX (VK) - реализованы в MVP. Пользователь общается с агентом в привычном интерфейсе.
- JS-виджет. Встраивается на сайт или в веб-приложение клиента. Агент работает как чат на странице - для онлайн-записи, регистрации обращений, квалификации лидов.
- REST API. Агент подключается к существующей системе клиента напрямую. CRM, ERP, внутренний портал, мобильное приложение - отправляют сообщения в агента и получают структурированные ответы. Никакого отдельного интерфейса не нужно.
Один и тот же сценарий работает через все точки интеграции без изменений. Меняется только адаптер, который транслирует ввод в платформенный формат.
Аудитория
Первичная аудитория - компании с повторяющимися процессами взаимодействия с клиентами: аутсорс бухгалтерии, юридические услуги, консалтинг, кадровые агентства, медицинские клиники, государственные сервисы.
Общие признаки целевого клиента:
- Процесс включает сбор информации или документов от клиента
- Есть чёткая последовательность шагов с условиями и дедлайнами
- Менеджер тратит 50%+ времени на координацию, а не на экспертную работу
Процессы могут быть как длинными (квартальное закрытие бухгалтерии - недели), так и разовыми (регистрация обращения, запись на приём - минуты). Пользователь обращается к агенту, проходит сценарий, получает результат. FSM одинаково хорошо работает с обоими типами.
Пример: вертикальный SaaS для бухгалтерии
Как конкретно выглядит применение Hublix для vertical SaaS - на примере аутсорсинговой бухгалтерской компании, которая ведёт 200 клиентов-ИП.
Проблема
Каждый квартал бухгалтер должен собрать у каждого клиента: банковскую выписку, акты сверки, документы по новым контрагентам, информацию об изменениях (новые сотрудники, смена адреса, изменение ОКВЭД). Менеджер рассылает напоминания, получает документы вперемешку с бытовой перепиской, вручную проверяет комплектность и передаёт бухгалтеру.
На 200 клиентов нужно 2-3 менеджера только для координации. Бухгалтер получает неполные пакеты и тратит время на переписку.
Решение на Hublix
Агент ведёт каждого клиента через квартальный процесс сбора документов. Точка интеграции - любая: Telegram, виджет в личном кабинете, API из 1С.
| Шаг | Состояние FSM | Что происходит |
|---|---|---|
| 1 | remind | За 2 недели до дедлайна агент пишет клиенту: «Квартал закрывается 25 числа. Нужны: выписка, акты сверки, данные по новым контрагентам» |
| 2 | collect_documents | Клиент присылает файлы. LLM классифицирует: «это банковская выписка за Q3». FSM обновляет чеклист |
| 3 | check_completeness | Decision-состояние: все документы собраны? Нет → повторный запрос недостающих. Да → передача бухгалтеру |
| 4 | handoff_to_accountant | Бухгалтер получает готовый пакет с классифицированными документами и заполненным чеклистом |
| 5 | sla_monitor | Если клиент не отвечает 3 дня - автоматическое напоминание. 7 дней - эскалация на менеджера |
Этот же шаблон ложится на любую сервисную вертикаль: юридический due diligence, HR-онбординг, медицинский сбор анамнеза, аудит. Меняются состояния и guard-условия, архитектура остаётся той же.
Быстрая доставка и средний бизнес
Средний бизнес (50-500 сотрудников) всегда находился в мёртвой зоне автоматизации: слишком большой для ручных процессов, слишком маленький для enterprise-решений. Внедрение CRM или BPM-системы занимает месяцы и стоит миллионы.
Сейчас ситуация меняется. Скорость разработки специализированных инструментов выросла на порядок благодаря LLM-ассистированному программированию, готовым inference API и декларативным фреймворкам. То, что раньше требовало команду из 5 инженеров на полгода, делается за 2-3 месяца силами двух человек.
Для среднего бизнеса это означает: становится экономически оправданным создавать узкоспециализированные инструменты под конкретную отрасль. Не «универсальная CRM», а инструмент, который знает специфику бухгалтерского аутсорса, строительной ИД или юридического due diligence.
Почему вертикальные инструменты выигрывают у горизонтальных:
- Готовые шаблоны процессов. Клиент не конструирует workflow с нуля, а выбирает шаблон «Квартальное закрытие для бухгалтерского аутсорса» и адаптирует детали.
- Отраслевая терминология в LLM-промптах. Агент понимает, что «выписка» - это банковская выписка, а не выписка из ЕГРЮЛ, потому что контекст сценария ограничен бухгалтерией.
- Интеграции с отраслевыми системами. Для бухгалтерии - 1С и банк-клиенты. Для строительства - ИСОГД и реестры СРО. Горизонтальная платформа не будет делать такие интеграции для каждой ниши.
- Fine-tuned модели под вертикаль. Для каждой отрасли можно дообучить LLM на специфичных данных: терминология, типовые документы, регламенты. Такая модель точнее классифицирует, меньше ошибается и дешевле в inference, чем универсальная. Платформа может предоставлять fine-tuned модели как часть вертикального решения.
- Ценообразование по ценности. Бухгалтерская компания платит не за «количество ботов», а за «количество обслуженных клиентов» - метрику, которая напрямую привязана к её выручке.
Конкуренты
Рынок автоматизации клиентских процессов в России и СНГ разделён на несколько категорий.
Конструкторы чат-ботов
BotHelp, Salebot, SendPulse. Визуальные конструкторы для маркетинговых воронок и простых сценариев. Работают по принципу «кнопка → ответ → кнопка». Не справляются с процессами, где пользователь отвечает свободным текстом, присылает документы или отклоняется от линейного сценария. Нет state management, нет SLA, нет LLM.
BPM-платформы
Elma, Битрикс24, amoCRM. Полноценные системы управления процессами, но внешние точки контакта (мессенджеры, виджеты) работают как уведомления, а не как полноценный интерфейс процесса. Клиент не может пройти весь процесс в одной точке - ему нужно переключиться в веб-интерфейс BPM. Дорогие, долгие во внедрении, требуют интеграторов.
AI-агентные платформы
Voiceflow, Botpress, Relevance AI. Ближе всего к Hublix по подходу, но ориентированы на международный рынок. Не интегрируются с российскими платформами (MAX/VK), не поддерживают российские LLM, не учитывают 152-ФЗ и требования локализации данных.
n8n и workflow-автоматизаторы
n8n, Make (Integromat), Zapier. Инструменты для построения автоматизаций из готовых интеграций. n8n - open-source, self-hosted, с визуальным редактором workflow. Позволяет связать сотни сервисов: получил webhook → обработал данные → отправил в CRM → уведомил в Slack.
На первый взгляд n8n решает ту же задачу, что и Hublix. На практике разница в единице абстракции:
| n8n | Hublix | |
|---|---|---|
| Единица | Workflow (цепочка действий, запускаемая триггером) | Процесс (конечный автомат с состояниями, переходами, SLA) |
| Модель взаимодействия | Event-driven: триггер → действия → результат. Однократное выполнение | Stateful: процесс живёт дни и недели, ждёт ответа пользователя, отслеживает дедлайны |
| Пользовательский интерфейс | Нет. n8n работает «за кулисами», пользователь не взаимодействует с workflow напрямую | Мессенджер, виджет, API. Пользователь ведёт диалог с агентом на естественном языке |
| LLM | Через ноды (OpenAI, Ollama). LLM - один из шагов в цепочке | LLM встроен в ядро: NLU на каждом шаге, нечёткий интерфейс, extraction, генерация ответов |
| State management | Между запусками workflow состояние не сохраняется (нужны внешние хранилища) | Контекст процесса хранится в движке: собранные документы, чеклисты, история взаимодействий |
| Типичная задача | «Когда приходит письмо с invoice, извлеки сумму и добавь строку в Google Sheets» | «Веди клиента через квартальное закрытие: собери документы, проверь комплектность, отслеживай дедлайны» |
n8n хорош для интеграций и реактивных автоматизаций: событие произошло → выполни цепочку действий. Hublix решает другую задачу - ведение долгоживущего процесса с участием человека, где агент сам инициирует взаимодействие, ждёт ответа, контролирует сроки и адаптируется к нечёткому вводу.
При этом n8n и Hublix не конкурируют напрямую - они комплементарны. n8n может выступать интеграционным слоем: Hublix передаёт собранные данные в n8n-workflow, который раскладывает их по внешним системам (1С, CRM, Google Sheets).
Возможные пивоты
Платформа спроектирована так, чтобы ядро (FSM + LLM + адаптеры интеграций) оставалось неизменным при смене бизнес-модели или целевого рынка.
| Направление | Суть | Что меняется |
|---|---|---|
| Вертикальный SaaS | Готовый продукт для одной отрасли (бухгалтерия, строительство, юристы) | Шаблоны сценариев, интеграции, ценообразование |
| Платформа-конструктор | Self-service: клиент сам строит сценарии в визуальном редакторе | UI редактора, онбординг, документация |
| White-label | Интеграторы и агентства используют Hublix под своим брендом | Multi-tenancy, брендирование, партнёрская программа |
| Внутренний инструмент | Enterprise-компании автоматизируют внутренние процессы (HR, IT-support, compliance) | SSO/SAML, on-premise, интеграция с корпоративными системами |
| Marketplace агентов | Разработчики публикуют готовых агентов, компании покупают подписку | Revenue share, рейтинги, песочница для тестирования |
Наиболее вероятный путь: начать как вертикальный SaaS для одной ниши (валидация product-market fit), затем открыть платформу для смежных вертикалей через шаблоны и конструктор.
Монетизация
Модель привязана к ценности, а не к инфраструктуре.
| Метрика | Цена | Логика |
|---|---|---|
| Завершённый процесс | 50-100 ₽ | Клиент платит за результат: собранный пакет документов, квалифицированный лид, оформленная заявка |
| Активный клиент в месяц | ~100 ₽ | Для сервисов с постоянной базой (бухгалтерия, коучинг) |
| CRM-интеграция | 500 ₽/мес | Подключение к amoCRM, Битрикс24, 1С |
LLM-токены транслируются по себестоимости с маржой ~70%. Средний чек на клиента: 3 000 - 10 000 ₽/месяц.
Compliance: работа по законам РФ
Платформа спроектирована для работы в правовом поле Российской Федерации. Все данные хранятся и обрабатываются на территории РФ.
| Закон | Требование | Как реализовано |
|---|---|---|
| 152-ФЗ «О персональных данных» | Хранение и обработка ПДн граждан РФ на территории РФ. Согласие на обработку, ограничение целей | Инфраструктура в Yandex Cloud (ru-central1). Данные не покидают территорию РФ |
| 149-ФЗ «Об информации, информационных технологиях и о защите информации» | Требования к операторам информационных систем, обеспечение целостности и доступности | TLS на всех соединениях, шифрование данных at rest, управление доступом |
| 187-ФЗ «О безопасности критической информационной инфраструктуры» | Требования к субъектам КИИ при работе с клиентами из регулируемых отраслей (финансы, медицина, транспорт) | Использование сертифицированных облачных сервисов Yandex Cloud. Audit trail всех операций |
| 242-ФЗ (поправки к 152-ФЗ) | Локализация баз данных с ПДн граждан РФ на территории РФ | PostgreSQL, Redis, object storage - всё в российских дата-центрах |