Skip to main content

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):

  1. Повысить дисциплину заполнения CRM: Увеличить средний коэффициент качества (Кк) по отделу на 30% в течение 6 месяцев после запуска.

  2. Снизить потери проектов: Уменьшить количество «спящих» клиентов (нет активности >3 мес.) на 25% за квартал.

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

  4. Ускорить онбординг: Сократить среднее время выхода нового менеджера на стандартную продуктивность на 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. Технические ограничения

  1. Интеграция только через API Grace CRM. Прямого доступа к базе данных нет. API самописное, требуется тщательное изучение документации (ее наличие уточняется) и проведение стресс-тестирования.

  2. Миграция на 1С ЕРП. До 01.07.2026 учет производства ведется в ВМС, затем планируется переход. Модули, связанные с производственными сроками (фаза 2), должны проектироваться с учетом будущей миграции (абстрактный слой данных).

  3. Нормы времени в Excel. Интеграция с производственными нормативами отложена на фазу 2. В фазе 1 расчеты ведутся только на данных CRM.

  4. Производительность. Система должна работать с объемом данных: ~1000 клиентов, ~700 активных проектов, ~15 одновременных пользователей без деградации производительности.

4.2. Бизнес-ограничения и политики

  1. Поэтапность разработки:

    • Фаза 1 (MVP): Модуль продаж (пп. 3.1, 3.2, 3.3, 3.6). Запуск в пилот.

    • Фаза 2: Расширенная аналитика (п. 3.4), интеграция с нормативами из Excel, модуль для производства.

    • Фаза 3: Полноценная интеграция с 1С ЕРП, модуль проектирования.

  2. Конфиденциальность данных. Строгое разграничение доступа:

    • Менеджер: Видит только свои проекты, свою аналитику, свой прогноз премии.

    • РОП/Ведущий: Видит данные по своим подчиненным/направлению.

    • Зам. ГД: Имеет доступ ко всей аналитике, но без данных о персональных премиях менеджеров (только агрегаты).

    • Реализуется на уровне API-запросов и логики приложения.

  3. Регламент. Все бизнес-правила (правила проверки, формулы) должны быть вынесены в конфигурационные файлы или админ-панель для оперативного изменения без релизов.

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. Открытые вопросы

  1. API Grace CRM: Существует ли официальная документация? Поддерживаются ли вебхуки? Каков лимит запросов в минуту?

  2. Формула Кк: Финальная формула и веса для каждой проверки -- требует утверждения РОПом и Зам. ГД.

  3. Telegram-бот: Разрешено ли корпоративными политиками использование Telegram для рабочих уведомлений? Альтернатива -- корпоративный мессенджер.

  4. Хостинг: Определить конкретный сервер / инфраструктуру для деплоя (on-premise или корпоративное облако).

  5. Команда: Кто несёт ответственность за разработку -- внутренняя команда ООО «АйТек» или внешний подрядчик?

9.2. Следующие шаги

  • Согласовать PRD с РОПом, Зам. ГД и ключевыми менеджерами (до [дата]).

  • Провести spike по API Grace CRM -- 2-недельное исследование возможностей интеграции.

  • Уточнить формулу Кк и утвердить правила проверки у бизнеса.

  • Собрать команду и назначить Product Owner.

  • Запустить Спринт 1 после согласования технического задания.

Документ подготовлен на основе материалов: «Правила заполнения данных CRM-системы. Продажи» (24.06.2024), «Бонусная политика ITECH», внутренних интервью с РОПом и менеджерами.

No comments to display

Back to top