Skiply Portal – мерчантская сторона Skiply для школ и образовательных центров

До концептов я прошёл три слоя:

• как сегодня школы и образовательные центры в ОАЭ ведут образовательные платежи – счета, ручной сбор на ресепшене, разовые платёжные ссылки, отдельные таблицы для списков учеников и аудиторий;
• админские и мерчантские панели в смежных категориях – e-commerce-админки, образовательные платформы, маркетплейсы – чтобы понять, какие паттерны масштабируются на нетехнических пользователей, а какие работают только с технически подкованными командами;
• модель данных на стороне клиентского приложения Skiply – как «оффер» выглядит для родителя, как мэтчатся аудитории, как идут платежи, – чтобы мерчантская модель ложилась на неё без переходных слоёв.

Главные выводы:

1. Основной пользователь на мерчантской стороне – не продакт и не админ, а сотрудник школы, чья основная работа – не работа с софтом. Интерфейс должен это учитывать. Паттерны, которые кажутся очевидными B2B SaaS-аудитории, здесь не безопасный дефолт.
2. Модель данных на мерчантской стороне должна повторять клиентскую. Если «аудитория» означает одно для родителя и другое для школы, маркетплейс ломается.
3. На мерчантской стороне тоже свой ритм – семестры, наборы, сезоны кружков. Платформа должна делать эти циклы дешёвыми в управлении, а не просто возможными.

1. Если свернуть мерчантский воркфлоу в несколько понятных модулей – офферы, аудитории, платежи, аналитика – вместо того чтобы повторять внутреннюю админскую структуру банка, школы смогут пользоваться платформой без отдельного обучения.
2. Если модель аудиторий на мерчантской стороне совпадает по форме с клиентской, офферы будут попадать к нужным семьям без ручной сверки, а нагрузка на команду банка останется управляемой по мере роста мерчантской базы.
3. Если переиспользовать дизайн-систему Skiply и адаптировать её под десктопный админский контекст, оба продукта будут ощущаться как одна экосистема, и нам не придётся параллельно поддерживать два визуальных языка.

Структура портала была главным решением. Изначально банк ожидал что-то близкое к традиционной банковской админке – много настроек, экранов верификации, админских деревьев.

Я двигал в другую сторону: небольшой набор мерчантских модулей, выстроенных вокруг реальных задач, которые школа решает каждый день – выложить оффер, определить, кому он виден, принять платёж, посмотреть, как идут дела. Банковские процессы (верификация, комплаенс, расчёты) остаются в платформе, но живут в своей зоне, отдельно от ежедневной работы.

Основные модули в итоге получились такие:

• Офферы – выкладка пакетов обучения, кружков, оборудования и разовых услуг, на той же модели данных, которую потребляет клиентское приложение.
• Аудитории – определение, кому адресован оффер, зеркаля механику матчинга на семейной стороне.
• Платежи – управление входящими платежами, расчётами и сверкой.
• Аналитика – базовая видимость того, что продаётся, кто платит и по чему пошли просрочки.

Портал ушёл в прод как desktop-first веб-приложение на той же дизайн-системе, что и клиентское приложение, с отдельным набором компонентов под админские контексты (плотные таблицы, сложные формы, многошаговые воркфлоу).

В финальном решении больше всего значили три вещи.

Во-первых, дизайн-система. Токены, типографика и базовые компоненты общие со Skiply. Там, где десктопной админке нужны были свои паттерны – плотные таблицы, side-by-side редакторы, массовые операции, – я расширял систему, а не форкал её.

Во-вторых, воркфлоу вместо экранов. Каждую мерчантскую задачу – опубликовать оффер, открыть новый набор, разобрать платежи – я собирал как воркфлоу с понятными состояниями, а не как набор разрозненных форм.

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

Ключевые дизайн-решения презентовал стейкхолдерам Rakbank в связке с клиентской частью, подавая портал как вторую половину одного продукта, а не как отдельный проект.

• Мерчантская платформа запустилась как вторая половина экосистемы Skiply, дав школам self-service-инструмент, чтобы выкладывать офферы, определять аудитории и проводить платежи.
• Оба продукта живут на общей дизайн-системе, что ускорило выпуск мерчантской стороны и удержало визуальный язык целостным между семейным приложением и мерчантским порталом.
• Платформа стала фундаментом для мерчантского бренда и маркетинговых материалов вокруг школьной стороны Skiply.
• Конкретные мерчантские метрики – подключённые школы, число листингов, платёжный объём – считаются на стороне банка. По договору с Rakbank я не могу публично делиться цифрами – готов обсудить детали на интервью.