Как сделать ИИ-агента для управления репутацией и отзывами

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

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

Первая рабочая версия будет делать так:

1. площадки и аккаунты хранятся в `review_sources`;
2. новые отзывы попадают в `review_inbox`;
3. исходные данные сохраняются в `raw_reviews`;
4. нормализованные поля пишутся в `normalized_reviews`;
5. рейтинг и история площадок пишутся в `rating_snapshots`;
6. правила тем лежат в `topic_rules`;
7. правила риска лежат в `risk_policy`;
8. sentiment и темы пишутся в `review_analysis`;
9. приоритет и следующее действие пишутся в `review_triage`;
10. критичные случаи попадают в `escalation_queue`;
11. черновики ответов пишутся в `reply_drafts`;
12. публичные ответы проходят через `approval_queue`;
13. публикации фиксируются в `published_replies`;
14. повторяющиеся проблемы пишутся в `issue_clusters`;
15. задачи для команд идут через `task_queue`;
16. запросы на жалобу или удаление пишутся в `platform_actions`;
17. все действия фиксируются в `audit_log`;
18. ошибки попадают в `error_log`;
19. weekly report показывает рейтинг, негатив, скорость ответа и повторяющиеся темы.

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

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

• n8n Cloud или self-hosted n8n.
• Google Sheets для управляющих таблиц.
• 1-2 площадки отзывов для MVP: Google Business Profile, Trustpilot, Yotpo, маркетплейс, App Store, Google Play или выгрузка из CRM.
• API или регулярный CSV/export, если API недоступен.
• Канал согласования: Telegram, Slack, email или задача в CRM.
• Канал задач: Jira, Asana, ClickUp, CRM tasks или Google Sheets.
• API-ключ LLM-провайдера.
• 50-100 прошлых отзывов для теста.
• Правила тона ответа, компенсаций, эскалаций и публичной коммуникации.

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

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

Хорошие варианты:

1. Google Business Profile для локального бизнеса;
2. Trustpilot для публичных отзывов о компании;
3. Yotpo для интернет-магазина;
4. маркетплейс с отзывами о товарах;
5. App Store или Google Play;
6. отзывы с сайта;
7. отзывы из CRM после закрытия сделки;
8. NPS/CSAT как внутренний поток обратной связи.

Проверка: вы можете назвать одну площадку, кто отвечает за ответы и какой SLA реакции нужен.

Шаг 2. Определите границы автоматизации

Запишите, что агенту разрешено.

Можно в первой версии:

• читать новые отзывы;
• сохранять исходный текст;
• определять sentiment;
• выделять темы;
• ставить приоритет;
• готовить черновик ответа;
• создавать внутреннюю задачу;
• отправлять критичный негатив на согласование;
• готовить weekly reputation report.

Нельзя в первой версии:

• публиковать ответ на негатив без approval;
• обещать компенсацию;
• спорить с клиентом;
• обвинять автора отзыва;
• раскрывать детали заказа;
• просить удалить отзыв;
• подавать жалобу на отзыв без человека;
• закрывать инцидент без владельца.

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

Шаг 3. Создайте таблицу проекта

Создайте Google Sheet:

Reputation reviews agent

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

settings
review_sources
review_inbox
raw_reviews
normalized_reviews
rating_snapshots
topic_rules
risk_policy
review_analysis
review_triage
escalation_queue
reply_templates
reply_drafts
approval_queue
published_replies
issue_clusters
task_queue
platform_actions
audit_log
weekly_report
error_log

Проверка: n8n может читать и писать во все листы.

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

В `settings` добавьте колонки:

key
value
description
updated_at

Заполните минимум:

default_language | ru | язык ответов
negative_review_sla_hours | 4 | срок реакции на негатив
positive_review_sla_hours | 24 | срок реакции на позитив
auto_publish_positive | false | автоответы выключены
auto_publish_negative | false | негатив только через approval
require_approval_for_rating_lte | 3 | все 1-3 звезды через согласование
legal_terms_approval | true | юридические темы только через человека
compensation_approval | true | компенсации только через человека
approval_channel | telegram | канал согласования

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

Шаг 5. Настройте review_sources

В `review_sources` храните площадки, откуда агент забирает отзывы.

Колонки:

source_id
source_type
account_name
location_id
api_mode
fetch_frequency
owner_email
status
last_fetch_at
created_at

`source_type`:

google_business_profile
trustpilot
yotpo
marketplace
app_store
google_play
manual_csv
email_notification

Проверка: у каждой площадки есть владелец и понятная частота обновления.

