Farmchel / Motiv Documentation Center
Внутренняя база знаний для ops команды

Business Docs

Процессы, роли, регламенты и операционные правила команды Motiv.

Версия 1.2.0 Изменено: 2026-04-18 Status: Active Owner: Ops Manager

Назначение раздела

Business docs фиксирует, как команда ведёт Motiv в ежедневной работе: цепочки решений, ответственность за сущности, минимально допустимое качество связей и правила эскалации. Это не техническая документация — для неё см. разделы Структура проекта, API и MSP.

Цель раздела — одинаковые ожидания у ops, владельцев приложений и руководства: что считается «готово», когда нужно подключать вторую линию и где искать истину по состоянию портфеля.

Аудитория и способ чтения

РольНа что смотреть в первую очередь
Ops / координаторПроцессы, регламенты, качество данных, эскалации.
Owner приложенияDefinition of Done по приложению, правила статусов и решений.
Responsible стратегииСвязь стратегия ↔ приложение ↔ ключи, блок «Стратегии» в CRM.
РуководительПринципы, решения по blocked/archived, контур эскалации.

Если действие не описано здесь явно — по умолчанию действует правило «фиксируем в системе»: заметка к сущности или обновление полей, без устных договорённостей без следа в Motiv.

Ключевые процессы

Ниже — каркас процессов. Детальный сценарный уровень (кто именно жмёт какую кнопку) может дополняться внутренними чек-листами команды, но статус и связи в CRM обязаны соответствовать этим шагам.

Запуск нового приложения в учёте

  1. Создать карточку приложения (store URL, платформа, базовые метаданные).
  2. Привязать компанию и ответственного владельца (owner).
  3. Назначить или создать стратегию, с которой приложение ведётся по рынку.
  4. Проверить согласованность: статус, стратегия, ключевые слова — не оставлять «пустые» связи без заметки-причины.
  5. Первая операционная заметка — контекст запуска (цель, ограничения, дедлайны обзора).

Обновление стратегии

  1. Проверить актуальность responsible и статуса жизненного цикла стратегии.
  2. Сверить ключевые слова и привязанные приложения — нет ли «висящих» связей.
  3. При изменении методики или масштаба — зафиксировать в заметке, что изменилось и для каких рынков/приложений.

Работа с аналитикой (клики и импорты)

  1. Импорт или ручной ввод строк аналитики завершается проверкой предупреждений и строк с ошибками.
  2. Для строк с классами warning/bad — указать причину или действие в операционном потоке (заметка / смена статуса / эскалация).
  3. Срезы по пресетам на дашборде используются как триггер review, а не как «истина по умолчанию» без контекста в данных.

Передача ownership

  1. Зафиксировать причину и дату в заметке у приложения или связанной сущности.
  2. Обновить поля owner / responsible в соответствии с новым распределением.
  3. Проверить дашбордные сигналы (requires attention), чтобы новый владелец не унаследовал скрытые блокеры.

Запуск приложения

От создания записи до первой осмысленной заметки и проверки связей.

Стратегия

Поддержание актуальности метода, ключей и ответственного.

Аналитика

Импорт → проверка качества → действия по отклонениям.

Ownership

Передача полей владения с текстовым следом в CRM.

Ритм работы (cadence)

Рекомендуемый минимальный ритм — не замена календарю команды, а нижняя граница дисциплины данных.

ИнтервалФокус
ЕженедельноПросмотр приложений и стратегий из блоков «требует внимания», закрытие висящих статусов импорта.
ЕжемесячноСверка топ-компаний/приложений по метрикам с полями ответственности и стратегиями.
По инцидентуЛюбой массовый сбой данных или несогласованность связей — с тикетом/заметкой и владельцем расследования.
Если команда физически не успевает weekly review — сужают объём (только критичные сущности), но не отменяют фиксацию статусов в системе.

Роли и зоны ответственности

