Müşteri portalı, işletmeyle müşterisi arasındaki belirli bilgi ve işlemlerin güvenli bir kullanıcı alanında sunulmasıdır. Siparişin durumunu öğrenmek, belgeye ulaşmak veya destek talebini takip etmek için kullanılabilir. Ancak bütün işletmelerde aynı içerik gerekli değildir. Bazı müşteriler yalnızca belge arar; bazıları kendi ekipleri adına işlem yapar. Bu nedenle başlangıçta hangi sorunun çözüleceği açıklanmalıdır. Bir giriş ekranı ve birkaç kart oluşturmak, kendi başına iyi hizmet deneyimi sağlamaz. Sunulan bilginin doğru, anlaşılır ve uygun kişiye ait olması gerekir.

İçindekiler

Müşteri portalı oluştururken işletmenin iç ekranını olduğu gibi dışarıya açmak uygun yaklaşım olmayabilir. İçeride kullanılan notlar, durum adları ve fiyat alanları müşteriye başka anlam verebilir. Dış kullanıcıya neyin gösterileceği ayrı değerlendirilmelidir. Bu rehber dokuz özellik başlığında hesap, kayıt, belge, talep ve bildirim düzenini ele alır. Hazır başarı oranı veya her müşterinin aynı alanı kullanacağı varsayımı sunmaz. İşletmenin hizmet biçimi, veri kaynakları ve kullanıcı rolleri incelenerek kapsam belirlenir. Küçük ve anlamlı başlangıç, gereksiz işlev kalabalığından daha kullanışlı olabilir.

Müşteri portalı planlarken en sık gelen soruları toplayabilirsiniz. Siparişim nerede, belgemin güncel halini nasıl alırım veya açtığım talebe cevap geldi mi gibi sorular örnek olabilir. Hangi soruların gerçekten tekrarlandığı ölçülmediyse sayı uydurmayın; gözlem olduğunu belirtin. Özel yazılım geliştirme görüşmesinde bu örnekleri ve bugün verilen cevapların yöntemini anlatın. Böylece ekranda ne bulunacağı teknik tercihten önce gerçek hizmet ihtiyacına bağlanır. Mevcut programların veriyi nasıl sağlayacağı da ayrıca incelenir.

Müşteri portalı ile işletme içi panelin ayrımı

Müşteri portalı tasarımından farklı olarak iç kullanıcı, bir kaydın bütün geçmişini ve iş notlarını görmek isteyebilir. Müşteri ise kendisi için anlamlı durum, tarih ve işlem sonucunu bekler. İç süreçte kullanılan beklemede sözcüğü dış kullanıcı için yetersiz olabilir. Eksik bilgi mi bekleniyor, hazırlık mı sürüyor, yoksa onay mı gerekiyor? Açıklama dili hizmetin bağlamına uygun olmalıdır. İç durumların tamamını dışarı göstermek zorunlu değildir. Hangi olayın müşteriye hangi bilgiyle yansıyacağı iş kararı olarak tanımlanmalıdır.

Müşteri portalı içinde işlem yapabilmekle işletmenin asıl sisteminde onaylanmış kayıt oluşması da aynı şey değildir. Dış kullanıcı talep veya sipariş isteği oluşturabilir; işletme incelemesinden sonra başka aşamaya geçebilir. Bu fark açık gösterilmezse müşteri işlemin kesinleştiğini düşünebilir. Ekrandaki başarı mesajı neyin başarıyla yapıldığını açıklamalıdır. Kayıt alındı, onaylandı ve tamamlandı farklı anlamlar taşır. Durumlar gerçek işleyişe dayanmalı, otomatik olarak daha olumlu görünsün diye seçilmemelidir.

İlk sürümde değerlendirilecek 9 özellik

1. Hesap açılışı ve güvenli giriş

Hesabın nasıl oluşturulacağı belirlenmelidir. İşletme daveti, müşteri başvurusu veya mevcut kayıtla eşleştirme farklı yöntemlerdir. Doğru kişinin doğru müşteri hesabına bağlanması önemlidir. Elektronik posta adresinin bilinmesi, kişinin bütün şirket kayıtlarına yetkili olduğunu tek başına göstermez. Onay ve hesap doğrulama adımları uygulamanın riskine göre tasarlanır. Kullanıcıya gereksiz adımlar eklemek de deneyimi zorlaştırabilir. Güvenlik ve kullanılabilirlik birlikte değerlendirilmelidir; bütün işletmelere tek giriş yöntemi önerilmez.

