Как настроить ИИ-агента поддержки клиентов: от базы знаний до первого ответа

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

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

В результате у вас будет схема, которую можно собрать в Chatwoot, HelpDesk, Usedesk, Zendesk, amoCRM, Bitrix24, n8n, Make или в собственной админке. Для инструкции берем нейтральную связку: канал обращений, таблицы данных, база знаний, n8n или Make как оркестратор, LLM API и очередь операторской проверки.

MVP должен дать такой результат:

1. все обращения попадают в `support_tickets`;
2. сообщения клиентов хранятся в `support_messages`;
3. клиенты лежат в `customer_profile`;
4. база знаний описана в `knowledge_articles`;
5. фрагменты базы знаний лежат в `knowledge_chunks`;
6. частые намерения клиента лежат в `support_intents`;
7. правила маршрутизации лежат в `routing_rules`;
8. SLA хранится в `sla_policy`;
9. агентские ответы пишутся в `agent_drafts`;
10. уверенность ответа хранится в `confidence_score`;
11. опасные или неясные ответы уходят в `human_review_queue`;
12. эскалации оператору пишутся в `escalation_log`;
13. обращения после ответа получают статус `waiting_customer` или `resolved`;
14. качество ответов проверяется через `support_test_cases`;
15. все действия агента фиксируются в `support_audit_log`.

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

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

Подготовьте минимальный набор:

1. канал обращений: чат на сайте, Telegram, WhatsApp, email или форма;
2. helpdesk или CRM, где есть карточка обращения;
3. n8n, Make, Albato или backend webhook;
4. LLM API или локальная модель;
5. база знаний в Notion, Google Docs, Confluence, Markdown, CMS или таблице;
6. список типовых вопросов клиентов;
7. список случаев, где нужен оператор;
8. тестовый клиентский чат;
9. отдельный email или тестовый канал для проверок;
10. доступ к истории 50-100 реальных обращений без лишних персональных данных;
11. таблица для логов и метрик;
12. ответственный оператор, который будет проверять первые ответы.

Для первого запуска достаточно одного канала и одной базы знаний. Не подключайте сразу все мессенджеры, CRM, телефонию и оплату.

Шаг 1. Выберите один канал для первого запуска

Начните с канала, где проще проверить весь путь от клиента до ответа.

Подойдут:

1. чат на сайте;
2. Telegram-бот;
3. email поддержки;
4. форма обратной связи;
5. внутренний тестовый чат.

Для MVP выберите один канал, например `site_chat`.

Запишите параметры в `support_channels`:

id
channel_key
channel_type
provider
inbound_webhook_url
outbound_api_url
is_test
is_active
created_at

Первое значение:

channel_key: site_chat_main
channel_type: web_chat
provider: chatwoot_or_helpdesk
is_test: true
is_active: true

Проверка: отправьте тестовое сообщение и убедитесь, что оно появляется в helpdesk или CRM.

Шаг 2. Опишите статусы обращения

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

Минимальные статусы:

1. `new` - обращение только создано;
2. `triage` - агент определяет тему и срочность;
3. `drafted` - агент подготовил черновик;
4. `human_review` - нужен оператор;
5. `waiting_customer` - ответ отправлен, ждем клиента;
6. `resolved` - вопрос закрыт;
7. `reopened` - клиент вернулся;
8. `spam` - мусорное обращение;
9. `blocked` - опасный или запрещенный запрос.

Создайте справочник `ticket_statuses`:

id
status_key
name
is_final
sort_order

Проверка: тикет нельзя закрыть в `resolved`, если нет отправленного ответа или операторского решения.

Шаг 3. Создайте таблицу `support_tickets`

`support_tickets` хранит карточку обращения.

Колонки:

id
external_ticket_id
channel_key
customer_id
subject
status
priority
intent_key
assigned_team
assigned_operator_id
sla_deadline_at
last_customer_message_at
last_agent_action_at
created_at
updated_at

Правила:

