ЕЛЕНА ТОНКИХ · PMELENA TONKIKH · PM
ГлавнаяHome /КейсыWork/ Кейс 02 · X-Keeper — 2025Case 02 · X-Keeper — 2025
Кейс · 2025–2026 · Senior Product ManagerCase · 2025–2026 · Senior PM

Самостоятельная работа вместо звонка менеджеру Self-service instead of a support call

−20%запросов в техподдержку
по перенастройке устройств
support tickets
on device reconfiguration
+9%сессий в личном кабинетеsessions in the customer dashboard
×4сессий в мобильном приложенииmobile-app sessions

В B2B-платформе для удалённого мониторинга транспорта пользователи писали в поддержку за тем, что уже могли сделать сами. Я пересобрала ключевые сценарии: настройку устройств, работу
с объектами и получение данных без помощи менеджера.

On a B2B telematics platform, users were calling support for actions already available in the dashboard. I rebuilt the key flows so clients could configure devices, manage assets and pull data themselves — without a manager

КомпанияCompany
X-Keeper
РольRole
PM / PO
ПродуктProduct
Личный кабинет + мобильное приложениеCustomer dashboard + Mobile
ФокусFocus
Самостоятельная работа пользователейUser self-service
ГодYear
2025–2026
Карта клиентских сценариев X-Keeper: AS IS и TO BE
Карта клиентских сценариев X-Keeper: переход от текущей логики к новой модели самостоятельной работыX-Keeper customer scenario map: from the current logic to a new self-service model
01 КонтекстContext

Контекст

Context

Для компании. X-Keeper развивал личный кабинет как основной инструмент удалённого контроля и масштабирования B2B-платформы. В соседнем кейсе про объектную модель фокус был на том, как показать ценность связки устройств. Здесь задача была другой: снизить зависимость клиентов от менеджеров
и техподдержки в ежедневных сценариях

For the business. X-Keeper was developing the dashboard as the main remote-control tool and a scalable B2B platform. The adjacent case focuses on making the value of connected devices visible. This case had a different goal: reduce clients' dependence on managers and support in everyday scenarios.

Про метрики. Личный кабинет не был каналом роста пользовательской базы, поэтому увеличение Session Length не считалось целевым результатом. Для такого продукта ценнее обратное: пользователь быстрее находит нужный сценарий, завершает действие без менеджера и реже обращается в поддержку

About metrics. The dashboard was not a user-acquisition channel, so higher Session Length was not a target outcome. For this product, the value is the opposite: users find the right flow faster, complete the task without a manager and contact support less often.

Для клиентов. Пользователи уже могли настраивать устройства, смотреть события, работать с объектами и мобильным приложением. Но сценарии были распределены между разделами, зависели от скрытых настроек и требовали знания внутренней логики продукта. Поэтому часть операций уходила в поддержку, хотя функциональность уже была в ЛК

For clients. Users could already configure devices, view events, work with objects and use the mobile app. But the flows were split across sections, depended on hidden settings and required knowledge of the product's internal logic. As a result, some operations still moved to support even though the functionality was already in the dashboard.

02 СтратегияStrategy

Стратегия

Strategy

Стратегия была в том, чтобы перевести ключевые сценарии в понятную самостоятельную работу внутри личного кабинета. Пользователь должен видеть следующий шаг, понимать зависимости между настройками и завершать настройку устройства, работу с объектом или получение данных без обращения к менеджеру

The strategy was to turn key flows into clear independent work inside the dashboard. Users should see the next step, understand dependencies between settings and complete device setup, object work or data retrieval without contacting a manager

Меньше обращений в поддержку начинается с понятной продуктовой логики

Not «fix the screen» — finish the scenario, with no hidden toggle buried in the settings

Логика самостоятельной работыSelf-service principle
03 РешенияApproach

Что я сделала

What I did

A · НавигацияNavigation

Табличный вид для больших кабинетов

Sidebar for large fleets

В больших кабинетах карта переставала быть основным рабочим инструментом: из-за нагрузки пины отключались, а пользователь работал с длинными списками объектов. Табличный вид помог быстро сортировать парк, находить нужный объект и переходить к действию без лишних открытий карточек.

Three modes: two for focusing on a selected asset and one tabular mode for large lists. In big fleets the map pins were turned off by default due to load — the tabular mode brings the value back.

B · СценарииFlows

Улучшение сценариев

No dead-end scenarios

Я убрала места, где пользователь упирался в скрытую зависимость. Например, автоматизация могла быть настроена по событию, но передача нужных событий с устройства была отключена. Теперь система включает зависимые настройки автоматически или подсказывает следующий шаг.

An automation could be set on an event while the device wasn't sending it. Now the system enables dependent settings automatically — or shows the next step.

C · АналитикаAnalysis

Таймлайн и второй показатель

Timeline + a second metric

Маршрут на карте теперь сопоставляется с высотой, скоростью и другими показателями: ползунок на таймлайне, два показателя одновременно. Личный кабинет становится инструментом анализа, а не просто просмотра.

The route on the map is now matched against altitude, speed and other metrics — a timeline scrubber and two metrics at once. The dashboard becomes an analysis tool, not a viewer.