Шаг 6. Подключите первый сбор отзывов

В n8n создайте workflow:

Review intake

Цепочка:

1. Cron Trigger каждые 1-4 часа;
2. прочитать активные `review_sources`;
3. забрать новые reviews через API, CSV или email;
4. создать `review_id`;
5. записать исходный payload в `raw_reviews`;
6. записать строку в `review_inbox`;
7. обновить `last_fetch_at`.

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

Шаг 7. Настройте review_inbox

`review_inbox` - очередь отзывов на обработку.

Колонки:

review_id
source_id
external_review_id
source_type
rating
review_url
received_at
status
priority
owner_email
created_at
updated_at

Статусы:

new
normalizing
analyzing
triage
waiting_approval
ready_to_reply
replied
escalated
ignored
error

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

Шаг 8. Сохраняйте raw_reviews

В `raw_reviews` добавьте колонки:

review_id
source_type
payload_json
fetched_at

Правило:

raw_reviews не редактируется агентом, только дописывается

Проверка: при ошибке анализа можно открыть исходный текст и payload.

Шаг 9. Нормализуйте normalized_reviews

В `normalized_reviews` добавьте колонки:

review_id
source_type
external_review_id
author_name
author_profile_url
rating
review_text
language
product_name
location_name
order_id_masked
review_url
has_reply
published_at
normalized_at

Правила:

1. пустой текст не выдумывать;
2. order ID хранить только masked;
3. персональные данные не переносить в черновик ответа;
4. язык определять отдельно;
5. одинаковый `external_review_id` не создавать дважды.

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

Шаг 10. Собирайте rating_snapshots

Репутация - это не только отдельные отзывы, но и динамика рейтинга.

В `rating_snapshots` добавьте колонки:

snapshot_id
source_id
rating_avg
reviews_count
one_star_count
two_star_count
three_star_count
four_star_count
five_star_count
captured_at

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

Шаг 11. Опишите topic_rules

В `topic_rules` добавьте колонки:

topic_id
topic_name
keywords
team_owner
priority_modifier
example
is_active
updated_at

Темы для MVP:

delivery | доставка, курьер, задержка | logistics | +15
support | поддержка, не ответили, оператор | support | +15
product_quality | сломано, брак, качество | quality | +20
payment | оплата, возврат, списание | finance | +20
service | обслуживание, персонал, менеджер | operations | +10
legal | суд, претензия, жалоба, закон | legal | +50
privacy | персональные данные, утечка | security | +50
fake_review | не был клиентом, подозрительно | reputation | +20

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

Шаг 12. Опишите risk_policy

В `risk_policy` добавьте колонки:

policy_id
condition
risk_level
action
owner
approval_required
is_active
updated_at

Примеры:

RP-001 | rating <= 2 | high | draft_reply_and_escalate | reputation | yes
RP-002 | topic = legal | critical | escalate_legal | legal | yes
RP-003 | topic = privacy | critical | escalate_security | security | yes
RP-004 | contains_compensation_request | high | manual_review | support_lead | yes
RP-005 | sentiment = positive and rating >= 4 | low | draft_thanks | reputation | no
RP-006 | has_personal_data = true | high | redact_and_review | reputation | yes

Проверка: критичный отзыв не зависит только от решения модели.

Шаг 13. Сделайте LLM-анализ отзыва

Prompt:

Ты анализируешь публичный отзыв.
Используй только текст отзыва и метаданные.
Не выдумывай заказ, клиента и причину.
Не раскрывай персональные данные.
Верни JSON:
{
  "sentiment": "positive|neutral|negative|mixed|unknown",
  "topics": ["topic"],
  "summary": "до 500 символов",
  "customer_problem": "проблема клиента или null",
  "risk_flags": ["legal|privacy|compensation|aggressive|fake_suspected|personal_data"],
  "recommended_action": "reply|escalate|ignore|manual_review",
  "confidence": "high|medium|low"
}

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

Шаг 14. Запишите review_analysis

В `review_analysis` добавьте колонки:

analysis_id
review_id
sentiment
topics_json
summary
customer_problem
risk_flags_json
recommended_action
confidence
model
created_at

Правило:

если confidence = low, отзыв идет в manual_review

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

Шаг 15. Настройте review_triage

В `review_triage` добавьте колонки:

triage_id
review_id
priority
risk_level
team_owner
next_action
sla_deadline
status
created_at

`priority`:

low
normal
high
urgent

`risk_level`:

low
medium
high
critical