РольОтветственность
OwnerФинальное решение по статусу приложения, приоритетам и коммерческому контексту учётной записи.
Ops managerЦелостность связей в CRM, корректность ownership, контроль проблемных и «бесхозных» сущностей.
Strategy responsibleАктуальность стратегии как метода: ключи, статус, связь с приложениями и сигналами.
Contact / AccountКоммуникационный контур по компании: контакты, handoff между командами, операционный контекст.

Границы ролей могут пересекаться в малой команде; тогда важно явно назначать ответственного по сущности в полях CRM, а не полагаться на общую память.

Регламенты

  • Не оставлять приложение без связки owner / company / strategy без записанной причины исключения.
  • Статус сущности обновляется при каждом существенном изменении состояния (не реже события).
  • Решения, влияющие на приоритет или доступность приложения на рынке, фиксируются заметкой у сущности.
  • Завершение импорта данных включает разбор failed rows и проверку дашбордных алертов.
  • Документация по продукту и API — живые страницы /docs/*; при изменении процесса, затрагивающего всех, обновляется соответствующий раздел и повышается версия документа.

Качество данных

Минимальный стандарт качества — возможность восстановить по CRM «кто что решил и почему» через связи, статусы и заметки.

ПроблемаОжидаемое действие
Дубли компаний или приложенийСлияние или пометка с заметкой; не оставлять неразрешённый дубль без владельца задачи.
Пустые обязательные связиЗаполнить или завести явное исключение со сроком пересмотра.
Расхождение статуса и реальностиОбновить статус либо зафиксировать временное состояние в заметке.
Устаревшие ключевые словаОбновление или архивация с причиной в заметке стратегии/приложения.

Эскалации

  • Уровень 1 — исполнитель вносит правки и заметку; ответственный в поле сущности контролирует закрытие.
  • Уровень 2 — ops manager подключается при блокировке процесса, массовых ошибках импорта или конфликте ownership.
  • Уровень 3 — owner / руководство при коммерческих последствиях, блокировке релизов или споре о приоритете портфеля.

Триггеры эскалации: повторяющиеся requires attention по одной сущности, отсутствие ответственного более согласованного срока, риск некорректной отчётности перед внешними стейкхолдерами.

Definition of Done

Application

Есть owner, company, strategy, статус, store URL и последняя операционная заметка по существенным изменениям.

Strategy

Назначен responsible, определены ключевые слова, статус отражает реальную готовность метода к использованию.

Company

Есть актуальный primary contact, видны связанные приложения и стратегии, статус компании осмыслен для ops.

Import batch

Ошибочные строки разобраны или заведены как отложенные задачи с владельцем; целостность ownership не нарушена.

Правила принятия решений

  • Переход в blocked или archived для ключевых сущностей — по согласованию owner и ops manager (или единолично owner при явной делегации в регламенте команды).
  • Архивация стратегии — только после причин, следов в заметках и понимания, что происходит с активными запусками.
  • Эскалация по ownership — через блок внимания на дашборде + заметка с явным адресатом действий.
  • Изменения, затрагивающие отчётность или внешние обязательства, не прячутся в комментариях без обновления статусов.

Глоссарий

ТерминСмысл в Motiv
OwnerВладелец учётной карточки приложения с точки зрения решений и приоритета.
Responsible (стратегия)Человек, отвечающий за актуальность метода и исполнение по стратегии.
СтратегияПовторяемый метод продвижения; не путать с разовым экспериментом без оформления.
Гипотеза / сигналРанние стадии до зрелой стратегии; см. также документ по стратегиям.
Requires attentionСигнал дашборда о нарушении минимальных правил связей или качества данных.

Operational principles

  • Единый источник правды — данные в Motiv, а не переписка.
  • Сначала корректные связи сущностей, затем интерпретация аналитики.
  • Ownership и статусы должны быть согласованы всегда, особенно перед отчётными точками.
  • Документация версионируется: при смене процесса обновляется текст и номер версии на странице docs.