1. один вопрос клиента равен одному ticket;
2. повторное сообщение в старой теме добавляется в тот же ticket;
3. новая тема создает новый ticket;
4. `priority` сначала ставит агент, потом оператор может изменить;
5. `status` меняется только по правилам workflow.

Проверка: тестовое обращение создает одну запись в `support_tickets`, а повторное сообщение клиента не создает дубль.

Шаг 4. Создайте таблицу `support_messages`

`support_messages` хранит все сообщения внутри тикета.

Колонки:

id
ticket_id
external_message_id
sender_type
sender_name
message_text
message_html
attachments_json
language
received_at
created_at

Значения `sender_type`:

1. `customer`;
2. `operator`;
3. `ai_agent`;
4. `system`.

Для агента важно видеть последние сообщения, но не тащить в prompt всю историю без ограничения. В MVP берите последние 10 сообщений или последние 12 000 символов.

Проверка: в тикете видны исходное сообщение клиента, черновик агента и финальный ответ оператора.

Шаг 5. Создайте профиль клиента

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

Колонки:

id
external_customer_id
name
email
phone_hash
company
plan_name
account_status
last_order_id
language
timezone
created_at
updated_at

В prompt можно передавать:

1. имя;
2. тариф;
3. статус аккаунта;
4. язык;
5. часовой пояс;
6. номер заказа, если он нужен для вопроса.

Не передавайте:

1. полный номер карты;
2. пароль;
3. токены;
4. паспортные данные;
5. лишнюю историю покупок;
6. приватные заметки операторов.

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

Шаг 6. Соберите базу знаний

Создайте папку или раздел `support_kb`.

Минимальные документы:

1. оплата и возвраты;
2. доставка или сроки выполнения;
3. регистрация и вход;
4. восстановление доступа;
5. тарифы и ограничения;
6. частые ошибки;
7. инструкции по продукту;
8. правила эскалации;
9. контакты поддержки;
10. политика безопасности.

Каждый материал должен отвечать на один тип вопроса. Не делайте один огромный документ на 50 страниц.

Проверка: оператор может найти ответ в базе знаний за 1-2 минуты без агента.

Шаг 7. Создайте таблицу `knowledge_articles`

`knowledge_articles` хранит документы базы знаний.

Колонки:

id
source_type
source_url
title
slug
topic
product_area
status
version
owner
updated_at

Статусы:

1. `draft`;
2. `review`;
3. `published`;
4. `outdated`;
5. `archived`.

В агентский поиск отправляйте только `published`.

Проверка: документ со статусом `draft` не попадает в ответ клиенту.

Шаг 8. Нарежьте базу знаний на фрагменты

Создайте `knowledge_chunks`.

Колонки:

id
article_id
chunk_index
heading
chunk_text
source_url
version
embedding_id
is_active
created_at

Правила нарезки:

1. один chunk должен отвечать на конкретный вопрос;
2. размер chunk: 700-1500 символов;
3. заголовок сохраняйте отдельно;
4. ссылку на исходный документ сохраняйте отдельно;
5. устаревшие chunks выключайте через `is_active = false`;
6. после изменения документа пересоздавайте chunks.

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

Шаг 9. Настройте поиск по базе знаний

Для MVP используйте гибридный поиск:

1. keyword search по словам клиента;
2. vector search по смыслу;
3. фильтр по `status = published`;
4. фильтр по продукту или тарифу;
5. top 5 chunks в prompt;
6. обязательная ссылка на источник.

Сохраняйте результат поиска в `retrieval_log`:

id
ticket_id
query_text
matched_chunk_ids_json
top_score
created_at

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

Шаг 10. Создайте справочник намерений клиента

`support_intents` помогает маршрутизировать обращения.

Минимальные intent:

1. `payment_issue`;
2. `refund_request`;
3. `delivery_status`;
4. `login_problem`;
5. `bug_report`;
6. `how_to_use`;
7. `pricing_question`;
8. `cancel_subscription`;
9. `complaint`;
10. `sales_question`;
11. `security_request`;
12. `other`.

Колонки:

id
intent_key
name
description
default_priority
requires_human
target_team

Проверка: сообщение "не могу войти в аккаунт" получает intent `login_problem`, а не `other`.

