Портал для дилеров: разработка, карта сервисов и приёмка результата

Разработка портала для дилеров — это в первую очередь проект про управляемые правила работы с партнёрами, и только во вторую — про интерфейс. Прямой ответ на вопрос «с чего начать»: с карты сервисов партнёра — перечня задач, которые дилер решает в системе, и данных, которые для этого нужны. Затем фиксируются роли, уровни, цены, документы и связь с учётными системами. И лишь после этого имеет смысл обсуждать структуру разделов и вёрстку. Ниже — порядок действий, развилки, типичные ошибки, учебный пример и способ принять работу.

Задача бизнеса и границы дилерского портала

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

Важно сразу очертить границы. Портал — это витрина и рабочий кабинет партнёра, а не замена учётной системы. Складской учёт, себестоимость, бухгалтерские проводки и налоговые расчёты остаются во внутренних системах. Портал показывает партнёру то, что ему разрешено видеть, и принимает от него заявки, которые дальше обрабатываются по обычным внутренним правилам. Если эту границу не зафиксировать, проект расползается: заказчик начинает ждать от портала функций ERP, а подрядчик — обещать их, чтобы не потерять сделку. Оба сценария заканчиваются одинаково — переделкой и спором о приёмке.

У задачи есть владелец со стороны бизнеса. Обычно это руководитель отдела продаж или руководитель партнёрской программы. Он отвечает за правила: кто становится дилером, какие у кого цены, какие документы доступны, кто утверждает заявку, как меняется уровень партнёра. Без такого владельца решения принимаются стихийно, и портал быстро расходится с реальной практикой: в системе один набор правил, а в жизни — другой. Поэтому первое, что стоит сделать до обсуждения бюджета, — назначить ответственного и договориться, что он утверждает правила, а не разработчик.

Ещё одна граница — что портал не решает. Он не чинит беспорядок в учёте, не заменяет договорную работу и не берёт на себя юридически значимый документооборот, если для этого нет отдельного процесса. Если данные во внутренней системе противоречивы, портал лишь сделает это противоречие заметным для партнёра. Это неприятно, но полезно: лучше увидеть проблему на этапе проекта, чем после запуска, когда партнёры уже привыкли к кабинету.

Карта сервисов партнёра — обязательный артефакт

Карта сервисов партнёра — это таблица, в которой для каждой задачи дилера описаны входные данные, действие в системе, наблюдаемый результат и ответственный. Это не техническое задание и не прототип интерфейса. Это договорённость о том, что именно делает портал, которую можно проверить до начала работ и по которой потом принимается результат.

Заполняется карта так. Сначала перечисляются задачи партнёра в том порядке, в котором он их решает: узнать условия партнёрства, подать заявку, получить доступ, посмотреть каталог со своими ценами, оформить заказ, отследить его статус, скачать документы, увидеть состояние расчётов, найти обучающие материалы. Затем напротив каждой задачи указывается, откуда берутся данные и кто отвечает за их актуальность. Если для задачи нет источника данных, это не задача портала, а задача внутреннего процесса, которую портал лишь отображает.

Входные данные и ответственные

Для каждой строки карты полезно ответить на четыре вопроса. Что партнёр вводит или запрашивает сам? Что система показывает ему в ответ? Откуда приходит эта информация и с какой периодичностью обновляется? Кто отвечает за то, что данные верны? Последний вопрос чаще всего забывают, и именно он определяет, будет ли портал вызывать доверие. Если за актуальность цены отвечает отдел продаж, а за остатки — склад, это нужно записать, иначе при расхождении никто не поймёт, к кому идти.

Что делать, если источника данных нет

Карта сервисов полезна тем, что обнажает пустые места. Например, партнёр хочет видеть задолженность, но в учётной системе нет однозначной привязки платежей к договорам. Значит, прежде чем показывать цифру в кабинете, нужно навести порядок в учёте, иначе портал будет уверенно показывать неверные суммы. Такие находки на этапе карты экономят месяцы переделок. Если источник данных отсутствует, у проекта есть три честных варианта: отложить задачу, пока не появится источник, показать партнёру не цифру, а статус («данные уточняются»), либо вынести задачу в отдельный этап с явным условием запуска. Молчаливое обещание «сделаем как-нибудь» — худший из вариантов.

