Согласование в мессенджере: как связать решение сотрудника с автоматизацией

Решение в переписке ещё не означает, что процесс завершён правильно. Руководитель мог ответить на устаревшую заявку, кнопку мог нажать другой сотрудник, а целевая система — не принять изменение. Поэтому маршрут нужно строить вокруг проверяемой связи: заявка → решение → действие → подтверждённый результат.

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

Когда согласование в мессенджере решает рабочую задачу

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

• разрешить или отклонить скидку;
• согласовать расход;
• подтвердить изменение срока;
• выдать доступ;
• разрешить исключение из стандартного правила.

Польза появляется не от переноса переписки в кнопки, а от связи ответа с конкретной заявкой. Система должна понимать, кто ответил, на какую версию данных распространяется решение и удалось ли выполнить разрешённое действие.

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

Из чего состоит маршрут согласования

У маршрута есть отдельные состояния:

1. Заявка подготовлена.
2. Карточка отправлена назначенному согласующему.
3. Система ожидает ответ.
4. Получено согласие или отказ либо срок ответа истёк.
5. Перед исполнением система повторно проверяет заявку.
6. Действие выполняется и подтверждается целевой системой либо передаётся на разбор.

Важно не смешивать три результата:

Документация n8n описывает механизм Wait: workflow можно приостановить, а затем продолжить с теми же данными после заданного ожидания или внешнего события. Это функция платформы n8n, а не готовый маршрут согласования. Состояния, права, последствия ответа и обработку ошибок нужно проектировать для конкретного процесса.

Что показать сотруднику в карточке

Карточка должна содержать сведения, без которых сотрудник не сможет понять предмет и последствия решения:

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

В документированном действии Start and wait for an approval в Power Automate предусмотрены поля Title, Assigned to и Details. Это подтверждает возможность задать заголовок, адресата и описание запроса именно в данном действии Power Automate. Состав карточки и доступные каналы в другой платформе нужно проверять отдельно.

Как определить, кто вправе ответить

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

До разработки составьте карту ролей:

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

В операции Send and Wait for Response узла Slack в n8n можно включить фиксацию ответившего и задать список пользователей, которым разрешено согласование. Если нажимает пользователь вне списка, workflow продолжает ждать. Документация также указывает, что n8n проверяет callback с помощью механизма подписи запросов Slack при корректно заданном signing secret.

Это свойства конкретной связки Slack и n8n и её настроек. Для работы нужны, среди прочего, доступный по HTTPS экземпляр n8n, настроенная интерактивность Slack, подходящие права и корректный секрет подписи. Эти возможности нельзя автоматически переносить на любой мессенджер или тариф.

Как связать ответ с заявкой и её версией

Для будущего решения полезно заранее определить контракт записи. Он может включать:

Это проектируемая структура, а не универсальный набор полей всех платформ.

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

Комментарий в переписке не следует трактовать как формальное решение. Лучше хранить выбранное действие отдельно от пояснения: «Согласовать» или «Отказать» определяет ветку, а комментарий сохраняет контекст.

Как продолжить процесс после согласия, отказа или отсутствия ответа

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

После отказа процесс сохраняет решение и причину, уведомляет автора, а затем завершает заявку или возвращает её на исправление — по заранее согласованному правилу.

Если срок истёк, корректный результат — «ответ не получен», а не автоматическое согласие или отказ. Дальнейший маршрут выбирают при проектировании: напоминание, замещение согласующего, возврат инициатору или ручной разбор. Универсального правильного срока нет.

Документация операции согласования Slack в n8n указывает, что первое решение остаётся в силе, а поздние клики его не меняют. Это поведение конкретной функции. Собственная логика всё равно должна проверять повторные события до бизнес-действия: повторно доставленный callback не должен второй раз изменить заявку.

Условный пример: согласование скидки в мессенджере

Ниже — синтетический учебный пример, а не клиентский проект Switch On AI и не результат живого теста CRM или мессенджера.

Менеджер создаёт заявку DISC-1042, версия 3. В ней указаны клиент, текущая сумма и условия, запрошенная скидка, автор и срок ответа. Система назначает руководителя и формирует карточку с действиями «Согласовать» и «Отказать».

Основная ветка выглядит так:

1. Менеджер создаёт заявку версии 3.
2. Руководитель получает карточку и выбирает решение.
3. Система сохраняет ответившего, время и решение.
4. Перед записью скидки система снова читает сделку.
5. Если значимые данные совпадают, система отправляет одну команду на изменение.
6. Процесс завершается только после подтверждения целевой системы.

Альтернативные ветки нужно описать до разработки:

• Ответил сотрудник без полномочий. Ответ не переводит заявку в состояние «согласовано», ожидание продолжается или событие передаётся на разбор.
• Условия сделки изменились. Старое решение не исполняется; система создаёт новую карточку с актуальной версией.
• Руководитель нажал кнопку повторно. Повторное событие не запускает вторую запись скидки.
• Ответ пришёл после истечения срока. Система сохраняет событие для разбора, но не исполняет просроченное решение автоматически.
• CRM временно не подтвердила запись. Процесс не сообщает об успехе; операция остаётся в состоянии ошибки или ожидает безопасного ручного продолжения по правилам проекта.

Такой пример показывает будущий контракт и ожидаемые ветки. Он не доказывает совместимость с конкретной CRM: доступные операции, права, ответы API и способ защиты от повторов проверяют при выборе систем и разработке.

Проверка перед рабочим запуском и ограничения

Приёмку следует строить вокруг смысловых сценариев, а не внешнего вида кнопок. Для каждого сценария заранее запишите входные данные, ожидаемое состояние заявки, допустимое действие и признак результата.

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

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

Switch On AI разрабатывает и внедряет автоматизацию таких операций. На странице услуг Switch On AI можно сравнить автоматизацию с ИИ-агентом и чат-ботом: для фиксированного маршрута согласования обычно важнее интеграция систем и участие сотрудника, а не автономное решение модели.

Для предметного разговора подготовьте описание одного согласования: источник заявки, значимые поля, список согласующих, используемый мессенджер и действие после ответа. Switch On AI разберёт маршрут на созвоне, затем подготовит ТЗ и коммерческое предложение. Ключевой фрагмент можно показать в бесплатном прототипе; прототип не равен полноценному внедрению и не подтверждает работу всех подключений.