Шаг 11. Опишите правила маршрутизации

Создайте `routing_rules`.

Колонки:

id
intent_key
condition_json
target_team
target_status
requires_human
priority
is_active

Правила для MVP:

1. `refund_request` всегда идет в `human_review`;
2. `security_request` всегда идет в `human_review`;
3. `complaint` всегда идет в `human_review`;
4. `login_problem` можно отвечать черновиком;
5. `how_to_use` можно отвечать автоматически после проверки;
6. `pricing_question` можно отвечать из базы знаний;
7. `bug_report` идет в команду поддержки или разработки;
8. `other` идет оператору.

Проверка: просьба "верните деньги" не отправляется клиенту автоматически.

Шаг 12. Настройте SLA

Создайте `sla_policy`.

Колонки:

id
priority
first_response_minutes
resolution_hours
business_hours_json
escalation_team
is_active

Стартовые правила:

1. `urgent` - первый ответ за 15 минут;
2. `high` - первый ответ за 30 минут;
3. `normal` - первый ответ за 2 часа;
4. `low` - первый ответ за 8 часов.

Агент должен вычислять `sla_deadline_at` при создании тикета.

Проверка: тикет с жалобой получает более короткий срок первого ответа.

Шаг 13. Создайте webhook для входящих сообщений

В n8n или Make создайте сценарий `support_inbound_message`.

Первый набор узлов:

1. `Webhook` принимает событие из чата или helpdesk;
2. `Normalize Payload` приводит данные к единому виду;
3. `Find or Create Customer` ищет клиента;
4. `Find or Create Ticket` создает или обновляет ticket;
5. `Save Message` пишет сообщение в `support_messages`;
6. `Run AI Triage` запускает классификацию.

Единый входной JSON:

{
  "channel_key": "site_chat_main",
  "external_ticket_id": "12345",
  "external_message_id": "m-987",
  "customer": {
    "name": "Иван",
    "email": "ivan@example.com"
  },
  "message": {
    "text": "Не могу войти в личный кабинет",
    "attachments": []
  }
}

Проверка: webhook одинаково обрабатывает сообщение из тестового чата и тестового email.

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

Перед отправкой в модель очистите сообщение.

Сделайте узел `Normalize Message`:

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

Пример нормализованного текста:

{
  "language": "ru",
  "clean_text": "Не могу войти в личный кабинет. Код восстановления не приходит.",
  "has_attachments": false,
  "masked": true
}

Проверка: длинная email-переписка не превращается в prompt на десятки тысяч символов.

Шаг 15. Сделайте классификацию обращения

Создайте prompt для triage.

Ты классификатор обращений поддержки.
Верни только JSON.
Определи intent, priority, language, needs_human, short_summary.
Не отвечай клиенту.
Если клиент просит возврат, жалуется, угрожает, сообщает о безопасности или требует индивидуального решения, needs_human = true.

Формат ответа:

{
  "intent": "login_problem",
  "priority": "normal",
  "language": "ru",
  "needs_human": false,
  "short_summary": "Клиент не может войти, код восстановления не приходит"
}

Сохраните результат в `ticket_ai_triage`:

id
ticket_id
intent_key
priority
needs_human
summary
model_name
created_at

Проверка: агент не пишет ответ клиенту на этапе triage.

Шаг 16. Подготовьте контекст для ответа

Соберите prompt context из пяти частей:

1. последнее сообщение клиента;
2. краткая история тикета;
3. профиль клиента без секретов;
4. найденные chunks базы знаний;
5. правила ответа поддержки.

Ограничение:

1. история тикета: до 10 последних сообщений;
2. база знаний: top 5 chunks;
3. профиль клиента: только нужные поля;
4. служебные правила: коротко;
5. вложения: только описание, если файл не распознан.

Проверка: prompt помещается в лимит модели и не содержит лишних персональных данных.

Шаг 17. Напишите системный prompt агента поддержки

Используйте такой каркас:

