Как выбрать подход к созданию партнерского портала
Партнерский портал — это не просто сайт, а инструмент работы с партнерами. На примере реального проекта рассказываю, с какими задачами сталкиваются компании и как избежать типичных ошибок при запуске.
История: партнерский портал
Более пятнадцати лет я руководил российским представительством одной известной канадской компании, занятой разработкой ПО. При наличии весьма обширной партнерской сети в России и странах СНГ создание партнерского портала было крайне необходимо. И нам в начале казалось, что задача вполне понятная. Нужно сделать раздел для партнеров, добавить форму регистрации, разместить материалы, конечно, раздел «Где купить», плюс, дать доступ партнерам в Личный кабинет. На словах все это выглядит элементарно.
Сразу было ясно, что партнерский портал — это не страница на сайте. На дворе был 2007 год, и мы выбрали прогрессивный по тем временам «Битрикс: Управление сайтом», альтернатив было немного. Но даже сейчас я не могу однозначно сказать, что в итоге это было именно выигрышное решение.
Уже в первой версии партнерский портал выглядел достаточно круто: каталог партнеров, новости, материалы. И даже автоматическая генерация партнерских дипломов. Но затем началось то, что обычно недооценивают на старте: одного партнера нужно проверить, другому выдать статус, третьего добавить не сразу, кому‑то открыть доступ к нужным материалам, а кому‑то ответить, где искать диплом или нужный файл. Вывод: партнерский портал почти никогда не оказывается тем, чем кажется в начале.
И еще важное. Партнерский портал — это не только набор функций, заложенных в ТЗ. Это еще и практическое отражение партнерской программы компании. И здесь особенно важно, чтобы все заложенные в программе принципы не оставались декларацией на бумаге, а реально соблюдались в работе; чтобы фраза «в качестве исключения» в переписке с партнерами появлялась действительно только в самых крайних случаях.
Чем дальше наш партнерский портал развивался, тем больше идей по его функционалу появлялось. Почти сразу стало понятно, что партнеру нужно назначать автоматически статус при выполнении определенных условий, и от этого статуса зависит многое.
Задач становилось все больше. Потребовались разнообразные оповещения — например, об окончании партнерского статуса. Появились компетенции партнеров. Затем понадобился механизм регистрации сделки — простой и надежный. Вдобавок — публичная ссылка на регистрацию сделки. Экзамен sales специалиста. И так далее — задач было много, и многое в итоге реализовали. И в итоге да — получилось относительно эффективно, хотя местами было странно. Но это понятно — ведь предвидеть всю схему портала на старте было нереально.
В итоге сеть из более чем 500 партнеров вполне управлялась одним сотрудником — и это, наверное, главный показатель, что система в целом работала хорошо. Но на то, чтобы создать это продвинутое решение ушло около 15 лет. А потом наступил 2022 год, и канадская компания в течение недели закрыла бизнес в России. Но сейчас речь не об этом.
- Аналитики назвали регионы с самым высоким заработком для таксистов
- СДЭК упростил отправление заказов с Авито по модели DBS
- В Телеграме появились стили для ИИ‑редактора и новые инструменты для опросов
- Аналитики Wildberries назвали ключевые факторы для выбора товара покупателем
- Wildberries снижает комиссии с продаж для ряда категорий с 7 мая
- 9 мая в Москве не будет работать мобильный интернет, включая белые списки
Теория: какой путь выбрать для создания партнерского портала
Если сегодня встает задача построить партнерский портал, на практике вариантов не так много. По сути, их три.
Первый путь — делать с нуля. Классическая история: берется подрядчик или внутренняя команда, пишется ТЗ, начинаем разработка. На старте кажется, что так можно учесть все особенности бизнеса (согласен — это важно) и сделать «как надо». В реальности почти всегда получаем длинный проект с постепенным наращиванием функционала. Что‑то сразу не предусмотрели, что‑то поменялось по ходу, что‑то оказалось сложнее, чем выглядело на бумаге, затем кого‑то уволили. В итоге партнерский портал постепенно обрастет доработками, а сроки и бюджет начнут жить своей жизнью. Приемлемый вариант для тех, у кого много времени и денег.
Второй путь — собрать на CMS. Тоже понятный и логичный вариант. Берется готовая платформа (примеры вам известны), добавляем модули, формы, роли, права доступа, интеграции, и кажется, что задача решена быстрее и дешевле. На старте так и есть. Но по мере развития портала выясняется, что типовые механизмы CMS не позволяют реализовать нужный функционал. Например, при попытке автоматической генерации партнерских дипломов в PDF с подстановкой данных и встроенными изображениями (логотипы и партнерские плашки) быстро становится понятно, что стандартных средств недостаточно. Начинаются доработки, кастомные решения. В какой‑то момент система становится смесью стандартных возможностей и накопленных «доработок под себя», и каждое обновление CMS начинает нести в себе элемент непредсказуемости: что‑то может работать как раньше, а что‑то потребовать немедленного вмешательства.
Третий путь — использовать специализированный продукт. Это менее очевидный вариант, потому что раньше таких решений на российском рынке почти не было (на Западе при этом давно существует отдельный сегмент PRM — Partner Relationship Management, систем для управления взаимодействием с партнерами). Сейчас такие продукты начинают появляться и в России. Логика здесь простая: если партнерский портал — это не страница на сайте, а отдельный процесс, то и инструмент под него должен быть отдельный.
Важно, что ни один из этих рассмотренных вариантов сам по себе не является «правильным» или «неправильным». Все зависит от масштаба задачи и ожиданий от портала. Но выбирая третий вариант, вы сэкономите не только время и деньги, но и получите уже накопленный опыт внедрения партнерских порталов у разных компаний. В том числе те нюансы, которые почти невозможно заранее предусмотреть в ТЗ при разработке с нуля или сборке на CMS.
Практика: от разработки к продукту
Пару лет назад ко мне обратился знакомый с просьбой сделать похожий партнерский портал — по сути, воспроизвести решение, над которым я работал много лет, но уже быстрее и без длинного цикла доработок.
В этот раз задача решалась иначе. Вместо того чтобы снова идти по пути постепенной разработки, мы постарались сразу заложить те принципы, к которым обычно приходят только через несколько лет эксплуатации:
- статусы партнеров должны быть встроены в логику системы, а не существовать отдельно;
- доступ к материалам должен автоматически зависеть от статуса и роли;
- ключевые процессы (регистрация партнера, сделки, уведомления) должны быть изначально предусмотрены, а не добавляться позже;
- система должна масштабироваться без постоянной переработки архитектуры;
- важно учитывать не только запуск, но и дальнейшую стоимость сопровождения.
По сути, задача свелась не к разработке “еще одного портала”, а к формированию более универсального подхода, который можно применять в разных компаниях.
Именно из этого подхода позже и вырос отдельный продукт — PartnerOS. Но в данном случае важнее не сам инструмент, а логика: партнерский портал стоит изначально строить как систему процессов, а не как набор страниц и доработок.
Если этот принцип заложен на старте, это позволяет сэкономить не только время запуска, но и годы последующих изменений.
- партнерский портал — это не раздел сайта, а рабочая система;
- основная сложность проявляется не на старте, а в процессе развития;
- самописная система и CMS часто приводят к накоплению доработок;
- специализированный продукт позволяет сократить сроки и упростить поддержку.