Müşteri portalı girişinde parola unutma ve erişim kaybı senaryoları da düşünülmelidir. Kullanıcı artık aynı şirkette çalışmıyorsa erişim nasıl kapatılacak? Şirket yetkilisi değiştiğinde hangi kontrol yapılacak? Bu işlerin kimin sorumluluğunda olduğu açıklanmalıdır. Yeni hesap oluşturmak kolay görünürken hesap yaşam döngüsü unutulabilir. Kullanıcı ve müşteri şirketi ilişkisi ayrı tutulduğunda bir hesabın birden fazla kişiye uygun yetkiyle açılması değerlendirilebilir. Gerçek ihtiyaç örnekleri bu kararı yönlendirmelidir.

İlk denemede yalnızca doğru parolayla giriş yapıldığını kontrol etmek yeterli değildir. Hatalı giriş, süresi dolmuş bağlantı ve kapatılmış hesap gibi durumlar uygun yöntemle değerlendirilir. Kullanıcıya verilen mesaj gereksiz hesap bilgisi açığa çıkarmamalıdır. Bu teknik kontroller uzman ekipçe uygulanır. İşletme ise hangi kişilerin hangi koşulda erişmesi gerektiğini açıklamalıdır. Hesap güvenliği sadece müşterinin güçlü parola seçmesine bırakılacak bir konu değildir. İşleyiş ve uygulama kontrolleri birlikte ele alınır.

2. Şirket ve kullanıcı yetkileri

Bir müşteri şirketinde farklı görevler bulunabilir. Satın alma sorumlusu işlem oluştururken başka kullanıcı yalnızca belge okuyabilir. Yönetici tüm şirket kayıtlarını, çalışan ise kendi taleplerini görebilir. Hangi yapının gerektiği açıklanmalıdır. Başlangıçta bütün dış kullanıcıları aynı yetkide açmak kolay görünse de gereksiz erişim yaratabilir. Görme, indirme, oluşturma ve onay verme ayrı değerlendirilmelidir. Kullanıcıların şirket değiştirmesi veya görev devri de örnek senaryolar arasında bulunabilir.

Müşteri portalı yetkileri yalnızca menülerde uygulanmamalıdır. Kayıt bağlantısı, arama sonucu veya dosya indirme adresi aynı sınırlara uymalıdır. Bir müşterinin başka müşteriye ait belgeye erişememesi temel gereksinimdir. OWASP yetkilendirme rehberi, kimliği doğrulamakla işlem yetkisini kontrol etmenin farklı olduğunu ve yetkinin isteklerde doğrulanması gerektiğini açıklar. Bu kaynağın bulunması uygulamanın güvenli olduğunun kanıtı değildir. Tasarımın ve kontrollerin gerçek senaryolarla denenmesi gerekir.

Yetki çizelgesini iş dilinde hazırlayabilirsiniz. Kimin hangi kayıtları göreceği ve hangi işlemi yapacağı yazılır. Teknik ekip bunu uygun kontrollere dönüştürür. İşletme kararını gerektiren sınırlar varsayımla belirlenmemelidir. Bir kişinin bütün şirket adına yetkili olduğu düşünülüyorsa bunun nasıl doğrulanacağı konuşulur. Geçici erişimlerin kapanması ve kullanılmayan hesapların yönetimi de değerlendirilir. Yetki düzeninin güncel sorumlusu bulunmalıdır. Başlangıçta doğru açılmış bir hesap, görev değişince uygun olmayabilir.

3. Sipariş veya hizmet durumları

Gösterilecek durumlar müşterinin ne bilmesi gerektiğine göre seçilir. Hazırlanıyor, bilgi bekleniyor veya teslim edildi gibi ifadelerin iş karşılığı açıklanmalıdır. Her iç olayın dış kullanıcıya yansıtılması gerekmez. Tarihler ve açıklamalar da önemli olabilir. Bir durum değiştiğinde müşterinin yapacağı işlem varsa bu görünür olmalıdır. Sadece renkli etiket yeterli açıklama sağlamayabilir. İç kayıt güncellenmediğinde dış ekranda eski bilgi kalıyorsa kullanıcının bunu nasıl anlayacağı düşünülmelidir.

