Destek ve operasyonların çoğunu kapsayan 12 admin panel ekranının pratik listesi ve önce neyi inşa edeceğinizi önceliklendirmek için basit bir yöntem.

"Operasyonların %80'ini karşılayan" bir admin paneli en çok ayarı olan değil; ekibinizin en yaygın destek ve operasyon isteklerini mühendis çağırmadan veya tek seferlik manuel düzeltme yapmadan dakikalar içinde çözmesini sağlayan paneldir.
Ana fark, ürün özelliklerini destek araçlarından ayırmaktır. Ürün özellikleri son kullanıcıların işini yapmasına yardım eder. Destek araçları ise iç ekibin şunu yanıtlamasına yardımcı olur: "Ne oldu? Bunu kim yaptı? Güvenle neyi değiştirebiliriz?" Birçok ekip kullanıcıya yönelik kontrol çokça sunar, ama destek yine de sahiplik, faturalama durumu, son hatalar veya temiz bir değişiklik geçmişi gibi temel bilgileri göremez.
Farklı ekipler admin panelini farklı amaçlarla kullanır. Destek kullanıcıları açmazları giderip güvenli değişiklikler yapmak ister. Finans faturalama, faturalar, iadeler ve vergi detaylarına bakar. Operasyon org sağlığını, kullanım trendlerini, risk kontrollerini ve dışa aktarımı ister. Mühendislik ise loglar ve denetim izi gibi hata ayıklama izlerini ister (tam gözlemlenebilirlik değil).
Neyin %80'e denk geldiğine karar vermek için sıklık vs etki kontrolü kullanın. Sıklık talebin ne kadar sık ortaya çıktığıdır. Etki, hızlı çözemediğinizde ne kadar acı verdiğidir (kayıp gelir, churn riski, uyumluluk riski).
Basit bir yöntem:
Eğer bir kullanıcı "Ücret alındı ama Pro'ya erişemiyorum" diyorsa, en iyi admin paneli kontrol listesi supportu kullanıcı aramasından abonelik durumuna, faturaya ve aksiyona götüren ve her değişiklik için denetim izi bırakan ekran olacaktır.
Bir admin paneli işini, biletleri hızlı ve güvenli kapatmanıza yardım ettiğinde hak eder. Doğru admin panel ekranlarını seçmenin en kolay yolu destek gerçeğinden başlamaktır; "tam" hissetmekten değil.
İlk olarak, zaten gelen (veya ilk 90 günde gelmesini beklediğiniz) en sık 20 soruyu yazın. Gelen kutunuzu, sohbet kayıtlarını ve iade notlarını kullanın. Koder.ai gibi bir şey inşa ediyorsanız, örnekler şunlar olabilir: "Neden giriş yapamıyorum?" "Bu ayarı kim değiştirdi?" "Neden iki kez ücretlendirildim?" "Verilerimi dışa aktarabilir misiniz?" "Uygulama herkes için mi kapalı?"
Sonra bu soruları birkaç tema altında gruplayın: erişim (kullanıcılar, kurumlar, roller), para (faturalama, faturalar, kullanım), veri (dışa aktarma, silme, saklama) ve olaylar (denetim, loglar, durum).
Her temayı bir ekrana çevirin ve 2-3 güvenli eylem ekleyin; bunlar çoğu bileti çözer. "Güvenli" geri alınabilir, loglanan ve kötüye kullanımı zor olan anlamına gelir. Örnekler: daveti yeniden gönderme, MFA sıfırlama, ödemeyi yeniden deneme, dışa aktarımı yeniden oluşturma veya konfigürasyon değişikliğini geri alma.
Her önerilen ekran için aynı puanlama lensini kullanın:
Biletleri uçtan uca çözen en küçük versiyonu inşa edin. İyi bir test, gerçek bir vakayı bir destek temsilcisinin mühendis istemeden çözüp çözememesi olur. Eğer çözemiyorsa, genellikle eksik bir detay vardır (örneğin son giriş, faturalama durumu veya neyin, ne zaman ve kim tarafından değiştiği).
Bu üç ekran bir ops admin panelinde günlük işlerin çoğunu yapar. Hızlıca iki soruyu yanıtlamalı: "Şu anda nerede yangın var?" ve "Kim etkilenmiş?"
Overview küçük, güvenilir bir nabız kontrolü olmalı. Bugün ve son 24 saate odaklı tutun: yeni kayıtlar, aktif kullanıcılar, ödeme hataları ve herhangi bir hata artışı. Destek ekibinin kaçırmaması gereken kısa bir uyarılar alanı ekleyin: olağan dışı giriş hataları, webhook hataları veya ani iade artışları gibi.
İyi bir kural: bu sayfadaki her metrik tek bir sonraki net tıklamaya götürmeli; genellikle Users, Organizations veya Logs olur.
Users ekranının mükemmel bir araması olmalı. Destek kişiler email, isim, kullanıcı ID ve organizasyonla arama yapabilmeli. Durum ve güven sinyallerini öne koyun: doğrulanmış email veya telefon (topluyorsanız), son giriş ve hesabın aktif mi, askıya alınmış mı yoksa davet edildi ama katılmamış mı.
Ana işlemleri tek bir tutarlı yerde tutun ve güvenli yapın: devre dışı bırakma veya yeniden etkinleştirme, erişimi sıfırlama (oturumlar, MFA veya parola ürününüze bağlı olarak) ve daveti yeniden gönderme. "İç not" alanı ekleyin; örneğin "9 Ocak'ta fatura değişikliği talebi" gibi, böylece biletler sıfırdan başlamaz.
Bu ekran üyeliği, mevcut planı, kullanım vs limitleri ve sahibi göstermeli. Destek genellikle "yanlış kişi erişimi var" veya "limiti aştık" vakalarını çözer, bu yüzden sahiplik devri ve üyelik yönetimini ekleyin.
Görünümleri filtreler, sıralama ve kaydedilmiş aramalarla hızlı tutun: "ödeme başarısız", "30 günde giriş yok", veya "limit aşıldı" gibi. Yavaş admin ekranları basit biletleri uzun sürümlü hale getirir.
Roller ve izinler destek ekibinin zaman kazanıp kaybettiği alandır. Bir kullanıcı "X yapamıyorum" dediğinde birkaç dakika içinde yanıt vermeniz gerekir. Bu ekranı rol tabanlı erişim kontrolünün (RBAC) açık, okunabilir bir görünümü olarak düşünün; geliştirici aracı gibi değil.
İki basit tabloyla başlayın: roller (neleri yapabilirler) ve kişiler (kimin hangi role sahip olduğu). En yararlı detay etkin erişimdir. Bir kullanıcının rollerini, herhangi bir org seviyesindeki rolünü ve varsa override'ları tek bir yerde gösterin; "Faturalamayı yönetebilir: Evet." gibi düz dil özeti ekleyin.
Güvenli bir izin düzenleyicisi önemlidir çünkü rol değişiklikleri hesapları hızla bozabilir. Kaydetmeden önce tam olarak neyin değişeceğini gösteren bir önizleme ekleyin: hangi yetenekler eklenecek veya kaldırılacak ve hangi kullanıcılar etkilenecek.
Destek dostu tutmak için bir "Neden bunu yapamıyor?" sorun giderici ekleyin. Destek bir eylem seçer (ör. "veri dışa aktar" veya "kullanıcı davet et"), kullanıcıyı seçer ve ekran eksik izni ve nerede verileceğini (rol vs org politikası) döndürür. Bu uzun geri dönüşleri azaltır.
Yüksek riskli işlemler için ekstra onay isteyin. Yaygın olanlar: yönetici rollerini değiştirme, faturalamaya veya ödeme bilgilerine erişim verme, prodüksiyon erişimi/dağıtım izinleri verme ve MFA gibi güvenlik kontrollerini devre dışı bırakma.
Son olarak, izin değişikliklerini denetlenebilir yapın. Her düzenleme kim tarafından yapıldığını, kimi etkilediğini, önce/sonra değerlerini ve nedeni kaydetmeli. Koder.ai gibi bir platformda bu geçmiş destek ekibinin bir kullanıcının neden aniden kaynak kodu dışa aktarabildiğini, dağıtım yapabildiğini veya özel bir alanı yönetebildiğini açıklamasına yardımcı olur.
Faturalama destek biletlerinin biriktiği yerdir. Bu admin paneli ekranları açık, hızlı ve kötü kullanılmaya zor olmayan şekilde olmalı. Sadece bir şeyi doğru yapacaksanız, şu sorunun yanıtını verin: "Hangi planda, ne ödedi ve neden erişim değişti?"
Mevcut planı, yenileme tarihini, durumu (active, trial, past due, canceled), koltuk sayısını ve fatura sahibini gösterin. Gerçeğin kaynağını üstte koyun; geçmiş (plan değişiklikleri, koltuk değişiklikleri) aşağıda olsun. Riskli kontrolleri (iptal, plan değiştir, yeniden başlat) görüntülemeyle ayrı tutun; onay ve gerekçe zorunlu olsun.
Destek basit bir fatura listesine ihtiyaç duyar: tarihler, tutarlar, vergi ve durum (ödendi, açık, başarısız, iade). Ödeme denemelerini ve hata nedenlerini (kart reddedildi veya doğrulama gerekli gibi) içermeli. Makbuzlara fatura satırından tek tıkla erişilmeli, ancak burada düzenleme yapmaktan kaçının.
Kullanımdan veya kredi bazlı ücretlendirmeden sorumluysanız, müşterinin gördüğü sayaçla eşleşen bir gösterge koyun. Mevcut dönem kullanımı, limitler, aşım ve herhangi bir cap gösterin. Destek ekibinin bunu basitçe açıklayabilmesi için kısa bir "neden engellendi" özeti ekleyin.
Buraya ait yaygın destek işlemleri yer alır ama kontrollü olmalı: bir kerelik kredi uygulama (süresi ve iç notla), deneme uzatma (sınırlı), vergi veya fatura adresi güncelleme (izlenebilir), başarısız ödemeyi yeniden deneme veya koltuk ekleme (planı değiştirmeden).
Okunur alanları düzenlenebilir alanlardan görsel olarak ayırın. Örneğin, "Plan: Business (yalnızca okunur)" ile "Koltuk sayısı (düzenlenebilir)" yan yana gösterin ki temsilci yanlışlıkla plan değişikliği tetiklemesin.
Destek "bir şey değişti" dediğinde bu iki ekran tahmini durdurur. Denetim kaydı size kim ne yaptıığını söyler. Sistem logu sistemin ne yaptığı veya yapamadığını gösterir. Birlikte takip sorularını azaltır ve hızlıca net cevap vermenizi sağlar.
Bir denetim kaydı üç soruyu bir bakışta yanıtlamalı: işlemi kim yaptı, neyi değiştirdi ve ne zaman gerçekleşti. Eğer nereden (IP adresi, cihaz, lokasyon tahmini) da yakalıyorsanız, şüpheli erişimi tespit edebilir ve garip davranışları kullanıcıyı suçlamadan açıklayabilirsiniz.
Destek için yararlı filtreler genelde aktör (admin, destek temsilcisi, son kullanıcı, API anahtarı), kullanıcı ve organizasyon, zaman aralığı, işlem türü (giriş, rol değişikliği, faturalama değişikliği, dışa aktarım) ve hedef nesne (hesap, proje, abonelik) içerir.
Her satırı okunabilir tutun: işlem adı, önce/sonra özeti ve mühendislikle paylaşılabilecek sabit bir olay ID'si.
Sistem logları "bozuldu" mu yoksa "çalıştı ama gecikti" mi ayırt etmenizi sağlar. Bu ekran hataları, tekrar denemeleri ve arka plan işlerini gruplayıp aynı zaman etrafında neler olduğuna bakmalı.
Hata ayıklamayı hızlandıracak dar bir alan gösterin: zaman damgası ve önem derecesi, istek ID ve korelasyon ID, servis veya iş adı (API, worker, billing sync), hata mesajı ile kısa bir stack trace (güvenliyse), tekrar deneme sayısı ve nihai durum.
Bu, destekleşteki gidip gelmeyi azaltır. Destek şu şekilde cevap verebilir: "Dışa aktarma 10:14'te başladı, iki kez tekrar denendi ve timeout ile başarısız oldu. Yeniden başlattık ve 10:19'da tamamlandı. Request ID: abc123."
Destek mühendisine ihtiyaç duymadan çoğu bileti baştan sona çözecek en küçük ekran setini hedefleyin.
Pratik bir v1 genellikle şunlardır:
Son ayın (veya ilk 90 gün için beklenen) biletlerini çekin ve her isteği puanlayın.
Basit bir yöntem:
Her ekranı tekrarlanabilir bir destek akışı etrafında tasarlayın.
İyi bir ekran bir temsilcinin şunları yapmasını sağlar:
Eğer temsilci hâlâ “bir eksik bilgi” için mühendis istemek zorundaysa, ekran eksik demektir.
Önce çalışır bir arama koyun: email, kullanıcı ID, isim ve organizasyonla bulunabilmeli.
Sonra destek için gerekli güven ve durum alanlarını gösterin:
İşlemleri tutarlı ve güvenli tutun: , , gibi, gerekli bir neden alanı ve denetim kaydı ile.
Destek için tek bakışta cevap verebilecekleri bilgileri gösterin:
Riskli kontrolleri görüntüden ayırın; iptal/plan değişikliği/yeniden başlatma gibi işlemler için onay ve neden gerektirin.
Faturalar hızlıca cevap vermeye yönelik olmalı, düzenleme amaçlı değil.
İçerik:
İzin verilen işlemler dar tutulmalı (ör. retry payment) ve her deneme loglanmalı.
Müşterinin gördüğü sayaçla aynı olsun.
En azından gösterin:
Kontrollü işlemler: , , , hepsi not ve denetim kaydıyla.
Evet—ikisine de ihtiyacınız var; çünkü farklı sorulara cevap verirler.
Birlikte destek ekibinin “ne oldu” diye tahminde bulunmasını engeller ve mühendisliğe yükseltmede stabil bir event/request ID sağlar.
Bayrakları kontrollü bir destek aracı gibi ele alın.
İyi varsayılanlar:
Bir bayrak kalıcı müşteri tercihi haline geliyorsa, onu gerçek bir ayara çevirin.
Exportlar veri sızdırmanın en kolay yollarından biridir; bu yüzden varsayılan olarak güvenli yapın.
Yapılması gerekenler:
Akış basit kalsın: tarih aralığı, birkaç filtre, CSV/JSON seçeneği.