Вопрос звучал как доработка бота
Оператор получал сведения о клиенте через бота и передавал сложные действия специалистам. Бизнес хотел расширить бот: добавить больше данных и команд. Это было понятное пожелание, но не описание всей работы сотрудника.
В одном обращении могли понадобиться тариф, платежи, связанные боты, история диалога и условия временного изменения. Вывести всё подряд в чат — значит заставить оператора искать нужное в длинной последовательности сообщений. Скрыть детали — оставить прежнюю зависимость от специалистов.
Сначала изменили форму работы
Я выбрал веб-приложение с карточкой клиента. Главное состояние видно сразу; подробности открываются по необходимости. Оператор может перейти от обращения к платежу, боту или истории, не теряя контекст задачи.
Важнее экрана оказались правила. Раньше специалист держал в голове, можно ли выдать пробный период, как рассчитать обещанный платёж и когда вернуть временный тариф. Платформа проверяет эти условия до действия и сохраняет незавершённые обязательства после него.
Старый API остался, риск уменьшился
Основная система по-прежнему исполняет текстовые команды. Переписать её для нового интерфейса не требовалось. Между оператором и прежним API появился слой: он проверяет роль и состояние клиента, рассчитывает параметры, формирует команду и записывает результат.
Так ограничение старого протокола не стало ограничением нового рабочего процесса. Сотрудник выбирает действие и видит причину запрета, если действие недоступно. Синтаксис команды остаётся внутри адаптера.
Результат проверяется работой людей
После внедрения операции, которые раньше ожидали второй линии 2–3 дня, оператор выполнял примерно за 2 минуты. Платформой пользовались сотрудники компании; отдельного курса обучения не потребовалось.
Этот случай напоминает мне: запрос на новые функции существующего инструмента иногда скрывает запрос на другую форму работы. Правильный экран появляется после того, как понятны действия человека, границы его полномочий и судьба операции после нажатия кнопки.