01Розгортання на одному екрані
Огляд відкриває робочий день. Стан системи: обслуговування, API-міст, база даних і кеш. Сигнали про брейкери, провайдерів і невирішені помилки. Робота у вигляді черг із лічильниками — 12 перевірок KYC в очікуванні, найстаріша 5h 02m, 8 розбіжностей звірки з €18,240 до зарахування, 2 погодження в очікуванні. Нижче — нещодавні привілейовані дії та стан кожного провайдера. Для цього екрана не потрібен жоден інший інструмент.
- Система, сигнали й черги — в одному вертикальному огляді
- Кожна картка веде до черги, яку вона підраховує
- Стан провайдера по кожному каналу — деградація, працює, відновлення
02Копілот оператора
Панель копілота відкривається поруч із будь-яким поданням із контекстними стартовими запитами — чому не проходять поповнення, підсумуй відкриті інциденти. Вона працює лише на читання й не виконує дій. І чесно деградує: поки ендпоінт моделі не підключено, панель прямо про це каже, а не вигадує відповіді.
03Аналітика
Уся операційна картина на одному екрані: 42,180 користувачів, 12,408 активних, рівень активації 61.8%, рівень успішності 96.4% та грошовий потік +€1.84M на вхід і −€1.52M на вихід за 30 днів. Поруч — воронки KYC та онбордингу, тож падіння активації видно вже в тиждень, коли воно почалося. Фінансові метрики доступні лише фінансовій ролі.
04Розбір помилок
Потік сповіщень приходить уже дедупльованим. 142 випадки однієї WebhookSignatureError, що зачепили 38 користувачів, згортаються в один критичний рядок із діями «підтвердити» та «вирішити», а подання оновлюється кожні 10 секунд. Оператори розв'язують сигнатури, а не сторінки шуму.
- Один рядок на сигнатуру помилки, з лічильником
- До кожної сигнатури прикріплено постраждалих користувачів
- Підтвердження й вирішення — як дії з аудитом
05Користувачі: пошук за будь-чим
12,408 акаунтів із пошуком за іменем, email, телефоном або ID, зі статусом KYC і акаунта в кожному рядку та вкладками: KYC в очікуванні, верифіковані, відхилені, заблоковані й архівні. Кожен рядок відкривається в User 360 — баланси, картки, пристрої, рівень KYC і повна історія одного клієнта на одному екрані.
06Черга перевірки KYC
Заявки на перевірку надходять чергою з лічильником і видимим годинником — у демо їх 12, і кожен рядок показує провайдера, статус, останню причину та скільки заявник уже чекає. Повторна перевірка liveness, що застрягла на 5h 02m, підсвічується червоним. Схвалюйте, відхиляйте чи скидайте прямо в консолі; кожне рішення потребує причини, аудитується й одразу змінює статус акаунта скрізь.
- Вкладки: в очікуванні, попередньо завершені, відхилені та всі
- Причини в рядку — перевірка адреси, повторний liveness, перевірка документів
- Час очікування на виду, найстаріше позначене
07Деталізація леджера
Кожен грошовий рядок розкривається до самого дна. Переказ TR-90211 — завершений peer-to-peer платіж на €120.00 — показує відправника, отримувача та обидві проведені проводки леджера: дебет −€120.00 і кредит +€120.00, подвійний запис, збалансований. Між оператором і леджером немає жодного зведеного подання.
08Криптопоповнення
Ончейн-депозити — повноцінні рядки, а не експорт звідкись іще. Успішне поповнення в мережі Base показує 250.00 USDC, зараховані на EUR-леджер, а в панелі — курс, комісію, адресу гаманця та хеш транзакції. Обидва канали в одній консолі, з трасуванням аж до блокчейну.
09Звірка
Вхідні SEPA-депозити автоматично зіставляються з користувачами; винятки потрапляють у чергу з лічильником: зіставлені рядки готові до зарахування, невідомий платник із двома кандидатами, а також вкладки «готові», «потребують перевірки», «незіставлені» та «історія». Зарахування — один клік, коли збіг чистий, і обґрунтоване рішення, коли ні, а кожне ручне зарахування потребує причини, з лімітами сум із конфігурації.
- Зіставте платіж із користувачем, зарахуйте й звірте
- Неоднозначні платники чекають на перевірку разом із кандидатами
- Банківські звіти імпортуються прямо в чергу
10Tracer
Вставте референс — і отримайте всю історію. Трасування 9F21-0716 відкривається як ланцюжок кроків: запит подано, леджер перевірено за політикою, котирування провайдера записано, ончейн-підтвердження в Base 12 з 12, розрахунок доставлено — кожен крок із часом, від +42ms до +22s. Лише читання за задумом: Tracer пояснює, але ніколи нічого не змінює.
- Один референс — усі кроки від запиту до розрахунку
- Політика й котирування, застосовані на кожному кроці, записані
- Ключ ідемпотентності видно в трасуванні
11Вхідні погодження
Зарахування понад встановлену межу чекають на другого оператора. Вхідні діляться на те, що чекає вашого погодження, і те, що запросили ви: з одного боку — кредит доброї волі на €500.00 та повернення за невдале поповнення на €120.00, з іншого — ваше власне сторно комісії на €40.00, що чекає на співпідписанта. Погоджувати власні запити не можна; їх можна відкликати.
12Журнал аудиту
18,942 дії операторів в append-only таблиці: час, оператор, дія, ціль, письмова причина та базовий запит із кодом відповіді. Системні дії потрапляють у той самий ланцюг, що й людські. Фільтруйте за оператором, дією чи датою; експортуйте в CSV, коли хтось поза консоллю попросить.
- Лише додавання — записи ніколи не редагуються й не видаляються
- До кожного рядка прикріплено причину й запит
- Фільтрація, пагінація, експорт
13Перегляд і повторне відтворення вебхуків
18,204 вхідні події провайдерів, у кожному рядку — результат перевірки підпису. Невдалу подію можна відтворити, щоб повторно застосувати пропущений вердикт — потрібна причина, дублікатів сповіщень немає — але лише якщо підпис дійсний; недійсним підписам не довіряють, і повтор блокується. Розкриття сирого payload надсилає у ваш браузер незамасковані PII, тому воно записується в аудит.
14Feature flags і віддалена конфігурація
38 типізованих ключів у 8 областях — перемикачі, суми, переліки — для карток, поповнень, KYC та решти runtime-поверхні. Для кожного ключа видно, хто змінив його востаннє й коли; кожна зміна має diff, причину й аудит. Ліміт витрат або перемикання провайдера — це правка в консолі, а не реліз у сторах.
- Типізовані елементи керування — жодних вільнотекстових рядків конфігурації
- Історія кожного ключа: хто, що, коли, чому
- Зміни діють без релізу застосунку
15Аварійні вимикачі
Коли щось треба зупинити, це зупиняється звідси. Глобальне заморожування показує екран обслуговування під час запуску застосунку; окремі вимикачі функцій зупиняють картки, поповнення, перекази чи KYC по одному — у демо 4 працюють, 0 вимкнено. Обхід OTP для QA захований за власним вимикачем і за замовчуванням вимкнений. Кожна зміна логується й підтверджується двічі.
16Оператори та ролі
Командою керують там, де відбувається робота. Шість облікових записів операторів — від superadmin до auditor, і в кожному записі видно нещодавню активність з аудиту. Зміна ролі проходить через діалог із причиною, а змінити власну роль чи деактивувати себе ніхто не може — це має зробити інший superadmin.
- Шість ролей — superadmin, ops, compliance, engineer, support, auditor
- Нещодавні дії кожного оператора — у його записі
- Жодного самопідвищення, жодної самодеактивації
17Дії з обов'язковою причиною
Привілейована дія пояснює себе ще до виконання. Заморожування картки 4417 відкриває діалог, який описує масштаб наслідків, вимагає письмову причину і — оскільки це production — просить оператора ввести PROD, перш ніж кнопка підтвердження стане активною. Причина потрапляє в незмінний журнал аудиту поруч із самою дією.
18Брейкери та стан провайдерів
Інженерна команда бачить брейкери й стан провайдерів наживо. Коли провайдер деградує, стан брейкера видно в консолі ще до того, як надійдуть звернення до підтримки. Так само видно і відновлення.
19Бекофіс платіжних посилань
Для посилань, які створюють клієнти, є окремий вигляд оператора: у демо — 214 посилань зі статусами «оплачено», «активне» й «прострочене». До кожного прикріплено переказ розрахунку та посилання для відкриття в Tracer з повним трейсом. Відкликання посилання — це не повернення коштів, і консоль попереджає про це заздалегідь.
20Вайтлісти входу та маскування PII
Доступ до консолі обмежено вайтлістом, а дані, які бачать оператори, мінімізовано за замовчуванням: email і телефон залишаються замаскованими, доки їх свідомо не розкрити, а фінансові метрики доступні лише з фінансовою роллю. Побачити більше — свідома дія, яку записують у журнал.
21Ручні нарахування й поповнення
Поповнення рахунку користувача — повноцінний сценарій консолі, а не запис у базу даних. Кожне нарахування має письмову причину, а нарахування понад поріг проходять через інбокс погоджень і потребують підтвердження другого оператора.
22Операції з картками
Картки по всій базі: заморожування й розморожування із зазначеним радіусом впливу, варіанти карток за програмами, і кожна картка доступна з User 360 її власника. Руйнівні дії проходять через той самий діалог з обов'язковою причиною, що й решта.
23Банківські рахунки
Банківські рахунки платформи мають власний розділ, а імпортовані банківські звіти потрапляють просто в чергу звірки. Рейку, якою реально рухаються гроші, видно в тій самій консолі, що й леджер, у який вони зараховуються.
24Командна палітра та пошук
⌘K відкриває палітру звідусіль; пошук приймає ім'я, email, телефон або ID і веде до потрібного запису. Консоль створено так, щоб нею можна було керувати з клавіатури навіть у найскрутніший день.
25Кампанії, реферали та інвайт-коди
Інструменти зростання — в тій самій консолі: налаштування й відстеження кампаній, моніторинг реферальних програм, випуск і відкликання інвайт-кодів. Операційна команда запускає акції без окремої адмінки.
26Версії застосунку та вкладки мобільного
Дивіться, які версії застосунку зараз у користувачів, і налаштовуйте розкладку вкладок віддалено. Оболонкою застосунку можна керувати з консолі: зміна вкладки — це конфіг, а не реліз.
27Контент, FAQ і чат
Контент у застосунку, записи FAQ та чат із клієнтами ведуться в консолі. Той, хто відповідає у зверненні до підтримки, має User 360 за один клік, а не в іншій вкладці іншої системи.
28Крипто-операції
Крипто має власний розділ: огляд, гаманці, реєстр активів і крипто-дії — поруч із чергою поповнень. Оператори бачать ончейн-частину так само глибоко, як фіатний леджер.
29Експорт
Дані виходять чисто, коли це потрібно: CSV-експорт журналу аудиту й операційних таблиць, відфільтрований саме так, як показано на екрані. Те, що просить аудитор, — це завантаження, а не задача для інженерів.
30Whitelabel і середовища
Консоль працює під вашим брендом: демо-розгортання називається YourBrand, а не нашим іменем. Постійний банер вказує середовище, продакшн-вигляди мають бейдж prod, а для продакшн-дій оператор вводить PROD. Ніхто не переплутає, в якому розгортанні працює.
