Личные кабинеты и B2B-порталы для клиентов, партнёров и команд⁠.

Bitrix24 с внешними пользователями или готовый CRM-сценарий могут быть достаточны, если клиенту нужны базовые задачи, коммуникация и доступ к отдельным материалам. Кастомный кабинет становится оправданным, когда важны собственный клиентский UX, нестандартные статусы, документооборот, контроль доступа, журнал действий или интеграция кабинета в уникальный процесс оказания услуги. amoCRM при этом корректнее использовать как CRM для заявок и коммуникаций, а не как полноценный клиентский портал.

Adoption — это продуктовая задача, а не «отправим ссылку». На главной кабинета у клиента понятный следующий шаг, минимальное число полей для заполнения, важные уведомления дублируются в привычных каналах (email, Telegram, SMS для критичных). Внедряем по этапам: в V1 — статус, документы, запросы команды и уведомления; обсуждения, подписи и операционные функции — во второй фазе после того, как клиенты регулярно заходят.

Способ входа выбираем под аудиторию и чувствительность данных: одноразовые ссылки или пароль для простых сценариев, корпоративный SSO для B2B-клиентов, усиленная аутентификация и повторное подтверждение на критичные действия — для процессов с повышенными требованиями. Изоляция клиентских данных проектируется на уровне модели доступа, API и хранения. Правила хранения, удаления и доступа к персональным данным определяются вместе с юридическими требованиями клиента; правовую модель и состав согласий подтверждает профильный специалист клиента.

Да. С Bitrix24, amoCRM, HubSpot и кастомными CRM — через REST API и webhooks. С 1С — через REST API или OData, когда это критично для бухгалтерии. Платёжный модуль подключается опционально: для российского контура — ЮKassa или интернет-эквайринг Т-Бизнеса; сценарии оплаты через СБП — где они применимы. Передачу данных для чеков и обработку событий оплаты реализуем по требованиям, подтверждённым клиентом и его бухгалтером. Международный платёжный контур оценивается отдельно под юридическую и платёжную структуру проекта.

Зависит от типа документов и юридической значимости процесса. Для значительной части кабинетов достаточно «клиент подтвердил, действие в журнале». Если процесс требует юридически значимого подписания, отдельно определяем тип документов, требуемый вид электронной подписи (простая, неквалифицированная или квалифицированная) и подходящего провайдера. Возможны интеграционные сценарии с российскими ЭДО/подписными сервисами, например Контур.Сайн, если они соответствуют требованиям клиента. Юридическую достаточность вида подписи подтверждает профильный юрист клиента.

Да. Формат «Клиентский кабинет V1» (8–14 недель) — это первая рабочая версия кабинета: вход, статусы, документы и запросы команды, уведомления, рабочее пространство команды, журнал чувствительных действий, документация и передача. Платежи, подписание, интеграции и расширенный контроль доступа подключаются в следующих фазах — на основе обратной связи от первых пользователей.

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

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