Документы, заявки, обучение и уровни партнёров

Партнёрская программа почти всегда многоуровневая, и портал должен это отражать. Уровень партнёра влияет на цену, на доступные материалы и на набор сервисов. Поэтому первым делом описываются уровни и правила перехода между ними: что должен сделать партнёр, чтобы получить следующий статус, и кто это подтверждает. Правила перехода — это не украшение, а рабочий инструмент: если они не описаны, уровень в портале превращается в статичную метку, которую кто-то вручную меняет по звонку.

Заявка на партнёрство и её статусы

Заявка на партнёрство — отдельный сценарий со своими состояниями. В типовых решениях на базе 1С-Битрикс заявку удобно вести через формы, присваивая ей статусы вроде «принята», «утверждена», «отклонена», закрепив за каждым статусом ответственного сотрудника. Это разумная логика: у заявки есть владелец на каждом шаге, и партнёр видит, на какой стадии находится его обращение. Конкретный набор статусов и способ их настройки в актуальной версии продукта стоит уточнять у разработчика и проверять на тестовом контуре, а не переносить из старых описаний.

Практический критерий здесь простой: у каждой заявки в любой момент времени есть ровно один ответственный и понятное следующее действие. Если заявка может «зависнуть» без владельца, сценарий описан не до конца. Отдельно стоит решить, что видит кандидат при отказе: сухое «отклонена» без причины порождает повторные обращения и звонки, поэтому формулировку отказа лучше подготовить заранее.

Документы и права на скачивание

Документы — самая чувствительная часть. Партнёру нужны счета, накладные, акты и другие файлы по его заказам. Здесь важно заранее решить три вопроса: откуда берётся документ, кто имеет право его скачать и как долго он хранится. Если документы формируются во внутренней системе, портал либо запрашивает их по требованию, либо получает заранее. Оба варианта рабочие, но у них разная нагрузка и разное поведение при недоступности внутренней системы. Запрос по требованию даёт свежий файл, но зависит от доступности учёта; заранее полученный файл доступен всегда, но требует места и регламента хранения.

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

Обучение по уровням

Обучение и методические материалы логично привязать к уровню партнёра. Новому дилеру нужны основы и регламенты, опытному — новинки каталога и условия акций. Материалы стоит хранить так, чтобы их можно было обновлять без пересборки портала, иначе каждая правка превращается в задачу для разработчика. Критерий готовности: сотрудник отдела продаж может добавить новый материал и открыть к нему доступ нужному уровню без обращения к подрядчику.

Связь с внутренними системами

Портал не живёт сам по себе: цены, остатки, заказы и документы приходят из учётных систем. В типовых решениях на базе 1С-Битрикс часто применяется интеграция с 1С:Предприятие с двусторонним обменом данными: заказы уходят внутрь, а статусы, цены и документы возвращаются в портал. Это описание подхода, а не гарантия конкретной конфигурации: состав обмена всегда определяется отдельно для каждого проекта и проверяется на тестовом контуре.

При проектировании обмена фиксируются четыре вещи. Первое — какие сущности синхронизируются: номенклатура, цены, остатки, заказы, контрагенты, документы. Второе — направление и частота обмена. Третье — что происходит при расхождении: например, заказ оформлен в портале, а позиция уже закончилась на складе. Четвёртое — поведение при недоступности одной из сторон: портал должен корректно сообщить партнёру о задержке, а не показывать устаревшие данные как актуальные.

Источник истины по каждому полю

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

Поведение при недоступности

Недоступность учётной системы — не гипотетическая ситуация, а нормальная часть эксплуатации. Поэтому заранее описывается, что видит партнёр, если данные не обновились: пометку о времени последнего обновления, сообщение о задержке или временную недоступность конкретного раздела. Критерий: партнёр никогда не должен принимать устаревшие данные за свежие. Это требование проверяется на тестовом контуре отдельным сценарием.