D · Мобильное приложениеMobile

Перезапуск мобильного на Kotlin Multiplatform

Mobile relaunched on Kotlin Multiplatform

Главный экран со списком объектов, раздел уведомлений, обновлённый экран объекта и настройки. KMP — чтобы не поддерживать две платформы отдельно.

A main screen with the object list, notifications, an updated object screen and settings. KMP — to avoid maintaining two platforms separately.

04 До / послеBefore / after

Как изменился личный кабинет

How the dashboard changed

Переход от карты с перегруженным сайдбаром к табличному виду для больших кабинетов.

A shift from a map with an overloaded sidebar to a tabular view for large accounts.

Стало: табличный вид для больших кабинетов
Было: карта с перегруженным сайдбаром
Было Before Стало After

Табличный вид для больших кабинетов: объекты, статусы и ключевые параметры в одном рабочем спискеTabular view for large accounts: objects, statuses and key parameters in one working list

Стало: мониторинг с маршрутом, событиями и таймлайном
Было: мониторинг с картой и карточкой устройства
Было Before Стало After

Дополнительный функционал мониторинга: маршрут, события, состояние объекта и временная шкала в одном рабочем сценарииAdditional monitoring tools: route, events, asset status and timeline in one working flow

Перезапуск мобильного приложения

Mobile app relaunch

БылоBefore Было: главная с перегруженной картой
СталоAfter Стало: главная со списком объектов

Главная: от перегруженной карты к списку объектовHome: from an overloaded map to an asset list

БылоBefore Было: экран объекта без ясного следующего действия
СталоAfter Стало: экран объекта с ключевыми состояниями

Экран объекта: ключевые состояния и быстрые действияAsset screen: key states and quick actions

БылоBefore Было: история с плотным списком событий
СталоAfter Стало: история как рабочий маршрут с группировкой событий

История: маршрут и события в одном сценарииHistory: route and events in a single flow

У продукта было мобильное приложение с небольшой активной аудиторией, но его ценность для ежедневной работы была недостаточно очевидна. Вместе с командой мы пересмотрели навигацию: добавили главный экран со списком объектов, раздел уведомлений, обновили экран объекта и настройки.

Также было принято решение перейти на Kotlin Multiplatform, чтобы не поддерживать две платформы отдельно и снизить нагрузку на разработку.

The product had a mobile app with a small active audience, but its value for daily work was not clear enough. Together with the team, we rebuilt navigation: added a main object list, notifications, an updated object screen and settings.

The team also decided to move to Kotlin Multiplatform to avoid maintaining two platforms separately and reduce development load.

05 РезультатResult

Цифры и оговорки

Numbers — with caveats

−20% запросов в техподдержку по вопросам перенастройки устройств. Часть привычки писать менеджеру сохранилась, но пик нагрузки заметно снизился

−20% support tickets on device-reconfiguration scenarios. Some old habits remained, but the peak load dropped noticeably

+9% сессий в личном кабинете. Часть данных косвенная: раньше сотрудники поддержки заходили в кабинеты пользователей и выполняли действия за клиента — после изменений эта работа перешла к самим клиентам

+9% sessions in the customer dashboard. Indirect in part: support agents used to log into clients' dashboards and act on their behalf — that work moved back to the clients

×4 сессий в мобильном приложении в первый месяц после анонса. Пользователи стали активнее устанавливать приложение и использовать его в повседневной работе

×4 mobile sessions in the first month after the announcement. Users started installing and using the app in everyday work

Главный результат — обновлённая продуктовая логика: личный кабинет ведёт пользователя через сложные сценарии до результата, помогает выполнять больше действий самостоятельно и снижает зависимость компании от ручного сопровождения

The main outcome is updated product logic: the dashboard guides users through complex flows, helps them complete more actions on their own and reduces the company's dependence on manual support

06 Моя рольMy role

Product Manager / Product Owner

Product Manager / Product Owner

  • Провела анализ обращений пользователей и выделила повторяющиеся причины нагрузки на техподдержку
  • Analysed user requests and identified recurring root-causes of support load
  • Составила карту личного кабинета и нашла ключевые сценарии, где пользователи теряли контекст или попадали в тупик
  • Mapped the customer dashboard and found key flows where users lost context or hit dead-ends
  • Сформировала концепцию новой навигации и сценариев самостоятельной работы
  • Defined the new navigation and the self-service scenario set
  • Проводила интервью с клиентами и собирала обратную связь от продаж, техподдержки, руководства и внутренних пользователей
  • Ran customer interviews and gathered feedback from sales, support, leadership and internal users
  • Совместно с дизайнером перевела продукт на новую дизайн-систему, обновлённые компоненты и дизайн-библиотеку в коде
  • Together with the designer, migrated the product to a new design system, updated components and a design library in code
  • Создала прототип в отдельной ветке на GitHub, чтобы команда могла проверить новые сценарии на реальных данных
  • Built a prototype on a dedicated GitHub branch so the team could validate new flows on real data
  • Подготовила документацию и передала требования команде разработки
  • Wrote the documentation and handed requirements to the dev team