14 Ara 2025·8 dk
SaaS Yetkilendirme Portalı İçin Nasıl Web Sitesi Oluşturulur
SaaS müşteri yetkilendirme portalı sitesi nasıl planlanır, tasarlanır ve oluşturulur—içerikten UX’e, kimlik doğrulamadan güvenliğe ve analitiğe kadar rehber.
SaaS müşteri yetkilendirme portalı sitesi nasıl planlanır, tasarlanır ve oluşturulur—içerikten UX’e, kimlik doğrulamadan güvenliğe ve analitiğe kadar rehber.
Bir müşteri yetkilendirme portalı, müşterilerin ekibinizi beklemeden ürününüzü başarılı şekilde kullanmaya gitmeleridir. “Yetkilendirme” genellikle üç ihtiyacı harmanlar: onboarding (kurulum ve aktivasyon), eğitim (iş akışları ve özelliklerin öğrenilmesi) ve destek (sorunları çözme ve cevap bulma).
Yeni bir müşteri için başarı görünümünü basit bir cümleyle yazmakla başlayın. Örnek: “Bir yönetici, veri kaynaklarını bağlayıp ekip arkadaşlarını davet ederek 30 dakika içinde ilk raporunu yayınlayabilmelidir.” Bu tanım portalın neleri içermesi gerektiğini yönlendirir: kurulum rehberleri, role‑göre kontrol listeleri, özellik gezintileri, sorun giderme ve en iyi uygulama örnekleri.
İyi bir portal “daha fazla içerik” değildir. Ölçülebilir çıktılar oluşturmalıdır:
Bu çıktıları desteklemek için portal sonraki adımı belirgin kılmalı, aramayı azaltmalı ve bilgiyi güncel tutmalıdır.
Çoğu SaaS ürünü birden fazla kitleye sahiptir ve portal bunu kabul etmelidir:
Aylık gözden geçireceğiniz küçük bir metrik seti seçin, örneğin:
Bu metrikler önceden tanımlandığında, içerik, UX ve erişimle ilgili her karar müşterilerin başarılı olmasına odaklanır.
Harika bir yetkilendirme portalı kütüphane değildir—kısayoldur. Sayfalar, araçlar veya şablonlar seçmeden önce portalın kimin için olduğunu, ne yapmaya çalıştıklarını ve ne zaman yardıma ihtiyaç duyduklarını netleştirin.
Personaları pratik tutun: demografi yerine hedeflere, bağlama ve karar yetkisine odaklanın. Tipik bir SaaS portalı için sıkça karşılaşacağınız roller:
Her persona için en önemli 5 görevi fiil cümlesi olarak yazın (“Kullanıcı davet et”, “Veri dışa aktar”, “SSO kur”). Bu görevler portalın ana gezinti adayları olur.
İhtiyaçları aşamaya göre organize edin ki portal doğru zamanda doğru soruyu cevaplasın:
En sık ve maliyetli soruları destek ticketları, sohbet kayıtları, satış görüşmeleri ve CSM notları içinden çekin. “Entegrasyon kurulumu”, “izinlerde karışıklık” veya “neden çalışmıyor?” gibi kalıplar genellikle ilk bilgi tabanı kategorilerinizi tanımlar.
Basit bir kural kullanın:
Harika bir yetkilendirme portalı açık hissettirir: insanlar iner, doğru yolu seçer ve hızlıca görevi tamamlar. Bu, net bir yapı ve ölçeklenebilir küçük bir içerik setiyle başlar—böylece portal dağınık bir dosya dolabına dönüşmez.
Çoğu SaaS portalı 4–6 üst düzey alandan iyi çalışır. Yaygın ve etkili bir set:
Bu isimler müşterilerin zaten kullandığı kelimelerle eşleşmeli. Ürününüz “Workspaces” diyorsa dokümanları “Projects” olarak etiketlemeyin.
İki katmanlı gezinme kullanın:
Ana sayfa ve önemli sayfalarda “Önerilen sonraki adım” ekleyin (ör. “SSO kur”, “Ekip davet et”, “Kullanımı takip et”). Bu, çıkmazları azaltır ama katı bir öğrenme yolu dayatmaz.
Küçük bir araç seti seçin ve tutarlı uygulayın:
Her alanın isimlendirilmiş bir sahibi ve inceleme periyodu olmalı. Her sayfada basit bir kural ekleyin: Sahip, Son incelendi, Sonraki inceleme tarihi. Bu, ölü içeriği engeller ve güncellemeleri yıllık temizlik yerine rutin hale getirir.
İyi yetkilendirme portalları ilk ziyaret edenin bile ne yapacağını anında anlamasını sağlar. UX hedefi hızdır: müşterilerin doğru cevabı veya sonraki adımı saniyeler içinde bulmasını sağlamak.
Ana sayfayı pazarlama sayfası gibi değil, kontrol paneli gibi düşünün. İçerikler:
Birden fazla ürün veya planınız varsa, kullanıcıların doğru alana gitmesini sağlamak için basit bir “Ürün/workspace seçici” ekleyin.
Etiketler müşteri diline uymalı, ekip içi terimlere değil. Örneğin “Kullanıcı ekle” genellikle “Provisioning”den daha iyidir; “Entegrasyonları bağla” “Ecosystem”den daha anlaşılır.
Sayfa düzenlerini tutarlı tutun:
Bu tutarlılık bilişsel yükü azaltır ve portalın öğrenilebilir hissetmesini sağlar.
Ziyaretçilerin çoğu tarar. Bunu destekleyin:
Uzun sayfalarda sabitlenen bir içindekiler menüsü ekleyin, kullanıcıların tam olarak ihtiyaç duydukları bölüme atlamasını sağlar.
Hızlı self‑servis deneyimi herkes için çalışmalıdır:
Bu temeller mobilde, parlak ortamlarda ve yorgun kullanıcılar için de kullanılabilirliği artırır.
Bir bilgi tabanı yalnızca güncel kaldığında işe yarar. Amaç, içerik oluşturmayı, güncellemeyi ve emekliye ayırmayı rutin hale getirmektir—böylece ekip ertelemek yerine düzenli olarak bakım yapar.
Müşteri hedeflerine uygun küçük kategori setiyle başlayın (organizasyon yapınıza göre değil). Esnek filtreleme için etiketler ekleyin.
Yeniden kullanılabilir makale şablonları tanımlayın:
Şablonlar düzenleme süresini azaltır ve okuyucuların taramasını kolaylaştırır.
Tutarlılık mükemmel yazıdan iyidir. Kısa bir stil rehberi yayınlayın ve editörünüzde bağlantı verin.
Yararlı kurallar:
Her makale okuyucunun ilerlemesini sağlamalı. Sonunda 2–4 ilgili bağlantı ekleyin, örnekler:
Bu bağlantılar çıkmazları azaltır ve müşteriyi self‑serviste tutar.
Alt kısma hafif bir istem ekleyin:
Raporları doküman sahibi (doküman ekibi, destek operasyonları veya PM) altında belirli bir SLA ile yönlendirin ki düzeltmeler makale problem olmadan önce yapılsın.
İyi bir portal sadece makaleleri depolamaz—müşterileri değere aktif şekilde yönlendirir. Amaç, yeni bir kullanıcının “giriş yaptım”dan “ürünü başarıyla kurdum ve kullandım” noktasına minimum destekle ulaşmasıdır.
Rol tabanlı yollarla başlayın; bir yöneticinin ilk haftası bir son kullanıcıdan farklıdır.
Üzerine kullanım amaçlı yollar (ör. “Onay otomasyonu” vs “Haftalık rapor oluşturma”) ekleyin ki müşteri niyetine uygun yolu seçebilsin.
Her yol sonlu hissettirmeli. Kısa bir kontrol listesi ve kilometre taşları ekleyin: “Veri kaynağını bağla”, “Ekip davet et” gibi. Süre tahminleri (5 dakika, 20 dakika) ekleyin ki kullanıcı planlayabilsin.
Adımları küçük ve taranabilir tutun. Mümkünse her adımı tek odaklı rehbere bağlayın. Onboarding e‑postaları veya uygulama içi istemler varsa, aynı kilometre taşlarına işaret edin ki ilerleme pekişsin.
Erken kazanımlar bırakmayı azaltır. Her yolda şunlar olsun:
Her hızlı kazancı “Sonraki ne?” bağlantısıyla bitirin; bu kullanıcıyı bir sonraki kilometre taşına veya /help-center içindeki daha kapsamlı bir kursta ilerletir.
Portalınız güven üzerine kurulur: müşteriler doğru içeriğe çabucak ulaşmalı, sizin ekibiniz ise özel dökümanların, eğitimlerin ve hesap verilerinin açığa çıkmadığından emin olmalıdır.
Neler public, nelerin private olacağına karar verin.
Emin değilseniz, temel bilgiler (genel bakış, onboarding temelleri) public kalsın ve yapılandırmaya, fiyat kademelerine veya müşteri verilerine bağlı her şeyi gate'leyin.
Kurum müşterileri genellikle tek oturum açma bekler.
Kenar durumları da tanımlayın: e‑postasını değiştiren kullanıcılar, yan kuruluşlar arasında çoğaltılmış hesaplar ve davet edilmiş fakat etkinleştirmemiş kullanıcılar gibi.
İzinleri organizasyon şeması yerine gerçek iş akışlarına göre eşleyin. Pratik bir temel:
Mümkünse ikinci bir boyut ekleyin: hesap‑bazlı erişim (yalnızca şirketinize ait içeriği görme) ve kademeye‑göre erişim (yalnızca planınızın özelliklerini görme).
Açık varsayılanlar belirleyin: parola kuralları, oturum zaman aşımı, hesap kurtarma.
Kurtarma akışlarını basit tutun (sihirli bağlantı veya e‑posta sıfırlama), kritik kimlik olaylarını loglayın ve “girişte sorun mu yaşıyorsunuz?” gibi kısa bir sayfa ile kullanıcıyı /support yönlendirin (bağlamı ekleyerek).
Bir yetkilendirme portalı bazen destek konuşmaları, hesap detayları, eğitim ilerlemeleri ve hassas ekler içerir. Güvenliği portal UX'inin bir parçası olarak ele alın: müşteriler güvende hissetmeli, ekibiniz ise net kontrollera sahip olmalıdır.
"Önce reddet" yaklaşımından başlayın ve sadece gerektiği kadar erişim açın. Roller müşteri ekiplerine uygun şekilde tanımlanmalı (Owner, Admin, Member, Read‑only gibi) ve her rolün ne göreceği/ne yapacağı sıkı şekilde sınırlandırılmalıdır.
İyi varsayılanlar hataları azaltır:
Birçok SaaS alıcısı SOC 2, GDPR ve veri yönetimini soracaktır. Sertifikanız olmasa bile uygulamalarınızı belgeleyerek ve güvenlik odaklı araçlar kullanarak erken hazırlanın.
“SOC 2 uyumlu” gibi iddialarda bulunmayın unless raporunuz varsa. Bunun yerine gerçek uygulamalarınızı söyleyin: iletimde şifreleme, erişim kontrolleri, saklama politikaları ve veri talepleriyle başa çıkma yöntemleri.
Denetim kayıtları tahmin yerine bilmenizi sağlar. Kritik portal eylemlerini zaman damgası ve aktörle loglayın:
Logları aranabilir ve dışa aktarılabilir yapın.
Footer'a linkleyebileceğiniz yalın bir güvenlik sayfası oluşturun (ör. /security). İçerik:
Portal, müşterilerin zaten güvendiği sistemlerle bağlandığında akıllı hisseder. Ama amaç her şeyi entegre etmek değil—amaç ölü noktaları kaldırmak ve sonraki adımı belirgin kılmaktır.
Yardım merkezi, ürün dokümanları ve API dokümanları farklı yerlerdeyse müşteriler sekmeler arasında dolaşır ve bağlam kaybeder. Portal gezinmesine canonical kaynakları doğrudan bağlayın ve URL'leri stabil tutun: ürün dokümanları, API dokümanları, sürüm notları ve durum sayfası. Bu kaynaklar ayrı sitelerdeyse bile adlandırma, breadcrumb ve “portala geri dön” bağlantılarıyla deneyimi tutarlı yapın (örnek yollar: /docs, /api, /status).
Self‑servis işe yarar ta ki işe yaramayana kadar—o zaman müşteriler hızlı yardım ister.
Net bir yükseltme yolu tasarlayın:
Otomatik doldurma ile mümkün olduğunca çok alanı doldurun: sayfa URL'si, makale ID, ürün alanı ve kısa "ne denediniz" alanı. Bu destek triage'ını hızlandırır. İletişim giriş noktaları /contact veya /support gibi yollar altında toplanabilir.
Mümkünse, portala hesap bağlamı geçirin: plan seviyesi, etkin özellikler, bölge ve yenileme aşaması. Bununla şunları yapabilirsiniz:
Küçük başlayın: plan seviyesi bayrağı bile alaka düzeyini dramatik biçimde artırır.
Portal, insanların cevapları saniyeler içinde bulabildiğinde işe yarar. En iyi bilgi tabanı bile kullanıcıların yardım için dosya dolabında gezmesi gerekiyorsa başarısız olur. Arama ve keşfi portalın çekirdek özellikleri olarak ele alın.
Her sayfaya belirgin bir arama çubuğu koyun. Hızlı niyet için optimize edin:
"Sonuç yok" raporu self‑servis kapsamınızı hızla geliştirmek için en hızlı yollardan biridir. Şunları takip edin:
Bunları harekete çevirin: eksik makaleler oluşturun, mevcut sayfaları daha iyi başlıklarla genişletin veya sık trafik alan sayfalara kısa SSS bölümü ekleyin.
Arama sonuçları kararsızlığı azaltmalı:
Kullanıcı hangi sonucu seçeceğine karar veremezse ticket oluşturmaya yönelir.
Kişiselleştirme kullanıcıyı hızlandırmalı, portalı parçalara ayırmamalı. Hafif öneriler ekleyin:
Ayrıca tüm içeriği dolaşmanın kolay bir yolu olsun ki ileri düzey kullanıcılar önerilerin ötesini keşfedebilsin.
Portal lansmanda bitmez. İçeriği ürün gibi yönetenler en hızlı gelişen portallardır: ne olduğunu ölçün, nedenini anlayın, sonra küçük değişikliklerle ilerleyin.
Müşteri başarısına bağlanan küçük bir olay setiyle başlayın, boş gösterişli metriklerden kaçının:
Mümkünse olaylara ek bağlam ekleyin: hesap kademesi, rol, ürün planı ve kullanıcının geldiği yer (in‑app, e‑posta, arama).
Günlük kararların çoğunu karşılayacak birkaç pano:
Bu panoları Support ve Customer Success ile paylaşıp gelişimin bölünmesini engelleyin.
Bir seferde bir değişiklik deneyin ve 1–2 hafta boyunca etkisini ölçün:
Değişiklikleri ve hareket eden metrikleri belgeleyin (tamamlama oranı, bırakma oranı, destek temasları) ki öğrenim birikimi sağlansın.
Hafif aylık rutin belirleyin: yüksek trafikli ama düşük faydalı sayfaları güncelleyin ve kullanıcıları yanıltan eski sayfaları emekliye ayırın. Daha küçük ama güncel bir portal genellikle büyük ama bayat bir portaldan daha iyi performans gösterir.
Portalın mükemmel bir yığını olması gerekmez—hızla gönderebileceğiniz, içeriği kimin yöneteceğini ve ürün/müşteri verisiyle ne kadar sıkı bağ kurmanız gerektiğini karşılayan bir yığın yeterlidir.
CMS‑first (headless veya geleneksel CMS): Portal içerik ağırlıklıysa ve teknik olmayan ekipler sık yayın yapacaksa en iyi seçenek. Auth/SSO ve bir arama katmanı ile eşleştirin.
Portal platformu (amaç‑için yapılmış): Bilgi tabanı, kategoriler, öğrenme yolları, ticket yönlendirme widget'ları ve temel analitik gibi özellikleri kutudan çıkarır; mühendislik ihtiyacı azdır fakat UI ve özel iş akışlarında esneklik sınırlıdır.
Özel uygulama (framework + API'ler): Derin kişiselleştirme, karmaşık roller veya sıkı in‑product deneyimler gerekiyorsa uygun. Daha fazla geliştirme süresi ve bakım planlayın; hangi parçaların özelleştirileceğini netleştirin.
Portal UX ve bilgi mimarisini tam inşa etmeden hızlı doğrulamak isterseniz, Koder.ai ile prototip oluşturabilirsiniz. Koder.ai sohbet tabanlı iş akışıyla tam uygulama üretebildiği için (genellikle web için React, backend için Go + PostgreSQL ve mobil için Flutter), ekipler navigasyon, rol tabanlı sayfalar, arama akışları ve admin düzenleme ekranları içeren çalışan bir portal iskeleti hızla kurup planlama modunda yineleyebilir ve hazır olduklarında kaynak kodunu dışa aktarabilirler.
Duyurudan önce odaklı bir QA çalışması yapın:
Basit bir go/no‑go gate isterseniz, ekip onayı için tek sayfalık bir kontrol listesi oluşturun ve /blog veya dahili wiki'de saklayın.
Her içerik alanı için sahip atayın, inceleme tarihleri belirleyin (ör. 90 günde bir) ve önemli rehberler için versiyon takibi yapın. Hafif bir içerik takvimi (yeni, güncellenen, emekliye ayrılan) bayat içeriğin birikmesini engeller.
30 gün: çekirdek IA, üst onboarding rehberleri ve en çok sorulan destek makalelerini yayınlayın; temel analitikleri enstrümante edin.
60 gün: aramayı iyileştirin, şablonlar/playbook'lar ekleyin, rol‑tabanlı açılış sayfaları oluşturun ve destek iş akışlarıyla entegrasyonları başlatın.
90 gün: öğrenme yollarını genişletin, kişiselleştirme ekleyin, gezinme üzerinde A/B testleri yapın ve arama ile ticket verilerine dayalı düzenli içerik denetimleri başlatın.
Bir enablement portal, müşterilerin ekibinizi beklemeden ürünü başarıyla kullanmalarını sağlar ve şu öğeleri birleştirir:
Portal, sadece “daha fazla içerik” değil; daha hızlı değer elde etme, daha az ticket ve daha yüksek benimseme gibi çıktılara odaklanmalıdır.
Yeni bir müşteri için başarıyı bir cümleyle tanımlayın ve portal içeriğini buna göre oluşturun.
Örnek: “Bir yönetici, veri kaynaklarını bağlayıp ekip arkadaşlarını davet ederek 30 dakika içinde ilk raporunu yayınlayabilmelidir.”
Bundan yola çıkarak gerekli içerikleri çıkarabilirsiniz: kurulum rehberleri, role göre kontrol listeleri, adım adım rehberler, sorun giderme ve en iyi uygulama örnekleri.
Aylık gözden geçirebileceğiniz küçük bir metrik seti seçin ve bunları müşteri çıktılarıyla eşleyin:
Bu ölçümleri erken enstrümante ederek portalı kanıta dayalı olarak geliştirin.
Pratik ve 3–5 persona ile başlayın; her biri için en önemli görevleri fiil olarak yazın (ör. “Kullanıcı davet et”, “Veri dışa aktar”, “SSO kur”). Yaygın roller şunlardır:
Bu görevler, ana gezinme ve içerik yol haritanızı oluşturur.
İçeriği müşteri yolculuğu aşamalarına göre organize edin ki kullanıcılar doğru zamanda doğru cevabı bulsun:
Her aşama için kontrol listeleri, kilometre taşları ve “önerilen sonraki adımlar” ekleyin, böylece yol yarıda kalmaz.
Basit bir kural kullanın:
Bu ayrım, kritik iş akışlarını yarıda bırakmadan portalı faydalı kılar.
Çoğu SaaS portalı için 4–6 sabit üst düzey bölüm işe yarar; örnek bir set:
İsimlendirme müşterinin kullandığı kelimelerle eşleşmeli ve bölümler içinde “Temel” vs “İleri” gibi gezinme olmalı. Önemli sayfaları “Önerilen sonraki adım” ile bitirin.
Hızı varsayılan hale getirin:
Uzun makalelerde kullanıcıların atlayabilmesi için içindekiler menüsü ekleyin.
Bilgi tabanını sürdürülebilir kılmak için hafif yönetişim uygulayın:
Neyin herkese açık neyin özel olacağına karar verin:
Kurumsal müşteriler için ve/veya SSO desteği planlayın; kimlik eşlemesi için genellikle , , ve isteğe bağlı olarak , veya alanları kaydedilir.
Varsayılan olarak en az ayrıcalık (deny by default) prensibini uygulayın. Roller gerçek iş akışlarına göre eşlenmeli (Owner, Admin, Member, Read‑only gibi) ve her rolün görebilecekleri/ yapabilecekleri net olmalı.
İyi varsayılanlar:
Uyumluluk iddialarında aşırıya kaçmayın; sertifikanız yoksa “SOC 2 compliant” gibi ifadelerden kaçının. Bunun yerine yaptıklarınızı açıkça belgeleyin: iletimde şifreleme, erişim kontrolleri, saklama politikaları ve veri talepleriyle nasıl uğraştığınız.
Ayrıca kullanışlı denetim kayıtları tutun:
Kısa, anlaşılır bir güvenlik sayfası yayınlayın ve footer'da linkleyin: nerede veri tutuluyor, nasıl korunuyor, güvenlik sorunları nasıl bildirilir, gizlilik yaklaşımınız ve kontrol özetleri.
Portalınızı ürün, destek ve müşterinin kullandığı verilerle bağlamak deneyimi akıllı kılar. Ama her şeyi entegre etmek gerekmez; amaç ölü noktaları kaldırmak ve sonraki adımı belirgin yapmak.
Doküman, API referansları ve durum sayfası gibi kaynakları portal gezinmesine bağlayın ve adlandırmalarda tutarlılık sağlayın (ör. /docs, /api, /status gibi görünür yollar). Destek elden çıkışını şu şekilde planlayın:
Gönderen bağlamı (hesap bilgisi, plan, ürün alanı) mümkün olduğunca portal bağlamına aktarın ki kişiselleştirme ve alakasız sonuçların gizlenmesi mümkün olsun.
Arama her sayfada merkezi olmalı:
"Sonuç yok" raporunu içerik yol haritası olarak kullanın: en çok aranan ama içeriği olmayan sorguları takip edip eksik makaleler oluşturun. Arama sonuçları kısa özetler, güncelleme tarihi ve hedef kitle (Başlangıç/İleri) gibi meta veriler göstermeli ki kullanıcı hangi sonucu seçeceğine karar verebilsin.
Portalı ürün gibi sürekli geliştirin: ölçün, nedenini anlayın, küçük değişikliklerle iterasyon yapın.
Öncelikli izlenecek olaylar:
Panolar oluşturun: benimseme ve popüler içerikler, öğrenme yollarındaki bırakma noktaları, ilk değere ulaşma süresi ve yönlendirme göstergeleri. Küçük kontrollü deneyler yapın (yeni onboarding yolu yayınlama, CTA değişikliği, başlık iyileştirmeleri) ve etkisini ölçün. Düşük faydalı yüksek trafik sayfalarını aylık güncelleme/retire rutininize alın.
Portal için uygun teknoloji yığını, hızlı gönderim, içeriği kimin yöneteceği ve ürünle ne kadar sıkı entegrasyon gerektiğine bağlıdır.
Yaklaşımlar:
Lansman öncesi odaklı bir QA yapın:
Yönetim çerçevesi planlayın: her içerik alanı için sahip atayın, inceleme tarihleri belirleyin (ör. 90 günde bir) ve önemli rehberler için versiyon takibi yapın. Hafif bir içerik takvimi (yeni, güncellenen, emekliye ayrılan) bayat içeriğin birikmesini engeller.
Pratik 30/60/90 planı:
Bu yaklaşımla bayat içerik birikmez ve güncellemeler rutin haline gelir.
Portal UX ve bilgi mimarisini hızlı doğrulamak isterseniz Koder.ai ile prototip oluşturabilirsiniz. Koder.ai sohbet tabanlı akışla tam uygulama ürettiği için (genellikle web için React, backend için Go + PostgreSQL, mobil için Flutter), ekipler navigasyon, rol tabanlı sayfalar, arama akışları ve admin düzenleme ekranları içeren çalışan bir portal iskeleti hızlıca oluşturup planlama modunda yineleyebilir ve üretime geçmeye hazır olduklarında kaynak kodunu dışa aktarabilirler.
Bir go/no-go listesi yapın ve ekibinizin onayına sunun.