Мы дали ИИ-ассистенту все права в интернет-магазине. Именно так звучит заголовок, но техническая граница важна: речь не о root-доступе к серверу и не о свободном доступе к WordPress-админке. Для теста был создан отдельный WooCommerce REST API-ключ с правами Read/Write. Официальная документация WooCommerce по аутентификации REST API прямо предусматривает уровни Read, Write и Read/Write.
Нас интересовал не сам факт, что API отвечает. Вопрос был управленческий: что руководитель получает, если ИИ видит магазин, умеет анализировать его состояние и может выполнять разрешённые действия? И второй вопрос — не менее важный: где такой ассистент обязан остановиться и сказать, что данных недостаточно.
Что мы проверили на действующем магазине
Тест шёл на production-магазине WooCommerce. На момент acceptance в каталоге было 10 товаров. У всех были SKU и цены; диапазон цен — от 4 990 до 11 990 ₽, медиана — 9 990 ₽. Все 10 товаров были в статусе instock.
При этом история продаж была пустой: заказов — 0, клиентов — 0, купонов — 0, активных webhook — 0. Это принципиально: мы не стали превращать отсутствие истории в выдуманную «аналитику». Если заказов нет, ИИ не может честно показать динамику выручки, средний чек или повторные покупки как реальные бизнес-результаты.
Read-часть охватила товары, категории, атрибуты, цены, доступность, заказы, клиентов, купоны, возвраты, способы оплаты, доставку, налоги, отчёты, аналитику и системное состояние. Отдельно проверили административные WooCommerce REST-маршруты и системную диагностику.
Что получает руководитель, когда в магазине появляются реальные операции
Самая полезная модель — не «покажи dashboard», а вопросы по исключениям. Например: какие заказы зависли, что оплачено, но не дошло до нужного статуса, где есть отмены или возвраты, какие товары требуют внимания, где расходятся цена, доступность или статус публикации.
При наличии истории заказов тот же API позволяет собирать управленческую картину по статусам, датам и способам оплаты: количество заказов, выручку, средний чек, товарный микс, скидки, возвраты, налоги и доставку. Клиентские данные позволяют считать повторные покупки в агрегированном виде. ИИ здесь полезен не потому, что складывает числа быстрее SQL, а потому что может связать несколько сигналов, предложить следующую проверку и объяснить, почему именно эта ситуация требует решения.
Если ИИ-ассистент руководителя подключён ещё и к CRM, 1С или складской системе, вопрос становится сильнее: «заказ на сайте оплачен — он появился в учёте, зарезервирован ли товар, назначена ли задача менеджеру и совпадает ли конечный статус?» Но это уже межсистемный контур; текущий тест доказывает именно возможности WooCommerce как источника и точки управляемого write-back.
Что произошло, когда мы разрешили запись
Read/Write проверяли только на специально созданных временных объектах. Реальные заказы и реальные клиенты не изменялись.
- Временный товар:
CREATE → READ → UPDATE → READ → DELETE → GET 404. - Временный купон: тот же полный CRUD-цикл и подтверждение удаления.
- Синтетический клиент с адресом в домене
.invalid: создание, чтение, изменение, удаление и контроль 404. - Временный заказ: только неоплаченный/pending сценарий без реальной платёжной операции; после проверки заказ удалён.
- Возврат: проверен как ручной API-return без обращения к платёжному шлюзу.
- Webhook: создан только в приостановленном состоянии с адресом
example.invalid, затем удалён.
После каждой записи выполнялся независимый read-back. В конце мы сравнили состояние до и после теста: 10 товаров, 0 заказов, 0 клиентов, 0 купонов и 0 webhook — те же значения, что были до acceptance. Дополнительный поиск тестовых маркеров в базе дал 0 совпадений.
Для руководителя это важнее, чем сам статус 200 или 201. Правильный рабочий контракт выглядит так: факт → решение → разрешённое действие → запись → независимая проверка результата. Ответ API «операция принята» сам по себе не считается выполненной бизнес-задачей.
Какие боли это снимает
Первый класс боли — ручная проверка магазина. Руководителю не нужно по очереди открывать каталог, заказы, платежи и отчёты, чтобы понять, где исключение. Ассистент может собрать очередь ситуаций, которые требуют внимания, и объяснить причину.
Второй — потерянные действия. Если после анализа нужно создать или изменить допустимый объект, write-back позволяет выполнить это из того же управленческого диалога. Для production-действий остаются обязательными права, журналирование, идемпотентность и подтверждение там, где действие влияет на деньги, клиента или необратимое состояние.
Третий — ложное чувство контроля. Обычный отчёт легко показать как «всё зелёное», даже когда нужных данных вообще нет. В этом тесте как раз обнаружились границы, которые нельзя замазывать красивым интерфейсом.
Где ИИ обязан остановиться
В магазине включено глобальное управление запасами, но ни один из 10 товаров не ведёт количественный остаток через manage_stock=true. Поэтому статус «в наличии» читать можно, а честно ответить «осталось 3 штуки» — нельзя. Для точного stockout-контроля нужен количественный склад в WooCommerce либо связка с 1С/МойСклад.
В WooCommerce также нет авторитетной себестоимости этих товаров. Значит, из WooCommerce в одиночку нельзя честно посчитать маржу. Для этого нужен источник COGS/закупочной стоимости из учётной системы.
И ещё одна граница: «брошенная корзина» не является гарантированным стандартным ресурсом wc/v3. Для такого сценария понадобится отдельная аналитика, событие или расширение. Хороший ассистент должен сообщить эту границу, а не изображать доступ к данным, которых у него нет.
Когда ИИ здесь вообще не нужен
Если руководителю нужны пять фиксированных показателей раз в неделю и никаких действий из отчёта выполнять не требуется, обычный SQL/BI-отчёт или заранее настроенная сводка будут проще и дешевле. ИИ начинает давать дополнительную ценность там, где нужно разбирать исключения, сопоставлять несколько источников, задавать уточняющие вопросы и после решения безопасно доводить разрешённое действие до проверенного результата.
Итог теста
WooCommerce прошёл техническую acceptance как реализация коннектора собственного интернет-магазина: чтение управленчески значимых данных подтверждено, безопасный write-back на временных объектах подтверждён, cleanup подтверждён. Это не означает автоматическую сертификацию любого интернет-магазина — другая платформа должна пройти свой platform-specific acceptance.
Практический вывод для руководителя простой. Он покупает не «чат с доступом к WooCommerce» и не ещё одну панель. Он получает сокращение пути от изменения в магазине до решения: увидеть ситуацию → понять причину → согласовать действие → выполнить → проверить конечное состояние.
Если нужно связать такой контур с вашим сайтом, на странице интеграции ИИ-ассистента с интернет-магазином описано, какие данные и действия можно подключить. А если задача начинается с самого owned-канала продаж, коммерческий раздел разработки собственного интернет-магазина остаётся отдельной точкой входа.