Цены, доступы и роли

Дилерский портал отличается от розничного магазина именно работой с ценами и правами. В типовых решениях на базе 1С-Битрикс часто заводят несколько типов цен и для каждого настраивают права доступа: какие группы пользователей могут покупать по этой цене. Партнёр может видеть несколько ценовых колонок, но оформлять заказ только по той, на которую у него есть право. Такой подход заодно служит мотивацией расти в сети: видеть больше, чем доступно сейчас, — понятный стимул.

Роли описываются до интерфейса. Минимальный набор: гость, зарегистрированный кандидат, действующий партнёр, менеджер партнёра, администратор. Для каждой роли нужно ответить на вопросы: что видит, что может изменить, какие данные ему недоступны. Если на эти вопросы нет ответа до начала вёрстки, интерфейс придётся переделывать, потому что разные роли требуют разной структуры экранов.

Несколько юрлиц под одним аккаунтом

Особый случай — когда один пользователь работает от нескольких юридических лиц. Эта потребность часто встречается в B2B-системах, и решается она через профили покупателя: у одного аккаунта несколько связанных организаций, между которыми он переключается. Критерий проверки: заказы, документы и состояние расчётов одного юрлица не смешиваются с данными другого, а переключение между организациями не требует повторного входа.

Права доступа — это ещё и про администрирование. Кто заводит новых партнёров, кто меняет им уровень, кто видит журнал действий. Эти вопросы удобно разбирать вместе с тем, как устроены Администрирование сайта на Битрикс — доступы, данные и настройки и разграничение прав, чтобы не выдать лишнего и не потерять контроль над системой.

Разработка портала для дилеров: развилки и границы

Не каждую задачу стоит решать в портале. Ниже — таблица принятия решения по типовым ситуациям. Она помогает договориться до начала работ, а не в момент сдачи, когда менять что-то уже дорого.

Учебный пример: портал для дилеров на тестовых данных

Учебный пример. Данные условные и приведены только для иллюстрации порядка работ, а не как статистика.

Входные условия. Компания продаёт оборудование через дилерскую сеть. Есть два уровня партнёров — базовый и привилегированный. Цены хранятся во внутренней учётной системе. Заказы сейчас приходят по почте в свободной форме. Документы формируются в учёте. Часть партнёров работает от двух юридических лиц.

Первый шаг — карта сервисов. Для учебного примера в неё попадают: подача заявки на партнёрство, вход в кабинет, просмотр каталога со своей ценой, оформление заказа, отслеживание статуса, скачивание документов, просмотр состояния расчётов, доступ к обучающим материалам. Напротив каждой задачи указывается источник данных и ответственный. Уже на этом шаге выясняется, что состояние расчётов в учёте привязано к договорам не полностью, поэтому задачу решают показывать как статус, а не как точную сумму, до наведения порядка в учёте.

Второй шаг — роли и уровни. Описываются гость, кандидат, базовый партнёр, привилегированный партнёр, менеджер, администратор. Для привилегированного уровня задаётся своя ценовая колонка. Для партнёров с двумя юрлицами настраиваются профили организаций. Проверяется, что кандидат без статуса не видит дилерских цен.

Третий шаг — обмен с учётом. Определяется, что синхронизируется: номенклатура, цены по уровням, остатки, заказы, документы. Фиксируется источник истины по каждому полю и поведение при недоступности учётной системы. Для учебного примера источник истины по цене — учётная система, портал только отображает.

Четвёртый шаг — сценарии заявки и заказа. Заявка проходит статусы от подачи до решения, у каждого статуса есть ответственный. Заказ принимается в портале, уходит внутрь, а обратно возвращается его статус. Отдельно описывается, что видит партнёр, если позиция закончилась между оформлением и обработкой.

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

Наблюдаемый результат. Партнёр самостоятельно находит свои условия, оформляет заказ и забирает документы. Менеджер перестаёт вручную рассылать прайсы и подтверждать каждую заявку по почте. Ответственный за программу видит, на какой стадии каждая заявка. Это и есть проверяемый эффект, который можно предъявить на приёмке, — в отличие от общих слов про «удобство».