Правила:

1. рейтинг 1-2 звезды = минимум `high`;
2. legal/privacy = `critical`;
3. positive 4-5 звезд = `low`;
4. повторяющаяся тема за неделю повышает priority;
5. отзыв без ответа после SLA повышает priority.

Проверка: негатив с юридической претензией сразу получает urgent/critical.

Шаг 16. Создайте escalation_queue

В `escalation_queue` добавьте колонки:

escalation_id
review_id
risk_level
reason
team_owner
owner_email
summary
review_url
status
created_at
resolved_at

Причины эскалации:

legal_claim
privacy_issue
compensation_request
public_conflict
safety_complaint
repeated_problem
personal_data
fake_review_suspected

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

Шаг 17. Создайте reply_templates

В `reply_templates` добавьте колонки:

template_id
scenario
sentiment
topic
body_template
forbidden_phrases
approval_required
is_active
updated_at

Сценарии:

positive_thanks
neutral_clarify
negative_apology
delivery_issue
quality_issue
support_delay
legal_manual_only
privacy_manual_only

Проверка: для legal/privacy нет автоматического публичного ответа, только manual review.

Шаг 18. Подготовьте reply_drafts

В `reply_drafts` добавьте колонки:

draft_id
review_id
template_id
reply_text
tone
contains_compensation
contains_legal_claim
contains_personal_data
approval_required
status
created_at

Prompt:

Составь черновик публичного ответа на отзыв.
Пиши коротко, спокойно и уважительно.
Не спорь с клиентом.
Не обвиняй автора.
Не обещай компенсацию, возврат, скидку или сроки.
Не раскрывай детали заказа и персональные данные.
Если тема legal или privacy, не пиши публичный ответ, верни manual_review.
Верни JSON:
{
  "reply_text": "текст или null",
  "tone": "calm|thankful|apologetic|clarifying",
  "risk_flags": [],
  "approval_required": true
}

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

Шаг 19. Проверьте опасные фразы

Перед approval прогоните deterministic checks.

Флаги:

contains_compensation
contains_refund
contains_discount
contains_legal_claim
contains_personal_data
contains_blame
contains_argument
contains_delete_request

Запрещенные фразы:

вы сами виноваты
удалите отзыв
мы гарантируем
вернем деньги
дадим скидку
вы неправы
мы подадим жалобу

Проверка: опасный черновик не может попасть в публикацию.

Шаг 20. Настройте approval_queue

В `approval_queue` добавьте колонки:

approval_id
review_id
object_type
object_id
reason
preview
approver_email
status
created_at
decided_at

`object_type`:

reply_draft
platform_action
compensation_request
legal_review
privacy_review

Статусы:

pending
approved
rejected
needs_edit
expired

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

Шаг 21. Сделайте Telegram approval

В n8n создайте workflow:

Review approval

Цепочка:

1. найти `approval_queue` со статусом `pending`;
2. отправить preview в Telegram;
3. добавить кнопки `Approve`, `Needs edit`, `Reject`;
4. обновить статус;
5. записать решение в `audit_log`;
6. публиковать ответ только после approve.

Сообщение:

Нужно согласовать ответ на отзыв
Площадка: Google Business Profile
Рейтинг: 2
Риск: high
Тема: delivery

Preview:
Спасибо, что написали. Нам жаль, что доставка задержалась...

[Approve] [Needs edit] [Reject]

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

Шаг 22. Публикуйте ответ только после approval

Для публикации используйте отдельный workflow:

Publish review reply

Цепочка:

1. взять approved `reply_draft`;
2. проверить, что отзыв еще не отвечен;
3. проверить актуальность review URL;
4. отправить ответ через API площадки или создать задачу человеку;
5. записать результат в `published_replies`;
6. обновить `review_inbox.status = replied`;
7. записать действие в `audit_log`.

Проверка: ответ публикуется только один раз и связан с конкретным review_id.

Шаг 23. Запишите published_replies

В `published_replies` добавьте колонки:

published_reply_id
review_id
draft_id
source_type
reply_text
published_by
published_at
external_reply_id
status

Статусы:

published
failed
manual_post_required
deleted_by_platform
edited

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

Шаг 24. Группируйте повторяющиеся проблемы

В `issue_clusters` добавьте колонки:

cluster_id
topic
problem_summary
review_ids
count_7d
count_30d
rating_impact
team_owner
status
created_at
updated_at

Пример:

CL-001 | delivery | Курьер опаздывает вечером в Москве | REV-1,REV-8,REV-14 | 3 | 12 | -0.3 | logistics | open

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

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

