Aydınlatma metni yükleniyor…
Müşteri portalı maliyeti; ekran sayısından veya kayıtlı kullanıcı sayısından tek başına hesaplanmaz. Üyelik ve kimlik doğrulama, hesap yapısı, belge erişimi, destek talepleri, bildirimler, ödeme, yetkilendirme, entegrasyon, veri taşıma, güvenlik, test ve işletim sorumlulukları toplam kapsamı belirler.
Sağlıklı teklif karşılaştırması için “portal yapılacak” demek yerine müşterinin hangi görevi, hangi veriyle, hangi yetki altında ve hangi hata durumlarıyla tamamlayacağını yazmak gerekir. Bu rehber sabit fiyat vermez; farklı teklifleri aynı kapsam üzerinden karşılaştırmak için bir yöntem sunar.
Müşteri Portalı Nedir, B2B Bayi Portalından Nasıl Ayrılır?
Müşteri portalı, bireysel veya kurumsal son müşterinin kendi hesabına bağlı işlemleri güvenli oturumla yapabildiği web yazılımıdır. Üyelik bilgisi güncelleme, sözleşme veya fatura görüntüleme, destek talebi oluşturma, randevu/başvuru durumu izleme, ödeme yapma ve bildirim tercihlerini yönetme örnek görevlerdir.
Bayi portalı çoğunlukla müşteriye özel katalog, fiyat, stok, teklif, sipariş, limit ve ticari onaylara odaklanır. Bu makale ise ürün ve sipariş ticaretinden ziyade son müşterinin öz-hizmet görevlerini kapsar. Aynı sistem iki rolü taşıyabilir; fakat veri, yetki ve işlem kuralları ayrı tanımlanmalıdır.
Daha geniş B2C modül ve entegrasyon çerçevesi için B2C yazılımı seçim rehberini inceleyebilirsiniz.
Kumsal Müşteri Öz-Hizmet Kapsam Matrisi
Bu özgün matris portalı sekiz kapsam alanında değerlendirir: kimlik, hesap, belge, talep, bildirim, ödeme, yetki/destek ve işletim/devir. Bir fiyat listesi değildir. Her alan için kullanıcı görevi, ana veri kaynağı, istisnalar, güvenlik sınırı, kabul testi, operasyon sahibi ve sonraki sürüm kararı yazılır.
| Alan | Temel karar | Maliyet sürücüleri |
|---|---|---|
| Kimlik ve üyelik | Kim nasıl kaydolur ve hesabını kurtarır? | Davet/açık kayıt, doğrulama, MFA, birleşik oturum, hesap kurtarma |
| Hesap ve profil | Kullanıcı hangi müşteri, abonelik veya hizmete bağlıdır? | Hesap ilişkileri, yetkiler, tercih ve onay kayıtları |
| Belge | Hangi belge kimden gelir ve kim görebilir? | Üretim, arşiv, sürüm, imza, indirme ve saklama |
| Talep | Hangi istek hangi ekibe ve duruma gider? | Form, dosya, kategori, SLA, mesaj, atama ve kapanış |
| Bildirim | Hangi olay hangi kanaldan bildirilir? | E-posta/SMS/push, şablon, tercih, tekrar ve teslim kaydı |
| Ödeme | Hangi borç veya işlem nasıl ödenir? | Sağlayıcı, yöntem, geri bildirim, mutabakat, iade ve hata |
| Yetki ve destek | Destek ekibi kullanıcıya nasıl yardımcı olur? | Rol, nesne erişimi, kullanıcı adına işlem, denetim izi |
| İşletim ve devir | Sistemi kim izler, günceller ve devralır? | Altyapı, log, yedek, olay, dokümantasyon ve kaynak sahipliği |
1. Üyelik ve Kimlik Doğrulama Kapsamı
Açık kayıt, davetli kayıt, mevcut müşteri numarasıyla eşleme veya kurum hesabı üzerinden giriş aynı geliştirme değildir. E-posta/telefon doğrulama, çok faktörlü kimlik doğrulama, sosyal veya kurumsal oturum, parola sıfırlama, kilitlenme, cihaz/oturum yönetimi ve hesap kapatma senaryoları ayrı kararlardır.
NIST Digital Identity Guidelines, kimlik doğrulayıcıların bağlanması, kullanılması, kurtarılması ve yaşam döngüsünün yönetilmesini ayrı gereksinimler olarak ele alır. Portal projesi bir kamu standardına uyduğunu varsaymamalı; kendi veri ve riskine göre kimlik doğrulama seviyesi, kurtarma kanalı ve destek yetkisini uzmanlarla belirlemelidir.
2. Hesap, Profil ve Hizmet İlişkileri
Tek kullanıcı tek hesap modeli basit görünebilir. Aile, şirket, şube, abonelik, poliçe, cihaz, araç, tesis veya birden fazla hizmet ilişkisi olduğunda veri modeli büyür. Kullanıcı bir ilişkiye başvurabilir, yönetici onaylayabilir veya ilişki başka bir ana sistemden gelebilir.
Profilde hangi alanların kullanıcı tarafından değiştirilebileceği; değişikliğin doğrudan mı yoksa onayla mı ana sisteme geçeceği belirlenmelidir. Adres, iletişim, fatura veya izin değişiklikleri farklı sahip ve doğrulama gerektirebilir.
3. Belge Merkezi Maliyetini Ne Artırır?
Sadece hazır PDF indirmek ile portaldan sözleşme üretmek aynı kapsam değildir. Belgenin kaynağı, formatı, kullanıcıya/hesaba eşlenmesi, sürümü, tarihi, indirme yetkisi, arşiv süresi, arama/filtre, çok dil ve erişilebilir alternatifler planlanır.
Belge yükleme varsa dosya türü, boyut, zararlı içerik kontrolü, durum, ret gerekçesi, saklama ve destek davranışı eklenir. Elektronik imza veya üçüncü taraf doğrulama gerektiğinde sağlayıcı, geri çağrı, iptal ve kanıt kayıtları ayrı entegrasyon olur. Hukuki geçerlilik ve saklama süresi ilgili uzmanlarca belirlenmelidir.
4. Talep ve Destek Akışları
“Destek talebi aç” özelliği; konu seçimi, açıklama, belge, müşteri/hizmet eşleme, öncelik, atama, durumlar, mesajlaşma, bildirim, kapanış ve yeniden açma kararlarını içerir. Talebin CRM, yardım masası, e-posta veya özel yönetim ekranında işlenmesi entegrasyon kapsamını değiştirir.
Müşteri portalda bir durum görürken operasyon ekibi başka sistemde çalışıyorsa durum sözlüğü ve güncelleme yönü belirlenmelidir. Kullanıcıya “çözüldü” gösteren fakat arka ofiste açık kalan kayıt güven ve destek yükü yaratır.
5. Bildirimler ve İletişim Tercihleri
Bildirim yalnız e-posta göndermek değildir. Olay, alıcı, kanal, şablon, dil, tekrar, teslim hatası ve tercih kuralları tanımlanır. Güvenlik bildirimi, işlem durumu ve pazarlama iletişimi aynı tercih altında toplanmamalıdır. Hangi kaydın zorunlu operasyon mesajı, hangisinin kullanıcı tercihine bağlı olduğu hukuk ve iş birimleriyle doğrulanmalıdır.
SMS veya push servisleri kullanıldığında birim maliyet, kota, başarısız teslim, sağlayıcı kesintisi ve alternatif kanal işletim maliyetine eklenir. Bildirim bağlantılarının kullanıcıyı yetkisiz veri göstermeden doğru işleme götürmesi test edilir.
6. Ödeme ve Mutabakat Kapsamı
Portal; yalnız borç gösterebilir, ödeme sağlayıcısının barındırdığı sayfaya yönlendirebilir veya daha bütünleşik ödeme alanları kullanabilir. Tek seferlik ödeme, kayıtlı yöntem, taksit, otomatik tahsilat, kısmi ödeme, çoklu para birimi, iade ve makbuz farklı kapsamlar doğurur.
Başarılı ekran ödeme kaydının kesinleştiğini tek başına kanıtlamaz. Sağlayıcı geri bildirimi, tekrar eden çağrı, gecikme, iptal, mutabakat ve muhasebe kaydı ele alınmalıdır. Kart verisi sorumluluğu ve uygulanacak standartlar ödeme sağlayıcısı, kuruluşun yapısı ve uzman değerlendirmesiyle belirlenmeli; makale veya teklif tek başına uyumluluk kanıtı sayılmamalıdır.
7. Yetkilendirme, Güvenlik ve Destek Araçları
Giriş yapmış olmak her kaydı görme hakkı vermez. Her belge, ödeme, talep ve profil işlemi kullanıcının ilgili hesap/nesne üzerindeki yetkisiyle doğrulanmalıdır. Destek çalışanı kullanıcı hesabını görüntüleyebiliyor veya kullanıcı adına işlem yapabiliyorsa yetki sınırı, gerekçe, süre ve denetim kaydı gerekir.
OWASP Application Security Verification Standard, web uygulamalarındaki teknik güvenlik kontrollerini tanımlamak ve doğrulamak için bir gereksinim temeli sunar. Portal teklifi; kimlik, oturum, erişim kontrolü, doğrulama, veri koruma, günlükleme ve hata davranışı için riskine uygun test kapsamını yazmalıdır. Bir kontrol listesini anmak güvenliği veya uyumu garanti etmez.
8. Erişilebilirlik, İşletim ve Devir
Portal müşterinin hizmete erişim kanalıysa klavye, odak sırası, etiketler, hata mesajları, durum değişiklikleri, renk/kontrast, mobil kullanım ve yardımcı teknoloji testleri kapsamda olmalıdır. W3C WCAG 2.2, algılanabilir, kullanılabilir, anlaşılabilir ve sağlam deneyimler için test edilebilir başarı ölçütleri sunar. Uygulanacak seviye ve yasal yükümlülük ayrıca doğrulanmalıdır.
İşletim maliyeti; barındırma, depolama, mesaj servisleri, izleme, yedek, sertifika, güvenlik güncellemesi, olay müdahalesi, kullanıcı desteği ve yeni geliştirmeleri içerir. Kaynak kod, veri modeli, entegrasyon bilgileri, sağlayıcı hesapları, ortamlar, log erişimi ve geri yükleme yöntemi devir planında açık olmalıdır.
Entegrasyonlar Maliyeti Nasıl Değiştirir?
Portal çoğu zaman CRM, ERP, muhasebe, ödeme, yardım masası, belge, kimlik veya bildirim sistemleriyle çalışır. Her entegrasyon için veri alanı, ana kayıt sistemi, yön, tetikleyici, sıklık, yetki, limit, zaman aşımı, hata, tekrar deneme, izleme, test ortamı ve sorumlu ekip yazılmalıdır.
“API mevcut” ifadesi bu kararları cevaplamaz. Teklifleri aynı veri akışlarıyla karşılaştırmak için web yazılım entegrasyonları rehberinden yararlanabilirsiniz.
Müşteri Portalı İçin Hazır, Özel ve Hibrit Seçenekler
| Yaklaşım | Uygun olabilecek durum | Maliyet ve risk sınırı |
|---|---|---|
| Hazır ürün | Görevler standart, entegrasyonlar destekli, hızlı başlangıç önemli | Lisans, kullanıcı/özellik katmanı, özelleştirme, veri çıkışı |
| Özel yazılım | Hesap, belge, yetki, talep veya entegrasyon kuralları ayırt edici | Analiz, geliştirme, test, bakım ve ürün sahipliği |
| Hibrit | Kimlik/ödeme gibi standart servisler ile özel görev akışları birleşecek | Sınırların, sağlayıcıların ve sürüm uyumluluğunun sahipliği |
Kararı ilk geliştirme bedeliyle sınırlamayın. Lisans, işlem/mesaj, entegrasyon, veri taşıma, eğitim, destek, altyapı, güvenlik, erişilebilirlik, bakım, yükseltme ve çıkış maliyetini aynı dönem için karşılaştırın.
Teklif Karşılaştırmasında Hangi Kalemler Ayrı Olmalı?
- Keşif, süreç ve kullanıcı araştırması
- Bilgi mimarisi, UX, görsel tasarım ve prototip
- Sekiz matris alanından hangilerinin ilk sürümde olduğu
- Yönetim paneli, rol ve içerik/işlem sahipliği
- Her entegrasyonun alan ve hata kapsamı
- Veri/belge taşıma, temizleme ve doğrulama
- İşlev, yetki, güvenlik, erişilebilirlik, performans ve cihaz testleri
- Pilot, eğitim, canlı geçiş ve geri dönüş
- Altyapı, lisans, mesaj, ödeme ve üçüncü taraf ücretleri
- Garanti dönemi, bakım, olay desteği ve yeni geliştirme ayrımı
- Kaynak kod, veri, hesap, dokümantasyon ve devir koşulları
Portal kapsamının özel web yazılımı içindeki yerini görmek için web yazılımı kullanım alanları rehberini kullanabilirsiniz.
Başarı Nasıl Ölçülmeli?
Ölçüm, “kaç kişi giriş yaptı?” sorusundan görev sonucuna ilerlemelidir. Uygun göstergeler; hesap kurtarma başarısı, belgeye erişim, doğru tamamlanan ödeme, talebin doğru ekibe ulaşması, tekrar iletişim, hata oranı, entegrasyon/mutabakat sorunu, destekle tamamlanan görev ve yetkisiz erişim olayı olabilir.
Başlangıç ölçümü olmadan iyileşme iddiası kurmayın. Portal kullanım zorunluluğu, müşteri profili, hizmet kalitesi ve operasyon kapasitesi sonuçları etkiler. Yazılım tek başına destek maliyeti, memnuniyet, tahsilat veya satış sonucu garanti etmez.
Sonuç
Müşteri portalı maliyetini ekran sayısı değil, müşterinin tamamlayacağı görevlerin veri, yetki, entegrasyon, hata ve sahiplik derinliği belirler. Müşteri Öz-Hizmet Kapsam Matrisi, üyelikten devre kadar sekiz alanı aynı teklif tablosunda görünür kılar.
Müşteri portalı, entegrasyon ve özel yazılım kapsamınızı değerlendirmek için Kumsal Ajans web yazılım ekibiyle görüşebilirsiniz.