Ты ИИ-агент службы поддержки.
Твоя задача - подготовить точный черновик ответа оператору.
Отвечай только на основе базы знаний и данных тикета.
Если ответа нет в базе знаний, честно напиши, что нужна проверка оператором.
Не обещай возврат денег, скидку, компенсацию, срок поставки или юридическое решение без подтвержденных данных.
Не проси пароль, полный номер карты, коды из SMS или токены.
Если запрос связан с безопасностью, оплатой, жалобой, возвратом или персональными данными, поставь needs_human = true.
Верни JSON.

Ожидаемый JSON:

{
  "draft_answer": "Иван, проверьте папку Спам и запросите код повторно через 2 минуты. Если код не придет, я передам обращение оператору для проверки почты в аккаунте.",
  "confidence_score": 0.82,
  "needs_human": false,
  "used_sources": ["kb-login-recovery-2026"],
  "next_status": "drafted",
  "internal_note": "Ответ найден в базе знаний по восстановлению доступа"
}

Проверка: модель возвращает валидный JSON, а не свободный текст.

Шаг 18. Создайте таблицу `agent_drafts`

`agent_drafts` хранит черновики ответов.

Колонки:

id
ticket_id
message_id
draft_answer
confidence_score
needs_human
used_sources_json
internal_note
next_status
model_name
created_at
approved_at
sent_at

Правила:

1. каждый черновик привязан к ticket;
2. каждый черновик показывает источники;
3. черновик с `confidence_score < 0.75` идет оператору;
4. черновик с `needs_human = true` идет оператору;
5. черновик без источников не отправляется автоматически.

Проверка: оператор видит текст ответа, уверенность и источник.

Шаг 19. Настройте пороги уверенности

Создайте `confidence_rules`.

Колонки:

id
intent_key
min_auto_send_score
min_draft_score
requires_source
requires_human
is_active

Стартовые пороги:

1. `how_to_use`: auto-send от `0.90`;
2. `pricing_question`: auto-send от `0.92`;
3. `login_problem`: draft от `0.75`, auto-send выключен;
4. `refund_request`: auto-send выключен;
5. `complaint`: auto-send выключен;
6. `security_request`: auto-send выключен;
7. `other`: auto-send выключен.

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

Шаг 20. Сделайте очередь операторской проверки

Создайте `human_review_queue`.

Колонки:

id
ticket_id
draft_id
reason
priority
assigned_team
status
created_at
resolved_at

Причины:

1. `low_confidence`;
2. `no_kb_source`;
3. `refund_or_payment`;
4. `security_or_privacy`;
5. `angry_customer`;
6. `legal_or_financial`;
7. `bug_report`;
8. `unknown_intent`.

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

Шаг 21. Настройте отправку ответа

Создайте отдельный шаг `Send Reply`.

Он должен запускаться только если:

1. `draft_answer` не пустой;
2. `used_sources` не пустой;
3. `confidence_score` выше порога;
4. `needs_human = false`;
5. intent разрешен для автоответа;
6. ticket еще не закрыт;
7. клиент не написал новое сообщение после генерации черновика.

Если условия не выполнены, сценарий отправляет черновик оператору.

Проверка: если клиент написал новое сообщение, старый черновик не отправляется.

Шаг 22. Добавьте внутреннюю заметку оператору

В helpdesk или CRM создайте внутреннюю заметку:

AI summary: клиент не может войти, код восстановления не приходит.
Intent: login_problem.
Confidence: 0.82.
Sources: kb-login-recovery-2026.
Recommendation: отправить черновик после проверки email клиента.

Правила заметки:

1. заметка не видна клиенту;
2. заметка содержит причину решения;
3. заметка содержит источники;
4. заметка содержит next action;
5. заметка не содержит секреты.

Проверка: оператор может быстро понять, что сделал агент.

Шаг 23. Подключите поиск заказа или аккаунта

Если поддержка часто отвечает по заказам, подключите tool `get_customer_order`.

Вход:

{
  "customer_id": "c-123",
  "order_id": "o-456"
}

Выход:

{
  "order_id": "o-456",
  "status": "paid",
  "delivery_status": "in_transit",
  "eta": "2026-05-27"
}

