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