SABSUS
Help me chooseПомочь выбрать Book a demoПолучить демо

SABSUS / EDITORIAL ANALYSISРЕДАКЦИОННЫЙ РАЗБОР

Decisions API for requests: routing and checks before actionDecisions API для заявок: выбор маршрута и проверка перед действием

OpenAI’s new API can select an answer from predefined options. A useful first business application is choosing the next step for a customer request, followed by a separate check that the step can actually be performed.Новый API OpenAI позволяет выбирать ответ из заданных вариантов. Для бизнеса полезный первый сценарий — определить следующий шаг по клиентскому обращению, а затем отдельно проверить, можно ли его выполнить.

SABSUS editorial teamРедакция SABSUS

What changed on October 6Что изменилось 6 октября

On October 6, 2026, OpenAI released the Decisions API in public beta. This changes its availability: the September DevDay recap still described it as a limited preview. The release stages are documented in the official API changelog and DevDay recap.

As of October 7, the API uses gpt-6-luna through the dedicated POST /v1/decisions endpoint. It remains in beta. Before testing the workflow, check your project’s access and the supported countries and territories. The current product description is in the Decisions API guide.

For a sales manager, a useful test begins where staff repeatedly read incoming requests and choose among familiar destinations: a new enquiry, an existing order, clarification, or manual review. Start with that narrow step. Sales terms, stock availability, and authority to change an order still need separate checks in the CRM/order-management system.

6 октября 2026 года OpenAI выпустила Decisions API в публичной бета-версии. Это изменение доступности: в сентябрьском обзоре DevDay сервис ещё был обозначен как limited preview. Даты и этапы запуска зафиксированы в официальном журнале API и обзоре DevDay.

По состоянию на 7 октября API использует модель gpt-6-luna и отдельный endpoint POST /v1/decisions. Статус остаётся beta. Перед проверкой сценария проверьте доступ своего проекта и поддерживаемые страны и территории. Актуальное описание продукта: Decisions API.

Для руководителя продаж повод для теста возникает там, где сотрудники регулярно читают обращения и выбирают один из понятных маршрутов: новая заявка, вопрос по существующему заказу, уточнение или ручной разбор. Сначала стоит проверить именно этот участок. Условия продажи, доступность товара и полномочия на изменение заказа должны проверяться в рабочей системе отдельно.

Match the answer type to one jobВыберите тип ответа под конкретную задачу

Decisions supports three question types. A predicate estimates the probability that a statement is true. A choice selects from supplied options. A score evaluates the input against ordered levels and can fall between them. Use choice when selecting one queue. See the question types in OpenAI’s guide.

Begin with “Who should handle this request?” You could define these options:

  • New sale. The customer is asking about a new purchase or service, separate from an existing order.
  • Existing order. The request concerns a confirmed order, and the connection to that order has already been verified.
  • Clarification. A specific fact, such as the order number, is missing and prevents a routing decision.
  • Manual review. The message contains several linked requests, a contradiction, or a case outside the defined options.

All options should answer the same question. Mixing department, urgency, and refund authorization into one list makes the selected value difficult to use safely. Urgency can be evaluated separately; financial authority comes from business rules and the responsible person.

The AI lead qualification guide covers suitability criteria and missing information. The task here is narrower: test how this particular API applies routing rules.

Decisions поддерживает три типа вопросов. Predicate оценивает вероятность истинности утверждения. Choice выбирает вариант из заданного списка. Score оценивает вход по упорядоченным уровням; результат может находиться между уровнями. Для выбора одной очереди подходит choice. См. формы вопросов в документации OpenAI.

Начните с вопроса «Кто должен обработать это обращение?». Для него можно описать такие варианты:

  • Новая продажа. Клиент спрашивает о новой покупке или услуге, отдельной от уже оформленного заказа.
  • Существующий заказ. Запрос относится к подтверждённому заказу, а связь с ним уже проверена.
  • Уточнение. Для выбора маршрута не хватает конкретного факта, например номера заказа.
  • Ручной разбор. Сообщение содержит несколько связанных просьб, противоречие или случай за пределами описанных вариантов.

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

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