Müşteri portalı durum bilgisinde tahmini tarih ile kesinleşmiş tarih ayrılmalıdır. İşletmenin henüz onaylamadığı bir planın kesin teslim sözü gibi görünmesi yanlış beklenti yaratabilir. Kullanılan dil gerçek bilgiye dayanmalıdır. Aynı şekilde boş tarih alanını otomatik olarak bugünle doldurmak uygun değildir. Kullanıcı hangi kayıtların kendisine ait olduğunu ve bilgilerin ne zaman güncellendiğini görebilmelidir. Kısmi teslim veya iptal gibi durumlar hizmet türüne göre ayrıca ele alınabilir.

Durum ekranını bir normal ve bir istisna kayıtla deneyin. İş yarım kaldığında ne görünüyor, kullanıcıdan bilgi istendiğinde ne yapması gerekiyor? Tamamlanan işlemin geçmişi bulunabiliyor mu? Beklenmedik gecikme varsa açıklamanın kimin tarafından yazılacağı belli olsun. Her olayı otomatik bildirimle göndermek zorunlu değildir. Ana ekranda göstermek ve ayrı haber vermek farklı kararlardır. Müşterinin anlamlı bilgiye ulaşması hedeflenir; iç sistemin bütün karmaşıklığını dışarı taşımak değil.

4. Belgeler ve sürüm bilgisi

Teklif, rapor veya hizmet belgesi gibi dosyalar uygun kapsamda sunulabilir. Hangi dosyanın güncel olduğu açık olmalıdır. Aynı isimle birden fazla belge varsa tarih ve açıklama yardımcı olabilir. Kullanıcı eski sürümü indirip işlem yapıyorsa sorun doğabilir. Belge değiştirilince önceki sürümün erişimi ve yeni sürümün gösterimi düşünülmelidir. Her dosyanın sınırsız süre görünmesi gerektiği varsayılmamalıdır. Saklama ve erişim koşulları işletmenin durumu ve ihtiyaçlarıyla ayrıca değerlendirilir.

Müşteri portalı belge alanında dosyanın doğru müşteriye bağlandığı kontrol edilmelidir. Yalnızca sayfada listelenmesi yeterli değildir; doğrudan indirme yolu da yetkili olmalıdır. Kullanıcı belge yükleyebilecekse dosya türü, boyut ve inceleme süreci değerlendirilir. Teknik güvenlik kontrolleri uygulanmadan sınırsız yükleme açılması uygun değildir. İş açısından hangi belgelerin neden istendiği açıklanmalıdır. Gereksiz dosya istemek hem kullanıcı yükünü hem saklanan bilgi miktarını artırabilir.

5. Talep oluşturma ve takip

Destek veya hizmet talebinde hangi bilgiler gerekli olduğu belirlenmelidir. Çok uzun form müşteriyi zorlayabilir; çok kısa form ise sürekli ek soru gerektirebilir. Konu, ilgili kayıt ve açıklama gibi alanlar ihtiyaca göre seçilir. Kullanıcı bir talep açtığında takip numarası veya anlaşılır kayıt bilgisi görebilir. Talebin alındığıyla çözüldüğü ayrılmalıdır. Beklenen cevap yöntemi açıklanmalı, henüz kararlaştırılmamış hizmet süresi taahhüt edilmemelidir. İşletme tarafında talebin hangi ekibe gideceği belli olmalıdır.

Müşteri portalı taleplerinde dosya ve mesaj geçmişi aynı kayda bağlanabilir. Ancak işletme içi notların dış kullanıcıya yanlışlıkla gösterilmemesi önemlidir. İç açıklama ve müşteriye cevap ayrı alanlar olabilir. Hangi davranışın gerektiği kullanıcı rolleriyle birlikte değerlendirilir. Talep kapanınca müşteri yeniden cevap verebilir mi, yeni konu aynı kayda mı eklenir? Bu sorular takip düzenini etkiler. Her yeni mesajın ayrı talep sayılması veya bütün konuların tek kayıtta birleşmesi farklı sorunlar yaratabilir.

İşletme ekibi de takip ekranını kullanabilmelidir. Müşteriye açılan alanın arkasında sorumluluk yoksa talep yanıtlanmadan bekleyebilir. Durumları kim güncelleyecek ve geciken kaydı kim görecek? Bu sorular yazılımın dışında kalan iş düzeniyle ilgilidir. Otomatik bildirim yardımcı olabilir; fakat sorumlunun yerini almaz. İlk sürümde az sayıda talep türüyle başlamak seçenek olabilir. Gerçek kullanımda hangi eksiklerin oluştuğu görülerek düzen geliştirilebilir.

