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