Личный кабинет клиента
Клиент видит свои заказы, документы, статусы, историю обращений и оплаты. Часть звонков в компанию исчезает сама: ответ уже есть в кабинете.
Снимает нагрузку с менеджеров и колл-центра.
Личные кабинеты клиентов и сотрудников, отраслевые сервисы, системы записи и приёма заявок, внутренние порталы. Это уже не сайт, а рабочий инструмент: в нём есть роли, данные и ответственность за то, что он не должен останавливаться.
У сайта-визитки сбой означает потерянную заявку. У портала, через который клиенты подают документы, а сотрудники ведут работу, сбой означает остановку процесса: люди не могут записаться, заявки не движутся, руководитель не видит, что происходит. Разница между этими двумя вещами не в дизайне, а в требованиях к данным, правам доступа и надёжности.
Поэтому в проектах такого рода мы с самого начала думаем не только о функциях, но и о том, где сервис развёрнут, как разграничены роли, что происходит при росте числа пользователей, откуда берётся резервная копия и кто отвечает на обращения. Разработка и эксплуатация здесь — одна задача, а не две.
Клиент видит свои заказы, документы, статусы, историю обращений и оплаты. Часть звонков в компанию исчезает сама: ответ уже есть в кабинете.
Снимает нагрузку с менеджеров и колл-центра.
Рабочее место для внутренней роли: задачи, объекты, документы, отчёты по своему участку. Доступ по логину, а не по общему паролю на всю компанию.
Полезно там, где сотрудники работают вне офиса.
Заявка попадает в систему, назначается ответственному, проходит по этапам с уведомлениями и историей. Видно, где она сейчас и кто её задерживает.
Заявки перестают жить в почте и мессенджерах.
Онлайн-запись на приём, услугу или осмотр с проверкой занятости, напоминаниями и переносами. Расписание синхронизируется с внутренней системой.
Частая задача в медицине и сервисных компаниях.
Публичный сервис со своей логикой: каталоги организаций, площадки для подбора, платформы регистрации участников. Продуктовая задача, а не сайт компании.
Проектируем под сценарий пользователя и рост аудитории.
Единая точка входа для сотрудников: документы, регламенты, справочники, объявления, ссылки на рабочие системы, поиск по внутренней базе знаний.
Работает в связке с сопровождением ИТ и учётными записями.
Внешне и то и другое открывается в браузере. Разница проявляется в требованиях, и именно она определяет стоимость и сроки работ.
| Что сравниваем | Сайт | Онлайн-сервис или портал |
|---|---|---|
| Кто пользуется | Анонимный посетитель, который читает и оставляет заявку | Авторизованный пользователь с ролью, который работает в системе |
| Данные | Тексты, товары, изображения — их правит редактор | Заявки, документы, статусы, персональные данные пользователей |
| Права доступа | Разделение только на посетителя и администратора | Роли, уровни доступа, разграничение по подразделениям и объектам |
| Последствия сбоя | Потеряна часть обращений за время недоступности | Остановлен рабочий процесс у клиентов и сотрудников одновременно |
| Инфраструктура | Достаточно типового размещения с базовыми копиями | Сервер под нагрузку, мониторинг, регулярные копии, отлаженные обновления |
| Жизнь после запуска | Наполнение и периодические доработки | Постоянное развитие по обратной связи и поддержка пользователей |
Внешний контур: клиент сам записывается, подаёт заявку, следит за статусом и получает документы. Требования к удобству и защите персональных данных здесь выше всего.
Внутренний контур: рабочие места, ведение объектов и задач, отчётность по участкам. Здесь важнее скорость ввода данных и точность прав доступа, чем внешняя эффектность.
Чаще всего оба контура живут в одной системе: клиент подаёт заявку во внешнем кабинете, сотрудник обрабатывает её во внутреннем, а руководитель видит сводку по обоим.
Площадка под сервис с ресурсами по реальной нагрузке и запасом на рост.
Подробнее →
Копии базы и файлов сервиса с проверкой того, что они разворачиваются.
Подробнее →
Внутренняя часть, куда попадают заявки и данные из личного кабинета.
Подробнее →Тем, что в нём есть авторизация и персональные данные конкретного пользователя. Это меняет всё: нужны роли и права, защита данных, журнал действий, восстановление доступа, продуманное поведение при ошибках. По объёму работ кабинет ближе к информационной системе, чем к странице сайта.
Иногда да, и мы говорим об этом честно. Для записи на услуги, приёма обращений и простых кабинетов существуют готовые сервисы, и если ваш процесс в них укладывается — это дешевле и быстрее. Разработка оправдана, когда логика отраслевая, требуется глубокая связь с внутренними системами или готовые продукты не дают нужного разграничения доступа.
Мы проектируем сервис так, чтобы данные хранились в контролируемом контуре, доступ к ним был разграничен по ролям, действия журналировались, а резервные копии были защищены. Размещение подбирается с учётом требований к хранению. Организационную часть — согласия, политики, регламенты — компания оформляет со своей стороны, мы подсказываем, что технически уже реализовано.
Ресурсы сервера расширяются без переписывания сервиса, если архитектура изначально это допускает, — поэтому мы закладываем такую возможность даже в небольших проектах. Мониторинг показывает, когда система приближается к пределу, и расширение делается заранее, а не после первого отказа в час пик.
Да, если есть доступ к исходному коду и понятно, где и как он развёрнут. Начинаем с разбора: состояние кода, окружение, наличие копий, что работает и что держится на честном слове. По итогам говорим прямо, что разумнее — развивать существующее или переносить логику в новое решение.
Это решается на старте. Обычно первую линию берёт на себя заказчик — сотрудники, которые знают процесс, — а технические обращения и доработки идут к нам через поддержку. Если своей линии нет, обсуждаем вариант, при котором обращения принимаем мы.
Расскажите, кто будет пользоваться системой и какой процесс она должна закрыть. Предложим состав первой версии и посчитаем работы.
Сервисы редко проваливаются из-за технологий. Гораздо чаще причина в том, что модель ролей продумана поверхностно, объём первой версии оказался неподъёмным, а после запуска сервисом никто не занимался. Ниже — вопросы, которые мы разбираем до начала разработки.
«Потом добавим права» — самая дорогая фраза в таких проектах. Разграничение доступа пронизывает всё: какие записи видит пользователь, какие поля может менять, что попадает в отчёты, что уходит в уведомления. Если модель ролей появляется в конце, её приходится вшивать в готовый код по всем экранам сразу. Мы описываем роли на этапе прототипа, вместе с ответом на вопрос, что происходит, когда сотрудник меняет должность или увольняется.
Соблазн заложить в сервис всё сразу очень велик, но чем длиннее список функций, тем позже сервис попадёт к живым пользователям — и тем больше шанс, что половина из этих функций окажется никому не нужна. Мы предлагаем выделять ядро: один-два ключевых сценария, ради которых всё затевалось. Остальное добавляется после того, как система начала работать и появилась реальная обратная связь.
Проектировать внутренний портал на несколько десятков сотрудников так, будто им будут пользоваться миллионы, — трата денег заказчика. Но и не думать о нагрузке нельзя: у публичных сервисов бывают всплески, у систем записи — часы пик, у отчётов — тяжёлые запросы. Мы оцениваем реальный профиль и подбираем сервер под него, с возможностью расширить ресурсы, когда поток вырастет.
Сервис почти никогда не живёт в одиночестве: ему нужны данные из учётной системы, отправка писем и сообщений, оплата, иногда телефония и подтверждение по звонку. Каждая такая связь — отдельная работа со своими ограничениями на стороне чужой системы. Поэтому список интеграций мы фиксируем до оценки, а не выясняем по ходу. Подробнее — в разделе автоматизации и интеграций.
Работающий сервис копит данные, обрастает пользователями и упирается в вещи, которых никто не предвидел. Нужны мониторинг доступности, регулярные резервные копии с проверкой восстановления, обновления без простоя — это зона DevOps — и человек, который отвечает пользователям. Последнее закрывает поддержка сервисов. Примеры того, какие системы мы уже делали, есть в разделе проектов.