Когда на сайте нужен личный кабинет, а когда это лишнее

«Нам нужен личный кабинет» - зачем?

Личный кабинет (ЛК) - раздел сайта после входа: история заказов, документы, статус заявки, подписка, профиль. Нужен, когда пользователь возвращается регулярно и есть что показывать только ему.

Звучит просто. На деле - нет.

Не нужен, когда цель - один раз оставить телефон на лендинге.

Я обычно спрашиваю: «Сколько клиентов зайдут второй раз в месяц?

Я это слышу раз в неделю.

Что они там будут делать без звонка менеджеру?» Если ответ размытый, ЛК откладываем.

Когда ЛК оправдан

  • Повторные покупки, подписки, SaaS.
  • Долгие сделки: статус ремонта, доставки, документы.
  • B2B: счета, акты, повторные заказы оптом.
  • Обучение: курсы, прогресс, материалы.
  • Бонусные программы с балансом.

Когда ЛК лишний

  • Разовая услуга: юрист, разовый ремонт.
  • Лид с лендинга, дальше всё в CRM у менеджера.
  • «Чтобы было как у больших» без сценария.
КритерийБез ЛКС ЛК
РазработкаБыстрее+2-6 недель
ПоддержкаНижеAuth, безопасность
Конверсия первого визитаВышеБарьер регистрации

Альтернативы ЛК

Telegram-бот со статусом заявки. Email с ссылкой на оплату.

Без магии.

Google Sheet для B2B (временно). Notion portal. ЛK на сайте - не единственный способ «личного».

Telegram vs форма, не всё сразу.

Минимальный ЛК

Email + magic link без пароля. Профиль: имя, телефон. Раздел: «мои заявки» из CRM. Не обязательно сразу OAuth, 2FA, аватарки.

Этап 1: форма + CRM
Этап 2: страница /orders по token из email
Этап 3: полноценный login + история

Безопасность

Пароли, сессии, HTTPS, rate limit, GDPR/152-ФЗ. ЛK - зона повышенного риска. Дешёвый ЛK «на коленке» хуже, чем его отсутствие.

Заказали ЛK, за первый год зашли 40 человек из 2000 клиентов. Бudget лучше вложили бы в форму и рекламу.

ЛK и CMS

WordPress + WooCommerce account, готовые SaaS, custom на React. Выбор зависит от интеграций. Выбор CMS, магазин или каталог.

Интеграция с CRM

ЛK имеет смысл, если данные синхронны с CRM/1С. Иначе клиент видит устаревший статус и злится. API - интеграция без боли.

Метрики

Доля повторных визитов, login rate, действия в ЛK, если <5% регистрируются - пересмотреть нужность.

Что написать в ТЗ

Роли пользователя, поля профиля, список экранов, откуда данные, forgot password, что не в первой версии. ТЗ на сайт.

Сводка

ЛK - для retention и self-service, не для галочки. Сначала заявки и CRM, потом кабинет, когда есть повторные сценарии. Смета - сколько стоит сайт.

SSO и вход через Google

Для B2B иногда проще «Войти через Google» corporate domain, чем пароли. Это уже проект, не MVP. Оцените, сколько клиентов реально залогинятся vs получат PDF по email.

Госуслуги и ESIA - отдельная лiga, не для типового SMB сайта.

Mobile app vs web ЛK

Если клиенты живут в mobile app, web ЛK может быть лишним, сайт - витрина, ЛK в app. Не дублируйте без нужды.

Push-уведомления в web (PWA) возможны, но поддержка сложнее. Честно взвесьте.

Документы в ЛK

Счета, акты, PDF договоров. Нужно хранение, права доступа, audit log, для бухгалтерии B2B это killer feature. Для салона красоты - overkill.

Ещё на практике

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

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

Красные флаги «кабинет не нужен»

Раз в месяц один клиент смотрит статус заказа. Проще письмо или SMS. Нет повторных покупок. Нет документов для скачивания. Тогда кабинет - дорогая игрушка.

Зелёные флаги: подписка, история платежей, загрузка файлов клиентом, лояльность с баллами. Тогда кабинет окупает разработку.

МVP кабинета

Этап 1: вход по email + magic link, просмотр статуса одной заявки. Этап 2: история, документы, оплата. Не тащите Amazon с первого релиза.

Альтернатива: личный кабинет в CRM, на сайте только форма входа «проверить статус по номеру заказа». Дешевле, если заказов мало.

Безопасность

Пароли, сессии, CSRF - зона dev. Заказчик проверяет: не могу зайти в чужой заказ по подбору id. Про CRM - своя или коробка.

B2B кабинет

Опт, дилеры, повторные заказы по договору - кабинет с прайсом по login оправдан. Разовые B2C клиенты - email с треком достаточно.

Коротко на практике

Я solo-разработчик и каждый такой проект веду сам: созвон, оценка, staging, выкладка, передача доступов. Заказчику не нужно разбираться в терминах, но нужно понимать решения: что вы выбрали, почему, что проверить при приёмке. Я обычно фиксирую это в переписке или в ТЗ, чтобы через полгода не вспоминать «а мы же договаривались».

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

После созвона - в документ

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

Hosting, ssl, домен, форма, Метрика - базовая инфраструктура любого сайта, даже если статья про другую тему. См. hosting и ssl и доступы. Покупка сайта целиком - порядок шагов.

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

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

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

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

Личный кабinet. Кabinet оправдан при повторных заказах и личных данных; для разовой заявки с лендинга он только удорожает и редко используется.

Маршрут для заказчика

  1. Опишите сценарий: что клиент делает в ЛK без менеджера.
  2. Посчитайте долю повторных клиентов.
  3. Рассмотрите Telegram или email вместо ЛK на старте.
  4. Заложите ЛK как этап 2 в ТЗ, если сомневаетесь.
  5. Согласуйте минимальный scope: magic link, 2 экрана.
  6. Требуйте HTTPS и политику данных для ЛK.

Ошибки, которые видел на созвонах

  • Заказывать ЛK на лендинге с одной услугой.
  • Не продумать, откуда данные в кабинете и кто их обновляет.
  • Требовать регистрацию до первой заявки.
  • Экономить на безопасности auth.
  • Не считать поддержку ЛK после запуска.

Если нужен код, а не совет. Разработчик оценит auth, API и поддержку; часто честно предложит отложить ЛK и усилить форму и CRM на первом релизе. Ориентиры по срокам и бюджету - на странице цен, услуги - в разделе услуг.

Я так делаю на каждом втором проекте.

Если не зафиксировать это письмом сразу после разговора, через две недели версии расходятся, и спор уже не про дизайн, а про то, кто что обещал.

Сроки плывут отсюда.

Проверено.

Технически всё может быть зелёным в PageSpeed, а на телефоне у клиента страница всё равно «прыгает», потому что баннер подгружается позже текста.

Звучит просто. На деле - нет.

Так.

На практике хватает одного созвона в начале и короткого чек-листа перед публикацией, если промежуточные правки не копятся в мессенджере без даты.

Без магии.

Важно.

Если не зафиксировать это письмом сразу после разговора, через две недели версии расходятся, и спор уже не про дизайн, а про то, кто что обещал.

Проверено на живых проектах.

Проверено.

Хотите обсудить похожую задачу? Опишите сценарий пользователя - скажу, хватит ли формы или нужен кабинет.

Обсудить проект →