Budibase позволяет собрать внутренний интерфейс, где предложение ИИ превращается в действие только после подтверждения человека: форма с полями, роли с разными правами, статус записи и журнал изменений. Платформу можно развернуть у себя или использовать в облаке. Такой экран уместен, когда согласующих несколько, а действие необратимо или стоит денег; для одного решения одного человека хватит таблицы с комментарием.
Что согласуем
Budibase держит предложение ИИ в записи со статусом, а внешнее действие ждёт решения согласующего. Интерфейс состоит из четырёх частей: форма, роли, статус и журнал изменений.
Допустим, менеджеры готовят коммерческие предложения, а ИИ подсказывает размер скидки по истории заказов клиента. Само предложение модели — число и короткое обоснование. Отправка предложения клиенту необратима, поэтому между ответом модели и отправкой ставится запись, которую видит человек с правом решения.
Работа делится так. Скрипт собирает сводку по клиенту из учётной системы и передаёт модели только нужные поля. Модель возвращает предлагаемый процент и обоснование. Скрипт сверяет процент с потолком, который задан политикой компании, и записывает результат в таблицу Budibase. Человек одобряет или отклоняет, а действие во внешней системе запускается после одобрения. От панели исключений в ToolJet, описанной в статье про панель оператора ИИ-процесса, этот интерфейс отличается предметом: там оператор разбирает очередь спорных случаев, здесь согласуется конкретное действие. Общая логика согласований между отделами описана в материале про автоматизацию согласований.
Клиентские данные в модель передаются выборочно: название сегмента, число заказов, средний объём, давность последней покупки. Контакты и реквизиты остаются в скрипте. Это сужает последствия ошибки модели и упрощает согласование интерфейса с тем, кто отвечает за персональные данные клиентов.
Форма и поля
По документации, Budibase строит приложения из источников данных, экранов, форм и автоматизаций, а форму собирают из готовых форм-блоков. Состав полей определяет, насколько удобно решать и проверять запись. Для каждого поля заранее решают, кто его заполняет и кто вправе править, и записывают решение рядом с таблицей. Таблицы согласований могут лежать в базе самой платформы или во внешней базе, среди внешних источников документация показывает PostgreSQL и MySQL. Если записи важны для учёта, храните их там, где уже настроены резервные копии.
| Поле | Кто заполняет | Зачем нужно |
|---|---|---|
| Клиент и номер предложения | Менеджер или скрипт | Связь записи с исходным документом |
| Предложенная скидка | Автоматизация по ответу модели | Предмет решения |
| Обоснование модели | Автоматизация | Подсказка согласующему |
| Потолок по политике | Скрипт | Граница, выше которой запись блокируется |
| Статус | Система | Ожидает, одобрено, отклонено, отправлено |
| Комментарий согласующего | Согласующий | Причина решения для истории |
Поля, заполненные автоматизацией, показывают только для чтения, а возможность такой настройки проверьте в своей версии платформы. Если интерфейс такой настройки лишён, защиту ставят на уровне данных и ролей. Правки согласующего допустимы, но каждая из них попадает в журнал изменений: решающий видит исходное предложение и свою версию рядом.
Обоснование модели сохраняют как текст, но решение принимают по цифрам из учётной системы: история заказов подтягивается скриптом отдельным полем. Расхождение между обоснованием и этими цифрами служит сигналом отклонить запись. Для отклонения комментарий обязателен: из накопленных причин потом складывается список поправок к инструкции модели.
Роли и права
В Budibase есть роли уровня организации, роли внутри приложения и пользовательские роли с наследованием прав. Шаблон Risk Management из документации показывает рабочую схему: рядовой пользователь создаёт записи и отменяет свои, а пользователь с расширенной ролью видит все записи и получает действия «Одобрить» и «Отклонить». Каждое действие строки (row action) меняет статус и отправляет письмо автору записи. Для согласования скидок берём ту же схему.
- Менеджер: создаёт записи, видит только свои, может отменить собственную запись до решения.
- Согласующий: видит все записи своего подразделения, одобряет и отклоняет, пишет комментарий.
- Администратор приложения: настраивает роли и источники данных. Согласует другой человек: автор правил и их исполнитель должны быть разными людьми.
Скрытая кнопка защитой считаться нельзя. Права на данные задаются ролями, а внешний сервис, который отправляет предложение клиенту, самостоятельно проверяет, что запись имеет статус «Одобрено» и что решение принял пользователь с нужной ролью. Сервер перепроверяет всё, что интерфейс показывает человеку. Дополнительно полезна одна норма: решение по записи принимает другой человек, а автору записи оно недоступно. Менеджеру согласовывать собственное предложение запрещено, даже если роль технически позволяет. Норму описывают в регламенте и проверяют в тесте ролей.
Какое действие ИИ в вашей компании должно требовать подтверждения руководителя?
Статус и аудит
Шаблон использует статусы «Ожидает», «Одобрено», «Отклонено» и «Отменено». К ним добавьте «Отправлено»: переход в него выполняет автоматизация и только из «Одобрено». Так видно, что решение принято, а действие уже совершено, и повторный запуск упирается в статус, поэтому предложение уходит клиенту один раз.
Встроенные журналы аудита Budibase, по документации, относятся к платной функции и доступны администраторам. Они фиксируют события пользователей, настроек, автоматизаций и данных, но аудит строк и запусков запросов по умолчанию отсутствует. Поэтому историю решений ведут отдельной таблицей. Способ такой: автоматизация срабатывает при обновлении строки, скрипт определяет изменённые поля, шаг создания строки записывает результат.
- Заведите таблицу аудита со связью с таблицей согласований.
- Добавьте автоматизацию с триггером обновления строки в таблице согласований.
- В скрипте сравните старые и новые значения и выберите изменившиеся поля.
- Для каждого изменения создайте строку: поле, прежнее значение, новое значение, тип действия, время.
- Проверьте, что решение «Одобрено» и «Отклонено» оставляет запись с именем согласующего.
Действия строки отправляют письмо автору записи, как в шаблоне: менеджер узнаёт о решении без захода в интерфейс. Текст письма содержит номер записи и итог, а цифры скидки и обоснование остаются внутри приложения. Таблицу аудита открывают на чтение узкому кругу: руководителю и контролёру. Менеджеры видят только свои записи в основном интерфейсе, и история чужих решений им ни к чему. Раз в неделю руководитель просматривает отклонённые записи: частые причины отказа показывают, какое правило пора поправить в инструкции для модели или в потолке политики.
Допуск в работу
Перед запуском интерфейс проверяют ролями. Зайдите под каждой ролью и убедитесь, что видны только положенные записи и кнопки. Попробуйте отправить предложение со статусом «Ожидает»: внешний сервис обязан отказать. Измените запись и найдите правку в таблице аудита. Отдельно проверьте нагрузку на согласующего: если записей накапливается больше, чем он успевает смотреть, потолок политики снижают, а часть типовых случаев переводят на выборочный контроль. Пилот проведите на узкой группе менеджеров, а решения собирайте в одном журнале, чтобы видеть, где согласующие чаще всего правят предложения модели.
Итог пилота читается по трём долям: сколько предложений согласовано без правок, сколько согласовано после правок и сколько отклонено. Заранее договоритесь, какая картина считается успешной, и зафиксируйте это до первого запуска. Если доля правок велика, дело в инструкции модели или в данных клиента, а работа согласующих здесь вторична. Приложение Budibase можно развернуть на собственном сервере или использовать облачную версию, поэтому место хранения определяют требования к данным клиентов. Если нужен проект под ключ, смотрите страницу про автоматизацию бизнес-процессов.
Если согласующий уходит в отпуск, запись простаивает, а продажи вместе с ней. Назначьте заместителя на каждую роль согласования до запуска и проверьте, что у заместителя те же права.