Лендинг или портал: как выбрать формат сайта без переплаты и переделок
Практическая матрица выбора между лендингом и порталом: сценарии, TCO на 3 года, миграция, GetCloud как пример и чек-лист перед стартом разработки.
Вопрос “нам нужен лендинг или портал?” редко про количество страниц. Он про модель бизнеса: одноразовая заявка или повторный сервис, ручная обработка или автоматизация, простая презентация или продуктовая система с ролями, статусами и интеграциями. Ошибка на этом этапе стоит дорого: лендинг начинают превращать в самодельный кабинет, а портал строят там, где хватило бы быстрой проверки спроса.
1. Начните не с формата, а со сценария
Лендинг продает решение здесь и сейчас: объясняет ценность, снимает возражения, ведет к заявке, оплате или консультации. Портал обслуживает пользователя после первого контакта: хранит данные, показывает статусы, принимает повторные действия, подключает поддержку, документы, счета, команды и роли. Это принципиально разные системы, даже если визуально обе начинаются с красивой главной страницы.
В проектах, которые мы запускали, самый надежный ранний сигнал простой: если пользователь после заявки возвращается в интерфейс больше двух-трех раз в месяц, формат лендинга быстро становится тесным. Возникают “временные” таблицы, менеджеры пересылают статусы вручную, клиенты спрашивают одно и то же в мессенджерах, а команда начинает обсуждать “небольшую админку”. Это уже не лендинг, а портал, просто без архитектуры.
- Лендинг отвечает на вопрос: почему стоит оставить заявку или купить сейчас.
- Портал отвечает на вопрос: что происходит с моими данными, заказом, услугой или командой дальше.
- Сайт-презентация оптимизирует конверсию первого касания, портал оптимизирует стоимость повторного обслуживания.
Экспертный ориентир: если ценность продукта заканчивается на “оставьте заявку”, начинайте с лендинга. Если ценность продолжается в статусах, файлах, оплатах, ролях и повторных действиях, проектируйте портал с первого дня.
2. Когда лендинга действительно достаточно
Лендинг не является “дешевой версией нормального сайта”. Хороший лендинг - это сфокусированный инструмент продаж. Он особенно силен, когда у компании один главный оффер, понятная аудитория, короткий цикл сделки и нет необходимости хранить персональные сценарии пользователя внутри интерфейса. В таком случае избыточная архитектура только замедляет запуск и размывает бюджет.
Для нового направления, MVP, рекламной кампании, мероприятия, спецпроекта или проверки спроса лендинг часто выигрывает у портала. Его можно запустить быстрее, измерить конверсию, собрать первые заявки, уточнить позиционирование и только потом решать, нужна ли автоматизация. Важно не путать быстрый старт с одноразовой поделкой: даже лендинг должен иметь нормальную структуру URL, аналитику, скорость, адаптивность и возможность расширения контента.
Типовые признаки “лендинг подходит”
Если продажа происходит через менеджера, а сайт нужен как точка входа в воронку, лендинг закрывает большинство задач. Особенно когда после отправки формы пользователь уходит в CRM, телефонный звонок, почту или мессенджер, а не в собственный кабинет.
- Один продукт, услуга или пакет с понятным результатом.
- Нет личного кабинета, ролей, повторных оплат и статусов.
- Контент меняется редко и не требует сложной редакционной модели.
- Главная цель - заявки, звонки, регистрации или предзаказы.
Где не стоит усложнять
Не надо строить портал ради “солидности”. Пользователю не нужен личный кабинет, если там пусто, нет понятной истории действий и нет причины возвращаться. Пустой кабинет ухудшает впечатление сильнее, чем аккуратная форма и быстрый ответ менеджера.
3. Когда без портала начинается операционный долг
Портал нужен не потому, что “сайт должен быть современным”, а потому что иначе бизнес платит людьми за то, что может делать система. Менеджеры копируют данные между таблицами, бухгалтерия вручную выставляет счета, клиентская поддержка отвечает на вопросы о статусах, администраторы собирают файлы по чатам, а руководство не видит единой картины. Все это скрытая стоимость отсутствующей платформы.
У портала появляется собственная инженерная логика: учетные записи, роли, жизненный цикл заявок, права доступа, уведомления, биллинг, интеграции, история изменений, аудит действий, админка, мониторинг, резервные копии. Это дороже лендинга, но сравнивать нужно не с ценой одной страницы, а со стоимостью ручного процесса за несколько лет.
- Пользователь должен видеть персональные данные, историю, статусы или документы.
- Есть повторные оплаты, продления, заявки, заказы или подписки.
- Нужны роли: клиент, менеджер, бухгалтер, администратор, партнер.
- Сайт должен обмениваться данными с CRM, 1С, биллингом, складом, ERP или внешним API.
- Команда регулярно отвечает на одинаковые вопросы о состоянии процесса.
Портал окупается быстрее всего там, где он заменяет не “красивые страницы”, а повторяемые операционные действия: сверки, статусы, документы, согласования, оплаты и поддержку.
4. Матрица решения: 12 вопросов перед бюджетом
Перед обсуждением дизайна полезно пройти короткую матрицу. Она не заменяет проектирование, но быстро показывает направление. Если большинство ответов в правой колонке, портал почти наверняка нужен. Если ответы в левой, лучше стартовать с лендинга и не замораживать деньги в лишней архитектуре.
Сигналы в пользу лендинга
Вы продаете один основной продукт, не храните пользовательскую историю, не принимаете повторные действия внутри сайта и можете обрабатывать заявки через CRM. Контент важен, но бизнес-процесс после заявки живет вне сайта.
- Сделка разовая или редкая.
- Менеджер вручную ведет клиента, и это экономически оправдано.
- Нет требований к персональному доступу и хранению документов.
- Главная неопределенность - спрос и позиционирование.
Сигналы в пользу портала
У вас есть повторяемый сервисный цикл: клиент заходит, делает действие, получает статус, оплачивает, скачивает, согласует, создает новую заявку или управляет командой. Здесь интерфейс становится частью продукта, а не рекламной обложкой.
- Есть разные роли и права доступа.
- Нужны интеграции и надежная синхронизация статусов.
- Поддержка перегружена повторяющимися вопросами.
- Ручные операции мешают масштабировать продажи.
5. TCO на 3 года: почему “дешевле на старте” не всегда дешевле
Полная стоимость владения складывается из разработки, поддержки, доработок, контента, инфраструктуры, лицензий, интеграций, ручного труда и потерь от ошибок. Лендинг почти всегда дешевле в первом релизе. Но если через полгода его начинают “обвешивать” кабинетами, платежами, выгрузками и самодельной админкой, TCO растет не линейно, а скачками.
Портал дороже проектировать: нужно описать сущности, права, статусы, API, тестовые контуры, безопасность, мониторинг. Зато правильно построенная основа снижает стоимость каждой следующей функции. Добавить новый тариф, роль, уведомление или тип заявки становится обычной задачей, а не переписыванием всего проекта.
Упрощенный расчет
Представим сервис, где 3 менеджера каждый день тратят по 2 часа на статусы, счета, файлы и уточнения. При полной стоимости сотрудника 180-250 тысяч рублей в месяц это 130-180 тысяч рублей операционного времени ежемесячно. За три года даже без учета ошибок получается 4,7-6,5 млн рублей. Если портал снимает половину нагрузки, он может окупить разницу между лендингом и платформой быстрее, чем кажется.
Что обычно забывают в TCO
В смету часто не включают обучение сотрудников, ручные сверки, исправление дублей в CRM, поддержку “потерянных” заявок, время руководителя на контроль процесса и стоимость технического долга. Но именно эти статьи объясняют, почему дешевые решения неожиданно становятся дорогими.
- Часы поддержки и менеджеров.
- Ошибки в ручном переносе данных.
- Потери заявок и задержки ответа.
- Стоимость срочных переделок после роста нагрузки.
Считайте не только “сколько стоит разработка”, а “сколько стоит выбранная модель работы в течение трех лет”. Это меняет разговор с цены страницы на экономику процесса.
6. GetCloud как пример эволюции: лендинг на входе, портал в основе
В проектах уровня GetCloud посадочная часть важна: она объясняет услугу, тарифы, сценарии использования и ведет пользователя к конфигуратору. Но основная ценность появляется после выбора: личный кабинет, биллинг, управление услугами, статусы, документы, поддержка, интеграции с провижинингом и внутренними системами. Если строить это как “лендинг плюс формы”, проект упрется в потолок почти сразу.
Правильная архитектура разделяет маркетинговую поверхность и сервисную часть. Маркетинг может быстро менять тексты, блоки и посадочные страницы. Портал сохраняет устойчивые контракты данных, права доступа, финансовую логику и операционные процессы. Тогда изменение оффера не ломает биллинг, а новая интеграция не требует переписывать публичный сайт.
- Публичная часть отвечает за спрос, объяснение и SEO.
- Кабинет отвечает за повторные действия и сервис.
- Админка отвечает за управление процессом и исключениями.
- Интеграционный слой отвечает за обмен с внешними системами.
7. Миграционный путь: как стартовать с лендинга и не загнать себя в угол
Не каждый бизнес должен сразу строить портал. Но почти каждый бизнес должен понимать, что будет, если гипотеза подтвердится. Поэтому хорошая стратегия - стартовать с лендинга, но проектировать его так, чтобы будущий портал не требовал уничтожить все сделанное. Это означает нормальные URL, ясную модель контента, аналитические события, аккуратную интеграцию с CRM и отсутствие решений, которые держатся на ручных копиях данных.
Первая версия может включать только публичные страницы, форму заявки, аналитику, SEO-основу и простую интеграцию. Вторая - кабинет с авторизацией и историей заявок. Третья - платежи, документы, роли и автоматические статусы. Четвертая - расширенная админка, интеграции, отчеты и SLA. Такой путь дает бизнесу скорость, но не отрезает рост.
Что заложить уже в первой версии
Даже если портал пока не нужен, полезно заранее зафиксировать сущности: заявка, клиент, тариф, услуга, документ, оплата, статус. Их не обязательно сразу реализовывать в базе, но команда должна одинаково понимать язык будущего продукта.
- Единые события аналитики для заявок и конверсий.
- CRM-интеграция без ручного копирования.
- Контентная структура, которую можно расширять.
- Техническое SEO: sitemap, canonical, мета-шаблоны, редиректы.
Самая дорогая миграция - та, где никто заранее не описал данные. Дизайн можно сменить относительно спокойно, а вот хаотичные заявки, статусы и документы приходится распутывать месяцами.
8. Частые ошибки при выборе формата
Главная ошибка - выбирать по бюджету первого месяца, а не по жизненному циклу клиента. Вторая - считать портал “набором страниц за логином”. Третья - думать, что интеграции можно безболезненно добавить потом, когда все уже запущено. В реальности интеграции влияют на модель данных, безопасность, тестирование, мониторинг и поддержку.
Еще одна распространенная ловушка - делать “универсальный” проект без приоритетов. Команда пытается одновременно запустить SEO-раздел, кабинет, платежи, блог, админку, CRM, рассылки и аналитику. В итоге первый релиз раздувается, бизнес поздно получает обратную связь, а качество страдает. Лучше выбрать минимальный полезный контур и расширять его релизами.
- Строить портал без описания ролей и статусов.
- Оставлять интеграции “на потом”, не учитывая их в модели данных.
- Пытаться заменить продуктовую логику красивыми блоками на главной.
- Не считать поддержку, мониторинг и резервное копирование.
- Запускать личный кабинет без сценариев, ради галочки.
9. Что подготовить перед разговором с подрядчиком
Хороший подрядчик поможет сформулировать требования, но не должен угадывать бизнес-процесс из воздуха. Перед оценкой соберите карту сценариев, список ролей, источники данных, текущие ручные операции, интеграции, ограничения по безопасности и ожидания по развитию на 12-18 месяцев. Это резко повышает точность оценки и снижает риск “сюрпризов” после старта.
Минимальный пакет для оценки
Не нужен идеальный документ на сто страниц. Достаточно структурированного брифа: кто пользователь, что он делает, какие данные вводит, какие статусы получает, кто внутри компании обрабатывает процесс, какие системы уже используются и какие метрики определяют успех.
- Цели проекта и критерии успеха.
- Сценарии пользователей и внутренних сотрудников.
- Список интеграций и владельцев внешних систем.
- Требования к SEO, аналитике, безопасности и языкам.
- Ожидаемые этапы развития после первого релиза.
10. Итоговый чек-лист выбора
Выбирайте лендинг, если сейчас нужно быстро проверить спрос, объяснить оффер и собрать заявки без сложной логики после отправки формы. Выбирайте портал, если сайт должен стать рабочим интерфейсом бизнеса: обслуживать клиентов, хранить историю, управлять статусами, проводить оплаты, синхронизироваться с системами и снижать ручную нагрузку.
Самая практичная стратегия - не спорить о формате в вакууме, а описать жизненный цикл клиента и посчитать экономику. Тогда решение становится инженерным и управленческим одновременно: что запустить сейчас, что заложить в архитектуру, какие риски принять и какой путь миграции оставить открытым.
- Если пользователь не возвращается - лендинг почти всегда рациональнее.
- Если пользователь возвращается и работает с данными - проектируйте портал.
- Если сомневаетесь - запускайте лендинг с архитектурой будущей миграции.
- Считайте TCO на 3 года, а не только цену первого релиза.
Формат сайта должен следовать за бизнес-процессом. Когда процесс простой, лендинг дает скорость. Когда процесс повторяемый и дорогой вручную, портал становится не роскошью, а способом управлять ростом.