Fairflow — Полная спецификация бизнес-процесса (v5.2)¶
Цель документа: описать систему Fairflow как проектно-центричную модульную CRM-платформу с чётким разделением ролей, типов аккаунтов, доступов и настраиваемых бизнес-процессов. Документ описывает только бизнес-логику — без привязки к конкретной реализации frontend или backend.
Версия: 5.2 Статус: рабочий черновик
1. Общее описание системы¶
Fairflow — проектно-центричная модульная CRM-платформа, в которой вся работа с клиентами, сделками и данными организована вокруг проектов. Проект является основной единицей изоляции данных и масштабирования.
1.1 Ключевые принципы¶
- Проект = центр всего. Все CRM-данные живут внутри проекта и изолированы от других проектов.
- Модульность. Каждый проект включает только нужные модули. Ненужные отключаются.
- Deal-centric продажи. Единая сущность «Сделка» движется по настраиваемой воронке. Лиды, заявки, продажи — это стадии, а не отдельные сущности.
- Order-centric исполнение. Тип продукта определяет процесс оформления (тип продажи): поля, этапы, документы, интеграции.
- Чистая база. Контакты и компании создаются явно, не автоматически из каждого обращения.
- Каждая запись имеет владельца. Сущности всегда привязаны к человеку или отделу — никогда не висят «ни у кого».
1.2 Два режима работы¶
- Индивидуальный — физическое лицо использует платформу самостоятельно или с приглашёнными участниками.
- Корпоративный — организация (юридическое лицо) использует платформу как рабочее пространство для команды сотрудников.
2. Глоссарий¶
| Термин | Определение |
|---|---|
| Пользователь (User) | Физическое лицо, зарегистрированное в системе. Имеет один аккаунт. |
| Аккаунт (Account) | Учётная запись пользователя. Всегда принадлежит физическому лицу. |
| Организация (Organization) | Юридическое лицо / ИП. Корпоративное рабочее пространство с сотрудниками и лицензиями. |
| Пространство (Workspace) | Контекст владения проектами: личное пространство пользователя или пространство организации. |
| Проект (Project) | Центральная сущность системы. Все CRM-данные привязаны к проекту. Имеет настраиваемый набор модулей. |
| Модуль (Module) | Функциональный блок CRM, включается/выключается per-project. |
| Сделка (Deal) | Универсальная сущность продажи. Проходит через стадии воронки. Заменяет лиды, заявки, продажи. |
| Воронка (Pipeline) | Настраиваемая последовательность стадий для сделок. |
| Продажа (Order) | Процесс исполнения/оформления. Создаётся из сделки. Форма и этапы определяются типом продажи. |
| Тип продажи (Order Type) | Шаблон процесса оформления: кастомные поля, этапы, документы, финальные действия. Привязывается к продукту. |
| Контакт (Contact) | Физическое лицо в базе CRM. Создаётся явно, не автоматически. Может быть связан с несколькими компаниями (many-to-many). |
| Компания (Company) | Юридическое лицо / организация клиента. Может быть связана с несколькими контактами (many-to-many). |
| Drawer | Глобальная боковая панель для быстрого создания CRM-сущностей. Один drawer без вложенности, с выпадающими списками для связанных сущностей. |
| Лицензия | Единица тарификации в организации. Одна лицензия = одно место для сотрудника. |
| Шаблон проекта (Project Template) | Преднастроенная конфигурация: набор модулей, воронка, типы продаж. |
3. Типы аккаунтов и жизненный цикл¶
3.1 Способы появления аккаунта¶
Путь 1: Самостоятельная регистрация
→ Полноценный аккаунт физлица
→ Может создавать личные проекты
→ Может создать организацию
→ Может быть приглашён в чужую организацию (сохраняя личные проекты)
→ Флаг «Создание личных проектов» = ДА
Путь 2: Приглашение в организацию
→ Аккаунт привязан к организации
→ Работает только внутри проектов организации (по умолчанию)
→ Флаг «Создание личных проектов» = НЕТ
→ Администратор организации может изменить этот флаг
3.2 Флаг «Создание личных проекто⻶
Управляет только возможностью создания новых личных проектов. Существующие личные проекты остаются доступными независимо от значения флага.
| Сценарий | Значение | Кто управляет |
|---|---|---|
| Самостоятельная регистрация | ДА | Всегда ДА, нельзя отключить себе |
| Приглашение (новый пользователь) | НЕТ | Администратор организации |
| Приглашение (существующий пользователь) | ДА (сохраняется) | Администратор может отключить |
| Сотрудник удалён из организации | ДА (автоматически) | Система |
При отключении флага: - Существующие личные проекты продолжают работать. - Кнопка «Создать проект» в личном пространстве исчезает.
3.3 Конвертация аккаунта¶
| Направление | Что с проектами |
|---|---|
| Физлицо → Юрлицо | Личные проекты остаются. Новые создаются в пространстве организации. Данные из личных проектов можно импортировать. |
| Юрлицо → Физлицо | Недоступно. Организация может быть только деактивирована. |
3.4 Удаление сотрудника из организации¶
Сотрудник удалён:
├── Теряет доступ ко ВСЕМ проектам организации
├── Записи сотрудника переназначаются ПО КАЖДОМУ ПРОЕКТУ ОТДЕЛЬНО:
│ ├── Руководитель отдела ЕСТЬ в этом проекте?
│ │ ├── Да → записи переназначаются ему
│ │ └── Нет → записи получают статус «Требует переназначения»
│ │ ├── Project Admin получает уведомление
│ │ ├── Записи видны Project Admin и Project Owner
│ │ ├── В списках сделок/продаж — фильтр «Без владельца»
│ │ └── Переназначение через bulk action или вручную
│ └── Записи НИКОГДА не передаются за пределы проекта (изоляция)
├── Данные организации недоступны
├── Аккаунт переходит в режим «Физическое лицо»
├── Флаг «Создание личных проектов» → ДА
├── Лицензия освобождается
└── Может войти в систему, создать свои проекты, быть приглашён в другую организацию
4. Авторизация и аутентификация¶
4.1 Маршруты¶
| URL | Экран |
|---|---|
/ |
Landing (редирект в /home при активной сессии) |
/auth/signin |
Sign In |
/auth/signup |
Sign Up |
/auth/signup/organization |
Org Setup (шаг 2) |
/auth/forgot-password |
Forgot Password |
/auth/reset-password/:token |
Reset Password |
/auth/verify-email/:token |
Verify Email |
/auth/2fa |
Two-Factor Auth |
/auth/invite/:token |
Accept Invitation |
4.2 Процесс входа¶
1. Email + пароль
2. Если 2FA → /auth/2fa
3. Определение контекста (организации, проекты, пространства)
4. Редирект:
├── Есть проекты → последний активный → /home
├── Нет проектов, флаг = ДА → онбординг / создание проекта
└── Нет проектов, флаг = НЕТ → заглушка «Вы не добавлены ни в один проект»
4.3 Регистрация¶
Физлицо:
/auth/signup → имя, email, пароль → подтверждение email
→ /onboarding/profile → /onboarding/first-project → /home
Юрлицо:
/auth/signup → имя, email, пароль → подтверждение email
→ /auth/signup/organization (реквизиты)
→ /onboarding/profile → /onboarding/first-project → /onboarding/invite-team → /home
По приглашению (новый):
/auth/invite/:token → регистрация (имя, пароль; email предзаполнен)
→ /onboarding/profile (краткий)
→ Авто-добавление в организацию + проекты → /home
Флаг = НЕТ (по умолчанию)
По приглашению (существующий):
/auth/invite/:token → вход → подтверждение → добавление в организацию
Личные проекты сохраняются. Флаг = ДА.
4.4 Онбординг¶
| URL | Когда |
|---|---|
/onboarding/profile |
После любой регистрации |
/onboarding/first-project |
После самостоятельной регистрации |
/onboarding/invite-team |
При создании организации |
4.5 Заглушка «Нет проекто⻶
Пользователь приглашён в организацию, но не назначен ни в один проект (флаг = НЕТ): - Показывается экран: «Вы ещё не добавлены ни в один проект. Обратитесь к администратору.» - Доступны: Профиль, Безопасность. - Недоступны: Портфель, Проекты (пустой список).
5. Модель пространств и владения проектами¶
5.1 Два типа пространств¶
Личное пространство Пространство организации
──────────────────── ─────────────────────────
Владелец = физлицо Владелец = организация
Проекты создаёт владелец Проекты создают PO / PA
В проект — ЛЮБОЙ пользователь В проект — ТОЛЬКО сотрудники
Лимит участников по тарифу Лимит сотрудников по лицензии
Данные между проектами НЕ передаются Данные МОЖНО передавать
Биллинг = личная подписка Биллинг = лицензия организации
Биллинг личного и корпоративного пространства полностью независим. Проблемы с личной подпиской никак не влияют на работу в проектах организации и наоборот.
5.2 Селектор проекта (шапка)¶
▼ Выбор проекта
┌──────────────────────────────────────────┐
│ Личные проекты [+ ◊] │ ← [+] если флаг = ДА
│ ◉ Фриланс │
│ ○ Консалтинг │
├──────────────────────────────────────────┤
│ Альфа Групп [+ ◊] │ ← [+] если PO/PA
│ ○ Продажи CIS │
│ ○ Маркетинг EU │
├──────────────────────────────────────────┤
│ Бета ООО │ ← нет [+]
│ ○ Партнёрка │
└──────────────────────────────────────────┘
5.3 Обмен данными между проектами организации¶
Правила:
• Только между проектами ОДНОЙ организации
• Личные проекты НЕ участвуют
• Инициировать может Manager и выше
• После передачи объекты живут независимо
• Изменения в целевом проекте НЕ синхронизируются с исходным
5.4 Матрица передачи: что копируется, что нет¶
| Сущность | Копируется? | Почему |
|---|---|---|
| Сделка | ✅ | Основная сущность передачи |
| Лёгкие контактные поля | ✅ | Часть сделки (имя, телефон, email, название компании) |
| Источник сделки | ✅ | Текстовое поле, часть сделки |
| Lineage-данные | ✅ | origin_project_id, origin_entity_id, snapshot_version, кто/когда |
| Контакт | ❌ | Привязка в целевом проекте вручную |
| Компания | ❌ | Привязка в целевом проекте вручную |
| Продажи | ❌ | Привязаны к Order Type проекта-источника, которого может не быть в целевом |
| Продукты | ❌ | Каталог продуктов per-project |
| Активности | ❌ | Задачи/звонки/встречи остаются в исходном проекте |
| Документы | ❌ | Привязаны к продажим и проекту-источнику |
5.5 Поведение переданной сделки в целевом проекте¶
Сделка приходит в целевой проект "чистой":
├── С лёгкими контактными данными (имя, телефон, email)
├── С lineage-ссылкой на исходный проект
├── Без продаж, продуктов, активностей, документов
├── Попадает на ПЕРВУЮ СТАДИЮ воронки целевого проекта
├── Помечена меткой «Передана из проекта "X"»
└── В исходном проекте: статус «Передан» + ссылка на целевой
Подсказка контактов:
├── Система ищет совпадения по лёгким полям (email, телефон, имя)
│ среди контактов/компаний целевого проекта
├── Если найдено → «Привязать к существующему контакту Иванов И.И.?»
├── Если не найдено → менеджер создаёт нового (с проверкой дублей)
└── Далее менеджер добавляет продукты из каталога целевого проекта
Менеджер работает с переданной сделкой как с обычной:
привязывает контакт → добавляет продукты → двигает по воронке → создаёт продажаы
Эволюционный путь: - v1: копия сделки + lineage-ссылка, подсказка контактов по лёгким полям. Дедупликация только внутри проекта. - v2+: opt-in «Org Master Data» — глобальный каталог контактов с кросс-проектной дедупликацией (на базе identity_hash).
6. Проектно-центричная архитектура¶
6.1 Модульная архитектура¶
ЯДРО (всегда включено):
├── Дашборд
├── Статистика
└── Настройки проекта / Участники / Роли / Политики доступа
БАЗОВЫЕ МОДУЛИ (включаются/выключаются per-project):
├── 👥 Контакты
├── 🏢 Клиенты (компании)
├── 💰 Сделки (воронки, канбан)
├── 🛒 Продажи (типы продаж, этапы, канбан)
├── 📋 Активности (задачи, звонки, встречи, календарь)
├── 📦 Продукты (каталог, прайсы, привязка к типам продаж)
├── 📊 Отчёты (аналитика, конструктор)
├── 📄 Документы (документы, шаблоны с подстановкой)
└── ⚡ Автоматизация (триггеры, правила, действия)
Если модуль отключён — скрывается не только пункт меню, но и все связанные поля и настройки в других разделах (Contextual UI). Отключение НЕ удаляет данные — при включении обратно всё доступно.
6.2 Шаблоны проектов¶
При создании проекта — выбор из списка базовых шаблонов:
Создание проекта:
Шаг 1 → Выберите шаблон из списка
Шаг 2 → Название, описание
Шаг 3 → Подтверждение модулей (можно изменить)
Шаг 4 → Приглашение участников
Базовые шаблоны v1 (5 штук, захардкожены):
| Шаблон | Модули | Воронка |
|---|---|---|
| Продажи B2B | Контакты, Клиенты, Сделки, Продукты, Продажи, Активности, Документы, Отчёты | Обращение → Квалификация → КП → Переговоры → Согласование → Оформление |
| Колл-центр | Контакты, Сделки, Активности, Отчёты | Входящий → Обработка → Квалификация → Передан в продажи |
| Автосалон | Контакты, Клиенты, Сделки, Продукты, Продажи, Активности, Документы, Отчёты | Обращение → Показ → Тест-драйв → КП → Trade-in → Сделка → Выдача |
| Доставка | Контакты, Сделки, Продукты, Продажи, Отчёты | Заявка → Подтверждение → Готовится → В пути → Доставлен |
| По умолчанию | Контакты, Клиенты, Сделки, Активности, Отчёты | Новая → В работе → Завершена |
Шаблон предзаполняет модули и воронку. Всё можно изменить после создания. В будущих версиях — возможность пользователю сохранить свой проект как шаблон.
6.3 Жизненный цикл проекта¶
Создание → Настройка → Работа → Архивация (read-only) → Удаление
Архивация проекта: - Все данные переходят в read-only (включая незавершённые продажаы). - Webhook'и и автоматизации останавливаются. - Статусы сущностей фиксируются «как есть». - Разархивация возможна (Project Owner).
7. Сделки и воронки (Deal-centric продажи)¶
7.1 Сделка — универсальная сущность продажи¶
Лиды, заявки, продажи — НЕ отдельные сущности. Это сделка на разных стадиях воронки.
7.2 На кого создаётся сделка¶
Сделка может быть создана: - На компанию — основной сценарий B2B. Контактное лицо подтягивается. - На контакт (физлицо) — если клиент = физическое лицо без компании.
Связь Контакт ↔ Компания = many-to-many: один контакт может работать в нескольких компаниях, одна компания может иметь несколько контактов.
7.3 Встроенные контактные данные (лёгкие поля)¶
Сделка содержит встроенные поля для быстрого ввода: - Имя контакта, телефон, email, название компании (текстом). - Это НЕ запись в базе контактов. Просто поля сделки.
Полноценный контакт/компания в базе создаётся явно: - Вручную: менеджер нажимает «Создать контакт/компанию из сделки». - Автоматически: при переходе на стадию воронки (настраивается).
7.4 Проверка дублей при квалификации¶
При создании контакта/компании из сделки система проверяет: - Контакт: email, телефон (нормализованный). - Компания: ИНН, домен email, название. - Лиды (сделки): проверка на дубли по контактным данным.
Результат проверки:
├── Совпадений нет → создаётся новая запись
├── Найдено совпадение → «Похожий контакт/компания уже существует. Привязать?»
│ ├── Да → сделка привязывается к существующему
│ └── Нет, это другой → создаётся новая запись
└── При повторном обращении: система авто-привязывает сделку к существующему контакту
В истории контакта добавляется запись о привязке новой сделки (событие + время + кто + данные).
7.5 Снимок контактных данных (Drift Detection)¶
При привязке контакта или компании к сделке система создаёт снимок ключевых полей на связи. Если данные контакта/компании позже изменятся — в карточке сделки отображается предупреждение.
Три слоя контактных данных:
Слой 1: Лёгкие поля сделки (текст)
«Иванов, +79205434343, ivan@mail.com»
Заполняются при создании сделки. НЕ меняются.
Не связаны с записью в базе контактов.
Нужны для быстрого ввода до квалификации.
Слой 2: Ссылка на контакт/компанию (живая)
deal.contact_id → Contact #42
Всегда показывает АКТУАЛЬНЫЕ данные.
Появляется после квалификации / ручной привязки.
Слой 3: Снимок на связи (drift detection)
deal_contact_link.snapshot = { name, phone, email, linked_at }
Хранится на связи между сделкой и контактом.
Сравнивается с текущим состоянием Contact #42.
Если есть расхождение → предупреждение в UI.
Поведение в UI:
Вариант А (данные не изменились):
Иванов Иван Иванович
+7 920 543-43-43
ivan@mail.com
Вариант Б (данные изменились после привязки):
Иванов Иван Иванович
+7 916 123-45-67 ⚠ изменён
ivan@mail.com
⚠ Данные контакта изменены после привязки к сделке
Телефон: +79205434343 → +79161234567 (Петрова, 15 янв)
[Принять изменения] [Открыть контакт]
«Принять изменения» — обновляет снимок до текущих данных. Предупреждение исчезает. В аудите — запись «подтверждение изменений контакта».
Приоритеты: - Продажа → Контакт/Компания: Must Have (данные критичны для документов и webhook) - Сделка → Контакт/Компания: Should Have
Подробнее: раздел 9.6.
7.6 Воронка (Pipeline)¶
Воронка — настраиваемая последовательность стадий для сделок.
Настройки воронки:
├── Стадии (название, порядок, цвет)
├── Ответственные по стадиям (отдел / роль)
├── Источники сделок (настраиваемый справочник)
│ ├── Яндекс.Директ, Google Ads, Сайт, Телефония
│ ├── Email-рассылка, Рекомендация, Холодный обзвон
│ └── + Добавить свой
└── Авто-создание контакта (на какой стадии, или «не создавать»)
Воронка для сделок, этапы для продаж — это разные механики:
Воронка сделки = ПРОДАЖА (дожим)
Канбан-доска: drag & drop по стадиям
Результат: клиент согласен → создаётся продажа(ы)
Этапы продажи = ИСПОЛНЕНИЕ (оформление)
Настраиваются внутри Order Type (шаблона продажи)
Канбан-доска тоже доступна (включается в настройках модуля Продажи)
Результат: продукт оформлен/выдан/подключён
7.7 Тайминги стадий и лог переходов¶
Система ведёт полный лог входов на каждую стадию. Каждый переход (включая возврат назад) — новая запись.
Хранение:
deal_stage_entered_at — когда сделка перешла на ТЕКУЩУЮ стадию (последний вход)
stage_log — полный лог всех переходов:
[
{ stage: "КП", entered_at: Jan 10, exited_at: Jan 15 },
{ stage: "Согласование", entered_at: Jan 15, exited_at: Jan 20 },
{ stage: "КП", entered_at: Jan 20, exited_at: null } ← возврат
]
Для продаж — аналогично: order_stage_entered_at + stage_log.
Поведение при возврате на предыдущую стадию:
├── Создаётся НОВАЯ запись в stage_log (не стирает историю)
├── deal_stage_entered_at обновляется на текущий момент
└── Таймер стадии считается с последнего входа
Использование в v1:
├── «Текущий срок на стадии» = с последнего входа (deal_stage_entered_at)
├── «Суммарное время на стадии КП» = сумма всех периодов на КП
├── «Количество возвратов» = сколько раз сделка возвращалась назад
├── Отчёт «Зависшие сделки» (> N дней без движения)
└── Фильтр «На стадии более X дней» в списках и канбане
Использование в v2+:
├── SLA per-стадия (настраиваемые лимиты времени)
├── Автоматические предупреждения при приближении к лимиту
├── Эскалация при превышении SLA
└── SLA-индикаторы в канбане (светофор: зелёный/жёлтый/красный)
8. Продажи и типы продаж (Order-centric исполнение)¶
8.1 Продажа создаётся из сделки¶
Когда сделка доходит до стадии «клиент согласен» — менеджер создаёт продажа(ы). Тип продажи определяется продуктом.
8.2 Тип продажи (Order Type)¶
Тип продажи — конфигурируемый шаблон процесса оформления:
Тип продажи содержит:
├── Название
├── Кастомные поля (конструктор форм)
│ ├── Тип: текст / число / дата / выбор / файл / чекбокс
│ ├── Обязательность
│ ├── Значение по умолчанию
│ └── Валидация
├── Этапы оформления (статусная модель)
│ ├── Название этапа
│ ├── Условия перехода
│ └── Действия при переходе
├── Шаблоны документов (с переменными для подстановки)
├── Финальное действие (webhook / email / задача / ничего)
│ └── Обработка ошибок — индивидуально для каждого шаблона (см. 8.7)
└── Версия схемы (schema_version)
8.3 Связь: Продукт → Тип продажи → Продажа¶
Продукт «ЗП Премиум»
└── Тип продажи = «Зарплатный проект»
Сделка «Банк Ромашка» (стадия: согласовано)
└── «Создать продажу» → система видит продукт → подставляет тип продажи
→ динамическая форма с полями этого типа
8.4 Одна сделка — несколько продаж¶
Сделка «Банк Ромашка — комплекс услуг»
├── Продажа #1: Зарплатный проект (тип: ЗП) → свои поля, этапы, webhook
└── Продажа #2: РКО (тип: РКО) → свои поля, этапы, webhook
Каждый продажа независим: свой статус, свой ответственный.
8.5 Канбан для продаж¶
Продажи тоже можно просматривать как канбан-доску по этапам (аналогично сделкам по стадиям воронки). Включается в настройках модуля Продажи.
/p/:pid/orders → список продаж (по умолчанию)
/p/:pid/orders/kanban → канбан по этапам (опционально)
8.6 Версионирование типов продаж¶
Типы продаж версионируются для обратной совместимости:
OrderType хранит schema_version.
Каждый Order хранит order_type_version (на момент создания).
Новые обязательные поля применяются только к новым продажим.
Для старых — поле nullable или со значением по умолчанию.
Детальная стратегия версионирования будет проработана отдельно
с учётом всех сценариев работы с версиями шаблонов.
8.7 Снимок контактных данных для продаж (Drift Detection)¶
Для продаж drift detection критически важен: данные контакта и компании подставляются в шаблоны документов и финальные действия (webhook). Если реквизиты изменились после создания продажи — это может привести к ошибкам в документах.
Поведение для продаж:
├── При создании продажи: снимок контакта и компании фиксируется
├── При изменении данных контакта/компании:
│ ├── В карточке продажи: ⚠ «Реквизиты компании изменены»
│ ├── При генерации документа: предупреждение перед генерацией
│ │ «Реквизиты компании изменились с момента создания продажи.
│ │ Проверьте данные перед генерацией документа.»
│ └── При финальном действии (webhook): предупреждение
└── Действие: «Принять изменения» → снимок обновляется
Подробнее: раздел 9.6.
8.8 Отказоустойчивость финальных действий (DLQ)¶
Финальные действия продаж (webhook, email) могут завершиться ошибкой (внешняя система недоступна, таймаут, 5xx, невалидные данные).
Механизм Dead-Letter Queue (DLQ):
├── При ошибке финального действия:
│ ├── Retry policy (настраивается per Order Type)
│ │ ├── Количество повторов
│ │ ├── Интервал (экспоненциальная задержка)
│ │ └── Максимальное время ожидания
│ ├── После исчерпания попыток → статус «Ошибка отправки»
│ │ ├── Продажа помечен на канбане (визуально выделен)
│ │ ├── Уведомление ответственному менеджеру
│ │ └── Кнопка «Повторить отправку» (Manager+)
│ └── Логирование: каждая попытка, код ответа, тело ошибки
│
├── Редактирование в статусе «Ошибка отправки»:
│ ├── Менеджер МОЖЕТ редактировать поля продажи
│ │ (ошибка может быть из-за невалидных данных — опечатка в ИНН и т.п.)
│ ├── После исправления → «Повторить отправку»
│ └── В аудите: изменение полей + повторная отправка
│
├── Продажа НЕ блокируется полностью — можно работать с любыми полями
└── В аудите: все попытки отправки с результатами
9. Контакты и компании¶
9.1 Many-to-many¶
Контакт ↔ Компания = many-to-many
Иванов работает в «Альфа» и «Бета»
В «Альфа» работают Иванов, Петрова, Сидоров
9.2 Identity Hash (подготовка к Org Master Data)¶
При создании контакта/компании система автоматически генерирует скрытый хеш для будущей кросс-проектной идентификации:
Contact.identity_hash = hash(normalize(email) + normalize(phone))
Company.identity_hash = hash(normalize(ИНН) + normalize(domain))
В v1: хеш хранится, но не используется в UI.
В v2+: при разработке Org Master Data хеш позволит мгновенно
связать записи одного клиента из разных проектов в единый профиль.
9.3 Создание через Drawer¶
Принцип: минимум полей при создании, обогащение позже.
Drawer = скорость. Карточка = полнота. Не смешиваем.
Создание сделки через Drawer (6-8 полей максимум):
├── Обязательные: Название, Воронка, Стадия
├── Лёгкие контактные: Имя, Телефон, Email (текстовые поля сделки)
├── Компания: dropdown «Выбрать» / «Новая» → только Название
├── Продукт: dropdown
└── Всё.
ИНН, реквизиты, адрес, доп. контакты — это ОБОГАЩЕНИЕ.
Менеджер заходит в карточку компании позже и дозаполняет.
Progressive Disclosure (аккордеон):
Если при создании менеджер выбирает «Новая компания» —
форма плавно раздвигается вниз, показывая только Название.
Остальные поля (адрес, реквизиты) — позже в карточке.
Один drawer без вложенности. Для связанных сущностей — выпадающие списки (выбор существующей компании/контакта). Если нужно создать новое — дополнительные поля прямо в drawer (Progressive Disclosure).
9.4 Merge дублей¶
Механизм слияния дублей контактов и компаний:
Дедуп-ключи:
Контакт: email, телефон (нормализованный)
Компания: ИНН, домен email, название
Merge-процесс:
1. Система предлагает кандидатов на слияние
2. Менеджер выбирает master-запись
3. Preview: что куда переедет (сделки, продажаы, активности, документы)
4. Подтверждение → merge
5. Shadow-копия хранится 30 дней (откат доступен Admin+)
6. Аудит: кто, когда, какие записи, что изменилось
Минимальная роль для merge: Manager
Откат merge: Admin+
9.6 Снимок данных при привязке (Drift Detection)¶
Контакты и компании — «записная книжка» проекта. Они переиспользуются в сделках, продажих и других сущностях. При привязке контакта/компании к сущности система делает снимок ключевых полей. Если данные позже изменятся — система подсвечивает расхождение.
Что фиксируется в снимке:
Контакт: name, phone, email
Компания: name, ИНН, phone
Где применяется:
├── Сделка → Контакт (Should Have)
├── Сделка → Компания (Should Have)
├── Продажа → Контакт (Must Have — данные в документах/webhook)
└── Продажа → Компания (Must Have — реквизиты в документах/webhook)
Поведение:
├── Данные не изменились → обычное отображение
├── Данные изменились →
│ ├── Индикатор ⚠ рядом с изменённым полем
│ ├── Подробности: «Телефон: +79205434343 → +79161234567 (Петрова, 15 янв)»
│ └── Действие: «Принять изменения» → снимок обновляется, ⚠ исчезает
└── В аудите: запись о подтверждении изменений
Особые случаи:
├── Множественные изменения:
│ Сравнивается текущее состояние с моментом привязки (не промежуточные)
├── Merge контактов:
│ Снимок остаётся от исходного → расхождение подсветится
├── Продажи + документы:
│ Предупреждение перед генерацией документа если есть drift
└── Передача сделки:
В целевом проекте при новой привязке — создаётся новый снимок
9.7 Коллизия Soft Delete и уникальных ключей¶
Сценарий А: Создание при наличии удалённого дубля
Контакт ivan@mail.com удалён (soft delete, в корзине 7 дней).
Кто-то создаёт нового с тем же email.
Поведение:
├── Система проверяет И живые И удалённые записи
├── Найден удалённый → «Контакт с таким email в корзине. Восстановить?»
│ ├── Да → восстановление из корзины
│ └── Нет, создать новый → старая запись hard-delete, новый создаётся
└── На уровне БД: partial unique index (WHERE deleted_at IS NULL)
Сценарий Б: Восстановление при наличии живого дубля
Контакт ivan@mail.com удалён. Создан новый ivan@mail.com (живой).
Админ пытается восстановить старого из корзины.
Поведение:
├── Система проверяет: ключ занят живой записью?
│ ├── Да → «Контакт с таким email уже существует. Объединить записи?»
│ │ ├── Да → стандартный Merge (восстанавливаемый + живой)
│ │ └── Нет → восстановить с очищенным email (ручная правка)
│ └── Нет → обычное восстановление
└── Система никогда не падает с ошибкой уникального индекса
10. Модуль «Продукты»¶
10.1 Продукт = шаблон бизнес-процесса¶
Продукт — не просто строчка в прайсе. Тип продукта определяет какой продажа будет создан.
Продукт:
├── Название, описание, категория
├── Ценообразование (прайс, тарифы, скидки)
├── Тип продажи → ссылка на Order Type
│ ├── «Стандартный продажа» (позиции + сумма)
│ ├── «Зарплатный проект» (кастомные поля)
│ └── null (продукт без продажи)
└── Предзаполнение полей продажи
└── Например: Тариф = «Премиум»
11. Источники сделок (вместо модуля «Маркетинг»)¶
Модуль «Маркетинг» убран в v5. Заменён справочником источников в настройках воронки.
Каждая сделка при создании:
├── Воронка: [выбор]
├── Источник: [выбор из справочника]
└── ...остальные поля
В отчётах:
└── Отчёт по источникам: кол-во сделок, конверсия, выручка
Будущее (v2+): полноценный модуль «Маркетинг» — кампании с бюджетами, email-рассылки, UTM-трекинг, ROI. Подробнее в Приложении А.
11a. Модуль «Активност軶
11a.1 Типы активностей¶
Задача (Task): название, описание, срок, приоритет, статус, ответственный
Звонок (Call): тема, направление (вх/исх), дата/время, длительность, результат
Встреча (Meeting): тема, дата начала/окончания, место/ссылка, участники, результат
Заметка (Note): текст, дата, автор
11a.2 Привязка к сущностям¶
Активность может быть привязана к одной или нескольким сущностям (сделка, продажа, контакт, компания). Активность без привязки — личная задача менеджера. В карточке каждой сущности — вкладка «Активности».
11a.3 Создание¶
- Через Drawer — быстрое создание (название, тип, срок, ответственный, привязка).
- Из карточки сущности — кнопка «+ Активность» с предзаполненной привязкой.
- Из календаря — клик на дату/время с предзаполненной датой.
11a.4 Напоминания¶
Настройка при создании задачи/встречи:
○ Без напоминания
◉ За 15 минут
○ За 1 час
○ За 1 день
○ В момент срока
Напоминание → уведомление in-app + email (по настройкам пользователя).
11a.5 Просроченные активности¶
Задача с истёкшим сроком:
├── Визуальное выделение в списке (красный цвет / метка «Просрочена»)
├── Счётчик просроченных в боковом меню: «Активности (3)»
├── На дашборде: виджет «Просроченные задачи»
└── Фильтр «Просроченные» в списке активностей
11a.6 Календарь¶
/p/:pid/activities/calendar
Представления: День / Неделя (по умолчанию) / Месяц
Что отображается: задачи (по сроку), звонки, встречи (по времени)
Фильтры: тип активности, мой/все, привязанная сущность
v1: только свой календарь.
v2+: командный календарь, синхронизация с Google Calendar / Outlook.
11b. Модуль «Отчёты» (детализация)¶
11b.1 Встроенные отчёты (v1)¶
1. По продажам: сделки (новые/Won/Lost), суммы, средний чек, конверсия, динамика
2. По воронке: конверсия между стадиями, среднее время на стадии, зависшие сделки
3. По клиентам: новые контакты/компании, топ-10 по сумме, контакты без сделок
4. По активности: активности по типам и менеджерам, просроченные, время до первой активности
5. По источникам: сделки по источникам, конверсия, выручка, средний чек
11b.2 Общие принципы¶
Каждый отчёт:
├── Таблица (всегда есть)
├── Диаграмма (bar / line / pie / funnel — по типу)
├── Переключатель таблица ↔ диаграмма
├── Фильтры: период, менеджер, воронка, источник
└── Селектор периода: сегодня / неделя / месяц / квартал / произвольный
Contextual UI: нет модуля «Активности» → отчёт по активности скрыт.
Данные: абсолютные значения из аудит-лога + текущее состояние.
11b.3 Конструктор отчётов (Could Have)¶
Выбор сущности → метрики → группировка → фильтры → визуализация → сохранение.
11c. Модуль «Документы» (детализация)¶
11c.1 Шаблоны документов¶
Шаблон содержит:
├── Название
├── Контекст привязки (Продажа / Сделка / Контакт / Компания)
├── Формат: DOCX (файл-шаблон с переменными)
└── Привязка к типу продажи (опционально)
11c.2 Доступные переменные¶
Контакт: {{contact.name}}, {{contact.phone}}, {{contact.email}}, {{contact.position}}
Компания: {{company.name}}, {{company.inn}}, {{company.address}}, {{company.phone}}
Сделка: {{deal.name}}, {{deal.amount}}, {{deal.source}}, {{deal.created_at}}, {{deal.owner.name}}
Продажа: {{order.number}}, {{order.created_at}}, {{order.type.name}}, {{order.owner.name}}
{{order.field.<key>}} — значения кастомных полей Order Type
Проект: {{project.name}}
Даты: {{today}}, {{today.year}}
11c.3 Генерация документа¶
1. Менеджер открывает карточку продажи/сделки → «Сгенерировать документ» → выбор шаблона
2. Система подставляет переменные из связанных сущностей
3. Drift Detection: предупреждение если данные контакта/компании изменились
4. Результат (DOCX) → сохраняется в разделе «Документы»
5. Скачивание, перегенерация (новая версия, старая сохраняется)
Автоматическая генерация: может быть настроена как действие при переходе на этап продажи.
11c.4 Версионирование¶
При перегенерации — новая версия, предыдущие доступны в списке версий. В аудите — событие «перегенерация» с указанием изменений.
12. Ролевая модель¶
12.1 Два уровня ролей¶
Системные роли (глобальные):
• Platform Owner — владелец организации
• Platform Admin — администратор организации
• Regular User — физлицо без организации
• Employee — сотрудник организации
Проектные роли (per-project):
• Project Owner — владелец проекта
• Project Admin — полный доступ
• Manager — управление данными, воронками, отчётами
• Member — работа с назначенными/доступными сущностями
• Viewer — только просмотр
12.2 Матрица: Системные роли¶
| Действие | Platform Owner | Platform Admin | Regular User | Employee |
|---|---|---|---|---|
| Управление организацией | ✅ | ✅ | — | ❌ |
| Биллинг организации | ✅ | ✅ | — | ❌ |
| Сотрудники и лицензии | ✅ | ✅ | — | ❌ |
| Подразделения | ✅ | ✅ | — | ❌ |
| Создание проектов организации | ✅ | ✅ | — | ❌ |
| Создание личных проектов | ✅ | ✅ | ✅ | По флагу |
| Флаг сотрудников | ✅ | ✅ | — | ❌ |
| Профиль и безопасность | ✅ | ✅ | ✅ | ✅ |
| Личная подписка | ✅ | ✅ | ✅ | По флагу |
| Удаление организации | ✅ | ❌ | — | ❌ |
12.3 Матрица: Проектные роли¶
| Действие | Owner | Admin | Manager | Member | Viewer |
|---|---|---|---|---|---|
| Настройки проекта, модули, политики | ✅ | ✅ | ❌ | ❌ | ❌ |
| Участники и роли | ✅ | ✅ | ❌ | ❌ | ❌ |
| Воронки и стадии | ✅ | ✅ | ✅ | ❌ | ❌ |
| Типы продаж (конструктор) | ✅ | ✅ | ✅ | ❌ | ❌ |
| Источники сделок | ✅ | ✅ | ✅ | ❌ | ❌ |
| Автоматизация | ✅ | ✅ | ✅ | ❌ | ❌ |
| Создание контактов/компаний | ✅ | ✅ | ✅ | ✅ | ❌ |
| Редактирование контактов/компаний | ✅ | ✅ | ✅ | ✅* | ❌ |
| Создание сделок | ✅ | ✅ | ✅ | ✅ | ❌ |
| Перемещение по воронке (канбан) | ✅ | ✅ | ✅ | ✅* | ❌ |
| Создание продаж (из сделки) | ✅ | ✅ | ✅ | ✅ | ❌ |
| Создание активностей | ✅ | ✅ | ✅ | ✅ | ❌ |
| Продукты и прайсы | ✅ | ✅ | ✅ | ❌ | ❌ |
| Отчёты: просмотр | ✅ | ✅ | ✅ | ✅ | ✅ |
| Отчёты: конструктор | ✅ | ✅ | ✅ | ❌ | ❌ |
| Документы: просмотр | ✅ | ✅ | ✅ | ✅ | ✅ |
| Документы: шаблоны | ✅ | ✅ | ✅ | ❌ | ❌ |
| Merge контактов/компаний | ✅ | ✅ | ✅ | ❌ | ❌ |
| Передача данных в другой проект | ✅ | ✅ | ✅ | ❌ | ❌ |
| Шаринг записей | ✅ | ✅ | ✅ | ✅ | ❌ |
| Массовые операции | ✅ | ✅ | ✅ | ❌ | ❌ |
| Удаление данных | ✅ | ✅ | ❌ | ❌ | ❌ |
| Архивация/удаление проекта | ✅ | ❌ | ❌ | ❌ | ❌ |
* Member — доступ определяется политикой (свои, отдела, расшаренные).
13. Политики доступа к записям¶
13.1 Три механизма¶
1. Роль (RBAC): Manager видит все, Member — по политике.
2. Иерархия: руководитель видит записи подчинённых (вверх по дереву отделов).
3. Шаринг: владелец может расшарить запись конкретному коллеге (view или edit).
13.2 Владение записями¶
Каждая сущность всегда привязана к владельцу: - Конкретный человек — менеджер, создавший или назначенный. - Отдел — если конкретный ответственный не назначен или уволен. Записями отдела управляет руководитель отдела (или выше по иерархии).
Записи никогда не остаются без владельца.
13.3 Шаринг доступа к отделу¶
Пользователю из другого отдела можно дать доступ ко всем записям отдела — виртуальное членство без переноса сотрудника в штат отдела: - Сотрудник видит записи отдела согласно своей проектной роли. - Не меняет иерархию подчинения.
13.4 Настройки политик per-project¶
Настройки проекта → Политики доступа
Видимость записей для роли «Member»:
○ Только свои записи
◉ Свои + расшаренные ← по умолчанию
○ Свои + записи подчинённых
○ Свои + записи своего отдела
○ Все записи проекта
Видимость для «Manager»:
◉ Все записи проекта ← по умолчанию
Шаринг:
☑ Разрешить шаринг записей
☑ Уведомлять при шаринге
14. Иерархическая структура подразделений¶
14.1 Дерево отделов¶
Организация «Альфа Групп»
├── Дирекция
│ ├── Генеральный директор (Platform Owner)
│ └── Финансовый директор (Platform Admin)
├── Департамент продаж
│ ├── Руководитель продаж
│ ├── Отдел B2B
│ │ ├── Руководитель B2B
│ │ └── Менеджеры...
│ └── Отдел B2C
│ ├── Руководитель B2C
│ └── Менеджеры...
└── Поддержка
├── Руководитель
└── Операторы...
14.2 Свойства подразделения¶
├── Название
├── Родительское подразделение (иерархия)
├── Руководитель
├── Сотрудники
├── Привязка к проектам (роль по умолчанию)
└── Шаринг доступа (внешние сотрудники с виртуальным доступом к записям отдела)
14.3 Два способа управления доступами¶
Через отделы (массовый):
Создать отдел → привязать к проекту с ролью по умолчанию
→ Добавление сотрудника в отдел = авто-добавление в связанные проекты
Через проект (ручной):
Открыть проект → добавить сотрудника → назначить роль
→ Работает независимо от отделов
15. Аудит и история¶
15.1 Единый журнал событий, два представления¶
Все действия хранятся в одной системе событий. Просмотр — через фильтры:
Событие (Event):
├── Тип: create / read / update / delete / transfer / status_change / login / logout / merge / share
├── Timestamp
├── Кто (user_id, user_name)
├── Сущность (entity_type, entity_id)
├── Проект (project_id)
├── Изменения (JSON Patch, RFC 6902 — только дельта, не полные old/new)
└── Метаданные (IP, user_agent — для login/logout)
15.2 Хранение изменений: гибридный подход¶
Изменения хранятся в двух форматах одновременно — для UI и для аналитики:
Формат 1: JSON Patch (RFC 6902) — для UI
Компактная дельта изменений. Используется для визуального diff в интерфейсе.
Пример: менеджер изменил стадию сделки и сумму
Patch:
[
{ "op": "replace", "path": "/stage", "from": "КП", "value": "Переговоры" },
{ "op": "replace", "path": "/amount", "from": 500000, "value": 750000 }
]
В UI аудита: визуальный diff (как в Git)
stage: КП → Переговоры
amount: 500 000 → 750 000
Формат 2: Абсолютные значения ключевых полей — для аналитики
Для бизнес-критичных полей дополнительно сохраняется абсолютное значение.
Позволяет SQL-запросы: «все сделки, где сумма была > 1 млн в январе».
Ключевые поля (фиксируются per-entity):
Сделка: stage, amount, owner_id, source
Продажа: status, order_type_id, owner_id
Контакт: email, phone
Компания: inn, name
Аналитика строится по абсолютным значениям (быстрые SQL-запросы). Детальный diff в UI — по JSON Patch.
Что логируется: - CRUD-операции на всех сущностях - Передача данных между проектами - Изменения статусов (сделки, продажаы) - Шаринг записей - Входы и выходы из системы - Merge контактов/компаний - Изменения ролей и прав - Доступ к данным (чтение)
15.3 Два представления¶
Per-entity (история сущности): В карточке каждой сделки/контакта/продажи — вкладка «История»: - Все события связанные с этой записью - Кто, когда, что изменил - Привязка новых сделок к контакту
Per-user (журнал пользователя): - Руководитель видит действия своих подчинённых (по иерархии отделов) - Сотрудник видит только свои действия - Platform Owner / Admin видит всё в организации - Project Admin видит все действия в проекте
15.4 Маршруты аудита¶
| URL | Экран | Доступ |
|---|---|---|
/p/:pid/audit |
Project Audit Log | Project Admin |
/account/organization/audit |
Organization Audit Log | Platform Owner, Admin |
16. Биллинг и лицензирование¶
16.1 Тарифы физлица¶
| Параметр | Free | Pro | Business |
|---|---|---|---|
| Проекты | 3 | 10 | ∞ |
| Участников в проекте | 5 | 15 | ∞ |
| Хранилище | 1 GB | 10 GB | 100 GB |
| Автоматизации (на проект) | 5 | 50 | ∞ |
| Конструктор отчётов | ❌ | ✅ | ✅ |
| Типы продаж | 1 | 10 | ∞ |
16.2 Лицензии организации¶
| Параметр | Starter | Pro | Enterprise |
|---|---|---|---|
| Сотрудники | 10 | 50 | ∞ |
| Проекты | 5 | 25 | ∞ |
| Хранилище | 5 GB | 50 GB | 500 GB |
| Автоматизации (на проект) | 10 | 100 | ∞ |
| Типы продаж (на проект) | 5 | 50 | ∞ |
| Передача данных между проектами | ✅ | ✅ | ✅ |
| Кастомные роли | ❌ | ✅ | ✅ |
| SSO / SAML | ❌ | ❌ | ✅ |
| Self-hosted | ❌ | ❌ | ✅ |
16.3 Перелимит и грейс-период¶
Перелимит (тариф понижен / лимит исчерпан):
├── Все существующие данные переходят в READ-ONLY
├── Создание новых сущностей заблокировано
├── Приглашение новых участников заблокировано
├── Редактирование существующих записей заблокировано
├── Баннер: «Ваш тариф не покрывает текущие проекты. Обновите план.»
└── Данные НЕ удаляются и НЕ архивируются автоматически
Неоплата:
├── Грейс-период: 7 дней
├── В течение грейс-периода: полная функциональность
├── После грейс-периода: read-only режим
└── Данные хранятся (не удаляются)
Биллинг личного и корпоративного пространства полностью независим. Перелимит личной подписки не влияет на работу в проектах организации.
16.4 Кто видит раздел оплаты¶
| Тип | Что видит |
|---|---|
| Физлицо (без орг.) | Свою подписку |
| Platform Owner / Admin | Подписку организации |
| Employee | Раздел скрыт |
| Физлицо + сотрудник | Свою личную подписку |
17. Удаление данных и retention¶
17.1 Трёхступенчатая модель¶
Soft Delete → Архив → Hard Delete
Soft Delete (корзина):
├── Период: 7 дней
├── Запись помечена как deleted, не отображается в списках
├── Можно восстановить (Admin+)
└── Связанные данные сохраняют ссылки
Архив:
├── Период: 6 месяцев после soft delete
├── Данные в read-only
├── Занимают место в хранилище
├── Доступны для аудита и lineage
└── Восстановление — по запросу (Admin)
Hard Delete:
├── Через 1 год после архивации
├── Физическое удаление из горячих таблиц
├── Аудит-записи сохраняются (без данных сущности)
└── Необратимо
17.2 Merge и shadow-копии¶
При merge контактов/компаний: - Shadow-копия поглощённой записи хранится 30 дней. - Откат merge доступен Admin+. - После 30 дней shadow-копия удаляется, merge необратим.
18. Массовые операции и импорт¶
18.1 Массовые операции (Bulk Actions)¶
Доступны для Manager и выше:
Выделить N записей → действие:
├── Перенести на стадию (сделки)
├── Назначить ответственного
├── Передать в другой проект (организация)
├── Расшарить
├── Удалить (soft delete)
├── Экспорт выборки
└── Изменить поле (массовое редактирование)
18.2 Импорт данных¶
Импорт из CSV/Excel:
Импортируемые сущности:
├── Контакты
├── Компании
└── Продукты
Процесс:
1. Загрузка файла (CSV / Excel)
2. Маппинг колонок → поля системы
3. Preview: первые N строк
4. Проверка дублей (по дедуп-ключам)
5. Импорт с отчётом: создано / обновлено / пропущено (дубли) / ошибки
6. Аудит: кто, когда, сколько записей
Минимальная роль: Manager
18.3 Экспорт данных¶
Экспорт отчётов и выборок — будет проработан отдельно (v2+).
19. Просмотр профиля других пользователей¶
| Кто смотрит | Что видит |
|---|---|
| Platform Owner / Admin | Полный профиль: данные, отдел, проекты, роли, лицензия, флаг |
| Project Admin | В контексте проекта: имя, email, роль, активность |
| Manager / Member | Базовый: имя, аватар, отдел, должность, роль в текущем проекте |
| Viewer | Минимальный: имя, аватар |
19a. Уведомления¶
19a.1 Каналы¶
v1:
├── In-app (колокольчик 🔔 в шапке) — основной канал
│ ├── Счётчик непрочитанных (badge)
│ ├── Dropdown: список уведомлений, прочитано/непрочитано
│ ├── «Отметить все как прочитанные»
│ └── Real-time обновление (WebSocket / SSE)
└── Email — для критичных событий и когда пользователь офлайн
19a.2 События-триггеры¶
| Категория | Событие | Кому | Канал |
|---|---|---|---|
| Сделки | Новая сделка назначена | Ответственный | In-app |
| Сделки | Сделка переведена на другую стадию | Ответственный | In-app |
| Сделки | Сделка передана в другой проект | Ответственный в целевом | In-app + Email |
| Продажи | Ошибка финального действия (DLQ) | Ответственный | In-app + Email |
| Продажи | Все попытки retry исчерпаны | Ответственный + PA | In-app + Email |
| Данные | Drift Detection: данные контакта/компании изменены | Ответственный | In-app |
| Данные | Запись расшарена пользователю | Получатель | In-app |
| Данные | Записи требуют переназначения | Project Admin | In-app + Email |
| Активности | Напоминание об активности | Ответственный | In-app + Email |
| Активности | Активность просрочена | Ответственный | In-app |
| Организация | Приглашение в проект/организацию | Приглашённый | |
| Организация | Проект архивирован | Все участники | In-app + Email |
| Биллинг | Перелимит тарифа | PO / PA | In-app + Email |
| Биллинг | Грейс-период истекает (за 2 дня) | PO / PA | In-app + Email |
| Импорт | Импорт завершён | Инициатор | In-app |
19a.3 Настройки per-user¶
Per-канал для каждой категории. Критичные уведомления НЕ отключаются:
• DLQ ошибки, перелимит, приглашения, переназначение записей.
Email-уведомления:
◉ Сразу ○ Дайджест раз в час ○ Дайджест раз в день ○ Выключены
19b. Дашборд и Статистика¶
19b.1 Дашборд (/p/:pid/dashboard)¶
Первый экран при входе в проект. Фиксированный набор виджетов (v1):
Верхняя строка — ключевые метрики:
Сделки в работе (кол-во + сумма) | Новые за период | Won за период | Продажи в работе
Средний блок:
Воронка (конверсия по стадиям) | Сделки по источникам
Нижний блок:
Просроченные задачи (макс. 5) | Ближайшие активности (макс. 5) | Последние действия (макс. 10)
Адаптивность по ролям: Member — только свои метрики, Manager+ — всего проекта. Адаптивность по модулям (Contextual UI): виджеты скрываются при отключении модуля. Селектор периода: сегодня / неделя / месяц (по умолчанию) / квартал / произвольный.
19b.2 Статистика (/p/:pid/statistics)¶
Более глубокая аналитика: продажи (динамика, средний чек), воронка (конверсия, среднее время на стадии), источники (конверсия, выручка), команда (активности по менеджерам), продажаы (по типам, среднее время).
19c. Поиск и фильтрация¶
19c.1 Глобальный поиск¶
Строка поиска в шапке. Контекст = текущий проект.
Поиск по: сделки, контакты, компании, продажаы, активности, продукты.
Начинается после ≥ 2 символов. По подстроке, регистронезависимый.
Результаты группируются по типу (макс. 5 на тип).
19c.2 Фильтрация в списках¶
Каждый список имеет панель фильтров: - Сделки: стадия, воронка, ответственный, источник, дата, сумма, «на стадии > N дней», «без владельца». - Контакты: компания, дата создания, создатель, «есть сделки». - Продажи: тип, этап, ответственный, DLQ-ошибка, дата. - Активности: тип, статус, просроченные, ответственный, срок.
19c.3 Сортировка и пагинация¶
Все списки: сортировка по клику на заголовок (▲ / ▼ / сброс). Пагинация: 25 / 50 / 100 записей. Канбан: infinite scroll, 20 карточек на колонку.
Фильтры сохраняются в URL (query params), сбрасываются при уходе. Сохранённые views — v2+.
19d. Настройки пользователя¶
/account/profile → секция «Настройки»
Язык: Русский (по умолчанию) / English. v2+: доп. языки.
Часовой пояс: авто из браузера, переопределяемый. Хранение в БД — UTC.
Формат даты: ДД.ММ.ГГГГ / ММ/ДД/ГГГГ / ГГГГ-ММ-ДД
Формат времени: 24ч (по умолчанию) / 12ч
Разделитель тысяч: пробел / запятая
Валюта: ₽ (RUB). v2+: мультивалютность per-project.
Вид по умолчанию:
Сделки: Канбан ◉ / Список ○
Продажи: Канбан ○ / Список ◉
Активности: Список ◉ / Календарь ○
Последний использованный вид запоминается.
Тема: v1 — светлая. v2+ — тёмная.
19e. Жизненный цикл связанных сущностей¶
19e.1 Закрытие сделки как «Проигрыш»¶
Есть незавершённые продажаы → предупреждение:
├── Отменить продажаы → статус «Отменён»
├── Оставить как есть → продажаы продолжают жить
└── Не закрывать сделку (отмена)
Активности остаются.
19e.2 Переоткрытие сделки¶
Закрытая сделка (Won/Lost) может быть переоткрыта Manager+. На любую активную стадию. В stage_log — новая запись. В аудите — событие + причина.
19e.3 Удаление стадии / воронки / типа продажи¶
Стадия с активными сделками:
НЕ удаляется. «Переместите сделки на другую стадию.»
Быстрое действие: «Переместить все на [стадия]».
Воронка:
Единственная → удаление запрещено.
С сделками → перенос в другую воронку (первая стадия).
Тип продажи:
С активными продажими → удаление запрещено.
Без активных → soft delete. Продукты теряют привязку (предупреждение).
19e.4 Удаление продукта¶
С активными сделками → предупреждение. Сделки сохранят название как текст.
Продажи не затрагиваются (хранят order_type_version).
19e.5 Отключение модуля с данными¶
Предупреждение: «Есть N незавершённых записей. Они станут недоступны.»
Данные НЕ удаляются. Webhook и DLQ retry приостанавливаются.
При включении обратно — всё доступно. Приостановленные webhook НЕ возобновляются автоматически.
19e.6 Удаление контакта/компании с привязками¶
Soft delete: привязки сохраняются, контакт помечен «Удалён».
Лёгкие поля сделки НЕ затрагиваются. При восстановлении — привязки восстанавливаются.
При hard delete — привязки обнуляются, лёгкие поля остаются.
20. Полная карта экранов и URL¶
20.1 Авторизация и онбординг (12 экранов)¶
| URL | Экран |
|---|---|
/ |
Landing |
/auth/signin |
Sign In |
/auth/signup |
Sign Up |
/auth/signup/organization |
Org Setup |
/auth/forgot-password |
Forgot Password |
/auth/reset-password/:token |
Reset Password |
/auth/verify-email/:token |
Verify Email |
/auth/2fa |
2FA |
/auth/invite/:token |
Accept Invitation |
/onboarding/profile |
Profile Setup |
/onboarding/first-project |
First Project |
/onboarding/invite-team |
Invite Team |
20.2 Глобальные (3 экрана)¶
| URL | Экран | Доступ |
|---|---|---|
/home |
Dashboard | Все |
/projects |
Projects List | Все |
/projects/new |
Create Project | По правам |
20.3 Аккаунт (22 экрана)¶
| URL | Экран | Доступ |
|---|---|---|
/account/profile |
My Profile | Все |
/account/security |
Security | Все |
/account/security/sessions |
Active Sessions | Все |
/account/organization |
Org Profile | PO, PA (edit) / Employee (read) |
/account/organization/convert |
Convert to Org | Физлицо без орг. |
/account/organization/departments |
Departments (tree) | PO, PA |
/account/organization/departments/new |
Create Department | PO, PA |
/account/organization/departments/:id/edit |
Edit Department | PO, PA |
/account/organization/employees |
Employees List | PO, PA |
/account/organization/employees/new |
Add Employee | PO, PA |
/account/organization/employees/:id |
Employee Profile | PO, PA (full) / коллеги (базовый) |
/account/organization/employees/:id/edit |
Edit Employee | PO, PA |
/account/organization/employees/invitations |
Invitations | PO, PA |
/account/organization/audit |
Org Audit Log | PO, PA |
/account/billing |
Billing Overview | Физлицо / PO, PA |
/account/billing/plans |
Plans | Физлицо / PO, PA |
/account/billing/payments |
Payment History | Физлицо / PO, PA |
/account/billing/invoices |
Invoices | Физлицо / PO, PA |
/account/billing/payment-methods |
Payment Methods | Физлицо / PO, PA |
20.4 Управление проектом (7 экранов)¶
| URL | Экран | Мин. роль |
|---|---|---|
/p/:pid/settings |
Project Settings | Project Admin |
/p/:pid/settings/modules |
Modules (on/off) | Project Admin |
/p/:pid/settings/policies |
Access Policies | Project Admin |
/p/:pid/members |
Project Members | Project Admin |
/p/:pid/members/invite |
Invite Member | Project Admin |
/p/:pid/roles |
Project Roles | Project Admin |
/p/:pid/audit |
Project Audit Log | Project Admin |
20.5 Портфель — CRM-экраны (модули)¶
Ядро (2 экрана)¶
| URL | Экран | Мин. роль |
|---|---|---|
/p/:pid/dashboard |
Dashboard | Viewer |
/p/:pid/statistics |
Statistics | Viewer |
Контакты — модуль (3 экрана)¶
| URL | Экран | Мин. роль | Примечание |
|---|---|---|---|
/p/:pid/contacts |
Contacts List | Member | Создание через drawer |
/p/:pid/contacts/:id |
Contact Details | Member | Many-to-many с компаниями, история |
/p/:pid/contacts/:id/edit |
Edit Contact | Member* |
Клиенты / Компании — модуль (3 экрана)¶
| URL | Экран | Мин. роль | Примечание |
|---|---|---|---|
/p/:pid/companies |
Companies List | Member | Создание через drawer |
/p/:pid/companies/:id |
Company Details | Member | Many-to-many с контактами, история |
/p/:pid/companies/:id/edit |
Edit Company | Member* |
Сделки — модуль (6 экранов)¶
| URL | Экран | Мин. роль | Примечание |
|---|---|---|---|
/p/:pid/deals |
Deals List | Member | Создание через drawer |
/p/:pid/deals/kanban |
Deals Kanban | Member | Drag & drop по стадиям воронки |
/p/:pid/deals/:id |
Deal Details | Member | Контактные поля, привязки, продажаы, история |
/p/:pid/deals/pipelines |
Pipelines List | Manager | |
/p/:pid/deals/pipelines/new |
Create Pipeline | Manager | Стадии, источники, авто-создание контакта |
/p/:pid/deals/pipelines/:id/edit |
Edit Pipeline | Manager |
Продажи — модуль (7 экранов)¶
| URL | Экран | Мин. роль | Примечание |
|---|---|---|---|
/p/:pid/orders |
Orders List | Member | Фильтр по типу, статусу |
/p/:pid/orders/kanban |
Orders Kanban | Member | По этапам (включается в настройках) |
/p/:pid/orders/:id |
Order Details | Member | Форма из Order Type, этапы, документы, история |
/p/:pid/orders/:id/edit |
Edit Order | Member* | |
/p/:pid/orders/types |
Order Types | Manager | |
/p/:pid/orders/types/new |
Create Order Type | Manager | Конструктор: поля, этапы, документы, действия |
/p/:pid/orders/types/:id/edit |
Edit Order Type | Manager |
Активности — модуль (4 экрана)¶
| URL | Экран | Мин. роль |
|---|---|---|
/p/:pid/activities |
Activities List | Member |
/p/:pid/activities/calendar |
Calendar View | Member |
/p/:pid/activities/:id |
Activity Details | Member |
/p/:pid/activities/:id/edit |
Edit Activity | Member* |
Продукты — модуль (4 экрана)¶
| URL | Экран | Мин. роль |
|---|---|---|
/p/:pid/products |
Products Catalog | Viewer |
/p/:pid/products/:id |
Product Details | Viewer |
/p/:pid/products/:id/edit |
Edit Product | Manager |
/p/:pid/products/pricing |
Pricing | Manager |
Отчёты — модуль (2 экрана)¶
| URL | Экран | Мин. роль |
|---|---|---|
/p/:pid/reports |
Reports Summary | Viewer |
/p/:pid/reports/builder |
Report Builder | Manager |
Встроенные типы: по продажам, по воронке, по клиентам, по активности, по источникам сделок.
Документы — модуль (5 экранов)¶
| URL | Экран | Мин. роль |
|---|---|---|
/p/:pid/documents |
Documents List | Viewer |
/p/:pid/documents/:id |
Document Details | Viewer |
/p/:pid/documents/templates |
Templates Library | Manager |
/p/:pid/documents/templates/new |
Create Template | Manager |
/p/:pid/documents/templates/:id/edit |
Edit Template | Manager |
Автоматизация — модуль (3 экрана)¶
| URL | Экран | Мин. роль |
|---|---|---|
/p/:pid/automation |
Automation Rules | Manager |
/p/:pid/automation/new |
Create Rule | Manager |
/p/:pid/automation/:id/edit |
Edit Rule | Manager |
* Member — доступ определяется политикой (свои, отдела, расшаренные).
21. Паттерн создания сущностей¶
21.1 Drawer — один, без вложенности¶
Глобальная боковая панель для быстрого создания. Один drawer, без стека/вложенности.
Принцип: минимум полей при создании, обогащение позже. Drawer = скорость. Карточка = полнота.
Создание через Drawer: Контакт, Компания, Сделка, Продажа (из сделки), Активность, Продукт.
Количество полей: 6-8 максимум. Подробный состав полей для каждой сущности описан в разделе 9.3 (на примере сделки).
Связанные сущности — Progressive Disclosure (аккордеон): - При создании сделки: выбор компании/контакта из dropdown. - Если «Новая компания» — форма плавно раздвигается вниз, показывая только Название. - ИНН, реквизиты, адрес — заполняются позже в карточке компании (обогащение). - Аналогично для контакта при создании компании.
Поведение: - При переключении проекта — drawer закрывается (предупреждение о несохранённых данных). - Drawer привязан к текущему проекту.
21.2 На отдельных страницах¶
Сложные сущности: Воронка, Тип продажи, Шаблон документа, Правило автоматизации, Отчёт (конструктор).
22. Полная структура системы (дерево)¶
Fairflow
│
├── Аккаунт
│ ├── Профиль
│ │ ├── Персональные данные
│ │ └── Настройки (язык, часовой пояс, уведомления)
│ ├── Организация (адаптивно по роли)
│ │ ├── ○ Нет → «Создать организацию»
│ │ ├── ● Владелец / Админ:
│ │ │ ├── Реквизиты
│ │ │ ├── Подразделения (иерархия)
│ │ │ │ ├── Дерево отделов
│ │ │ │ ├── Создание / редактирование
│ │ │ │ ├── Руководитель
│ │ │ │ ├── Привязка к проектам (роль по умолчанию)
│ │ │ │ └── Шаринг доступа (виртуальное членство)
│ │ │ ├── Сотрудники и лицензии
│ │ │ │ ├── Список (X / Y лицензий)
│ │ │ │ ├── Добавление / приглашение
│ │ │ │ ├── Карточка (данные, отдел, проекты, флаг)
│ │ │ │ ├── Редактирование
│ │ │ │ └── Приглашения (ожидающие)
│ │ │ └── Журнал аудита (организация)
│ │ └── ● Сотрудник → информация (чтение)
│ ├── Оплата (адаптивно)
│ │ ├── Физлицо → личная подписка
│ │ ├── PO/PA → лицензия организации
│ │ └── Сотрудник → скрыт
│ │ Содержимое:
│ │ ├── Текущий план и лимиты
│ │ ├── Тарифные / лицензионные планы
│ │ ├── История платежей
│ │ ├── Счета
│ │ └── Способы оплаты
│ └── Безопасность
│ ├── Активные сессии
│ ├── 2FA
│ └── Смена пароля
│
├── Проекты
│ ├── ▼ Селектор (шапка)
│ │ ├── Личные [+ если флаг = ДА]
│ │ ├── Организация А [+ если PO/PA]
│ │ └── Организация Б [без +]
│ ├── Список проектов
│ ├── Создание проекта
│ │ ├── Шаблон (B2B / Колл-центр / Автосалон / Доставка / По умолчанию)
│ │ ├── Название, описание
│ │ ├── Подтверждение модулей
│ │ └── Приглашение участников
│ ├── Настройки проекта
│ │ ├── Общие
│ │ ├── Модули (вкл/выкл)
│ │ └── Политики доступа
│ ├── Участники / Приглашения
│ ├── Роли проекта
│ └── Журнал аудита (проект)
│
└── Портфель (контекст проекта, модули)
│
├── Дашборд (ядро)
├── Статистика (ядро)
│
├── 👥 Контакты (модуль)
│ ├── Список (создание через drawer)
│ ├── Карточка (many-to-many с компаниями, история)
│ └── Редактирование
│
├── 🏢 Клиенты (компании) (модуль)
│ ├── Список (создание через drawer)
│ ├── Карточка (many-to-many с контактами, история)
│ └── Редактирование
│
├── 💰 Сделки (модуль)
│ ├── Список (создание через drawer)
│ ├── Канбан (воронка, drag & drop)
│ ├── Карточка
│ │ ├── Встроенные контактные поля (лёгкие)
│ │ ├── Привязка к контакту / компании
│ │ ├── Привязанные продукты
│ │ ├── Привязанные продажаы
│ │ ├── Источник сделки
│ │ ├── Шаринг
│ │ └── История (события)
│ └── Воронки
│ ├── Список
│ ├── Создание (стадии, источники, авто-контакт)
│ └── Редактирование
│
├── 🛒 Продажи (модуль)
│ ├── Типы продаж (конструктор)
│ │ ├── Список типов
│ │ ├── Создание (поля, этапы, документы, действия)
│ │ └── Редактирование
│ ├── Список продаж
│ ├── Канбан (по этапам, опционально)
│ ├── Карточка (форма из типа, этапы, документы, история)
│ └── Редактирование
│
├── 📋 Активности (модуль)
│ ├── Список (создание через drawer)
│ ├── Календарь
│ ├── Карточка
│ └── Редактирование
│
├── 📦 Продукты (модуль)
│ ├── Каталог (создание через drawer)
│ ├── Карточка (+ привязка к типу продажи)
│ ├── Редактирование
│ └── Прайсы
│
├── 📊 Отчёты (модуль)
│ ├── Сводка
│ └── Конструктор (?type=sales|funnel|clients|activity|sources)
│
├── 📄 Документы (модуль)
│ ├── Список
│ ├── Просмотр
│ └── Шаблоны (библиотека, создание, редактирование)
│
└── ⚡ Автоматизация (модуль)
├── Список правил
├── Создание
└── Редактирование
23. Сводка по экранам¶
| Категория | Кол-во |
|---|---|
| Авторизация и онбординг | 12 |
| Глобальные (Home, Projects) | 3 |
| Аккаунт: Профиль, Безопасность | 5 |
| Аккаунт: Организация, подразделения, сотрудники, аудит | 10 |
| Аккаунт: Оплата | 5 |
| Управление проектом (settings, modules, policies, members, roles, audit) | 7 |
| Портфель: Ядро | 2 |
| Портфель: Контакты | 3 |
| Портфель: Клиенты | 3 |
| Портфель: Сделки и воронки | 6 |
| Портфель: Продажи и типы | 7 |
| Портфель: Активности | 4 |
| Портфель: Продукты | 4 |
| Портфель: Отчёты | 2 |
| Портфель: Документы | 5 |
| Портфель: Автоматизация | 3 |
| Итого | ~81 экран |
24. Бизнес-процессы (ключевые сценарии)¶
24.1 Полный цикл продажи (банк)¶
1. Обращение → сделка в воронке «Продажи»
Источник: Сайт. Лёгкие поля: имя, телефон, email, «хочу ЗП проект».
2. Квалификация → проверка дублей
├── Телефон совпал с существующим контактом → «Привязать к Иванову И.И.?»
├── Да → сделка привязана к контакту, в истории контакта — событие
└── Нет совпадений → «Создать контакт» (авто на стадии или вручную)
3. КП → Согласование → Клиент согласен
4. «Создать продажу» → продукт «ЗП Премиум» → тип продажи «Зарплатный проект»
Динамическая форма: кол-во карт, тариф, дата начала...
5. Продажа проходит этапы:
Заполнение → Проверка → Подписание → Отправка
6. Финальное действие → webhook в АБС
7. Продажа = «Завершён». Сделка = «Закрыта (Won)».
24.2 Несколько продуктов в сделке¶
Сделка «Банк Ромашка — комплекс»
├── Продажа #1: ЗП проект (тип: ЗП) → свои поля, этапы, webhook
└── Продажа #2: РКО (тип: РКО) → свои поля, этапы, webhook
Независимые. Разные ответственные.
Сделка закрывается когда все продажаы завершены (или вручную).
24.3 Передача между проектами¶
1. Проект «Входящие» → сделка квалифицирована → B2B
2. «Передать в "Продажи B2B"»
3. Копируется ТОЛЬКО сделка:
✅ Лёгкие контактные поля (имя, телефон, email)
✅ Источник сделки
✅ Lineage-ссылка (origin_project, snapshot)
❌ Продажи, продукты, активности, документы
❌ Контакт / компания (как записи в базе)
4. В исходном: статус «Передан» + ссылка
5. В целевом: сделка на первой стадии воронки + метка «Передана из "Входящие"»
6. Система подсказывает: «Найден контакт Иванов И.И. (ivan@mail.com). Привязать?»
7. Менеджер привязывает контакт → добавляет продукты → работает как с обычной сделкой
24.4 Иерархический доступ и шаринг¶
Иванов (менеджер) создал сделку:
✅ Иванов — владелец
✅ Козлов — руководитель (иерархия)
✅ Сидоров — руководитель Козлова (вверх)
❌ Петрова — коллега (не видит)
Иванов расшарил Петровой → ✅ видит.
24.5 Увольнение сотрудника¶
1. PA удаляет Иванова
2. Система проверяет ПО КАЖДОМУ ПРОЕКТУ:
Проект «Продажи B2B»: руководитель Козлов есть в проекте?
✅ Да → 30 сделок Иванова → Козлову
Проект «Холодные звонки»: руководитель Козлов есть в проекте?
❌ Нет → 20 сделок → статус «Требует переназначения»
→ Project Admin получает уведомление
→ Фильтр «Без владельца» в списке сделок
3. Лицензия освобождается
4. Иванов → режим физлица, может использовать платформу
24.6 Массовые операции¶
Manager выделяет 30 сделок на стадии «Холодная база»:
→ «Назначить ответственного: Петрова»
→ Все 30 переназначены, в истории каждой — событие
24.7 Импорт при миграции¶
1. Компания переходит с другой CRM
2. Экспортирует контакты и компании в CSV
3. Manager загружает CSV → /p/:pid/contacts (импорт)
4. Маппинг колонок → поля системы
5. Проверка дублей → «5 совпадений, обновить существующие?»
6. Импорт: создано 450, обновлено 5, ошибок 3
7. Аудит: событие «импорт 458 записей»
25. Self-hosted / Локальное развёртывание¶
25.1 Что заложить в архитектуру (v1)¶
├── Контейнеризация (Docker)
├── Абстракция хранилища (S3-интерфейс)
├── Абстракция email (SMTP-интерфейс)
├── Конфигурация через environment variables
├── Экспорт данных организации
└── API-first архитектура
25.2 Реализация (v2+)¶
├── Docker Compose для self-hosted
├── Helm chart для Kubernetes
├── Документация по развёртыванию
├── Лицензионный сервер
├── MinIO для локального S3
└── Admin-панель on-premise
26. Расширения (v2+)¶
Полный roadmap v2+ вынесен в Приложение А в конце документа. Краткий перечень направлений:
- Платформа: Self-hosted, мобильное приложение, live-редактирование
- Данные: Org Master Data, кросс-проектная дедупликация, кросс-проектные отчёты, lineage-граф
- Роли: Кастомные роли, кастомные поля, SSO/SAML
- Модули: Маркетинг (кампании, рассылки, ROI), отраслевые (Автосалон, Общепит, Недвижимость)
- Сделки/Продажи: Мультивалютность, SLA per-стадия, Split-View канбан, fuzzy merge
- UX/AI: Drawer-Assistant, пользовательские шаблоны проектов
- Интеграции: Email, телефония, мессенджеры, API, обогащение по ИНН
- Экспорт: Данные проекта, отчёты
27. Классификация требований (MoSCoW)¶
Must Have (v1)¶
- Изоляция данных на уровне проектов
- Ролевая модель (системные + проектные роли)
- Модульная архитектура per-project
- Базовые политики видимости (RBAC + иерархия)
- Order Types (динамические типы продаж)
- Воронки (настраиваемые стадии для сделок)
- Drawer (глобальное быстрое создание, Progressive Disclosure, 6-8 полей)
- Шаблоны проектов (5 базовых)
- Проверка дублей при квалификации (+ проверка корзины при создании И при восстановлении)
- Единый журнал аудита (гибрид: JSON Patch + абсолютные значения ключевых полей)
- Импорт данных (CSV/Excel)
- Contextual UI (скрытие всего что связано с отключённым модулем)
- Soft delete + архив + hard delete (retention)
- Перелимит → read-only + грейс-период
- Заглушка «нет проектов» для сотрудников без назначений
- DLQ для финальных действий продаж (retry + статус ошибки + редактирование полей)
- Stage log: полный лог входов на стадии (включая возвраты, для отчётов по срокам)
- identity_hash для контактов/компаний (заложить в модель, не в UI)
- Переназначение записей при увольнении (per-project проверка + «Требует переназначения»)
- Матрица передачи сделок (что копируется, что нет) + подсказка контактов в целевом проекте
- Drift Detection для продаж: снимок контакта/компании при привязке, предупреждение при изменении данных
- Уведомления: in-app (колокольчик) + email для критичных событий
- Глобальный поиск по проекту (по сделкам, контактам, компаниям, продажим)
- Фильтрация и сортировка в списках (сделки, контакты, продажаы, активности)
- Пагинация (25/50/100 записей на странице)
- Дашборд: фиксированный набор виджетов (метрики, воронка, просроченные задачи)
- Статистика: отчёты по продажам, воронке, источникам, команде, продажим
- Активности: задачи, звонки, встречи, заметки — типы, привязка к сущностям, напоминания
- Календарь активностей (свой, день/неделя/месяц)
- Просроченные активности: визуальное выделение, счётчик в меню
- Жизненный цикл: запрет удаления стадий/воронок/типов продаж с активными данными
- Настройки пользователя: язык, часовой пояс, формат даты, вид по умолчанию
Should Have (v1)¶
- Иерархическая видимость (начальник → подчинённые)
- Передача данных между проектами (копия сделки + lineage, без контактов/продаж/продуктов)
- Генерация документов по шаблонам (DOCX с переменными)
- Шаблоны документов: переменные контакта, компании, продажи, сделки
- Версионирование документов (при перегенерации)
- Merge контактов/компаний (с откатом)
- Шаринг записей и доступа к отделу
- Массовые операции (bulk actions)
- Канбан для продаж
- Drift Detection для сделок: снимок контакта/компании при привязке, предупреждение при изменении данных
- Встроенные отчёты: по продажам, по воронке, по клиентам, по активности, по источникам
- Переоткрытие закрытых сделок (Manager+)
- Настройки уведомлений per-user (выбор категорий, частота email)
Could Have (v1)¶
- Конструктор отчётов
- Автоматизация (триггеры/правила)
- Сохранённые фильтры (views)
- Настраиваемый дашборд (drag & drop виджетов)
Won't Have (v1)¶
- Полноценный модуль «Маркетинг»
- Self-hosted развёртывание
- Мобильное приложение
- Кастомные роли
- AI-парсинг (Drawer-Assistant)
- Cross-Project Lineage (граф)
- Live-редактирование
- Экспорт данных (будет проработан отдельно)
- Circuit Breaker для webhook (паттерн «предохранитель»)
- SLA-индикаторы в канбане (светофор)
- Повторяющиеся активности
- Командный календарь, синхронизация с Google Calendar / Outlook
- Тёмная тема
- Push-уведомления
28. Принятые архитектурные решения (changelog)¶
| # | Решение | Обоснование |
|---|---|---|
| 1 | Проект — единица изоляции данных | Масштабирование через проекты |
| 2 | Модульная архитектура per-project | Разные проекты = разные инструменты |
| 3 | Contextual UI: отключённый модуль = скрыты все связанные элементы | Минимальная когнитивная нагрузка |
| 4 | 5 базовых шаблонов проектов (захардкожены) | Быстрый старт, пользовательские шаблоны — v2+ |
| 5 | Лиды, заявки, продажи = стадии воронки, не отдельные сущности | Deal-centric подход |
| 6 | Контакты создаются явно, не автоматически | Чистая база без мусора |
| 7 | Контакт ↔ Компания = many-to-many | Один человек может работать в нескольких компаниях |
| 8 | Сделка может быть на компанию или на контакт (физлицо) | Поддержка B2B и B2C |
| 9 | Воронка для сделок, этапы для продаж — разные механики | Продажа и исполнение разделены |
| 10 | Канбан доступен и для сделок (воронка) и для продаж (этапы) | Единый UX-паттерн |
| 11 | Продукт определяет тип продажи | Разные продукты = разные процессы оформления |
| 12 | Одна сделка → несколько продаж | Каждый продажа независим |
| 13 | Маркетинг убран в v1, заменён источниками сделок | Справочник + отчёт = 90% потребностей |
| 14 | Двухуровневые роли (системные + проектные) | Платформа vs проект |
| 15 | RBAC + иерархия отделов + шаринг | Гибкая видимость |
| 16 | Каждая запись ВСЕГДА привязана к владельцу (человек или отдел) | Нет «сиротских» записей |
| 17 | Шаринг доступа к отделу = виртуальное членство | Без переноса сотрудника |
| 18 | Флаг «Создание личных проектов» = только создание новых | Существующие проекты не затрагиваются |
| 19 | Биллинг личного и корпоративного пространства независим | Флаг управляет правами, не деньгами |
| 20 | Перелимит = read-only (grandfathering) | Данные не теряются |
| 21 | Грейс-период при неоплате: 7 дней | Мягкий подход |
| 22 | Удалённый сотрудник → проверка по каждому проекту отдельно | Руководителю если он в проекте, иначе «Требует переназначения» + уведомление Admin. Изоляция проектов не нарушается |
| 23 | Удалённый сотрудник → аккаунт = физлицо | Не блокирует человека |
| 24 | Передача между проектами = копируется ТОЛЬКО сделка | Продажи, продукты, активности, контакты, компании НЕ копируются. Полная матрица в 5.4 |
| 25 | Drawer — один, без вложенности, 6-8 полей max | Progressive Disclosure (аккордеон). Обогащение — в карточке |
| 26 | Проверка дублей при квалификации | По email, телефону, ИНН. Проверка и живых и удалённых записей |
| 27 | Merge с shadow-копией 30 дней, откат Admin+ | Защита от ошибок |
| 28 | Единый журнал аудита, два представления (per-entity, per-user) | Одна система, два фильтра |
| 29 | Аудит: CRUD + статусы + входы + merge + шаринг + передачи | Полная прозрачность |
| 30 | Аудит: иерархическая видимость (руководитель → подчинённые) | Согласованность с политиками доступа |
| 31 | Аудит: гибридное хранение (JSON Patch + абсолютные значения ключевых полей) | Patch для UI-diff, абсолютные значения для SQL-аналитики |
| 32 | Soft delete 7 дней → архив 6 мес → hard delete 1 год | Трёхступенчатый retention |
| 33 | Soft delete + unique index: проверка при создании И при восстановлении | Создание: предложить восстановить. Восстановление: если ключ занят → предложить Merge |
| 34 | Архивация проекта = read-only всех данных (включая продажаы) | Статусы фиксируются «как есть» |
| 35 | Массовые операции для Manager+ | Bulk actions без ада кликов |
| 36 | Импорт CSV/Excel (контакты, компании, продукты) | Миграция с других CRM |
| 37 | Конкурентное редактирование: last write + история (v1), live-editing v2+ | Минимальная сложность для v1 |
| 38 | Версионирование Order Type (schema_version) | Обратная совместимость |
| 39 | DLQ для финальных действий (retry + статус ошибки + редактирование полей) | Менеджер может исправить данные и повторить отправку |
| 40 | identity_hash для контактов и компаний (заложить в модель) | Нулевая стоимость сейчас, фундамент для Org Master Data v2+ |
| 41 | Stage log: полный лог входов на каждую стадию (включая возвраты) | Каждый вход = новая запись. Возврат не стирает историю. Фундамент для SLA v2+ |
| 42 | Переданная сделка → первая стадия воронки + метка + подсказка контактов | Система ищет совпадения по лёгким полям в целевом проекте |
| 43 | Self-hosted: заложить в архитектуру (Docker, абстракции), реализовать v2+ | Скорость разработки v1 |
| 44 | Drift Detection: снимок контакта/компании при привязке к сделке/продажау | Менеджер видит что данные изменились после привязки. Для продаж — Must Have (документы, webhook), для сделок — Should Have |
| 45 | Уведомления: in-app (колокольчик) + email, real-time через WebSocket/SSE | Критичные события (DLQ, перелимит, приглашения) не отключаются. Остальные настраиваются per-user |
| 46 | Активности: 4 типа (задача, звонок, встреча, заметка), привязка к любой сущности | Покрывает 90% потребностей менеджера. Повторяющиеся активности — v2+ |
| 47 | Дашборд: фиксированный набор виджетов, адаптивный по ролям и модулям | Настраиваемый дашборд — v2+. Contextual UI: виджеты скрываются при отключении модуля |
| 48 | Глобальный поиск по проекту (по подстроке, ≥ 2 символов) | Результаты группируются по типу сущности, макс. 5 на тип |
| 49 | Фильтры в URL (query params), сбрасываются при уходе. Сохранённые views — v2+ | Минимальная сложность для v1, фильтры шарятся через копирование URL |
| 50 | Запрет удаления стадий/воронок/типов продаж с активными данными | Сначала перемещение, потом удаление. Защита от потери данных |
| 51 | Документы: DOCX-шаблоны с переменными ({{entity.field}}), генерация по клику | Интеграция с Drift Detection: предупреждение если реквизиты изменились |
| 52 | Настройки пользователя: язык, timezone, формат даты. Хранение в UTC, конвертация на UI | Два языка в v1 (русский, английский). Последний вид (список/канбан) запоминается |
Приложение А. Roadmap v2+¶
Все пункты отложены из v1 с сохранением фундамента в архитектуре.
А.1 Платформа и инфраструктура¶
| Направление | Описание |
|---|---|
| Self-hosted | Docker Compose, Helm chart, лицензионный сервер, MinIO, admin-панель on-premise |
| Мобильное приложение | Та же архитектура, другой UI |
| Live-редактирование | Совместная работа с разрешением конфликтов (оптимистичная блокировка → CRDT/OT) |
| Удаление неактивных организаций | Политика: 6 мес уведомление, 2 года hard delete |
А.2 Данные и MDM¶
| Направление | Описание |
|---|---|
| Org Master Data | Глобальный каталог контактов организации с синхронизацией (на базе identity_hash) |
| Кросс-проектная дедупликация | Поиск дублей между проектами одной организации |
| Кросс-проектные отчёты | Аналитика на уровне организации, а не проекта |
| Cross-Project Lineage (граф) | Визуальное дерево передач сделок между проектами |
А.3 Роли и доступ¶
| Направление | Описание |
|---|---|
| Кастомные роли | Конструктор ролей из матрицы прав |
| Кастомные поля | Доп. поля для контактов, сделок per-project |
| SSO / SAML | Enterprise-аутентификация |
А.4 Модули¶
| Направление | Описание |
|---|---|
| Маркетинг | Кампании с бюджетами, email-рассылки, UTM-трекинг, ROI |
| 🚗 Автосалон | Оценка trade-in, запись на показ, каталог авто (VIN, фото, статус) |
| 🍔 Общепит / Доставка | Меню с модификаторами, расширение продаж (адрес, курьер) |
| 🏠 Недвижимость | Объекты, показы |
А.5 Сделки и продажаы¶
| Направление | Описание |
|---|---|
| Мультивалютность | Конвертация, несколько валют в одном проекте |
| SLA per-стадия | Настраиваемые лимиты времени, предупреждения, эскалация (на базе stage_log) |
| SLA-индикаторы в канбане | Светофор: зелёный/жёлтый/красный по времени на стадии |
| Split-View канбан | Сделки + связанные продажаы в одном экране |
| Версионирование Order Type (детальное) | Миграции payload, обратная совместимость, UI обновления |
| Fuzzy merge | pg_trgm, расстояние Левенштейна для нечётких дублей |
| Circuit Breaker для webhook | Паттерн «предохранитель»: при массовых ошибках одного Order Type — пауза + алерт Admin |
А.6 UX и AI¶
| Направление | Описание |
|---|---|
| Drawer-Assistant (AI) | Парсинг текста/звонка в поля сделки, подсказка источника/продукта |
| Пользовательские шаблоны | Сохранить свой проект как шаблон для повторного использования |
А.7 Интеграции¶
| Направление | Описание |
|---|---|
| Входящая/исходящая почта привязанная к сделкам | |
| Телефония | Звонки, запись, привязка к карточкам |
| Мессенджеры | Telegram, WhatsApp |
| API / Webhooks | /p/:pid/settings/api для внешних систем |
| Обогащение по ИНН | Автозаполнение реквизитов компании из внешних сервисов |
| Уведомления | Глобальный центр уведомлений |
А.8 Экспорт¶
| Направление | Описание |
|---|---|
| Экспорт данных проекта | JSON / CSV выгрузка всех сущностей проекта |
| Экспорт отчётов | PDF / Excel выгрузка отчётов |
Документ является основой для проектирования frontend и backend. Не содержит деталей реализации — только бизнес-логика, роли, доступы, процессы и решения.