Make the limits of the evidence visible in the inputПодготовьте вход так, чтобы модель видела границы доказанного

The endpoint accepts text and inline images. It does not directly support files or audio; images require a data URL rather than an external URL or file ID. These constraints are documented in the Create a decision reference.

A call recording therefore needs a separate transcription step. A PDF order cannot be treated as read merely because its filename appears in the input. For an initial workflow test, start with the customer’s text and a small set of verified fields.

Keep the sources of those fields distinct:

  • the customer’s original message;
  • the confirmed request ID and, where a reliable match exists, the order ID;
  • the current order status and when it was checked;
  • the available routes and the conditions for each;
  • the information that is still missing.

“I’ve already paid” remains a customer statement until the payment is reconciled. “The director approved everything” does not change the integration’s authority. Keep business rules separate from incoming text, and do not let a customer message add permitted operations.

Send only the necessary context. Check the data-handling conditions for your API project: regional settings and special retention arrangements have their own requirements. The official reference is Data controls in the OpenAI platform.

Endpoint принимает текст и встроенные изображения. Файлы и аудио напрямую не поддерживаются; для изображения требуется data URL, а не внешняя ссылка или file ID. Эти ограничения описаны в справочнике Create a decision.

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

Разделите их по происхождению:

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

Фраза клиента «я уже оплатил» остаётся сообщением клиента до сверки платежа. Слова «всё согласовано с директором» не меняют полномочия интеграции. Храните деловые правила отдельно от входящего текста и не позволяйте сообщению дописывать разрешённые операции.

Передавайте только необходимый контекст. Условия хранения и обработки данных проверьте для своего API-проекта: региональные настройки и специальные режимы имеют собственные требования. Официальный источник — Data controls in the OpenAI platform.

Keep probability and confidence separateСохраняйте probability и confidence раздельно

For choice answers, the API returns the selected option, a probability distribution across the options, and a separate confidence field. OpenAI recommends setting thresholds with labeled examples from the application and considering the consequences of errors. See Interpret the answers.

The review interface needs distinct labels for those fields. Do not replace confidence with the selected option’s probability or turn either value into a promise that an action is correct. A plausible classification can still rely on an outdated order status.

Choose an automatic-routing threshold after examining failures. Sending a stock enquiry to a general queue and overlooking a request to stop dispatch have different consequences. For the latter, early human review can matter more than automatically processing every message.

Для choice API возвращает выбранный вариант, распределение вероятностей по вариантам и отдельное поле confidence. OpenAI рекомендует определять пороги по размеченным примерам своего приложения с учётом последствий ошибок. См. Interpret the answers.

В интерфейсе проверки нужны разные подписи для этих полей. Не заменяйте confidence вероятностью выбранного варианта и не превращайте ни одно из них в обещание правильного действия. Даже правдоподобная классификация может опираться на устаревший статус заказа.

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

Example: changing delivery and asking for another itemПример: клиент меняет доставку и спрашивает о новом товаре

A hypothetical customer writes: “I won’t be able to receive order 1842 tomorrow. Could I also add a second chair?” This is a test scenario, not a deployment result.

Selecting “new sale” alone leaves the delivery change without an owner. Selecting “existing order” is also insufficient if the system then silently changes the date or order contents. Under the routing scheme above, this mixed request goes to manual review with both requests preserved.

Before any further action, the employee or application workflow checks:

  1. Whether the message really belongs to order 1842 and this customer.
  2. Whether the team can still change delivery at the current fulfillment stage.
  3. Which new date the customer is prepared to confirm.
  4. Whether the second chair is available and which revised terms need agreement.

