Контекст
Разбираем задачи пользователей портала и границы первой версии.
Делаем доступ к сервису, документам и совместной работе простым для пользователя и управляемым для компании. Портал снимает нагрузку с команды, не скрывая важные детали за очередным письмом.
Вы также можете отправить запрос на нашу почту hello@meretti.pro
Не начинаем с экрана. Сначала проверяем, какое решение должен ускорить портал, затем собираем опыт, данные и технологический контур.
Разбираем задачи пользователей портала и границы первой версии.
Описываем роли, доступы и документы, из которых строится портал.
Проверяем сценарии доступа к сервисам в прототипе.
Собираем портал инкрементами с демо рабочих разделов.
Тестируем права доступа, документы и интеграции с сервисами.
Запускаем, смотрим на использование разделов и донастраиваем портал.
Заполните заявку и получите расчёт на ваш проект — и скидку 20% на разработку.
Оставьте номер — пришлём расчёт и скидку 20% в течение 15 минут. Без презентаций и давления.
Фиксируем задачу, риски и критерии успеха портала.
Согласуем структуру разделов, права доступа и интеграционный контур.
Создаём интерфейс портала и проверяем сценарии в прототипе.
Собираем портал инкрементами с демо рабочих разделов каждую неделю.
Тестируем доступы, переносим документы и обучаем команду.
Отслеживаем использование портала и развиваем его по обратной связи.
| Критерий | meretti.pro | Шаблонное решение | Фриланс без команды |
|---|---|---|---|
| Соответствие процессу | Проектируем под ваш сценарий | Ограничено возможностями платформы | Зависит от исполнителя |
| Интеграции | Проверяем и тестируем контур | Часто через плагины | Без системной гарантии |
| Развитие | Архитектура и план следующих версий | Рост усложняется | Зависит от доступности |
| Ответственность | Команда и прозрачный процесс | Поддержка платформы | Один исполнитель |
Перезвоним в течение 2 часов в рабочее время (Пн–Пт, 10:00–19:00 МСК) — коротко разберём объём, сроки и порядок цифр. Без продаж и обязательств.
Оценка зависит от интеграций и объёма данных; фиксируем состав работ до старта.
Клиентский — статусы заказов, документы, обращения. Партнёрский — прайсы, остатки, заявки дилера. Внутренний — заявки HR/IT, базы знаний, согласования. Смешивать все аудитории в одном кабинете без ролей — путь к хаосу прав и утечкам. На старте выбираем одну приоритетную аудиторию для MVP. См. также клиентский портал и портал сотрудников.
Кабинет часто — узкий набор действий вокруг заказа. Портал — рабочая среда с ролями, документами, задачами, уведомлениями и интеграциями. Если пользователи заходят ежедневно и ведут процессы — это портал. Границу проводим по сценариям, не по названию в ТЗ.
CRM/ERP/1С для данных о заказах и контрагентах, почта/мессенджеры для уведомлений, файловое хранилище, SSO при корпоративных требованиях. Список зависит от того, где сейчас «правда» о клиенте и документах. Проектируем обмен так, чтобы портал не стал ручным дублем учёта.
Роли, разграничение объектов (видит только свои данные), 2FA при необходимости, журнал входов, политика паролей, шифрование канала, аккуратная работа с файлами. Для партнёрских порталов особенно опасны «общие логины». Требования ИБ собираем на discovery и включаем в приёмку.
Узкий кабинет статусов — недели. Портал с документами, ролями и несколькими интеграциями — месяцы. Срок упирается в готовность API и качество данных на стороне учёта. Делаем фазы: аутентификация и профиль → ключевые сценарии → интеграции → отчёты. Оценка — после карты ролей в брифе.
Да, если передаём код, документацию и понятную архитектуру. Часто оставляют нам ядро, а контент/мелкие правки забирает внутренняя команда. Договоримся о стандартах кода и зоне ответственности. Права и репозиторий фиксируем в договоре.
Разбираем, из чего складывается разработка портала: карта ролей, права доступа и безопасность, интеграции с CRM, 1С и Active Directory. Реальные сроки, цены и ошибки при выборе подрядчика.
Портал — это не просто раздел «Личный кабинет» с более длинным меню. Разбираем, чем портал отличается от сайта и обычного кабинета и когда компании он действительно нужен.
На первой встрече разберём задачи пользователей, риски и состав первой версии.