6. Bildirim ve tercih yönetimi

Her durum değişikliğinde mesaj göndermek müşteriye fayda sağlamayabilir. Hangi olayın gerçekten haber gerektirdiği belirlenmelidir. Bilgi isteği, yeni belge veya önemli sonuç örnek olabilir. Bildirimin hangi kanalla ve hangi içerikle gönderileceği ayrıca değerlendirilir. Kullanıcıya hassas bilgilerin mesaj içinde açılmaması gerekebilir. Bazı içeriklerin yalnızca giriş yapıldıktan sonra görülmesi uygun olabilir. İletişim tercihleri ve ilgili yükümlülükler işletmenin koşullarına göre ayrıca ele alınmalıdır. Bu yazı mevzuat uygunluğu hükmü vermez.

Müşteri portalı bildirimi gönderildiğinde bunun mutlaka okunduğu varsayılmamalıdır. Teslim, görüntüleme ve işlem yapma farklı olaylardır. Uygulamanın hangi bilgiyi gerçekten bildiği açıklanmalıdır. Bir mesaj başarısızsa tekrar deneme veya işletme içi takip gerekebilir. Sürekli aynı bildirimi göndermek de uygun olmayabilir. Bildirim listesinin okunabilir olması ve kullanıcının ilgili kayda ulaşması önemlidir. Hangi bildirimlerin zorunlu, hangilerinin tercihli olduğu iş ve iletişim kurallarıyla birlikte belirlenir.

7. Arama ve geçmişe erişim

Kayıt sayısı arttığında müşterinin eski belge veya talebi bulması gerekir. Tarih, durum veya ilgili işlem üzerinden arama düşünülebilir. Kullanıcı kendi kullandığı sözcüklerle bilgi arayabilir; işletmenin iç kodlarını bilmesi beklenmemelidir. Arama sonuçları da yetki sınırına uymalıdır. Sonuç başlığı veya kısa açıklama başka müşterinin bilgisini sızdırmamalıdır. Boş sonuçla erişim yok durumu uygun biçimde ele alınır. Filtreler birikince kullanıcının neden sonuç bulamadığını anlaması önemlidir.

Müşteri portalı geçmişinde tamamlanmış kayıtların gösterimi günlük açık işlerden ayrılabilir. Eski kayıtları sürekli öne çıkarmak yeni işi bulmayı zorlaştırabilir. Buna karşılık geçmişe erişimi gereksiz gizlemek tekrar iletişim ihtiyacını artırabilir. Uygun sıralama ve filtreler gerçek kullanıcılarla değerlendirilir. Dışa aktarma gerekiyorsa hangi alanların verileceği belirlenmelidir. Ekranda görünmeyen özel iç alanlar dosyada bulunmamalıdır. İndirilen bilginin hangi dönemi kapsadığı kullanıcıya açıkça gösterilebilir.

8. Mobil ve erişilebilir kullanım

Müşteri alanı telefondan kullanılacaksa temel işlemler küçük ekranda denenmelidir. Dosya indirme, form doldurma ve durum okuma masaüstündeki kadar kolay olmayabilir. Kullanıcının uzun yatay tabloyu sürekli kaydırması zor olabilir. Önemli bilgi önceliği ve düğme açıklamaları düşünülmelidir. Yalnızca renkle anlam vermek yeterli olmayabilir. Yazıların okunması, klavyeyle kullanım ve anlaşılır hata mesajları da değerlendirilir. Bu kontrollerin kapsamı kullanıcı ihtiyaçları ve uygulamaya göre belirlenir.

Müşteri portalı içinde yükleme veya kayıt işlemi sürerken kullanıcıya durum bilgisi verilmelidir. Düğmeye birkaç kez basılması aynı talebin tekrar oluşmasına yol açmamalıdır. Teknik yöntem seçilen yapıya bağlıdır; iş açısından beklenen davranış açıklanabilir. Bağlantı zayıf olduğunda ne olduğu, formdaki bilgilerin kaybolup kaybolmadığı ve kullanıcının tekrar nasıl deneyeceği düşünülür. Hata mesajı sadece teknik koddan oluşmamalıdır. Müşteri ne yapabileceğini anlamalı, gerektiğinde ilgili kayıt bilgisiyle destek isteyebilmelidir.

