01पूरा डिप्लॉयमेंट एक स्क्रीन पर
ओवरव्यू से दिन की शुरुआत होती है। मेंटेनेंस, API ब्रिज, डेटाबेस और कैश में सिस्टम की सेहत। breaker, प्रोवाइडर और अनसुलझे एरर के सिग्नल। काम गिनी हुई क्यू के रूप में — 12 KYC समीक्षाएँ लंबित, सबसे पुरानी 5h 02m की, 8 reconciliation ब्रेक जिनमें €18,240 क्रेडिट के लिए तैयार, 2 अप्रूवल प्रतीक्षा में। हाल की privileged कार्रवाइयाँ और प्रति-प्रोवाइडर सेहत नीचे हैं। इस स्क्रीन पर कुछ भी करने के लिए दूसरे टूल की ज़रूरत नहीं।
- सिस्टम, सिग्नल और क्यू — एक ही वर्टिकल व्यू में
- हर कार्ड उस क्यू से जुड़ा है जिसे वह गिनता है
- हर rail पर प्रोवाइडर की सेहत — degraded, up, recovering
02ऑपरेटर copilot
किसी भी व्यू के बगल में copilot डॉक खुलता है, संदर्भ के अनुसार शुरुआती सुझावों के साथ — टॉप-अप क्यों फ़ेल हो रहे हैं, खुली घटनाओं का सारांश दो। यह केवल पढ़ सकता है और कोई कार्रवाई नहीं करेगा। और यह ईमानदारी से काम करता है: जब तक मॉडल endpoint जुड़ा नहीं है, डॉक साफ़ बता देता है, जवाब गढ़ता नहीं।
03Insights
पूरा ऑपरेशन एक स्क्रीन पर: 42,180 यूज़र, 12,408 सक्रिय, 61.8% activation rate, 96.4% success rate, और 30 दिनों में +€1.84M अंदर और −€1.52M बाहर का मनी फ़्लो। KYC और ऑनबोर्डिंग फ़नल साथ में हैं, इसलिए activation में गिरावट शुरू होने के हफ़्ते में ही दिख जाती है। मनी मेट्रिक्स financial रोल के पीछे रहते हैं।
04एरर ट्राइएज
अलर्ट स्ट्रीम डीडुप्लिकेट होकर आती है। एक ही WebhookSignatureError की 142 घटनाएँ — 38 यूज़र प्रभावित — acknowledge और resolve कार्रवाइयों वाली एक critical पंक्ति में समा जाती हैं, और व्यू हर 10 सेकंड में रिफ़्रेश होता है। ऑपरेटर सिग्नेचर सुलझाते हैं, शोर के पन्ने नहीं।
- हर एरर सिग्नेचर की एक पंक्ति, गिनती के साथ
- हर सिग्नेचर से जुड़े प्रभावित यूज़र
- Acknowledge और resolve — ऑडिट होने वाली कार्रवाइयाँ
05यूज़र, किसी भी चीज़ से खोजें
12,408 अकाउंट नाम, ईमेल, फ़ोन या ID से खोजे जा सकते हैं; हर पंक्ति पर KYC और अकाउंट स्टेटस है, और pending KYC, verified, rejected, blocked व archived के टैब हैं। हर पंक्ति User 360 में खुलती है — एक ग्राहक के बैलेंस, कार्ड, डिवाइस, KYC टियर और पूरा इतिहास एक स्क्रीन पर।
06KYC समीक्षा क्यू
लंबित समीक्षाएँ घड़ी दिखाती गिनी हुई क्यू के रूप में आती हैं — डेमो में 12, हर पंक्ति में प्रोवाइडर, स्टेटस, ताज़ा कारण और आवेदक कितनी देर से प्रतीक्षा में है। 5h 02m पर अटका liveness retry लाल दिखता है। Console में ही approve, reject या reset करें; हर निर्णय में कारण अनिवार्य है, ऑडिट होता है, और अकाउंट का स्टेटस हर जगह एक साथ बदल देता है।
- Pending, precompleted, rejected और all — टैब के रूप में
- कारण पंक्ति पर — address review, liveness retry, doc review
- प्रतीक्षा समय दिखता है, सबसे पुराना चिह्नित
07Ledger ड्रिल-डाउन
पैसे की हर पंक्ति नीचे तक खुलती है। ट्रांसफ़र TR-90211 — €120.00 का पूरा हुआ peer-to-peer पेमेंट — प्रेषक, प्राप्तकर्ता और पोस्ट हुए दोनों ledger लेग दिखाता है: −€120.00 डेबिट और +€120.00 क्रेडिट, डबल-एंट्री और संतुलित। ऑपरेटर और ledger के बीच कोई सारांश व्यू नहीं आता।
08क्रिप्टो टॉप-अप
ऑन-चेन डिपॉज़िट पहली श्रेणी की पंक्तियाँ हैं, कहीं और से लाया गया एक्सपोर्ट नहीं। Base नेटवर्क का सफल टॉप-अप ड्रॉअर में दिखाता है कि 250.00 USDC EUR ledger में क्रेडिट हुए, साथ में एक्सचेंज रेट, फ़ीस, वॉलेट पता और ट्रांज़ैक्शन हैश। दोनों rail, एक console, चेन तक ट्रेस करने योग्य।
09रिकॉन्सिलिएशन
आने वाले SEPA डिपॉज़िट अपने-आप यूज़र से मैच हो जाते हैं; अपवाद गिनी हुई वर्क क्यू में आते हैं — क्रेडिट के लिए तैयार मैच वाली पंक्तियाँ, दो संभावित मैच वाला अज्ञात भुगतानकर्ता, और ready, needs review, unmatched व history के टैब। मैच साफ़ हो तो क्रेडिट एक क्लिक में होता है, वरना कारण सहित निर्णय से — और हर मैन्युअल क्रेडिट में कारण अनिवार्य है, राशि की सीमाएँ config से पढ़ी जाती हैं।
- पेमेंट को यूज़र से मैच करें, फिर क्रेडिट और reconcile करें
- अस्पष्ट भुगतानकर्ता अपने संभावित मैच के साथ समीक्षा के लिए रोके जाते हैं
- बैंक रिपोर्ट सीधे क्यू में इम्पोर्ट
10Tracer
रेफ़रेंस पेस्ट करें और पूरी कहानी पाएँ। Trace 9F21-0716 hop trace के रूप में खुलता है — रिक्वेस्ट सबमिट, पॉलिसी के विरुद्ध ledger वैलिडेट, प्रोवाइडर कोट दर्ज, Base पर ऑन-चेन कन्फ़र्मेशन 12 में से 12, सेटलमेंट डिलीवर — हर hop का समय, +42ms से +22s तक। डिज़ाइन से read-only: Tracer समझाता है, कभी बदलता नहीं।
- एक रेफ़रेंस, रिक्वेस्ट से सेटलमेंट तक हर hop
- हर hop पर लागू पॉलिसी और कोट, दर्ज
- Trace पर idempotency key दिखती है
11अप्रूवल इनबॉक्स
सीमा से ऊपर के क्रेडिट दूसरे ऑपरेटर की प्रतीक्षा करते हैं। इनबॉक्स दो हिस्सों में बँटा है: जो आपके अप्रूवल का इंतज़ार कर रहा है और जो आपने माँगा है — एक तरफ़ €500.00 का goodwill क्रेडिट और €120.00 का फ़ेल टॉप-अप रिफ़ंड, दूसरी तरफ़ आपका अपना €40.00 का फ़ीस रिवर्सल, जो co-signer की प्रतीक्षा में है। जो आइटम आपने माँगे, उन्हें आप approve नहीं कर सकते; वापस ले सकते हैं।
12ऑडिट लॉग
append-only टेबल में 18,942 ऑपरेटर कार्रवाइयाँ: समय, ऑपरेटर, कार्रवाई, लक्ष्य, लिखित कारण, और रिस्पॉन्स कोड के साथ मूल रिक्वेस्ट। सिस्टम की कार्रवाइयाँ उसी रीढ़ में दर्ज होती हैं जिसमें इंसानों की। ऑपरेटर, कार्रवाई या तारीख़ से फ़िल्टर करें; console के बाहर कोई माँगे तो CSV में एक्सपोर्ट करें।
- Append-only — प्रविष्टियाँ कभी एडिट या हटाई नहीं जातीं
- हर पंक्ति के साथ कारण और रिक्वेस्ट जुड़े
- फ़िल्टर, पेजिनेशन और एक्सपोर्ट योग्य
13Webhook निरीक्षण और रीप्ले
प्रोवाइडर के 18,204 इनबाउंड इवेंट, हर पंक्ति पर सिग्नेचर वेरिफ़िकेशन के साथ। छूटे हुए निर्णय को दोबारा लागू करने के लिए फ़ेल इवेंट रीप्ले किया जा सकता है — कारण अनिवार्य, डुप्लिकेट नोटिफ़िकेशन नहीं — पर केवल तभी जब उसका सिग्नेचर वैध हो; अवैध सिग्नेचर पर भरोसा नहीं किया जाता और रीप्ले रोक दिया जाता है। रॉ payload दिखाने पर बिना मास्क किया PII आपके ब्राउज़र में आता है, इसलिए ऐसा करने पर ऑडिट इवेंट लिखा जाता है।
14फ़ीचर फ़्लैग और रिमोट config
8 क्षेत्रों में 38 टाइप्ड की — टॉगल, राशियाँ, enum — कार्ड, टॉप-अप, KYC और बाकी रनटाइम सतह के लिए। हर की दिखाती है कि इसे आख़िरी बार किसने और कब बदला; हर बदलाव का diff, कारण और ऑडिट होता है। खर्च की सीमा या प्रोवाइडर का स्विच console में एक एडिट है, स्टोर रिलीज़ नहीं।
- टाइप्ड कंट्रोल — फ़्री-टेक्स्ट config स्ट्रिंग नहीं
- प्रति-की इतिहास: किसने, क्या, कब, क्यों
- बदलाव ऐप रिलीज़ के बिना लागू होते हैं
15Kill switch
जब कुछ रोकना हो, तो यहीं से रुकता है। ग्लोबल फ़्रीज़ ऐप लॉन्च पर मेंटेनेंस स्क्रीन दिखाता है; फ़ीचर-वार kill switch कार्ड, टॉप-अप, ट्रांसफ़र या KYC को अलग-अलग बंद करते हैं — डेमो में 4 चालू, 0 बंद। QA के लिए OTP bypass अपने अलग स्विच के पीछे है, डिफ़ॉल्ट रूप से बंद। हर बदलाव लॉग होता है और दोहरी पुष्टि से गुज़रता है।
16ऑपरेटर और रोल
टीम का प्रबंधन वहीं होता है जहाँ काम होता है। छह ऑपरेटर अकाउंट superadmin से auditor तक के रोल चलाते हैं, और हर रिकॉर्ड अपनी हाल की ऑडिट की गई गतिविधि दिखाता है। रोल बदलाव कारण वाले डायलॉग से गुज़रते हैं, और कोई अपना रोल नहीं बदल सकता या खुद को निष्क्रिय नहीं कर सकता — यह दूसरे superadmin को करना होगा।
- छह रोल — superadmin, ops, compliance, engineer, support, auditor
- हर ऑपरेटर की हाल की कार्रवाइयाँ उसके रिकॉर्ड पर
- न खुद को प्रमोट, न खुद को निष्क्रिय
17कारण-अनिवार्य एक्शन
Privileged कार्रवाई चलने से पहले खुद को समझाती है। कार्ड 4417 फ़्रीज़ करने पर एक डायलॉग खुलता है जो असर का दायरा बताता है, लिखित कारण माँगता है, और — क्योंकि यह production है — कन्फ़र्म बटन चालू होने से पहले ऑपरेटर से PROD टाइप करवाता है। कारण कार्रवाई के ठीक बगल में अपरिवर्तनीय ऑडिट लॉग में दर्ज होता है।
18Breakers और provider हेल्थ
इंजीनियरिंग टीम breakers और provider हेल्थ को लाइव देखती है। जब कोई provider धीमा या खराब होता है, तो सपोर्ट टिकट आने से पहले ही कंसोल में breaker की स्थिति दिख जाती है — और रिकवरी भी।
19Payment-links बैक ऑफिस
ग्राहकों के बनाए लिंक का एक ऑपरेटर व्यू है: डेमो में paid, active और expired मिलाकर 214 लिंक, हर एक के साथ उसका settlement transfer जुड़ा है और पूरा ट्रेस देखने के लिए Tracer में खोलने का लिंक है। लिंक रद्द करना रिफंड नहीं है — कंसोल यह आपके कार्रवाई करने से पहले ही बता देता है।
20Sign-in whitelist और masked PII
कंसोल का एक्सेस whitelist से तय होता है, और ऑपरेटर को डिफ़ॉल्ट रूप से कम से कम डेटा दिखता है: ईमेल और फ़ोन तब तक masked रहते हैं जब तक जानबूझकर न खोले जाएँ, और धन से जुड़े मेट्रिक्स फ़ाइनेंशियल रोल के पीछे रहते हैं। ज़्यादा देखना एक सोचा-समझा, लॉग किया गया कदम है।
21मैन्युअल क्रेडिट और फंडिंग
यूज़र को फंड करना कंसोल का एक पूर्ण फ़्लो है, डेटाबेस में सीधा बदलाव नहीं। हर क्रेडिट के साथ लिखित कारण दर्ज होता है, और सीमा से ऊपर के क्रेडिट approvals inbox से गुज़रते हैं, जहाँ दूसरे ऑपरेटर की मंज़ूरी चाहिए।
22कार्ड ऑपरेशंस
पूरे बेस के कार्ड एक जगह: blast radius बताकर फ्रीज़ और अनफ्रीज़, हर प्रोग्राम के हिसाब से कार्ड वेरिएंट का प्रबंधन, और हर कार्ड उस User 360 से सीधे पहुँच में जिससे वह जुड़ा है। विनाशकारी कार्रवाइयों के लिए भी वही कारण-अनिवार्य डायलॉग आता है जो बाकी सब के लिए है।
23बैंक खाते
प्लेटफ़ॉर्म के बैंक खातों का अपना अलग व्यू है, और इम्पोर्ट की गई बैंक रिपोर्ट सीधे reconciliation queue में जाती हैं। जिस रेल पर पैसा असल में चलता है, वह उसी कंसोल में दिखता है जिसमें वह लेजर है जहाँ पैसा पहुँचता है।
24Command palette और सर्च
⌘K कहीं से भी palette खोलता है; सर्च में नाम, ईमेल, फ़ोन या ID डालिए और सही रिकॉर्ड पर पहुँचिए। कंसोल इस तरह बना है कि मुश्किल दिन में भी उसे कीबोर्ड से चलाया जा सके।
25Campaigns, referrals और invite codes
ग्रोथ से जुड़े टूल उसी कंसोल में हैं: campaigns का कॉन्फ़िगरेशन और ट्रैकिंग, referral प्रोग्राम की निगरानी, invite codes जारी करना और रद्द करना। प्रमोशन चलाने के लिए Ops को अलग एडमिन टूल नहीं चाहिए।
26ऐप वर्ज़न और मोबाइल टैब
देखिए कि कौन-से ऐप वर्ज़न यूज़र्स के पास चल रहे हैं, और मोबाइल ऐप का टैब लेआउट दूर से कॉन्फ़िगर कीजिए। ऐप का शेल कंसोल से संचालित होता है — टैब बदलना कॉन्फ़िग है, रिलीज़ नहीं।
27कंटेंट, FAQ और चैट
ऐप के भीतर का कंटेंट, FAQ एंट्री और ग्राहक चैट कंसोल में ही चलते हैं। सपोर्ट थ्रेड का जवाब देने वाले के पास User 360 बस एक क्लिक दूर है, किसी दूसरे सिस्टम के दूसरे टैब में नहीं।
28Crypto ऑपरेशंस
Crypto के लिए अलग सेक्शन है: crypto ओवरव्यू, wallets, asset registry और crypto actions — top-ups queue के साथ। ऑपरेटर on-chain सतह को उतनी ही गहराई से देखते हैं जितनी गहराई से fiat लेजर को।
29Exports
ज़रूरत पड़ने पर डेटा साफ़-सुथरे ढंग से बाहर आता है: ऑडिट लॉग और ऑपरेशनल टेबल पर CSV export, ठीक वैसे ही फ़िल्टर के साथ जैसे स्क्रीन पर दिखते हैं। ऑडिटर जो माँगे वह एक डाउनलोड है, इंजीनियरिंग टिकट नहीं।
30Whitelabel और एनवायरनमेंट
कंसोल आपके ब्रांड के नाम से चलता है — डेमो डिप्लॉयमेंट YourBrand है, हमारा नहीं। एक स्थायी बैनर एनवायरनमेंट बताता है, production व्यू पर prod बैज रहता है, और production कार्रवाइयों के लिए ऑपरेटर को PROD टाइप करना पड़ता है। कोई भी डिप्लॉयमेंट को लेकर भ्रमित नहीं होता।