В `task_queue` добавьте колонки:

task_queue_id
review_id
cluster_id
team_owner
task_payload_json
priority
status
created_at
processed_at
error_message

Пример payload:

{
  "title": "Проверить повторяющиеся жалобы на доставку",
  "assignee": "logistics@company.ru",
  "description": "За 7 дней 3 отзыва с жалобой на вечернюю доставку. Средний рейтинг этих отзывов: 2.0.",
  "source": "reputation_reviews_agent"
}

Проверка: повторяющаяся жалоба превращается в задачу владельцу процесса.

Шаг 26. Настройте platform_actions

Не все действия - это ответ. Иногда нужно пожаловаться на фейковый отзыв или запросить проверку площадки.

В `platform_actions` добавьте колонки:

platform_action_id
review_id
action_type
reason
evidence
approval_required
status
created_at
processed_at

`action_type`:

report_review
request_removal
edit_reply
manual_check
mark_no_action

Правило:

report_review и request_removal всегда требуют approval

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

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

В `audit_log` добавьте колонки:

audit_id
review_id
actor
action
object_type
object_id
before_json
after_json
created_at

Логируйте:

1. получение отзыва;
2. нормализацию;
3. sentiment analysis;
4. triage;
5. эскалацию;
6. создание reply draft;
7. approval;
8. публикацию ответа;
9. создание task;
10. platform action;
11. ошибку API.

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

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

В `error_log` добавьте колонки:

error_id
review_id
workflow_name
node_name
error_type
error_message
payload_snapshot
status
owner_email
created_at

Типы ошибок:

review_fetch_failed
duplicate_review_id
llm_invalid_json
approval_timeout
reply_publish_failed
platform_api_failed
task_create_failed
rating_snapshot_failed

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

Шаг 29. Соберите weekly_report

В `weekly_report` добавьте колонки:

week_start
reviews_total
avg_rating
positive_count
neutral_count
negative_count
critical_count
unanswered_reviews
avg_response_time_hours
replies_published
tasks_created
top_topics
top_risks
rating_change
created_at

Минимальный отчет:

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

Проверка: команда видит не только красивые ответы, но и реальные репутационные проблемы.

Шаг 30. Протестируйте на 70 отзывах

Возьмите тестовый набор:

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

Проверьте:

1. sentiment определен корректно;
2. темы выделены без потери смешанных отзывов;
3. legal/privacy ушли в escalation;
4. компенсации требуют approval;
5. позитив получил короткий черновик;
6. негатив не публикуется без approval;
7. персональные данные не попали в reply draft;
8. повторяющаяся тема попала в `issue_clusters`;
9. задачи создались владельцам;
10. ошибки попали в `error_log`.

Проверка: минимум 60 из 70 отзывов должны получить корректный статус и понятное действие.

Минимальная проверка результата

MVP готов, если:

• площадки описаны в `review_sources`;
• отзывы попадают в `review_inbox`;
• исходные данные пишутся в `raw_reviews`;
• нормализация работает в `normalized_reviews`;
• рейтинг пишется в `rating_snapshots`;
• темы описаны в `topic_rules`;
• риски описаны в `risk_policy`;
• анализ пишется в `review_analysis`;
• triage пишется в `review_triage`;
• критичные отзывы попадают в `escalation_queue`;
• шаблоны есть в `reply_templates`;
• черновики пишутся в `reply_drafts`;
• approval блокирует публикацию;
• опубликованные ответы пишутся в `published_replies`;
• повторяющиеся проблемы пишутся в `issue_clusters`;
• задачи создаются через `task_queue`;
• действия площадки идут через `platform_actions`;
• audit и error logs заполнены;
• weekly report показывает динамику.

Перед живым запуском пройдите чек-лист:

1. Добавьте одну площадку в `review_sources`.
2. Загрузите 10 тестовых отзывов.
3. Проверьте `normalized_reviews`.
4. Запустите sentiment analysis.
5. Проверьте `review_triage`.
6. Создайте один позитивный reply draft.
7. Создайте один негативный reply draft.
8. Отклоните негативный ответ через approval.
9. Одобрите позитивный ответ через approval.
10. Проверьте `published_replies`, `audit_log`, `error_log` и `weekly_report`.

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

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

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

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

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

Чем агент для отзывов отличается от агента поддержки?

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

Какие отзывы обрабатывать в первую очередь?

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

Как не звучать шаблонно?

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

Какие метрики показывают пользу агента?

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