9. İç sistem bağlantısı ve sorumluluk

Gösterilen bilgilerin hangi kaynaktan geldiği belli olmalıdır. Portal kendi başına ayrı kayıt oluşturabilir veya mevcut iş sisteminden bilgi alabilir. Aynı bilginin iki yerde değişmesi durumunda hangi kaynak geçerli olacak? Güncelleme gecikirse kullanıcı ne görecek? Bu sorular teknik bağlantı tasarımından önce iş açısından açıklanmalıdır. İşletmenin mevcut programının bağlantı olanakları incelenir. Her programın gereken veriyi dışarı verebildiği varsayılmamalıdır. Sağlayıcının resmi belgeleri ve erişim koşulları kontrol edilmelidir.

Müşteri portalı işletime alındıktan sonra veri ve hesap sorumluları belli olsun. Yanlış belge bağlandığında kim düzeltecek, kullanıcı şirketten ayrıldığında kim erişimi kapatacak ve bilgi gecikmesini kim takip edecek? Bunlar sadece geliştirme anında değil günlük kullanımda önemlidir. Teknik bakım ile iş verisini yönetmek farklı sorumluluklar olabilir. Yeni özellik talepleri de kontrollü değerlendirilmelidir. Dış kullanıcı alanını sürekli işlev ekleyerek büyütmek yerine, hangi ihtiyacı gerçekten karşıladığı düzenli gözden geçirilebilir.

Varsayımsal örnek: Belge sorusunu takip edilebilir hale getirmek

Bir hizmet işletmesinde müşterilerin tamamlanan işin belgesini elektronik postayla istediğini düşünelim. Bu tamamen varsayımsal örnekte müşteri giriş yaptıktan sonra kendisine ait işler ve güncel belgeler görünür. Eksik belge için talep açılabilir. İşletme ekibi ilgili kayda cevap yazar. Kullanıcı başka şirketlerin kayıtlarına erişemez. Burada bütün belgelerin otomatik oluştuğu veya iletişim yükünün belirli oranda azaldığı iddia edilmez. Amaç, hizmet sorusunun hangi ekran ve sorumluluklarla karşılanabileceğini göstermektir.

Müşteri portalı bu örnekte doğru belgeyi buldurduğu kadar yanlış belge erişimini önlemelidir. Hesap eşleştirme, dosya yetkisi ve güncel sürüm açıklaması birlikte ele alınır. İşletme ekibi belgenin ne zaman hazır olduğunu güncellemezse müşteri yine eski bilgi görür. Yazılım tek başına iş disiplininin yerine geçmez. Örnek kayıtlarla kullanıcı ve işletme adımlarının denenmesi, gerçek gereksinimleri netleştirebilir. Çalışma kapsamı, veri kaynakları ve onay düzeni incelenerek belirlenir. Gerçek müşteri sonucu olarak sunulmaz.

İlk sürümü gereksiz büyütmeden planlamak

Müşteri portalı başlangıcında bütün işlemleri dış kullanıcıya açmak şart değildir. Sık kullanılan bir hizmet sorusu seçilebilir. Bunun için gereken veri, yetki ve işletme sorumluluğu tamamlanır. Sonra gerçek kullanım değerlendirilir. Küçük başlangıç, güvenlik ve veri doğruluğundan vazgeçmek anlamına gelmez. Sınırlanan işlev sayısıdır. Örneğin sadece belge görüntüleme yapılacaksa yeni sipariş oluşturma sonradan değerlendirilebilir. Bu ayrım ilk sürüm sınırında açık yazılır. Kullanıcıya henüz sunulmayan işlevin varmış gibi tanıtılması doğru değildir.

Müşteri portalı geri bildirimlerinde kullanım sorusu, hata ve yeni özellik isteği ayrı tutulmalıdır. Aynı konuda tekrar gelen sorular açıklama veya tasarım eksiğine işaret edebilir. Her istek doğrudan geliştirmeye dönüşmemelidir. Kullanıcının asıl amacı anlaşılırsa daha sade çözüm bulunabilir. Bir ekranın kullanılmaması da tek başına gereksiz olduğunu kanıtlamaz; kullanıcı erişim veya bilgi eksikliği yaşıyor olabilir. Uygun değerlendirme için gerçek görevlerle kısa denemeler yapılabilir. Sonraki karar, gözlem ve iş ihtiyacına dayanmalıdır.

