Product Requirements Document (PRD) AI-ассистент для менеджеров продаж ITECH (Grace CRM) Версия документа: 1.0 Дата: [Текущая дата] Автор: [Имя автора/Команда продукта] Статус: Черновик на согласование 1. Введение и обзор продукта 1.1. Видение продукта AI-ассистент для менеджеров продаж ITECH (далее -- Grace CRM Assistant) -- это мультиагентная система на базе больших языковых моделей (LLM), внедряемая поверх корпоративной CRM-системы Grace (grace.i-tech.su). В основе архитектуры -- набор специализированных AI агентов, каждый из которых обладает доступом к инструментам (tool calls), долгосрочной памятью и способностью к рассуждению (reasoning). Агенты автономно анализируют состояние проектов, формируют рекомендации, рассчитывают прогнозы и отправляют уведомления -- без ручной настройки правил. Со временем система накапливает паттерны успешных сделок компании и повышает качество рекомендаций. 1.2. Проблема и обоснование В ООО «АйТек» существуют следующие болевые точки в процессе продаж: Низкая дисциплина заполнения CRM: Неполные или неактуальные данные приводят к снижению коэффициента качества (Кк) и, как следствие, к потере части квартальной премии менеджерами. Отсутствие прозрачности в расчете премии: Менеджеры не имеют возможности в реальном времени отслеживать прогноз по своей квартальной премии, что демотивирует и не позволяет корректировать действия. Потеря проектов и клиентов: Из-за несвоевременных действий или отсутствия запланированного «следующего шага» проекты «зависают», а клиенты переходят в разряд «спящих» (>3 месяцев без активности). Длительное обучение новых менеджеров: Отсутствие встроенного обучающего модуля и четких подсказок по регламенту увеличивает время адаптации новых сотрудников. 1.3. Цели и задачи Основная цель продукта: Повысить эффективность работы отдела продаж ООО «АйТек» за счет автоматизации, аналитики и персонализированных рекомендаций на базе ИИ. Ключевые задачи (OKR): Повысить дисциплину заполнения CRM: Увеличить средний коэффициент качества (Кк) по отделу на 30% в течение 6 месяцев после запуска. Снизить потери проектов: Уменьшить количество «спящих» клиентов (нет активности >3 мес.) на 25% за квартал. Повысить прозрачность и мотивацию: Обеспечить 100% менеджеров доступом к прогнозу премии в реальном времени. Ускорить онбординг: Сократить среднее время выхода нового менеджера на стандартную продуктивность на 20%. 2. Анализ целевой аудитории 2.1. Пользователи и их роли Роль Количество Ключевые задачи в системе Ключевые потребности Менеджер по продажам ~10-15 чел. Ведение проектов, получение напоминаний, просмотр своего дашборда и прогноза премии, прохождение обучения. Четкие подсказки, простота интерфейса, мотивация через прозрачный расчет премии. Ведущий менеджер Несколько чел. Все функции менеджера + доступ к расширенной аналитике по своим проектам/клиентам. Углубленная аналитика, инструменты для наставничества. Руководитель отдела продаж (РОП) 1 чел. Мониторинг общей воронки, аналитика по эффективности команды, доступ ко всем данным о премиях (с разграничением). Обзорные дашборды, данные для планирования, выявление узких мест. Заместитель ГД по развитию 1 чел. Стратегический обзор воронки, прогноз выручки, анализ по ключевым клиентам. Высокоуровневая аналитика, прогнозные модели. 2.2. Контекст использования Рабочий инструмент: Grace CRM (через браузер) + уведомления в Telegram/e-mail. Окружение: Работа с ~1000 активными клиентами и ~700 проектами одновременно. Ключевой регламент: «Правила заполнения данных CRM-системы. Продажи» (утв. 24.06.2024). 3. Детальное описание основных функций (Core Features) 3.1. Мониторинг качества данных CRM Описание: Автоматический движок правил, который анализирует каждую запись о проекте в Grace CRM на предмет соответствия регламенту. Функциональные требования: Проверка обязательных полей: Клиент, Объект, Стадия, Следующий шаг, Дата следующего контакта/действия. Проверка актуальности: Дата следующего контакта не должна быть в прошлом. Проверка логики стадий (например, стадия «КП отправлено» не может быть без прикрепленного файла КП). Расчет персонального коэффициента качества (Кк) для каждого менеджера как отношения количества корректно заполненных проектов к общему числу активных проектов. Визуализация проблемных мест в интерфейсе (например, подсветка проектов с низким качеством). Бизнес-правила: Правила проверки должны быть настраиваемыми администратором без привлечения разработчиков (через админ-панель). 3.2. Умные напоминания и рекомендация «Следующего шага» Описание: Recommendation Agent -- LLM-агент, который по расписанию или по событию получает полный контекст проекта (стадия, история активностей, тип клиента, отрасль, прошлые коммуникации) и формулирует конкретное, аргументированное действие для менеджера на естественном языке. Функциональные требования: Агент вызывает инструменты ( get_project_context, get_activity_history, get_client_profile) и на их основе генерирует рекомендацию вида: «По проекту X для клиента Y (строительная отрасль, стадия "Переговоры") -- последний контакт 18 дней назад. Рекомендую: позвонить и уточнить статус решения по КП от 10.05, предложить пилотный запуск на одном объекте. Срок: до 15.05». Агент использует RAG по истории закрытых сделок: находит похожие по отрасли и стадии проекты из векторной памяти и учитывает, какие действия привели к успеху. Агент самостоятельно решает, требует ли ситуация эскалации к РОПу (просрочка > N дней, высокая сумма, риск потери клиента) -- и уведомляет его с кратким обоснованием. Каналы доставки: Telegram-бот (приоритет), e-mail, всплывающее окно в Grace CRM. 3.3. Калькулятор премии в реальном времени Описание: Модуль, отображающий прогноз квартальной премии для менеджера на основе актуальных данных CRM. Функциональные требования: Расчет по формуле: П = [Σ((Пр × Ку) - КРр)] × Кк, где: Пр -- плановая сумма проекта. Ку -- коэффициент уверенности (берется из стадии проекта в CRM). КРр -- коэффициент риска по проекту (может зависеть от типа клиента, условий). Кк -- коэффициент качества (из п. 3.1). Отображение текущего прогноза премии, разбивки по проектам, динамики изменения за неделю/месяц. Система доступа: Данные видны только самому менеджеру и его непосредственному руководителю (РОП). Для РОП -- виджет со сводкой по всем менеджерам. Возможность «посмотреть расчет» для каждого проекта (прозрачность формулы). 3.4. Аналитический дашборд воронки продаж Описание: Интерактивная панель визуализации ключевых метрик отдела продаж. Функциональные требования: Виджеты: Воронка продаж по стадиям в динамике. Распределение проектов и сумм по менеджерам. Топ-10 «спящих» клиентов (по длительности неактивности). Прогноз закрытий на текущий/следующий квартал (на основе Ку и дат). Динамика среднего Кк по отделу. Фильтры: по менеджеру, периоду, стадии, типу клиента. Возможность выгрузки отчетов в Excel/PDF. 3.5. Обучающий модуль Описание: Интегрированный в интерфейс помощник, помогающий освоить правила работы с CRM. Функциональные требования: База знаний: Структурированные статьи и видеоинструкции на основе «Правил заполнения...» от 24.06.2024. Интерактивные туры: Пошаговые подсказки при первом входе в систему или при открытии нового раздела. Примеры: Галерея «как правильно/как неправильно» заполнены карточки проектов. Тестирование: Тесты для новых менеджеров по завершении модулей. Результаты тестов доступны РОПу. 3.6. Интеграция с Grace CRM API Описание: Технический модуль, обеспечивающий двусторонний обмен данными. Функциональные требования: Чтение данных: Синхронизация справочников (клиенты, объекты, пользователи), проектов, статусов, истории активностей. Запись данных: Обновление полей (напр., Следующий шаг по рекомендации ассистента), добавление комментариев. Режим работы: Периодический полинг (раз в N минут) или вебхуки (если API Grace поддерживает). Отказоустойчивость: Очередь сообщений, логирование ошибок, механизм повторных попыток. 4. Технические и бизнес-ограничения 4.1. Технические ограничения Интеграция только через API Grace CRM. Прямого доступа к базе данных нет. API самописное, требуется тщательное изучение документации (ее наличие уточняется) и проведение стресс-тестирования. Миграция на 1С ЕРП. До 01.07.2026 учет производства ведется в ВМС, затем планируется переход. Модули, связанные с производственными сроками (фаза 2), должны проектироваться с учетом будущей миграции (абстрактный слой данных). Нормы времени в Excel. Интеграция с производственными нормативами отложена на фазу 2. В фазе 1 расчеты ведутся только на данных CRM. Производительность. Система должна работать с объемом данных: ~1000 клиентов, ~700 активных проектов, ~15 одновременных пользователей без деградации производительности. 4.2. Бизнес-ограничения и политики Поэтапность разработки: Фаза 1 (MVP): Модуль продаж (пп. 3.1, 3.2, 3.3, 3.6). Запуск в пилот. Фаза 2: Расширенная аналитика (п. 3.4), интеграция с нормативами из Excel, модуль для производства. Фаза 3: Полноценная интеграция с 1С ЕРП, модуль проектирования. Конфиденциальность данных. Строгое разграничение доступа: Менеджер: Видит только свои проекты, свою аналитику, свой прогноз премии. РОП/Ведущий: Видит данные по своим подчиненным/направлению. Зам. ГД: Имеет доступ ко всей аналитике, но без данных о персональных премиях менеджеров (только агрегаты). Реализуется на уровне API-запросов и логики приложения. Регламент. Все бизнес-правила (правила проверки, формулы) должны быть вынесены в конфигурационные файлы или админ-панель для оперативного изменения без релизов. 5. Соображения по реализации 5.1. Мультиагентная архитектура Система построена на фреймворке Agno (Python). Agno реализует концепцию Agent Teams: каждый агент -- объект класса Agent с декларативно заданными инструментами, памятью и базой знаний; команда агентов управляется объектом Team, который маршрутизирует задачи и объединяет результаты. ┌────────────────────────────────────────────────────────┐│             Sales Team (agno.Team)                   ││   mode=coordinate │ leader: Orchestrator Agent       │└──────┬──────────┬──────────┬──────────┬───────────────┘       │         │         │         │┌──────▼──┐ ┌────▼────┐ ┌───▼───┐ ┌───▼──────────┐│ CRM   │ │ Recom- │ │ Bonus │ │ Notification ││ Monitor │ │mendation│ │ Calc. │ │   Agent     ││ Agent │ │ Agent │ │ Agent │ │(TG / e-mail) │└──────┬──┘ └────┬────┘ └───┬───┘ └──────────────┘       │         │         │┌──────▼──────────▼──────────▼──────────────────────────┐│             Tool Layer (agno.tools + custom)       ││ Grace CRM API │ PostgreSQL (agno.storage) │ pgvector ││               │ (agno.knowledge / RAG)               │└───────────────────────────────────────────────────────┘ Агенты системы ( agno.Agent): Агент Роль Инструменты (tools) LLM Orchestrator Agent Лидер Team: принимает входящую задачу, делегирует агентам, агрегирует результат; при критических ситуациях инициирует эскалацию к РОПу schedule_task, route_to_agent, escalate_to_rop GPT-4o CRM Monitor Agent Проверяет каждый проект на соответствие регламенту, рассчитывает персональный Кк get_projects, check_required_fields, update_kk_score, flag_project GPT-4o-mini Recommendation Agent Анализирует контекст проекта, ищет паттерны успешных сделок через agno.knowledge (pgvector RAG), генерирует рекомендацию следующего шага get_project_context, get_activity_history, vector_search_similar_deals, write_recommendation GPT-4o Bonus Calc Agent Детерминированный расчёт прогноза квартальной премии по формуле П = [Σ((Пр × Ку) − КРр)] × Кк; LLM используется только для форматирования объяснения get_manager_projects, get_kk_score, get_stage_coefficients, calculate_bonus GPT-4o-mini Notification Agent Форматирует и доставляет сообщения в Telegram / e-mail; адаптирует стиль под роль получателя send_telegram, send_email, format_message_for_role GPT-4o-mini Ключевые возможности Agno, используемые в проекте: agno.storage .PostgresStorage -- персистентная структурированная память агентов (история сессий, кэш CRM-данных, расчёты Кк). agno.knowledge.PgVector2 -- векторная база знаний на pgvector: закрытые сделки и успешные паттерны переговоров для RAG в Recommendation Agent. agno.Team (mode="coordinate") -- Orchestrator делегирует подзадачи агентам и собирает единый ответ. Встроенный мониторинг -- Agno natively интегрируется с agno.io для трейсинга вызовов агентов и просмотра истории сессий. Типы памяти агентов: Краткосрочная (in-context / AgentMemory): история текущей сессии агента, хранится в PostgresStorage. Долгосрочная (векторная, PgVector2): закрытые сделки, удачные рекомендации, паттерны успешных переговоров -- используется Recommendation Agent через RAG. Структурированная (PostgreSQL): кэш данных Grace CRM, расчёты Кк, история уведомлений, конфигурации правил. 5.2. Высокоуровневая архитектура системы Бэкенд: Python 3.12 + FastAPI. Агентный фреймворк -- Agno ( agno.Agent, agno.Team). Планировщик агентных задач -- Celery Beat. Фронтенд: React 18 + TypeScript. Встраивается в Grace CRM как iframe или отдельный портал. Адаптивный дизайн. База данных: PostgreSQL 16 + расширение pgvector (векторная база знаний через agno.knowledge.PgVector2). agno.storage .PostgresStorage -- для персистентной памяти агентов. LLM провайдеры: OpenAI GPT-4o / GPT-4o-mini (основной), Google Gemini 1.5 Pro (резервный). Agno поддерживает оба провайдера нативно -- переключение без изменения логики агентов. Очередь задач: Celery + Redis -- фоновые запуски агентных задач по расписанию и по событиям из Grace CRM. Уведомления: Telegram Bot API (приоритет); SMTP для e-mail резерва. Деплой: Docker Compose на внутреннем сервере компании (on-premise). CI/CD через GitLab CI. 5.3. Технологический стек Слой Технология Обоснование Агентный фреймворк Agno ( agno.Agent, agno.Team) Лёгкий, Pythonic API; нативная поддержка Teams, pgvector RAG, PostgreSQL storage; встроенный мониторинг через agno.io LLM (основной) OpenAI GPT-4o / GPT-4o-mini Function calling, высокое качество reasoning, tool use; нативная интеграция в Agno LLM (резервный) Google Gemini 1.5 Pro Fallback при недоступности OpenAI; нативная интеграция в Agno Векторная БД pgvector + agno.knowledge.PgVector2 RAG по истории сделок без отдельного сервиса; управляется через Agno из коробки Хранилище агентов agno.storage .PostgresStorage Персистентная память сессий агентов в PostgreSQL Бэкенд Python 3.12 + FastAPI Async, нативная совместимость с Agno Фронтенд React 18 + TypeScript Компонентность, скорость разработки UI-библиотека Ant Design Таблицы, дашборды, форм-контролы из коробки Реляционная БД PostgreSQL 16 Хранение кэша CRM, логов, истории уведомлений Кеш / очередь Redis 7 + Celery Планировщик запуска агентов, кеш справочников Интеграция с Grace REST API (HTTP/JSON) Единственный поддерживаемый канал доступа Уведомления python-telegram-bot Telegram-бот для менеджеров Наблюдаемость agno.io + Sentry Встроенный трейсинг вызовов агентов; мониторинг ошибок Деплой Docker Compose Простота развёртывания on-premise 5.4. Безопасность и разграничение доступа Аутентификация: SSO через существующую корпоративную систему (LDAP/AD) или собственный JWT с 2FA для администраторов. Авторизация (RBAC): Роли -- manager, senior_manager, rop, deputy_gd, admin. Доступ к данным фильтруется на уровне API-запросов, а не только UI. Шифрование: HTTPS (TLS 1.3) для всего трафика. Пароли и API-ключи хранятся в переменных окружения ( .env, Vault) -- не в коде. Логирование: Все действия пользователей (просмотр премий, изменение правил) фиксируются в audit log с timestamp и user_id. Персональные данные: Данные о премиях -- конфиденциальные. Передача третьим лицам запрещена. Хранятся только агрегированные данные для аналитики Зам. ГД. Защита от инъекций: Все входные данные валидируются через Pydantic. Parameterized queries для всех SQL-запросов. 6. Дорожная карта (Roadmap) Фаза 1 -- MVP (срок: 2–3 месяца после старта) Цель: Запустить в пилот ключевые модули для отдела продаж. Спринт Задачи Спринт 1–2 Изучение API Grace CRM. Разработка схемы БД. Базовая аутентификация. Docker-окружение. Спринт 3–4 Модуль синхронизации данных с Grace CRM (п. 3.6). Расчёт Кк (п. 3.1). Спринт 5–6 Калькулятор премии (п. 3.3). Умные напоминания и Telegram-бот (п. 3.2). Спринт 7–8 Фронтенд: личный дашборд менеджера, виджет Кк, прогноз премии. Тестирование. Пилот. Критерии готовности MVP: Все менеджеры могут видеть свой Кк и прогноз премии. Telegram-уведомления работают. Синхронизация с Grace без ошибок > 48 часов. Фаза 2 -- Расширенная аналитика (срок: 2–3 месяца после MVP) Аналитический дашборд воронки продаж (п. 3.4) для РОП и Зам. ГД. Обучающий модуль (п. 3.5): база знаний, интерактивные туры. Расширенная фильтрация и выгрузка отчётов (Excel/PDF). Первые ML-эксперименты: предсказание вероятности закрытия сделки. Фаза 3 -- Интеграция с 1С ЕРП (срок: после 01.07.2026) Подключение к 1С ЕРП для учёта производственных норм и сроков. Расширение калькулятора премии с учётом производственных коэффициентов. Модуль проектирования и контроля производственных этапов. Полноценная интеграция с нормативной базой (Excel -> 1С ЕРП). 7. Метрики успеха 7.1. Ключевые показатели эффективности (KPI) Метрика Базовое значение Целевое значение Срок Средний Кк по отделу < 0.7 (оценка) ≥ 0.91 +6 мес. после запуска Доля менеджеров с Кк ≥ 0.85 < 50% ≥ 80% +3 мес. Количество «спящих» клиентов (>3 мес.) Базовый замер −25% +1 квартал Время выхода нового менеджера на норму ~3 месяца ≤ 2.5 месяца +6 мес. Доля менеджеров, использующих систему ежедневно 0% ≥ 85% +2 мес. после запуска Количество ошибок синхронизации с Grace CRM -- < 0.1% запросов Постоянно 7.2. Метрики качества продукта Доступность системы: ≥ 99.5% uptime в рабочие часы (Пн–Пт, 8:00–20:00 МСК). Время отклика API: P95 < 500 мс для всех эндпоинтов. Точность расчёта Кк: 100% соответствие ручному расчёту по регламенту (верифицируется на тестовых наборах). NPS системы: Опрос менеджеров через 3 месяца после запуска -- цель NPS ≥ 30. 8. Риски и митигация # Риск Вероятность Влияние Митигация R1 API Grace CRM закрытое / плохо документированное Высокая Критическое Провести spike (2 недели) на изучение API до старта разработки. Предусмотреть прямой SQL-доступ как fallback (согласовать с вендором). R2 Сопротивление менеджеров внедрению (change management) Средняя Высокое Вовлечь 2–3 «чемпионов» из команды продаж на этапе дизайна. Показать прямую выгоду через прозрачность премии. R3 Изменение формулы расчёта премии / регламента CRM Средняя Среднее Вынести все бизнес-правила в конфигурационные файлы. Обеспечить возможность изменений без релизов. R4 Задержка миграции на 1С ЕРП (>01.07.2026) Средняя Низкое Фаза 3 не входит в MVP. Архитектура фазы 1–2 проектируется с абстрактным слоем данных. R5 Нехватка ресурсов разработки Средняя Высокое Зафиксировать минимальный состав команды (1 бэкенд + 1 фронтенд + 1 PM/аналитик) до старта. R6 Утечка конфиденциальных данных о премиях Низкая Критическое Строгий RBAC, аудит-лог, тестирование безопасности перед запуском. Принцип минимальных прав. 9. Открытые вопросы и следующие шаги 9.1. Открытые вопросы API Grace CRM: Существует ли официальная документация? Поддерживаются ли вебхуки? Каков лимит запросов в минуту? Формула Кк: Финальная формула и веса для каждой проверки -- требует утверждения РОПом и Зам. ГД. Telegram-бот: Разрешено ли корпоративными политиками использование Telegram для рабочих уведомлений? Альтернатива -- корпоративный мессенджер. Хостинг: Определить конкретный сервер / инфраструктуру для деплоя (on-premise или корпоративное облако). Команда: Кто несёт ответственность за разработку -- внутренняя команда ООО «АйТек» или внешний подрядчик? 9.2. Следующие шаги Согласовать PRD с РОПом, Зам. ГД и ключевыми менеджерами (до [дата]). Провести spike по API Grace CRM -- 2-недельное исследование возможностей интеграции. Уточнить формулу Кк и утвердить правила проверки у бизнеса. Собрать команду и назначить Product Owner. Запустить Спринт 1 после согласования технического задания. Документ подготовлен на основе материалов: «Правила заполнения данных CRM-системы. Продажи» (24.06.2024), «Бонусная политика ITECH», внутренних интервью с РОПом и менеджерами.