Как сделать ИИ-агента для интернет-магазина

Что получится в результате

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

В результате будет рабочий прототип:

1. каталог товаров хранится в `product_catalog`;
2. остатки и доступность обновляются в `inventory_snapshot`;
3. правила цен и скидок лежат в `price_rules`;
4. заказы читаются в `order_queue`;
5. статусы заказов пишутся в `order_status_log`;
6. обращения покупателей создаются в `support_cases`;
7. рекомендации товаров пишутся в `recommendation_queue`;
8. возвраты идут в `return_requests`;
9. финансовые действия идут в `refund_requests`;
10. любые рискованные действия проходят через `approval_queue`;
11. ответы покупателям создаются как draft в `message_drafts`;
12. все действия фиксируются в `audit_log`.

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

Что понадобится

Минимальный набор:

1. Google Sheets как база прототипа.
2. n8n для workflow.
3. LLM API для понимания запросов и подготовки ответов.
4. CMS интернет-магазина: Shopify, WooCommerce, OpenCart, 1С-Битрикс, самописная CMS или API.
5. Источник заказов: CMS, CRM, 1С, RetailCRM, МойСклад или CSV.
6. Платежный провайдер: Stripe, YooKassa, CloudPayments или банк.
7. Служба доставки: СДЭК, Boxberry, Почта России, DPD, Shiptor или ручной трекинг.
8. База знаний по доставке, оплате, возвратам и гарантиям.
9. Оператор поддержки, который утверждает спорные ответы.

Для первого запуска хватит Google Sheets, n8n, выгрузки 50 товаров, 20 тестовых заказов и одного канала общения: чат сайта, Telegram или email.

Шаг 1. Выберите один сценарий для MVP

Не начинайте с агента, который полностью ведет магазин.

Безопасные сценарии:

1. ответы по наличию и характеристикам товара;
2. подбор товара по потребности;
3. статус заказа;
4. создание обращения оператору;
5. подготовка заявки на возврат;
6. объяснение условий доставки и оплаты;
7. уведомление о задержке заказа;
8. поиск похожих товаров вместо отсутствующего.

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

Проверка: сценарий заканчивается статусом `reply_draft_ready` или `needs_operator`, а не “агент сам все решил”.

Шаг 2. Запретите опасные действия

Запретите агенту:

1. менять цену товара;
2. менять остатки;
3. отменять заказ;
4. создавать refund;
5. менять адрес доставки;
6. обещать точную доставку без данных службы доставки;
7. выдавать скидку без правила;
8. менять карточку товара на сайте;
9. отправлять клиенту юридически спорный ответ;
10. показывать чужие персональные данные;
11. удалять заказ или клиента;
12. скрывать ошибку оплаты или доставки.

Системное правило:

Ты помощник интернет-магазина.
Ты отвечаешь только по данным product_catalog, inventory_snapshot, order_queue, delivery_rules, return_policy и knowledge_base.
Ты не меняешь цены, остатки, заказы, оплаты, возвраты и адреса доставки.
Любое финансовое, юридическое или внешнее действие отправляй в approval_queue.
Если данных не хватает, создай support_case.

Проверка: просьба “сделай мне возврат прямо сейчас” создает `refund_requests.status = waiting_approval`.

Шаг 3. Создайте Google Sheet проекта

Создайте таблицу `ecommerce_agent_mvp`.

Добавьте листы:

ecommerce_settings
product_catalog
inventory_snapshot
price_rules
delivery_rules
return_policy
customer_profiles
order_queue
order_status_log
knowledge_base
support_cases
recommendation_queue
cart_recovery_queue
return_requests
refund_requests
message_drafts
approval_queue
crm_updates
performance_log
audit_log
error_log

Проверка: все листы созданы, первая строка занята заголовками, доступ на редактирование ограничен командой магазина.

Шаг 4. Заполните ecommerce_settings

Лист `ecommerce_settings` хранит ограничения.

Колонки:

key
value
description
updated_by
updated_at

Стартовые строки:

answer_min_confidence | 0.82 | минимальная уверенность ответа
recommendation_min_score | 0.70 | порог рекомендации товара
price_change_allowed | no | агент не меняет цены
stock_change_allowed | no | агент не меняет остатки
refund_requires_approval | yes | возврат денег только через approval
order_cancel_requires_approval | yes | отмена заказа только через approval
address_change_requires_approval | yes | смена адреса только через approval
send_customer_message_requires_approval | yes | внешние сообщения через approval
personal_data_masking | yes | маскировать персональные данные в логах

Проверка: workflow читает `refund_requires_approval = yes`, а не хранит правило только в prompt.

Шаг 5. Создайте product_catalog

Лист `product_catalog` хранит товары, которые агент может рекомендовать.

Колонки:

product_id
sku
title
category
brand
description
attributes_json
price
currency
url
image_url
status
updated_at

Статусы:

active
hidden
archived
out_of_sale

Пример:

prod_1001 | SKU-1001 | Робот-пылесос X10 | техника | CleanBot | влажная уборка, лидар, приложение | {"area":"80m2","battery":"120min"} | 24990 | RUB | /product/x10 | /img/x10.jpg | active | 2026-05-23

Проверка: агент не рекомендует товар со статусом `hidden` или `out_of_sale`.

Шаг 6. Создайте inventory_snapshot

Лист `inventory_snapshot` хранит остатки.

Колонки:

sku
warehouse_id
available_qty
reserved_qty
incoming_qty
available_for_sale
updated_at
source_system

Правила:

1. `available_for_sale = yes`, если товар можно продавать;
2. `available_qty = 0` не значит “никогда не будет”;
3. если данные старше допустимого времени, ставьте `needs_stock_check`;
4. не обещайте наличие, если нет свежего остатка.

Проверка: товар с `available_for_sale = no` не предлагается как доступный.

Шаг 7. Создайте price_rules

Лист `price_rules` нужен, чтобы агент не придумывал скидки.

Колонки:

rule_id
rule_name
condition
discount_type
discount_value
applies_to
valid_from
valid_to
requires_approval
status

Пример:

PR-001 | скидка на второй товар | category=accessories and cart_qty>=2 | percent | 10 | accessories | 2026-05-01 | 2026-06-01 | no | active
PR-002 | ручная скидка лояльности | customer_segment=vip | percent | 15 | all | 2026-05-01 | 2026-12-31 | yes | active

Проверка: агент предлагает только скидку, которая есть в `price_rules`.

Шаг 8. Создайте delivery_rules

Лист `delivery_rules` хранит условия доставки.

Колонки:

rule_id
region
delivery_method
min_days
max_days
price
free_from_amount
carrier
tracking_available
status

Пример:

DEL-001 | Москва | courier | 1 | 2 | 350 | 5000 | own_courier | yes | active
DEL-002 | Россия | pickup_point | 3 | 7 | 450 | 7000 | CDEK | yes | active

Проверка: агент говорит диапазон доставки, а не обещает точное время без tracking API.

Шаг 9. Создайте return_policy

Лист `return_policy` описывает возвраты.

Колонки:

policy_id
product_category
return_days
condition_required
documents_required
non_returnable
requires_operator
status

Пример:

RET-001 | техника | 14 | товарный вид, комплектация | чек, номер заказа | no | yes | active
RET-002 | цифровой товар | 0 | не применяется | номер заказа | yes | yes | active

Проверка: агент не обещает возврат, а пишет условия и создает заявку на проверку.

Шаг 10. Создайте customer_profiles

Лист `customer_profiles` нужен для контекста, но не для лишнего раскрытия данных.

Колонки:

customer_id
email_hash
phone_hash
name_masked
segment
orders_count
last_order_at
loyalty_level
communication_allowed
status

Правила:

1. храните hash или masked данные;
2. не пишите полные телефоны и email в `audit_log`;
3. используйте `communication_allowed`;
4. не показывайте данные одного клиента другому.

Проверка: в логах нет полного телефона или email.

Шаг 11. Создайте order_queue

Лист `order_queue` хранит заказы.

Колонки:

order_id
external_order_id
customer_id
created_at
status
payment_status
delivery_status
delivery_method
tracking_number
items_json
total_amount
currency
customer_comment
source_system
updated_at

Статусы заказа:

new
paid
processing
packed
shipped
delivered
cancel_requested
cancelled
return_requested
completed
problem

Проверка: агент отвечает по заказу только если клиент подтвердил email, телефон или номер заказа.