Doğru hesaba bağlanma sürecini ayrıntılandırmak

Müşteri portalı hesabında görünen şirketin doğru olduğundan emin olmak temel ihtiyaçtır. Aynı kişinin birden fazla işletmeyle ilişkisi bulunabilir. Hangi şirket adına işlem yaptığı açık gösterilmelidir. Hesaplar arasında geçiş düşünülüyorsa veriler ve işlemler karışmamalıdır. Kullanıcı eski ekrandan gönderim yaptığında hangi şirket bağlamının geçerli olacağı teknik olarak değerlendirilir. İş açısından beklenti basittir: kişi yalnızca yetkili olduğu şirketin kaydına işlem yapmalı ve hangi şirketle çalıştığını anlamalıdır. Bunun nasıl sağlanacağı uygun kontrollerle tasarlanır.

Müşteri portalı açılışında eski müşteri kayıtlarıyla eşleştirme yapılacaksa aynı elektronik posta adresinin farklı kayıtlarda bulunması gibi durumlar incelenir. Otomatik eşleştirmenin hangi koşullarda yapılacağı açıklanmalıdır. Belirsiz durumda manuel kontrol gerekebilir. Kullanıcıyı hemen içeri almak adına yanlış şirkete bağlamak uygun değildir. Buna karşılık her girişte gereksiz belge istemek de kullanıcıyı zorlaştırabilir. İhtiyaca uygun doğrulama yöntemi seçilir. Hesap ilişkisinin sonradan düzeltilmesi gerekiyorsa kimlerin yetkili olacağı ve geçmiş işlemlerin nasıl korunacağı konuşulur.

Formlarda eksik ve yanlış bilgiyi ele almak

Müşteri portalı formlarında hangi alanın neden istendiği anlaşılır olmalıdır. Kullanıcıdan sistemde zaten bulunan bilgiyi tekrar girmesi isteniyorsa bunun gerekçesi değerlendirilebilir. Otomatik doldurma yapılacaksa kaynağın güncelliği önemlidir. Yanlış adres veya eski telefon bilgisinin sessizce kullanılması sonraki hizmeti etkileyebilir. Kullanıcının hangi alanı değiştirebileceği belli olsun. Her bilgiyi dış kullanıcıya düzenletmek uygun olmayabilir. Değişiklik için ayrı talep veya onay gerekebilir. Bu ayrım gerçek iş sorumluluklarına göre belirlenir.

Müşteri portalı kayıt işleminde hata oluşursa kullanıcıya anlaşılır bilgi verilmelidir. Hangi alanın eksik olduğu ve nasıl düzeltileceği gösterilebilir. Formdaki bütün bilgilerin kaybolması tekrar yük yaratabilir. Ancak girilen verinin cihazda tutulması düşünülüyorsa gizlilik ve ortak cihaz kullanımı da değerlendirilmelidir. Kullanıcı bilgisayarını başka biriyle paylaşıyor olabilir. Kolaylık sağlayan bir özellik yeni bilgi riskleri doğurabilir. Bu nedenle yalnızca başarılı gönderim değil, yarım bırakma ve tekrar deneme senaryoları da tasarım kapsamında konuşulmalıdır.

Müşterinin ekranında bulunmaması gerekenler

Müşteri portalı alanında iç kullanıcı adları, teknik hata ayrıntıları veya başka müşteriye ait kısa bilgiler istemeden görünebilir. İyi görünüm kontrolü bütün veri yollarını kapsamaz. Liste, belge, bildirim ve arama sonuçları ayrı örneklerle incelenebilir. Bir bölümde doğru yetki bulunması diğer bölümlerin de doğru olduğunu kanıtlamaz. İşletme hangi bilgilerin dış kullanıcıya uygun olduğunu açıklamalıdır. Teknik ekip bu sınırları uygulamada doğrular. Sadece test hesabıyla normal giriş yapmak bütün olası erişim durumlarını değerlendirmek için yeterli değildir.

