Как выбрать между API-интеграцией, RPA и AI-агентом

Как получить доступ к нужной операции

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

У API есть контракт — описание запроса и ответа. Узнайте, как поставщик сообщает об изменениях контракта и можно ли найти запись по внешнему номеру после обрыва связи. Это определяет, сможет ли программа самостоятельно продолжить работу.

Если подходящей операции в API нет, проверьте штатный импорт или экспорт. Для оставшихся экранных шагов рассмотрите RPA — роботизацию действий пользователя. В документации Microsoft по desktop flows описана работа с элементами окна, изображениями и координатами. На пилоте выясните, что произойдёт при истечении сеанса, смене названия кнопки или появлении дополнительного диалога. Назначьте ответственного за проверку после обновления программы.

Кому поручить выбор следующего шага

Запишите правило так, чтобы два сотрудника независимо получили одинаковый результат. Например, «если в CRM есть ровно один заказ с указанным номером и он ещё не отгружен, подготовить смену адреса». Для структурированной заявки такую проверку можно выполнить обычным кодом.

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

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

Три процесса и границы автоматизации

Учебный пример. Системы и права доступа в таблице вымышлены. Здесь нет работающего робота или отправки данных.

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

Как письмо превращается в проверяемый черновик

1. Клиент пишет «Для заказа 18 доставьте вторую партию на Садовую». Модель возвращает номер, указание на партию и исходную цитату. Номер дома остаётся пустым.
2. Правила проверяют принадлежность заказа клиенту, состояние отгрузки и полноту адреса. Для улицы без номера дома задача уходит менеджеру на уточнение. Текущий адрес сохраняется.
3. После уточнения система повторно проверяет заказ и через API создаёт черновик изменения. Менеджер видит рядом прежний адрес, новый адрес, партию и подтверждение клиента.
4. Только после подтверждения система передаёт изменение на склад. В журнал попадают идентификаторы письма, заказа и черновика, версия записи, решение менеджера и результат операции.

Что делать после тайм-аута или спорного результата

• Связь оборвалась после записи. Заказ мог сохраниться. Сначала найдите его по идентификатору операции. Если API поддерживает ключ идемпотентности, используйте один ключ для всех повторов этой записи. Когда исход нельзя установить, передайте задачу на сверку до следующей записи.
• Экран изменился или сеанс закрыт. Остановите робота до следующего нажатия. Сохраните номер задачи и последний подтверждённый шаг. Оператор восстановит сеанс и сверит состояние заказа перед продолжением.
• Два подходящих заказа или противоречивые инструкции. Покажите проверяющему оба варианта и выдержку из письма. Сохраните его выбор и причину. Для платежа, отгрузки или внешнего сообщения заранее определите, кто вправе подтвердить действие.

Как оценить пилот вместе с сопровождением

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

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

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

Частые вопросы