Who owns the AI order?Кто отвечает за AI-заказ

Separate the news from the mechanismОтделите новость от механики

This July 2 analysis originally drew on Axios’s June 26 reporting about brands adapting to AI commerce. That remains secondary-news context. A primary historical example is Stripe’s September 29, 2025 account of the Agentic Commerce Protocol, which describes agent-assisted checkout with the business retaining merchant-of-record responsibility.Этот разбор от 2 июля первоначально опирался на материал Axios от 26 июня об адаптации брендов к AI-торговле. Это контекст вторичной новости. Первичный исторический пример — публикация Stripe об Agentic Commerce Protocol от 29 сентября 2025 года, где оформление с помощью агента сохраняет за бизнесом роль продавца, ответственного за транзакцию.

Current ACP concepts help explain the protocol model, but protocol availability does not prove approval for every consumer AI channel. A technical standard, a channel agreement and an implemented store connection are different things. None of these sources establishes native ACP or UCP integration in SABSUS.Текущие концепции ACP объясняют модель протокола, однако доступность стандарта не подтверждает допуск в каждый потребительский AI-канал. Технический стандарт, договор с каналом и работающая связь магазина — разные вещи. Эти источники не подтверждают нативную интеграцию ACP или UCP в SABSUS.

Supporting sources: Источники к разделу: Developing an open standard for agentic commerce · ACP key concepts · Axios: Brands told to act fast on AI commerce

Compare three purchase routesСравните три пути покупки

With an ordinary referral, the assistant links to the merchant and checkout happens on the merchant’s site. With embedded checkout, the shopper may stay in another interface while the merchant receives the order. With delegated purchasing, a representative also needs a defined scope of authority for the specific purchase.При обычном переходе помощник даёт ссылку, а оформление происходит на сайте продавца. При встроенном оформлении покупатель может оставаться в чужом интерфейсе, пока продавец получает заказ. При делегированной покупке представитель дополнительно нуждается в определённом объёме полномочий на конкретную покупку.

For each proposed route, ask who presents the final terms, receives payment, issues the order reference and handles changes. Record what the customer sees when a payment or order response is uncertain. The interface’s branding does not settle those responsibilities, and a familiar assistant name is not a substitute for the channel contract.Для каждого варианта выясните, кто показывает итоговые условия, принимает оплату, выдаёт номер заказа и обрабатывает изменения. Запишите, что видит клиент при неопределённом ответе оплаты или заказа. Бренд интерфейса не определяет эти обязанности, а известное имя помощника не заменяет договор с каналом.

Inspect usable data, field by fieldПроверьте доступные данные

Request a permitted sample showing order ID, items, customer or guest reference, contact route, source channel, payment link and known communication choices. Mark unavailable fields explicitly. Access to a fulfillment address does not establish permission to use it for another purpose, and a branded app does not guarantee exclusive control of every data copy.Запросите разрешённый пример с номером заказа, позициями, ссылкой на клиента или гостя, способом связи, каналом, оплатой и известными настройками сообщений. Недоступные поля отмечайте явно. Адрес для доставки не подтверждает право другого использования, а брендированное приложение не гарантирует исключительный контроль всех копий данных.

The data owner and service lead should distinguish technical access, permitted use, correction and export. Ask how a changed contact preference reaches already prepared messages. Keep source identifiers during imports; missing contact history remains unknown. Do not merge two people merely to make an AI-origin order look like a complete CRM profile.Ответственный за данные и руководитель сервиса разделяют технический доступ, допустимое использование, исправление и экспорт. Уточните, как новая настройка связи влияет на подготовленные сообщения. При импорте сохраняйте идентификаторы источника; отсутствующая история остаётся неизвестной. Не объединяйте людей ради полной на вид карточки заказа.

Test the return after the saleПроверьте работу после продажи

Illustrative case: a guest buys through an assistant, receives a partial delivery and asks the merchant to return one item. Can staff locate the accepted terms, original payment and missing item without access to the assistant’s private conversation? Name the support owner and the verified route for reaching the customer.Условный случай: гость покупает через помощника, получает часть заказа и просит продавца оформить возврат одной позиции. Найдут ли сотрудники принятые условия, исходную оплату и недостающий товар без доступа к приватному диалогу с помощником? Назначьте владельца обращения и проверенный способ связи.

Preserve separate states for return requested, goods received and refund confirmed. If the external channel becomes unavailable, the merchant still needs a practical continuation path for open obligations. Test a usable export with those relationships, not only a contact list, and agree how the customer receives updates during an exit.Сохраняйте отдельные состояния запроса возврата, приёма товара и подтверждения возврата денег. При недоступности внешнего канала продавцу нужен рабочий путь для открытых обязательств. Проверьте пригодный экспорт этих связей, а не только контактов, и согласуйте информирование клиента при выходе из канала.

Choose with service and economicsОцените сервис и расходы

Compare contribution after channel, payment and service costs, alongside the share of orders your staff can service from available records. Keep attribution of first discovery separate from repeat ordering. Moving a returning customer between interfaces is not automatically new demand, and data portability alone does not establish profitable acquisition.Сравнивайте вклад после расходов канала, оплаты и сервиса вместе с долей заказов, которые сотрудники могут обслужить по доступным записям. Источник первого знакомства отделяйте от повторных покупок. Переход постоянного клиента между интерфейсами не становится новым спросом, а переносимость данных не доказывает выгодное привлечение.

Use SABSUS White Label to discuss a branded operating path and verify the actual export, order, support and connection scope. Keep product configuration and external-channel approval as separate requirements. Accept the channel only when one normal order and one post-purchase exception can be reconstructed with clear responsibility and usable records.Обсуждая SABSUS White Label, проверьте брендированный путь и конкретный состав экспорта, заказов, поддержки и подключений. Настройка продукта и разрешение внешнего канала — отдельные требования. Принимайте канал, когда обычный заказ и исключение после покупки можно восстановить по пригодным записям с ясной ответственностью.

Supporting sources: Источники к разделу: SABSUS accepted integration boundaries

Sources and scopeИсточники и границы

Sources checked on October 6, 2026 (UTC). Dated announcements establish the vendor’s stated scope at that time. Current documentation may describe later changes. Workflow examples and acceptance tests are editorial recommendations; availability in your account and any SABSUS connection need separate verification.Источники проверены 6 октября 2026 года (UTC). Датированные анонсы подтверждают заявленный поставщиком состав на тот момент. Текущая документация может описывать более поздние изменения. Примеры и проверки — редакционные рекомендации; доступность в вашем аккаунте и связи SABSUS проверяются отдельно.

• Developing an open standard for agentic commerce
• ACP key concepts
• SABSUS accepted integration boundaries
• Axios: Brands told to act fast on AI commerce

SABSUS product scopeСостав продукта SABSUS · SABSUS integration boundariesГраницы интеграций SABSUS