Müşteri portalı bildiriminde müşteri dışındaki kişinin adı görünmesi bile yanlış ilişkilendirme göstergesi olabilir. Kullanıcıdan gelen böyle bulgular önemsenmeli ve ilgili kayıt araştırılmalıdır. Düzeltme yapılırken yalnızca görünen etiket değil, verinin neden yanlış bağlandığı incelenir. Aynı kaynağı kullanan başka ekranlar bulunabilir. Bildirimi alan kişiye gereksiz teknik veya özel bilgi verilmeden durum açıklanabilir. İşletmenin sorun yönetim yöntemi ve sorumluları baştan belli olursa bu tür bulgular dağınık mesajlar arasında kaybolmaz.

İşletme ekibinin yeni düzene hazırlanması

Müşteri portalı kullanıma açıldığında çalışanların günlük görevleri değişebilir. Önceden telefonla verilen bilgi artık ekranda güncellenmelidir. Müşteri durumun otomatik değiştiğini düşünürken işletme personelinin işlem yapması gerekebilir. Bu sorumluluk açıklanmazsa portal eski bilgi gösterir. Hangi olayda hangi kayıt güncellenecek ve kim kontrol edecek? İşletme içi kısa kullanım açıklaması hazırlanabilir. Teknik otomasyon mümkünse kapsamı ve bağımlılıkları incelenir. Otomatik olmadığı halde kullanıcıya öyle tanıtılması yanlış beklenti yaratır.

Müşteri portalı taleplerini yanıtlayacak kişilerin erişimi ve görev sırası belirlenmelidir. Birden fazla kişi aynı talebe cevap yazdığında karışıklık oluşabilir. Talebin üstlenilmesi veya iç yönlendirme gibi yöntemler düşünülebilir. Her işletmeye ayrıntılı destek merkezi kurmak gerekmez; iş hacmine uygun sade düzen yeterli olabilir. Yanıt verilmemiş kaydın fark edilmesi ve ilgili sorumluya ulaşması önemlidir. Kullanıcıya vaat edilen iletişim yönteminin arkasında gerçekten uygulanabilir iş düzeni bulunmalıdır. Yazılım ve işletme süreci birlikte hazırlanır.

Müşteri portalı için başlangıç değerlendirmesinden sonra küçük bir kullanıcı grubuyla anlamlı görevler denenebilir. Örneğin son belgesini bulması veya açık talebine cevap yazması istenir. Kullanıcının nerede zorlandığı gözlenir. Bu bir müşteri sınavı değildir; hizmet alanının anlaşılır olup olmadığını görme yöntemidir. Sadece ekranı beğenip beğenmediğini sormak gerçek kullanım sorularını kaçırabilir. Geri bildirimler toplandıktan sonra zorunlu düzeltme, açıklama ihtiyacı ve yeni özellik talebi ayrılır. Öncelik, doğru kişinin temel işini güvenle yapabilmesidir.

Yerel işletmeler için görüşme hazırlığı

Müşteri portalı ihtiyacını görüşmek isteyen Maltepe, İdealtepe ve Anadolu Yakası işletmeleri, sık gelen sorularını ve kullandıkları belge örneklerini HD Bilgisayar ile paylaşabilir. Hassas bilgiler ayıklanarak küçük örnek hazırlanması uygundur. İletişim numarası 0532 396 34 71, adres Altayçeşme, Oba Çıkmazı No:3, Maltepe, İstanbul’dur. Görüşmenin zamanı ve yöntemi ayrıca kararlaştırılır. Bu rehber belirli maliyet, teslim süresi veya hizmet sonucu taahhüdü değildir. Mevcut sistem ve ihtiyaçlar değerlendirilerek kapsam netleştirilir.

Yayına hazırlık kontrol listesi

Müşteri portalı değerlendirmesinde iç kullanıcı ve dış kullanıcı adımlarını birlikte deneyin. Doğru kişinin doğru kaydı gördüğü, talebin ilgili ekibe ulaştığı ve belgenin güncel olduğu kontrol edilir. Sadece başarılı senaryolar yeterli olmayabilir. Yanlış hesap ilişkisi, kapanmış kullanıcı, yükleme hatası veya gecikmiş veri gibi durumlar da kapsamına göre ele alınır. Açık kalan soruların sorumlusu belli olsun. Sonuçları yalnızca beğeni üzerinden değil, kullanıcının gerçek işini yapabilmesi üzerinden değerlendirmek daha yararlıdır.