Шаг 12. Создайте order_status_log

Лист `order_status_log` хранит историю.

Колонки:

event_id
order_id
created_at
old_status
new_status
payment_status
delivery_status
tracking_number
source_system
comment

Проверка: если клиент спрашивает “где заказ”, агент видит последнюю запись, а не только старый статус.

Шаг 13. Создайте knowledge_base

Лист `knowledge_base` хранит короткие правила магазина.

Колонки:

kb_id
topic
question
answer
applies_to
updated_at
owner
status

Темы:

payment
delivery
return
warranty
product_care
loyalty
contacts

Проверка: если вопрос про гарантию не найден, агент создает `support_case`, а не выдумывает срок.

Шаг 14. Настройте импорт каталога

Создайте workflow `ecommerce_catalog_sync`.

Узлы:

1. `Schedule Trigger`;
2. `Shopify Admin API` или `WooCommerce REST API`;
3. `Normalize products`;
4. `Google Sheets Upsert product_catalog`;
5. `Google Sheets Upsert inventory_snapshot`;
6. `Audit append catalog_sync`.

Правила:

1. не импортировать скрытые товары как активные;
2. не затирать ручные комментарии редактора;
3. сохранять `updated_at`;
4. логировать количество товаров и ошибок.

Проверка: после sync в `product_catalog` есть товары, а в `inventory_snapshot` - остатки по SKU.

Шаг 15. Настройте импорт заказов

Создайте workflow `ecommerce_order_sync`.

Узлы:

1. `Schedule Trigger` или webhook order update;
2. `Read orders`;
3. `Normalize order`;
4. `Upsert order_queue`;
5. `Append order_status_log`, если статус изменился;
6. `Audit append order_sync`.

Проверка: изменение статуса заказа в CMS появляется в `order_status_log`.

Шаг 16. Настройте входящий чат

Создайте workflow `ecommerce_customer_message`.

Узлы:

1. `Webhook` из чата сайта, Telegram или email;
2. `Detect intent`;
3. `Identify customer`;
4. `Route by intent`;
5. `LLM reply draft`;
6. `Create message_drafts`;
7. `Create support_case`, если нужен оператор.

Intent:

product_question
product_recommendation
order_status
delivery_question
return_question
refund_question
complaint
other

Проверка: вопрос “где мой заказ 12345” идет в ветку `order_status`.

Шаг 17. Настройте prompt определения intent

Prompt:

Определи тип обращения покупателя интернет-магазина.
Верни JSON без Markdown.
Не отвечай на вопрос, только классифицируй.

Схема:
{
  "intent": "product_question|product_recommendation|order_status|delivery_question|return_question|refund_question|complaint|other",
  "confidence": 0,
  "needs_order_lookup": true,
  "needs_product_lookup": true,
  "needs_operator": false,
  "reason": "short"
}

Проверка: вопрос про возврат денег получает `refund_question` и `needs_operator = true`.

Шаг 18. Создайте recommendation_queue

Лист `recommendation_queue` хранит предложенные товары.

Колонки:

recommendation_id
customer_message_id
customer_id
intent
filters_json
recommended_skus
excluded_skus
score_json
status
created_at

Правила:

1. рекомендовать только `active` товары;
2. проверять `available_for_sale`;
3. объяснять, почему товар подходит;
4. не скрывать важные ограничения;
5. не рекомендовать товар, если confidence ниже порога.

Проверка: если подходящий товар закончился, агент предлагает альтернативу или оператора.

Шаг 19. Настройте prompt рекомендации товара

Prompt:

Подбери товары из product_catalog по запросу покупателя.
Используй только товары со status=active и available_for_sale=yes.
Не придумывай характеристики.
Если подходящего товара нет, скажи, что нужна помощь оператора.

Верни JSON:
{
  "recommended_skus": [
    {
      "sku": "string",
      "reason": "почему подходит",
      "limitations": ["что важно учесть"],
      "score": 0
    }
  ],
  "needs_operator": false,
  "message_draft": "короткий ответ покупателю"
}

Проверка: рекомендации содержат SKU из каталога, а не выдуманные товары.

Шаг 20. Создайте support_cases

Лист `support_cases` хранит обращения оператору.

Колонки:

case_id
customer_id
order_id
intent
priority
status
assigned_to
summary
customer_message
agent_suggestion
created_at
updated_at

Статусы:

new
in_progress
waiting_customer
waiting_approval
resolved
closed

Priority:

low
normal
high
urgent

Проверка: жалоба, refund и спорный заказ создают `support_case`, а не автоматический ответ.

Шаг 21. Создайте message_drafts

Лист `message_drafts` хранит ответы покупателю.

Колонки:

draft_id
case_id
customer_id
order_id
channel
message_type
body
status
approved_by
approved_at
sent_at
created_at

Типы:

product_answer
order_status_answer
delivery_answer
return_instruction
operator_handoff
complaint_reply

Статусы:

draft
waiting_approval
approved
sent
rejected
needs_fix

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

Шаг 22. Настройте prompt ответа покупателю

Prompt:

Составь черновик ответа покупателю.
Используй только переданные данные: product_catalog, inventory_snapshot, order_queue, delivery_rules, return_policy, knowledge_base.
Не обещай точную доставку без tracking data.
Не обещай refund.
Не раскрывай персональные данные.
Если данных недостаточно, предложи передать оператору.
Пиши коротко и понятно.

Проверка: ответ про заказ содержит только статус, который есть в `order_queue` или `order_status_log`.

Шаг 23. Создайте return_requests

Лист `return_requests` хранит заявки на возврат товара.

Колонки:

return_id
order_id
customer_id
sku
reason
condition_declared
photos_required
policy_id
status
operator_decision
created_at
updated_at

Статусы:

draft
waiting_customer_info
waiting_operator
approved_by_operator
rejected_by_operator
closed

Проверка: агент создает заявку, но не принимает решение по возврату сам.

Шаг 24. Создайте refund_requests

Лист `refund_requests` хранит финансовые действия.

Колонки:

refund_id
return_id
order_id
payment_id
amount
currency
reason
status
approved_by
approved_at
payment_provider
external_refund_id
created_at

Статусы:

draft
waiting_approval
approved
sent_to_provider
completed
failed
cancelled

Проверка: refund не отправляется в Stripe, YooKassa или CloudPayments без `approved_by`.

Шаг 25. Создайте approval_queue

Лист `approval_queue` хранит подтверждения.

Колонки:

approval_id
entity_type
entity_id
approval_type
assigned_to
status
decision
decision_comment
created_at
decided_at

Типы:

customer_message
refund
order_cancel
address_change
manual_discount
product_content_change
complaint_reply

Решения:

approved
needs_fix
rejected
escalate

Проверка: `refund_requests.status = approved` появляется только после строки `approval_queue.decision = approved`.

Шаг 26. Создайте crm_updates

Лист `crm_updates` хранит записи, которые можно отправить в CRM.

Колонки:

update_id
case_id
customer_id
order_id
target_system
action_type
payload_json
status
approved_by
external_id
created_at

Разрешенные действия:

create_note
create_task
add_tag
update_case_status

Запрещенные без отдельного approval:

cancel_order
change_order_items
change_address
issue_refund
change_price

Проверка: агент может создать note или task, но не меняет заказ напрямую.

Шаг 27. Добавьте cart_recovery_queue

Лист `cart_recovery_queue` нужен для брошенных корзин.

Колонки:

recovery_id
customer_id
cart_id
items_json
cart_amount
last_activity_at
reason_guess
message_draft_id
status
created_at

Правила:

1. писать только тем, у кого есть согласие на коммуникацию;
2. не обещать скидку без `price_rules`;
3. не отправлять массовые сообщения без approval;
4. учитывать частотность.

Проверка: клиент без разрешения на коммуникацию не получает draft для отправки.

Шаг 28. Создайте performance_log

Лист `performance_log` хранит результаты работы агента.

Колонки:

metric_id
date
channel
intent
messages_count
resolved_by_agent
operator_handoffs
recommendations_shown
recommendation_clicks
orders_assisted
refund_requests
avg_response_time
csat
comment

Проверка: видно, где агент помогает, а где слишком часто передает оператору.

Шаг 29. Настройте audit_log

Лист `audit_log` обязателен.

Колонки:

event_id
created_at
actor
entity_type
entity_id
action
before_json
after_json
reason
system