Правила:

1. tool только читает данные;
2. tool не меняет заказ;
3. tool не возвращает платежные секреты;
4. agent видит только нужные поля;
5. все вызовы tool пишутся в лог.

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

Шаг 24. Настройте tool policy

Создайте `support_tool_policy`.

Колонки:

id
tool_name
can_read
can_write
requires_human_approval
allowed_intents_json
blocked_fields_json
is_active

Правила для MVP:

1. `search_kb` разрешен всегда;
2. `get_customer_profile` разрешен только для текущего клиента;
3. `get_order_status` разрешен только на чтение;
4. `create_refund` запрещен;
5. `change_tariff` запрещен;
6. `delete_account` запрещен;
7. `send_reply` разрешен только после confidence rules;
8. `close_ticket` разрешен только для простых intent.

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

Шаг 25. Обработайте вложения

В MVP не пытайтесь автоматически разбирать все файлы.

Сделайте правила:

1. изображения сохраняются как attachment;
2. PDF передается оператору, если OCR не настроен;
3. архивы не открываются;
4. исполняемые файлы блокируются;
5. скриншоты ошибок можно отправить в OCR только в тестовом режиме;
6. файлы с персональными документами идут оператору;
7. вложения логируются отдельно.

Создайте `support_attachments`:

id
ticket_id
message_id
file_name
file_type
file_size
storage_url
scan_status
created_at

Проверка: агент не обещает решение по файлу, который он фактически не прочитал.

Шаг 26. Настройте защиту от опасных запросов

Создайте `support_guardrails`.

Блокируйте автоматический ответ, если клиент:

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

Сохраняйте срабатывания в `guardrail_events`:

id
ticket_id
rule_key
severity
action
created_at

Проверка: фраза "удалите мой аккаунт и верните деньги" уходит оператору.

Шаг 27. Логируйте все действия агента

Создайте `support_audit_log`.

Колонки:

id
ticket_id
event_type
actor
payload_json
model_name
created_at

Логируйте:

1. входящее сообщение;
2. классификацию;
3. поиск в базе знаний;
4. найденные источники;
5. вызовы tools;
6. созданный черновик;
7. confidence;
8. решение auto-send или human-review;
9. отправленный ответ;
10. ошибку сценария.

Проверка: по одному ticket можно восстановить весь путь решения.

Шаг 28. Создайте тестовые обращения

Создайте `support_test_cases`.

Колонки:

id
case_key
customer_message
expected_intent
expected_route
expected_contains
expected_not_contains
is_active

Минимальные тесты:

1. "не могу войти" -> `login_problem`;
2. "как поменять тариф" -> `pricing_question`;
3. "верните деньги" -> `refund_request` и оператор;
4. "где мой заказ" -> `delivery_status`;
5. "у меня ошибка 500" -> `bug_report`;
6. "удалите аккаунт" -> оператор;
7. "пришлите мой пароль" -> блокировка;
8. "как подключить интеграцию" -> `how_to_use`;
9. "вы ужасные, буду жаловаться" -> `complaint`;
10. "сколько стоит тариф Pro" -> `pricing_question`.

Проверка: 10 тестов проходят до включения агента на реальных клиентах.

Шаг 29. Запустите тестовый сценарий вручную

Отправьте в тестовый чат сообщение:

Не могу войти в личный кабинет. Код восстановления не приходит.

Проверьте путь:

1. ticket создан;
2. message сохранен;
3. customer найден или создан;
4. intent = `login_problem`;
5. priority = `normal`;
6. база знаний нашла статью про восстановление доступа;
7. черновик создан;
8. confidence выше `0.75`;
9. автоотправка выключена;
10. оператор видит черновик;
11. оператор подтверждает;
12. ответ уходит клиенту;
13. status меняется на `waiting_customer`;
14. audit log заполнен.

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

Шаг 30. Включите режим только черновиков

На первой неделе используйте режим `draft_only`.

Правила:

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

Создайте `operator_feedback`:

id
draft_id
operator_id
rating
edited_answer
feedback_reason
created_at

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

