Масштаб
Зачем сети партнерский кабинет и когда он пока не нужен
Как понять, когда сети достаточно существующих инструментов, а когда нужен собственный кабинет.
Редакция
Партнерский кабинет нужен не потому, что у крупной компании принято иметь собственный портал. Он нужен, когда повторяемая работа между центром и партнерами теряет управляемость: непонятно, какая версия документа актуальна, кто принял заявку и где остановился запуск точки.
Я начинаю с таких конкретных действий. Если проблема решается согласованной папкой, формой и понятным ответственным, собственная разработка может быть преждевременной. Система оправдана, когда правила, доступы и история уже не помещаются в этот простой процесс.
Выбрать один законченный сценарий
Вместо задания «сделать кабинет франчайзи» полезнее определить результат. Например, партнер получает утвержденные материалы, запрашивает локальную адаптацию, видит решение и использует актуальную версию. Или центр передает обращение, партнер подтверждает прием и фиксирует следующий шаг.
Это разные сценарии с разными данными. Их не обязательно выпускать одновременно. Начальный объем должен включать весь путь выбранного действия, в том числе отказ, исправление и передачу другому ответственному.
Матрица ролей до дизайна экранов
| Роль | Что получает | Что может изменить | Что не должно открываться |
|---|---|---|---|
| Центр сети | Согласованную общую картину | Правила, версии, назначение ролей | Данные вне полномочий конкретного сотрудника |
| Руководитель точки | Задачи и материалы своей точки | Ответственных и состояние работ | Обращения чужих партнеров |
| Исполнитель | Назначенные ему действия | Результат и необходимые уточнения | Не относящиеся к задаче документы |
| Поддержка | Обращения по сопровождению | Статус разбора и комментарий | Коммерческие данные без рабочей необходимости |
У матрицы должны быть проверяемые правила на сервере. Скрытое меню не является защитой данных. OWASP рекомендует запрет доступа по умолчанию и проверку полномочий при каждом запросе. OWASP Authorization Cheat Sheet. Это инженерный ориентир, а не сертификат безопасности конкретного продукта.
Отдельно проектируются приглашение сотрудника, смена роли, прекращение доступа и принадлежность к точке. Проверка должна учитывать не только название роли, но и организацию, данные которой запрашиваются.
Условный пример: устаревшее коммерческое предложение
Представим сеть, где партнер скачал материал из общего чата, а затем продолжил отправлять старые условия. В центре новая версия уже согласована, но никто не знает, кто ее получил.
Кабинет может хранить утвержденную версию, историю замен и подтверждение ознакомления. Однако он не способен автоматически отозвать все ранее скачанные копии. Поэтому дополнительно нужны правила использования и уведомления об изменении. Это условный сценарий для проектирования, не заявление о действующей сети LVUP.
Что должно войти в приемку
Я проверяю путь каждой роли на собственных тестовых данных. Пользователь чужой точки не видит запись даже по прямому адресу; повторное нажатие не создает дублирующую задачу; отзыв доступа прекращает работу с закрытыми данными. Изменение значимого статуса оставляет понятную историю.
Кроме экранов нужны экспорт, резервное копирование, восстановление и ответственный за сопровождение. Пользователь должен понимать, куда обратиться при ошибке. Доступность сервиса и время реакции согласуются отдельно, а не подразумеваются словом «платформа».
Состав приемки удобно записать до разработки. Для сценария передачи обращения он может выглядеть так:
| Проверка | Какой результат нужен |
|---|---|
| Центр назначает обращение точке | Видны адресат, состояние передачи и ответственный; действие не теряется при обновлении страницы |
| Партнер принимает или возвращает задачу | Решение и причина сохраняются, центр видит, где требуется вмешательство |
| Партнер открывает прямую ссылку на чужую запись | Сервер отказывает в доступе, даже если ссылка известна |
| Внешняя CRM временно недоступна | Передача не показывается как успешная; есть понятное состояние ошибки и безопасный повтор |
| Администратор восстанавливает данные | Контрольное восстановление проверяется на отдельной копии, не на рабочей базе клиентов |
Это пример проверок для согласованного сценария, не список уже реализованных возможностей любого продукта LVUP. Для кабинета материалов вместо передачи обращения проверяются версии, согласование и доступ к документам. Одна и та же приемка не подходит всем системам.
Как выбрать между готовым сервисом и разработкой
Сначала я сравниваю существующие инструменты бизнеса с описанным сценарием. Иногда достаточно настройки CRM или управления документами. Собственная система рассматривается, когда подтверждены существенные ограничения готового решения и понятна стоимость владения.
Результат первого этапа: рабочий сценарий, роли, данные, правила доступа и критерии приемки. Расширение на обучение, продажи, поддержку и аналитику возможно последовательно. Большой перечень будущих модулей не должен подменять полезность первого выпуска или создавать впечатление уже доступного функционала.
За что платят отдельно
Если устройство системы еще не определено, сначала нужна архитектура: роли, данные, интеграции, границы первого выпуска и критерии приемки. Ее результатом будет описание решения, не готовый кабинет. Для простой задачи не обязательно покупать отдельную большую архитектуру: сначала проверяется, можно ли ограничить работу одним понятным сценарием.
Разработка внутренней системы рассчитывается на один законченный рабочий сценарий с согласованными ролями и подключениями. Начальная цена не распространяется на все будущие модули сети. До расчета нужны примеры данных, роли пользователей, требования к размещению и описание действующих инструментов. Инфраструктура, платные лицензии, масштабная миграция и сопровождение оцениваются отдельно; поддержка 24/7 не подразумевается.
Собственные технологии LVUP могут стать частью решения, когда подходят задаче. Их наличие не обязывает заменять вашу CRM и не делает любой внешний сервис ненужным. Я определяю, где сохраняется основной источник данных, что связывается интеграцией и кто будет поддерживать систему после запуска.