Автоматизация коммуникаций в соцсети для сети ресторанов

1. Текущий объём внедрения
1.1. Количество аккаунтов
На первом этапе автоматизация внедряется для двух аккаунтов двух ресторанов.
Каждый аккаунт рассматривается как отдельный объект автоматизации, несмотря на общую архитектуру системы.

1.2. Принцип разделения аккаунтов
- у каждого аккаунта собственные триггеры и события;
- у каждого аккаунта собственный набор данных ресторана;
- история взаимодействий ведётся раздельно;
- автоматизации не пересекают данные и пользователей между аккаунтами.

Общими являются:
- логика сценариев;
- система анти-фрода;
- принципы GDPR;
- механизм имитации человеческого поведения.

1.3. Структура данных для ресторанов (обязательно)
Для каждого ресторана должны быть заведены отдельные записи в системе знаний: – меню;
- адрес;
- часы работы;
- актуальные акции;
- ссылки.

Важно: система не должна допускать ситуации, при которой:
- один аккаунт отвечает данными другого аккаунта;
- пользователь получает информацию не «своего» ресторана.

1.4. Масштабирование
Архитектура должна позволять:
- добавлять новые рестораны без изменения логики сценариев;
- подключать новые аккаунты через добавление данных в систему знаний;
- управлять автоматизациями на уровне каждого аккаунта.

2. Общая концепция
Автоматизация реализуется в виде набора независимых сценариев, а не одного универсального бота.
Каждый сценарий запускается собственным событием соцсети и имеет отдельную логику, лимиты и анти-фрод-защиту.
Все сценарии используют единую систему знаний (RAG) и общее хранилище истории взаимодействий.

2. Список автоматизаций
A1. Комментарий → личное сообщение (DM)
Триггер:
- пользователь оставил комментарий под постом аккаунта ресторана.
Действие:
- отправка личного сообщения пользователю.
Цели:
- вовлечение;
- передача предложения;
- перевод в приватный диалог.
Ограничения:
- одно DM на пользователя в рамках заданного периода;
- исключение повторных сообщений при множественных комментариях.

A2. Комментарий → ответ под комментарием
Триггер:
- пользователь оставил комментарий под постом.
Действие:
- публичный ответ в ветке комментариев.
Цели:
- поддержание активности;
- социальное доказательство;
- корректное, не шаблонное общение.
Ограничения:
- лимит ответов на пост;
- вариативность формулировок.

A3. Подписка → приветственное сообщение в DM
Триггер:
- пользователь подписался на аккаунт ресторана.
Действие:
- отправка приветственного сообщения в личку.
Цели:
- первое касание;
- задание тона общения;
- мягкое вовлечение.
Ограничения:
- только одно приветственное сообщение;
- учёт, получал ли пользователь ранее сообщения от этого аккаунта.

A4. Упоминание аккаунта в сторис → реакция + DM
Триггер:
- пользователь отметил аккаунт ресторана в сторис.
Действия:
Реакция на сторис.
Личное сообщение с благодарностью и бонусом.
Цели:
- стимулирование user-generated content;
- рост органического охвата;
- укрепление лояльности.
Ограничения:
- бонус выдаётся один раз;
- повторные упоминания фиксируются, но не поощряются автоматически.

A5. Упоминание аккаунта в сторис → репост в наших сторис
Триггер:
- пользователь отметил аккаунт ресторана в сторис.
Действия:
Реакция на сторис.
Репост в наших сторис.
Цели:
- стимулирование user-generated content;
- рост органического охвата;
- укрепление лояльности.

3. Единая система знаний (RAG)
3.1. Назначение
Обеспечить:
- корректные ответы;
- отсутствие путаницы между ресторанами;
- контекстность и вариативность.

3.2. Структура
Уровень 1. Общие данные бренда
- стиль общения;
- стандарты сервиса;
- допустимые формулировки;
- базовые правила ответов.

Уровень 2. Данные по ресторанам (отдельно для каждого аккаунта)
- меню;
- адрес и геолокация;
- часы работы;
- актуальные акции;
- ссылки и контакты.

3.3. Требования
- каждый аккаунт получает доступ только к своим данным;
- система не смешивает информацию разных ресторанов.

4. Хранение истории взаимодействий
4.1. Что фиксируется
- ID пользователя;
- тип события (комментарий, подписка, сторис);
- дата и время;
- сценарий автоматизации;
- факт и тип бонуса;
- статус обработки.

4.2. Назначение
- анти-фрод;
- контроль лимитов;
- персонализация;
- юридическая прозрачность.

5. Анти-фрод и защита от злоупотреблений
Обязательные механики:
- один бонус = один пользователь;
- лимиты по количеству действий;
- учёт частоты комментариев и упоминаний;
- блокировка сценариев при подозрении на накрутку.
Анти-фрод реализуется сквозным образом для всех автоматизаций.

6. Имитация человеческого поведения
Требования:
- рандомизация задержек ответов;
- лимиты сообщений в час и сутки;
- вариативность текстов;
- отсутствие массовых мгновенных реакций.
Цель: минимизация рисков теневого бана и блокировок.

7. Требования к реализации
- сценарии включаются и отключаются независимо;
- логика сценариев конфигурируема без переписывания всей системы;
- возможна последующая масштабируемость на новые аккаунты и рестораны.