Платформа для обмена клиентами внутри бизнес-экосистемы для Misty

Главное о кейсе

Команда Misty пришла с идеей: сделать платформу для коммерческих и маркетинговых коммуникаций между бизнесами, входящими в экосистему. Грубо говоря, создать место,где компании смогут взаимодействовать друг с другом для запуска акций, стимулирующих перетоки клиентов между ними — прозрачно, удобно и с понятными метриками эффективности (прежде всего это количество посещений старыми клиентами новых бизнес-проектов). Такая платформа должна увеличить LTV клиентов — важно сохранять клиента внутри экосистемы, чтобы он посещал новые бизнес-проекты.

Бизнес-задача и ее решение

Сделать платформу для коммерческих и маркетинговых коммуникаций между бизнесами, входящими в экосистему. Создать сервис, где компании смогут взаимодействовать друг с другом для запуска акций, стимулирующих перетоки клиентов между ними — прозрачно, удобно и с понятными метриками эффективности (прежде всего это количество посещений старыми клиентами новых бизнес-проектов). Такая платформа должна увеличить LTV клиентов — важно сохранять клиента внутри экосистемы, чтобы он посещал новые бизнес-проекты.

Крафт (мастерство), реализация, технические детали

Как мы провели аналитику
Перед стартом разработки мы погрузились в бизнес-процессы Misty и собрали все ключевые требования. Изучили, как взаимодействуют сотрудники управляющей компании и проектов, какие данные нужны для работы и какие ограничения следует учитывать. На основе этого составили сценарии использования, описали роли пользователей и подготовили схемы процессов.

Как выбирали архитектуру
Параллельно с этим шло проектирование архитектуры платформы. Учитывая, что экосистема Misty включает 16 разных бизнесов и в перспективе может расширяться, мы отказались от монолитной модели в пользу микросервисной архитектуры.

Склониться к микросервисному подходу помогло сразу несколько факторов:
Масштабируемость. Это один из главных плюсов: в долгосрочной перспективе микросервисы позволяют сэкономить ресурсы и адаптироваться к росту нагрузки.
Отказоустойчивость. Если один сервис выйдет из строя, это не парализует работу всей платформы.
Гибкость. Микросервисы не зависят друг от друга, их можно развивать и обновлять независимо, быстро адаптировать под бизнес-задачи.
Управляемость. Упрощается мониторинг и контроль работы каждого отдельного сервиса, что критично при росте числа пользователей.
Независимая разработка. Команды могут параллельно работать над своими сервисами, не мешая друг другу.
Минимизация рисков. При выпуске нового функционала снижается вероятность того, что изменения заденут другие части системы.
Мы также обозначили заказчику потенциальные минусы подхода: микросервисная архитектура требует больше времени на проектирование (по оценке, примерно на 15% больше по сравнению с монолитом), а также более сложного мониторинга и логирования.

Для первого релиза мы запланировали разделить систему на следующие сервисы:

управление пользователями и проектами;
управление предложениями;
уведомления;
аналитика;
управление файлами;
логирование;
внешние интеграции.
Такой подход обеспечивает стабильную основу для масштабирования платформы и выпуска новых функций без угрозы стабильности системы. Срок реализации MVP составил 6 месяцев.

Инсайты, гипотезы, процесс создания и взаимодействия с заказчиком

дзен и взаимопонимание!

Скриншоты