Перейти к основному содержимому

Критерии готовности CRM

Зачем нужно​

Документ задаёт проверяемый минимум, по которому CRM можно считать готовой к использованию.

Кто использует​

  • product owner;
  • QA;
  • operations;
  • finance;
  • разработчики.

Сценарии​

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

Данные​

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

Правила​

  • CRM не редактирует данные, которыми владеют identity или LMS.
  • Финансовые изменения воспроизводимы.
  • PII защищена ролями.

Интеграции​

Должны работать сценарии storefront → CRM, billing → CRM, identity → CRM, LMS → CRM и CRM → management.

Безопасность​

Нужно проверить роли, аудит, экспорт и маскирование чувствительных данных.

Нестандартные случаи​

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

Готовность​

  • менеджер видит полную клиентскую картину;
  • оплаты и долги отображаются корректно;
  • доступ к обучению связан с финансовыми правилами;
  • расчёт ЗП преподавателей прозрачен;
  • все ручные корректировки аудируются;
  • роли ограничивают доступ к чувствительным данным.

Детальные критерии​

Документация​

  • границы CRM описаны в scope.md;
  • модель данных описывает account, contacts, leads, deals, orders, billing, balance, entitlement, support, payroll и audit;
  • схема БД содержит append-only balance entries, webhook idempotency и financial audit;
  • все основные сущности имеют статусные модели;
  • API разделяет user endpoints, service endpoints и provider webhooks;
  • DTO и validation описаны для account, lead, invoice, payment webhook, refund, adjustment, entitlement и payroll;
  • матрица прав покрывает PII, billing, refunds, adjustments, payroll, exports и audit;
  • тест-план покрывает financial, security и integration сценарии.

Клиентская карточка​

  • account создаётся вручную и из storefront lead;
  • контакты нормализуются и не создают скрытых дублей;
  • person links отличают payer, parent, student, teacher, contact и guardian;
  • order/entitlement разделяют purchaser, payer, beneficiary и enrollment subject;
  • карточка показывает source каждого read-model блока;
  • учебный summary из LMS не редактируется в CRM;
  • restricted notes видны только разрешённым ролям.

Продажи​

  • storefront submission создаёт lead идемпотентно;
  • lead можно перевести в converted с account/deal;
  • deal won требует order или invoice;
  • order фиксирует price snapshot и product refs;
  • отмена deal/order не удаляет историю коммуникаций.

Биллинг​

  • issued invoice immutable;
  • invoice amount совпадает с суммой invoice items;
  • successful payment создаёт payment и balance entry;
  • duplicate webhook не создаёт повторный payment;
  • partial payment переводит invoice в partially_paid;
  • refund не удаляет payment и создаёт debit entry;
  • adjustment требует reason и permission;
  • balance воспроизводится из append-only entries.

Entitlement​

  • entitlement имеет source: invoice, payment, order или manual;
  • active entitlement публикует событие или command в target domain;
  • refund может создать suspend/revoke decision;
  • CRM хранит trace sync с LMS/competitions/task-bank;
  • revoked/suspended entitlement требует reason и audit;
  • CRM не создаёт LMS enrollment напрямую без контракта владельца.

Payroll​

  • teacher rate имеет период действия;
  • payout calculation использует source activity snapshot;
  • каждая сумма имеет activity/rate/source;
  • manual payroll adjustment требует reason;
  • approved payout immutable без cancellation/new calculation;
  • teacher self-view показывает только свой payout summary.

Интеграции​

  • storefront → CRM lead работает с idempotency;
  • payment provider webhook проверяет signature;
  • CRM → LMS entitlement activation traceable;
  • LMS → CRM learning summary read-only;
  • CRM → management financial/operational events не содержат лишнюю PII;
  • sync logs показывают failed/retry/ignored состояния.

Безопасность​

  • PII маскируется по роли;
  • billing block недоступен без crm.billing.read;
  • support не может делать refund или adjustment;
  • exports требуют crm.exports.create и audit;
  • audit logs доступны только crm.audit.read;
  • payment webhook с invalid signature не меняет состояние;
  • PII не уходит в events и application logs.

MVP acceptance​

MVP CRM можно принимать, если работают:

  1. account/card с contacts и person links;
  2. storefront lead ingestion с idempotency;
  3. deal/order/invoice lifecycle;
  4. payment webhook с signature check и duplicate protection;
  5. append-only balance entries;
  6. refund или adjustment с reason и audit;
  7. entitlement activation и trace sync;
  8. support ticket/timeline;
  9. базовый payroll calculation или documented stub;
  10. tests из test-plan.md для финансовых и sensitive путей.