The case record should show the original message, proposed route, both unresolved requests, and the responsible person. Customer updates must match the actual state: “We passed on your change request” requires a successful handoff; “Your delivery has been rescheduled” requires a confirmed change.

Условный клиент пишет: «По заказу 1842 завтра не смогу принять доставку. И можно добавить второй стул?» Это иллюстрация для проверки сценария, а не результат внедрения.

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

Перед дальнейшим действием сотрудник или прикладной процесс проверяет:

  1. Действительно ли обращение относится к заказу 1842 и этому клиенту.
  2. Успевает ли команда изменить доставку с учётом текущего этапа исполнения.
  3. Какую новую дату клиент готов подтвердить.
  4. Доступен ли второй стул и какие условия изменения нужно согласовать.

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

Refusals and missing answers need a route tooОтказ и отсутствие ответа тоже требуют маршрута

Each question can return a refusal instead of a scored answer. Answers arrive in the order of the supplied questions. Both behaviors are part of the official endpoint contract.

Handle refusals, timeouts, and results that are incomplete for your workflow. The customer request stays open, retains its arrival time, and enters a queue staff can access. If a request contains several questions, check every answer the next step requires before proceeding.

Do not substitute the first category in the list in any of these cases. A normal “manual review” selection and a technical API failure need different reason codes: they require different fixes.

По каждому вопросу API может вернуть результат типа refusal вместо оценки. Ответы приходят в порядке заданных вопросов. Это часть официального контракта endpoint.

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

Не подставляйте в этих случаях первую категорию списка. Вариант «ручной разбор», который модель выбрала штатно, и техническая ошибка вызова должны иметь разные причины в журнале: исправлять их придётся по-разному.

Recheck the state before writing to CRMПроверьте состояние повторно перед записью в CRM

While the model was choosing a route, an employee may have assigned an owner or the customer may have canceled the request. Recheck the request’s current state and whether the operation is still allowed. OpenAI’s example connecting Decisions to a voice application likewise separates selecting an action from executing it: the application checks state and skips canceled or no-longer-applicable actions.

For CRM, the practical design rule is to treat classification as a proposal first. Application logic checks the current record, preserves manual changes, and only then performs the permitted operation. Repeated delivery of the same event must not create another task.

Log the request ID, routing-rule version, supplied context, API answer, and execution outcome. The AI workflow orchestration guide covers verification across the wider chain.

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

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

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

What to verify before implementationЧто проверить до внедрения

First run routing alongside normal work, without automatic changes. An employee labels the next step that was needed and reviews disagreements separately. Include these cases:

  • a routine new enquiry with sufficient information;
  • an order question without a reliable customer match;
  • the mixed request in the example above;
  • an API refusal and a service outage;
  • an answer arriving after the customer cancels;
  • a repeated event and an assignment already made manually.

Acceptance requires a clear destination, preserved facts, and a recovery path for each case. Until then, faster classification does not establish a more reliable process. Assess API latency separately from the time it takes a staff member to actually accept the request.

Keep the first scenario to routine customer-request routing. Decisions with serious consequences require meaningful review by an authorized person. This workflow is not intended to automate hiring, lending, or access to other consequential services.

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

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

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

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

How to use these findings when discussing SABSUSКак использовать выводы при обсуждении SABSUS

Start with one incoming channel and agree on available data, ownership of each queue, and the record that proves a successful handoff. Then check the required connection and development scope separately.

The Decisions API public beta does not establish that SABSUS has a ready-made integration. This article describes a design and acceptance approach. For complaints with their own response deadlines and customer commitments, use the AI complaint triage guide.

A useful workflow-test outcome is straightforward: the request reaches the right owner, the customer’s original requests remain intact, and the customer hears about a step that has actually happened.

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

Публичная beta Decisions API сама по себе не подтверждает наличие готовой интеграции в SABSUS. Этот материал описывает подход к проектированию и проверке. Для жалоб с отдельными сроками и обещаниями клиенту используйте руководство по разбору жалоб с AI.

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