---
title: "Skiply Portal – мерчантская сторона Skiply для школ и образовательных центров"
description: "Сборка мерчантской стороны Skiply – где школы публикуют офферы, управляют аудиториями и проводят платежи – чтобы замкнуть цикл с семейным приложением"
canonical: "https://igorabramkin.com/ru/skiply-portal"
lang: "ru"
doc_version: "1"
last_updated: "2026-09-04"
---

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

Сборка мерчантской стороны Skiply – где школы публикуют офферы, управляют аудиториями и проводят платежи – чтобы замкнуть цикл с семейным приложением

- **Роль:** Lead Product Designer
- **Команда:** 3 продуктовых дизайнера, Product Owner, Бизнес-аналитик, 3 разработчика
- **Мой вклад:** Исследования пользователей, Концептуализация, Проектирование опыта, Интеракционный дизайн, Дизайн-система, Дизайн интерфейса
- **Срок:** 8 недель

![Скриншоты приложения Skiply Portal](https://igorabramkin.com/projects/skiply-portal/skiply-portal-cover.png)

## Исследование

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

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

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

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

## Гипотезы

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

## Концепты

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

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

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

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

## Финальное решение

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

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

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

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

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

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

## Результат

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

## Sitemap

Полный список страниц: [sitemap](https://igorabramkin.com/sitemap.md).