Логируйте:

1. импорт каталога;
2. импорт остатков;
3. импорт заказов;
4. входящее сообщение;
5. lookup товара;
6. lookup заказа;
7. создание draft;
8. создание support_case;
9. approval;
10. отправку сообщения;
11. создание refund_request;
12. ошибку API.

Проверка: по одному `order_id` можно восстановить, что сказал агент и кто подтвердил действие.

Шаг 30. Настройте error_log

Лист `error_log` хранит ошибки.

Колонки:

error_id
created_at
entity_type
entity_id
step
severity
error_code
message
raw_payload_url
resolved
resolved_by
resolved_at

Типовые `error_code`:

product_not_found
stock_data_stale
order_not_found
customer_not_verified
llm_json_invalid
price_rule_missing
refund_requires_approval
delivery_tracking_unavailable
api_sync_failed
personal_data_blocked

Проверка: если заказ не найден, агент создает понятную ошибку и просит оператора проверить данные.

Шаг 31. Протестируйте контрольные сценарии

Создайте тестовый набор.

Минимум:

1. вопрос по активному товару в наличии;
2. вопрос по товару без остатка;
3. подбор товара по задаче;
4. вопрос по заказу с корректной верификацией;
5. вопрос по чужому заказу;
6. просьба изменить адрес доставки;
7. просьба отменить заказ;
8. просьба сделать refund;
9. жалоба на качество;
10. вопрос по гарантии;
11. запрос скидки без правила;
12. prompt injection в сообщении покупателя.

Ожидаемые результаты:

товар без остатка не предлагается как доступный
чужой заказ не раскрывается
refund идет в approval_queue
адрес не меняется автоматически
prompt injection игнорируется

Проверка: после изменения prompt все тесты проходят без регрессий.

Шаг 32. Проверьте минимальный результат

Прототип готов, если:

1. товары попадают в `product_catalog`;
2. остатки попадают в `inventory_snapshot`;
3. заказы попадают в `order_queue`;
4. вопрос покупателя классифицируется по intent;
5. агент делает lookup товара или заказа;
6. ответ создается в `message_drafts`;
7. спорные случаи создают `support_cases`;
8. возвраты создают `return_requests`;
9. refund создает `refund_requests` и `approval_queue`;
10. CRM update не меняет заказ без approval;
11. метрики пишутся в `performance_log`;
12. все действия видны в `audit_log`.

Проверка: задайте три вопроса: про наличие, про статус заказа и про возврат. Первый должен дать draft ответа, второй - ответ после верификации, третий - заявку на проверку оператором.

Что нельзя автоматизировать в первой версии

Не автоматизируйте сразу:

1. изменение цен;
2. изменение остатков;
3. отмену заказа;
4. refund;
5. изменение адреса доставки;
6. выдачу ручной скидки;
7. публикацию изменений карточки товара;
8. решение спорных жалоб;
9. обещание точной даты доставки без tracking;
10. показ персональных данных без верификации;
11. массовые сообщения по брошенной корзине;
12. удаление клиентов, заказов и обращений.

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

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

Может ли агент сам делать возврат денег?

Нет. Он может собрать причину, номер заказа, товар, сумму и создать `refund_request`, но отправка refund в платежный провайдер должна идти только после approval.

Можно ли подключить Shopify или WooCommerce сразу?

Да, но сначала дайте read-only доступ: товары, остатки, заказы и клиенты. Write-действия вроде отмены заказа, изменения адреса и возврата денег добавляйте только через отдельную очередь согласования.

Что делать, если товара нет в наличии?

Агент должен честно сказать, что сейчас товар недоступен, предложить альтернативы из `product_catalog` с `available_for_sale = yes` или создать обращение оператору. Нельзя обещать поступление без данных.

Как защитить персональные данные покупателя?

Проверяйте email, телефон или номер заказа перед ответом по заказу. В логах храните masked или hash-данные, не отправляйте полные персональные данные в LLM без необходимости.

Какой минимум нужен для запуска?

Таблицы `product_catalog`, `inventory_snapshot`, `order_queue`, `knowledge_base`, `support_cases`, `message_drafts`, `approval_queue`, `return_requests`, `refund_requests`, n8n workflow, LLM intent classifier и обязательный `audit_log`.