Шаг 31. Подготовьте правила автоответа

Автоответ можно включать только для узких случаев.

Разрешите auto-send, если:

1. intent входит в белый список;
2. confidence выше порога;
3. найден источник базы знаний;
4. вопрос не связан с деньгами;
5. вопрос не связан с безопасностью;
6. клиент не злится;
7. нет вложений;
8. клиент не VIP;
9. SLA не нарушен;
10. операторские правки за последние 20 похожих обращений были минимальными.

Белый список для старта:

1. `how_to_use`;
2. `pricing_question` без индивидуальной скидки;
3. `delivery_status` только при read-only tool;
4. `login_problem` только с общими шагами, без доступа к аккаунту.

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

Шаг 32. Настройте метрики качества

Создайте `support_ai_metrics`.

Колонки:

id
date
total_tickets
drafts_created
drafts_approved
drafts_edited
auto_sent
human_escalated
wrong_intent_count
bad_answer_count
avg_confidence
avg_first_response_seconds
created_at

Смотрите каждый день:

1. доля черновиков от всех тикетов;
2. доля принятых черновиков;
3. доля сильно отредактированных ответов;
4. количество ошибочных intent;
5. количество эскалаций;
6. скорость первого ответа;
7. темы без ответа в базе знаний;
8. жалобы клиентов после AI-ответа.

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

Шаг 33. Сделайте ежедневный разбор ошибок

Создайте короткий процесс на 15 минут.

Каждый день смотрите:

1. 10 случайных черновиков;
2. все ответы с низкой оценкой оператора;
3. все auto-send ответы;
4. все обращения с жалобами;
5. все случаи без найденного источника;
6. все срабатывания guardrails;
7. все тикеты, где клиент повторно спросил то же самое.

Результаты разбора:

1. обновить статью базы знаний;
2. добавить тест-кейс;
3. изменить routing rule;
4. изменить confidence threshold;
5. запретить auto-send для intent;
6. добавить операторскую подсказку.

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

Шаг 34. Минимальный результат для запуска

MVP готов, если выполнены условия:

1. один канал подключен;
2. тикеты создаются без дублей;
3. сообщения сохраняются;
4. база знаний опубликована;
5. поиск находит релевантные chunks;
6. intent определяется правильно на тестах;
7. черновик ответа содержит источник;
8. confidence считается и сохраняется;
9. сложные темы уходят оператору;
10. автоотправка выключена или включена только для белого списка;
11. оператор видит внутреннюю заметку;
12. все действия есть в audit log;
13. есть 10-20 тестовых обращений;
14. есть ежедневная проверка качества;
15. есть правила, что агенту запрещено делать.

Финальная проверка: отправьте 10 тестовых обращений из списка. Если 8-9 из них правильно классифицированы, все опасные случаи ушли оператору, а простые ответы имеют источники, MVP можно включать на небольшой поток реальных обращений.

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

В первой версии не автоматизируйте:

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

Сначала агент должен помогать оператору отвечать быстрее. Когда накопится статистика и тесты, можно постепенно включать автоответы на простые вопросы.

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

Можно ли сразу включить автоматические ответы клиентам?

Лучше начать с режима черновиков. Автоответы включайте только после проверки на реальных обращениях и только для простых intent с высокой уверенностью.

Что важнее: prompt или база знаний?

База знаний важнее. Хороший prompt не спасет, если в базе нет точных правил, актуальных тарифов, сроков и инструкций.

Сколько тестовых обращений нужно для старта?

Минимум 10-20. Для стабильного запуска лучше собрать 50-100 обращений по основным темам поддержки.

Что делать, если агент уверенно ошибается?

Понизьте порог автоответа, добавьте тест-кейс, проверьте найденные chunks и исправьте материал базы знаний. Ошибку нужно чинить в данных и правилах, а не только в тексте prompt.

Можно ли подключить агента к CRM и заказам?

Да, но на первом этапе только в режиме чтения. Агент может смотреть статус заказа или тариф, но не должен менять деньги, доступы, договоры и учетные записи без оператора.