Как проверить результат и принять работу

Приёмка дилерского портала — это проверка правил, а не только внешнего вида. Ниже чек-лист, который стоит пройти до подписания.

• Карта сервисов партнёра заполнена, у каждой задачи есть источник данных и ответственный
• Роли описаны, и для каждой проверено, что видно и что можно изменить
• Ценовые колонки привязаны к уровням, партнёр не видит чужих условий
• Сценарий заявки на партнёрство проходит все статусы и не теряет обращения
• Заказ из портала корректно доходит до учётной системы и возвращается со статусом
• Документы доступны только владельцу и не отдаются по прямой ссылке посторонним
• Поведение при недоступности учётной системы проверено и понятно партнёру
• Партнёр с несколькими юрлицами не смешивает заказы и документы между ними
• Обновление цен и материалов не требует вмешательства разработчика
• Есть план возврата: копия, резервная копия и порядок отката изменений

Полезно заранее продумать, как устроены Резервное копирование сайта на Битрикс — хранение и восстановление и порядок отката, чтобы изменения в портале не оставались без страховки. А перед крупными доработками разумно провести Аудит сайта на Битрикс: как проходит и что вы получите, чтобы понимать текущее состояние системы и не строить новый контур на непроверенном фундаменте.

Типичные ошибки и ограничения

Первая ошибка — начинать с дизайна. Красивый кабинет без продуманных правил цен и ролей быстро расходится с реальностью, и партнёры возвращаются к почте. Внешний вид важен, но он не заменяет договорённостей о данных и правах.

Вторая — размытая граница с учётной системой. Если непонятно, где источник истины по цене и остатку, портал начинает показывать данные, которым никто не доверяет. Партнёр быстро это замечает и перестаёт пользоваться кабинетом.

Третья — один аккаунт на компанию без учёта нескольких юрлиц. Партнёр, работающий от двух организаций, получает путаницу в заказах и документах, а бухгалтерия — лишнюю работу по разбору.

Четвёртая — отсутствие владельца программы. Без ответственного за правила уровни, цены и статусы заявок быстро устаревают, и портал превращается в снимок прошлого года.

Пятая — обещание функций, которых нет. Если подрядчик обещает «всё как в ERP», а учётная система этого не отдаёт, конфликт на приёмке почти неизбежен. Честнее зафиксировать способ проверки, чем заложить в проект предположение, которое потом окажется неверным.

Ограничения тоже стоит назвать честно. Портал не заменяет учёт и не решает проблемы, которые существуют во внутренних данных. Если в учёте нет порядка, портал лишь сделает беспорядок заметнее. Кроме того, состав функций и способ их настройки зависят от версии продукта и конфигурации, поэтому конкретные возможности нужно проверять на актуальной версии и тестовом контуре, а не переносить из старых описаний. Если речь идёт о платформе, стоит отдельно обсудить разработку сайтов на Битрикс и то, какие модули подходят под вашу задачу.

Какие исходные данные подготовить для оценки

Чтобы оценить объём работ, подрядчику нужен не список пожеланий, а факты. Подготовьте следующее.

Список уровней партнёров и правила перехода между ними. Перечень ценовых колонок и то, как цена связана с уровнем. Описание учётной системы и того, какие данные из неё нужны порталу. Список документов, которые должен получать партнёр, и откуда они берутся. Схему ролей: кто что видит и кто что меняет. Примеры реальных заявок и заказов, включая нестандартные. Сведения о партнёрах с несколькими юрлицами. Требования к хранению и доступу к персональным данным партнёров — их стоит согласовать с профильным специалистом.

Чем конкретнее эти данные, тем точнее оценка. Если какой-то пункт неизвестен, это не повод его пропустить: лучше зафиксировать способ проверки, чем заложить в проект предположение, которое потом окажется неверным. Отдельно стоит подготовить ответ на вопрос, кто со стороны бизнеса будет принимать решения по спорным местам, — иначе оценка будет уточняться бесконечно.