• Hesap açılışı ve şirket eşleştirmesi tanımlı mı?
• Görme, indirme ve işlem yetkileri ayrıldı mı?
• İç notlarla dış açıklamalar birbirinden ayrılıyor mu?
• Durum ve tarihler gerçek işleyişi açıklıyor mu?
• Güncel belge ve dosya yetkisi kontrol edildi mi?
• Talep, cevap ve kapanış düzeni anlaşılır mı?
• Bildirimlerin içeriği ve sorumlusu belli mi?
• Mobil kullanım ve hata durumları denendi mi?
• Veri kaynağı, güncelleme ve bakım görevleri açık mı?

Sık sorulan 6 soru

Sadece belge göstermek için portal yapılabilir mi?

İhtiyaç ve kapsam uygunsa sınırlı belge alanı düşünülebilir. Hesap eşleştirmesi ve dosya yetkileri yine önemlidir. Müşteri portalı az işlev içerse de doğru müşteriye doğru belgeyi sunmalıdır. Güncel sürümün nasıl anlaşılacağı ve eski belgelerin nasıl bulunacağı açıklanır. İlk sürümün küçük olması bu kontrollerin gereksiz olduğu anlamına gelmez. Mevcut programın dosyaları nasıl sağlayacağı ayrıca değerlendirilir.

Bir şirketten birden fazla kişi kullanabilir mi?

Böyle ihtiyaç varsa kullanıcı rolleriyle planlanabilir. Her kişinin aynı yetkiye sahip olması gerekmez. Bazıları işlem oluşturabilir, bazıları yalnızca kayıt okuyabilir. Müşteri portalı için şirket ile kullanıcı ilişkisi açık olmalıdır. Kullanıcının görev değişikliği ve erişim iptali de düşünülür. Bir hesabın parolasını bütün ekiple paylaşmak yerine uygun kişi hesapları ve yetki düzeni değerlendirilmelidir. Kesin yöntem uygulamanın ihtiyaçlarına bağlıdır.

İç sistemdeki bütün notlar müşteriye görünmeli mi?

Genellikle hangi bilginin dış kullanıcıya uygun olduğu ayrıca seçilir. İç operasyon notu ile müşteriye verilecek açıklama aynı amaçla yazılmaz. Yanlışlıkla görünür bilgi oluşmaması için alanlar ve roller değerlendirilir. Müşteri portalı durum adları da dış kullanıcı açısından anlaşılır olmalıdır. İç sistemin bütün karmaşıklığını taşımak yerine müşterinin ihtiyacına uygun açıklama sunulabilir. Bu kararlar örnek kayıtlar üzerinden netleştirilmelidir.

Bildirim gönderilmesi talebin okunduğunu kanıtlar mı?

Hayır. Mesajın gönderilmesi, teslim edilmesi ve kullanıcının ilgili işlemi yapması farklı olaylardır. Uygulamanın gerçekten hangi bilgiyi bildiği açıklanmalıdır. Müşteri portalı bildirimleri uygun kayda ulaşma yolu sağlayabilir. Ancak bütün iletişim sorumluluğu otomatik mesaja bırakılmamalıdır. Önemli taleplerin işletme içindeki takibi ve sorumlusu belli olmalıdır. Hangi durumun ayrı haber gerektirdiği işin niteliğine göre belirlenir.

Telefon ekranında da kullanılabilir mi?

Bu ihtiyaç tasarım ve test kapsamına alınabilir. Sadece sayfanın açılması bütün işlemlerin rahat yapıldığını göstermez. Form, dosya ve durum ekranları gerçek cihazlarla değerlendirilir. Müşteri portalı kullanıcıları uzun tablo veya belirsiz düğme nedeniyle zorlanabilir. Bağlantı kesintisi ve yükleme hatası gibi durumlarda ne olacağı da düşünülmelidir. Kullanıcıya anlaşılır bilgi ve tekrar deneme yöntemi sunulması önemlidir.

İlk görüşmeye ne getirmeliyim?

Müşteri portalı için sık gelen üç soruyu, örnek bir belgeyi ve bugün verilen cevabın sürecini hazırlayın. Kullanıcıların kişi mi şirket temsilcisi mi olduğunu belirtin. Hassas bilgileri ayırarak örnek gösterebilirsiniz. Teknik çözümü kendiniz seçmek zorunda değilsiniz. Hangi sorunun nerede aksadığını ve müşterinin neyi kendi başına yapmasını istediğinizi anlatın. Ardından hesap, veri, yetki ve sorumluluklar birlikte değerlendirilebilir.