İş uygulamaları için tekrar kullanılabilir ekranlar: 12 ekranlık şablon

Çoğu iş uygulaması neden gereğinden uzun sürer

Pek çok iş uygulaması basit görünür: “kullanıcılar giriş yapar, kayıt ekler ve rapor çıkarır.” Zaman yiyen kısım bu temel fikrin etrafındaki her şeydir. Ekipler aynı temel ekranları tekrar tekrar yeniden inşa eder, her seferinde biraz farklı seçimler yaparlar.

Yavaşlamanın nedeni genelde tekrardır. Bir kişi bir giriş ekranı tasarlar, başka bir kişi admin alanı için ikinci bir versiyon yapar ve üçüncüsü “şifre unutuldu” akışını farklı davranacak şekilde ekler. Aynısı ayarlar, roller, faturalama, yardım ve hata durumlarında da olur. Her tekrar ek QA, daha fazla uç durum ve kullanıcıları şaşırtan küçük UI farkları ekler.

Tekrarlanan bu ekranlar ayrıca erken tespit edilmesi zor hatalar yaratır. Bir izin ekranı role atamaya izin verirken, “kullanıcı davet et” ekranı aynı kuralı uygulamayı unutabilir. Bir faturalama ekranı limitleri gösterebilir, ama bir yükleme formu kullanıcının neden limite takıldığını açıklamayabilir. Uygulama çalışır ama dağınık hisseder.

Tekrar kullanılabilir ekran şablonu, çoğu iş uygulamasının ihtiyaç duyduğu varsayılan ekranların, net davranış ve içerik kurallarıyla paylaşılan setidir. Boş bir sayfadan başlamak yerine kanıtlanmış yapı taşlarından başlar ve yalnızca gerçekten benzersiz olanı değiştirirsiniz.

Bu rehber; daha hızlı göndermek isteyen kuruculara, küçük ekiplere ve ürün sahiplerine yönelik. Chat-öncelikli bir araçla (örneğin Koder.ai) çalışıyorsanız, böyle bir şablon net istemler yazmayı ve ürün boyunca tutarlı sonuçlar almayı da kolaylaştırır.

Bir ekranı gerçekten tekrar kullanılabilir yapan ne

Tekrar kullanılabilir bir ekran, tekrar kullanılabilir bir bileşenden daha büyüktür. Bileşen bir parça (buton, tablo, modal) iken; tekrar kullanılabilir ekran “Kullanıcıları yönet” veya “Faturalama” gibi birçok uygulamada aynı işi yapan eksiksiz bir sayfadır. Net bir amacı, tanıdık bir düzeni ve öngörülebilir durumları vardır.

Bir ekranı tekrar kullanılabilir kılmak için insanların yeniden öğrenmemesi gereken parçaları standartlaştırın:

• Düzen ve navigasyon (sayfa başlığı, birincil eylemler, “Geri”nin nereye gittiği)
• Metin tonu ve etiketler (kısa, sade dil ve tutarlılık)
• Durumlar (yüklenme, boş, başarı, hata ve “erişim yok”)

Aynı zamanda değişiklik gösteren parçaları esnek tutun. Bir Ayarlar ekranı yapıyı paylaşırken alanlar ürüne göre farklılık gösterebilir. Roller ekranı aynı deseni koruyabilir (rol listesi ve izin matrisi) ama gerçek izinler alanınıza göre değişir. Faturalama farklı planlar, kullanım limitleri, vergiler ve para birimleri için alan bırakmalıdır. Markalama ekranı yeniden yazmadan değiştirilebilir olmalıdır.

İşte bu yüzden 12-ekranlı bir şablon iyi çalışır: her ekranı bir kez tanımlarsınız, sonra küçük bir CRM gibi gerçek bir uygulamaya sadece alanlar, roller ve plan kuralları için birkaç değişiklikle uyarlarsınız.

12 tekrar kullanılabilir ekranın hızlı özeti

Hazır kopyalanabilir bir ekran setiniz olursa yeni ürünler sıfırdan başlamıyormuş gibi hissettirir. Püf nokta bu ekranları ayrı görevler olarak değil, birbirine bağlı bir yol olarak ele almaktır.

Basit bir yolculuk şöyle işler: yeni bir kullanıcı kaydolur ve giriş yapar, kısa bir onboarding adımı tamamlar, profilini günceller, ekip arkadaşlarını davet eder, roller atar, ayarları düzenler, sonra (ücretli ise) bir plan seçer ve kullanımını izler. Bir şey ters görünürse denetim kaydına bakar veya yardımı açar.

Küçük bir MVP’de bile hangi ekranları yayınlayacağınızı erken belirleyin. Çok kullanıcılıysanız genelde Ekip ve Roller gerekir. Para alıyorsanız Faturalama gerekir. Kotalar uygunsa Kullanım gerekir. Diğer her şey basit başlayıp sonra büyüyebilir.

Kimlik doğrulama ekranları: giriş, kayıt, şifre sıfırlama

Kimlik doğrulama ilk güven anıdır. Eğer kafa karıştırıcı veya güvensiz hissedilirse insanlar ürünü görmeden ayrılır.

Giriş ekranı için temel gereksinimler

Sayfayı basit tutun: e-posta (veya kullanıcı adı), şifre ve tek bir net buton. Destek taleplerini azaltacak küçük iyileştirmeleri ekleyin ama karmaşa yaratmayın.

Eğer birkaç ekstra ekleyecekseniz bunlar olsun: “şifreyi göster” togglesı, yanlış kimlik bilgisi için net hata metni ve “Şifreyi e-posta ile asla sormayız” gibi kısa bir güvenlik notu. Uygulama çoğunlukla kişisel cihazlarda kullanılıyorsa “Beni hatırla”yı kullanın. SSO yalnızca gerçekten iyi destekleyebiliyorsanız ekleyin.

Kayıt, nasıl sattığınızla eşleşmelidir. Genel ürünler açık kayıt ve e-posta doğrulama notu kullanabilir. Ekip araçları genellikle davetiyeyle çalışır; öyleyse “Yöneticinize davet için başvurun” gibi basit bir mesaj çıkmaz yollara gitmektense daha iyidir.

Şifre sıfırlama akışları güvenli ve öngörülebilir olmalı. E-posta varlığını onaylamayan mesajlar kullanın: “Eğer hesap bu e-posta ile eşleşiyorsa, sıfırlama bağlantısı gönderdik.” Adımları kısa tutun: istek, e-posta, yeni şifre, başarı.

Kilitlenme veya şüpheli etkinlik durumlarında yardımcı ve sakin kalın. Çok fazla denemeden sonra “15 dakika sonra tekrar deneyin veya şifrenizi sıfırlayın” genelde yeterlidir. Riskli bir giriş algılarsanız hızlı bir doğrulama isteyin ve bir cümleyle ne olduğunu açıklayın.

Onboarding ve profil temel öğeleri

Onboarding, insanların uygulamanızı basit mi yoksa yorucu mu bulduğuna karar verdiği yerdir. İlk çalıştırmayı kısa tutun: bir karşılama gösterin, başlamak için yalnızca gerekli olanı sorun ve isteğe bağlıysa “şimdi atla”yı belirgin yapın. Bir adım zorunluysa (ör. şart kabulü veya çalışma alanı seçimi) bunu açıkça sade kelimelerle belirtin.

Faydalı bir kural: “başlangıç” ile “mükemmelleştirme”yi ayırın. Kullanıcıların hızlıca çalışmaya başlamasına izin verin, sonra onları doldurmaya teşvik edin.

Rahatsız etmeyen ilk çalıştırma onboarding’i

Her biri bir ekrana sığacak küçük adımlar hedefleyin. Çoğu uygulama için bu şunlardır:

• Bir çalışma alanı oluşturma veya seçme (uygulama birden çok ekip destekliyorsa)
• Zaman dilimi ve dili ayarlama, böylece tarihler ve e-postalar doğru görünür
• E-postayı onaylama (eğer güvenlik veya davetleri etkiliyorsa)
• İçe aktarma veya ekip davetlerini isteğe bağlı, atlanabilir adımlar olarak sunma

Gerçekten kullanılan profil temel öğeleri

Profil ekranı kişisel bilgileri (isim, e-posta), avatar, zaman dilimi ve dili kapsamalıdır. “Şifre değiştir” ve “oturumlar/cihazlar” gibi güvenlikle ilgili öğeleri diğer güvenlik öğelerinin yanına koyun ki kullanıcılar aramak zorunda kalmasın.

Ürününüz birden çok çalışma alanını destekliyorsa, üst çubukta ve profil/ayarlar içinde net bir ekip değiştirme seçeneği ekleyin. İnsanlar nerede olduklarını ve nasıl geçiş yapacaklarını her zaman bilmelidir.

Oturumu kapatma ve oturum zaman aşımı hakkında kasıtlı olun. Çıkışı beklenen yerde koyun (profil menüsü yaygındır). Bir oturum süresi dolduğunda ne olduğunu ve ne yapılacağını açıklayın. “Etkinlik olmaması nedeniyle oturumunuz kapatıldı. Lütfen tekrar giriş yapın.” sessiz bir yönlendirmeden daha iyidir.

Roller, izinler ve kullanıcı yönetimi

Pek çok “güvenlik” problemi aslında UI problemidir. İnsanlar kim ne yapabilir göremezse tahmin ederler. Tekrar kullanılabilir bir roller-ve-kullanıcı alanı bu tahminleri ortadan kaldırır ve neredeyse her takım uygulamasına uyar.

Basit bir Roller ekranı ile başlayın: kısa açıklamalı rol listesi (Owner, Admin, Member, Viewer). Bunu, satırlar eylemler (ör. “kayıtları görüntüle”, “dışa aktar”, “faturalamayı yönet”, “çalışma alanını sil”) ve sütunlar roller olan bir izin matrisi ile eşleştirin. Okunabilir tutun: onay işaretleri kullanın, eylemleri birkaç kategoriye ayırın ve sadece gerektiğinde küçük ipuçları ekleyin.

Kullanıcı yönetimi bir veritabanı tablosu gibi değil, gelen kutusu gibi hissettirmeli. Her kişi için net bir durum rozeti (Aktif, Davet Edildi, Onay Bekliyor, Askıya Alındı) ve hızlı eylemler olmalı: e-posta ile davet et (rol ile), daveti yeniden gönder, rol değiştir (onay ile), kullanıcıyı kaldır ("verileri ne olur?" metni ile) ve hızlı denetim için “son aktif” tarihi.

Erişim isteklerine ihtiyacınız varsa hafif tutun: bir “Erişim isteği” butonu, kısa bir sebep alanı ve adminler için onay kuyruğu.

Koruyucular önemlidir. Sadece Owner’lar fatura ile ilgili izinleri değiştirmeli, çalışma alanını silebilmeli veya sahipliği devredebilmelidir. Birisi bunu yapmaya çalıştığında net bir neden ve bunu kimin (veya hangi rolün) yapabileceğini gösterin.

Büyüdükçe düzenli kalan ayarlar

Ayarlar ekranları genelde bir hurda çekmecesine dönüşür. Çözüm stabil bir ayarlar merkezi: sol navigasyon ile tutarlı kategoriler ve seçim değiştikçe sağ panelin güncellenmesi.

Basit bir kural yardımcı olur: bir şeyi birden fazla kez değiştireceklerse, Ayarlar’a koyun. İlk kurulumun parçasıysa onboarding içinde tutun.

Öngörülebilir bir ayarlar merkezi kullanın

Menüyü kısa ve insanların tanıdığı eylemler gibi ifade edin. Çoğu iş uygulaması için birkaç kategori neredeyse her şeyi kapsar: Profil ve tercihler, Bildirimler, Güvenlik, Organizasyon (veya Çalışma Alanı) ve Entegrasyonlar (gerçekten varsa).

Çekici ama anlamsız isimlerin altına saklamayın. “Organizasyon” genelde “Workspace DNA”dan daha iyidir.

Erken fayda sağlayan ayar alanları

Bildirimler kanal (e-posta vs uygulama içi) ve önem derecesine göre ayrıldığında en iyi çalışır. Kritik olmayan güncellemeler için frekans seçimine izin verin, ama kritik uyarıları açıkça etiketleyin.

Güvenlik ayarları güvenin kazanıldığı yerdir. 2FA ekleyin (destekleyebiliyorsanız) ve kullanıcıların diğer cihazlardan çıkış yapabilmeleri için aktif oturum listesi gösterin. Paylaşılan bilgisayarlar için “son aktif” ve cihaz bilgisi yardımcı olur.

Organizasyon ayarları adminlerin ilk aradığı şeyleri kapsamalıdır: org adı, temel markalama (logo/renkler) ve yeni davetler için varsayılan rol.

Küçük bir CRM’de satış temsilcileri bildirim sıklığını ve zaman dilimini değiştirirken, admin şirket adını ve varsayılan rolü günceller. Bu öğeleri tahmin edilebilir yerlerde tutmak sonraki destek taleplerini önler.

Faturalama, planlar ve kullanım limitleri

Faturalama güvenin kazanıldığı veya kaybedildiği yerdir. İnsanlar ödeme yapmaktan rahatsız olmaz ama sürprizlerden nefret ederler. Faturalamayı her zaman aynı soruları yanıtlayan küçük ekranlar olarak ele alın.

Başlangıç olarak sıkıcı ama iyi şekilde “sıkıcı” bir Faturalama genel bakışı oluşturun: mevcut plan adı, yenileme tarihi, ödeme yöntemi, fatura geçmişi ve makbuzlar için kullanılan e-posta. “Ödeme yöntemini düzenle”yi görünür yapın.

Sonra bir Plan karşılaştırma görünümü ekleyin. Limitleri sade dilde yazın (kullanıcı sayısı, projeler, depolama, API çağrıları vb.) ve bir limit aşıldığında ne olacağını açıkça belirtin. “Adil kullanım” gibi belirsiz etiketlerden kaçının.

Ayrı bir Kullanım ve limitler ekranı destek taleplerini önler. Birkaç gösterge ve kullanıcı bloke olmadan önce net mesajlar genelde yeterlidir. Eylemler ekliyorsanız basit tutun: bir yükseltme butonu ve yalnızca adminlerin planı değiştirebileceğine dair not.

İptal ve düşürmeyi tek bir buton yerine bir akış olarak ele alın. Nelerin değişeceğini açıklayın, bir onay adımı ekleyin ve “faturalama değişti” türünde bir bildirim gönderin.

Örnek: 3 kişilik bir CRM Free’de 1 pipeline, Pro’da 5 pipeline izin verebilir. Takım pipeline #2 eklemeye çalıştığında limit gösterin, ne yapabileceklerini ve bir yükseltme yolu sunun; çıkmaz bir yol göstermeyin.

Denetim, yardım ve destek ekranları

Denetim, yardım ve destek ekranlarını ikinci sınıf değil birinci sınıf olarak ele alın. Bunlar güven sorunlarını azaltır, destek konuşmalarını kısaltır ve admin işlerini sakinleştirir.

Denetim kaydı ekranı

Bir denetim kaydı üç soruyu hızlıca yanıtlamalı: kim ne yaptı, ne zaman ve (izliyorsanız) nereden. Veriyi veya erişimi değiştiren olaylara odaklanın. İyi bir başlangıç seti: oturum açma etkinlikleri, şifre değişiklikleri, rol/izin değişiklikleri, ana kayıtların oluşturulma/güncellenme/silme olayları, fatura olayları (plan değişimi, ödeme hatası), kullanım limiti tetiklemeleri ve dışa aktarma işlemleri.

Okunabilir tutun: net bir olay adı, aktör, hedef (kayıt), zaman damgası ve kısa bir detay çekmecesi. Temel filtreler ekleyin (tarih aralığı, kullanıcı, olay türü). Dışa aktarma için mevcut filtrelerle bir CSV ihracı çoğu ekip için yeterlidir.

Yardım merkezi ve destek

Yardım ekranınız, insanlar stresliyken bile işe yarayacak şekilde olmalı. Küçük bir SSS listesi, bir iletişim seçeneği ve kısa bir durum notu (bilinen sorunlar veya planlı bakım) ekleyin. Dil sade ve eylem odaklı olsun.

“Bir sorun bildir” için desteğin her zaman ihtiyaç duyduğu bilgileri isteyin: beklenen vs gerçekleşen, yeniden üretme adımları, ekran görüntüsü veya kayıt, cihaz/tarayıcı ve uygulama sürümü, olay zamanı ve varsa hata mesajı. Gönderim sonrası, yakalanan bilgileri ve nasıl takip edilir özetleyen bir onay gösterin.

Atlanamayacak hata, boş ve yüklenme durumları

Çoğu ekip hata ve boş ekranları sona bırakır, sonra delikleri yamamak için günler harcar. Bu durumları paylaşılan desenler olarak ele alın; böylece daha hızlı gönderir ve daha az destek bileti alırsınız.

Kullanıcıların gerçekten göreceği hatalar

Küresel bir hata sayfası nazik ve faydalı olmalı: ne olduğunu sade sözlerle söyleyin, net bir sonraki adım (Tekrar dene) sunun ve destekle ulaşmanın bir yolunu verin. Teknik detayları (istek ID’leri vb.) küçük bir “Daha fazla detay” alanının arkasında tutun.

Satır içi (inline) hatalar daha da önemlidir. Mesajları düzeltmesi gereken alanın yanına koyun ve tonu nötr tutun. “E-posta doğru görünmüyor” “Geçersiz giriş”den daha etkilidir. Bir form gönderimi başarısız olursa kullanıcının yazdıklarını koruyun ve ilk hatayı vurgulayın.

Boş, yüklenme ve çevrimdışı durumlar

Boş durumlar boş sayfalar değildir. Bu sayfalar şunu yanıtlamalı: bu sayfa ne için ve şimdi ne yapabilirim? Örnek: “Henüz faturanız yok. İlk faturayı oluşturun, ödeme takibini başlatmak için.” Tek bir net çağrı ekleyin.

Yüklenme durumları bekleme süresine göre olmalı. Hızlı eylemler için spinner, daha uzun sayfa yüklemeleri için iskelet ekranlar kullanın ki kullanıcı düzenin geldiğini görsün.

Uygulama çevrimdışıysa bunu açıkça belirtin, hangi şeylerin çalışmaya devam ettiğini gösterin (ör. önbelleğe alınmış verileri görüntüleme) ve ağ geri geldiğinde onay verin.

Bu şablonu yeni bir yapı için nasıl kullanırsınız (adım adım)

Hız, ortak ekranları yayınlamaya karar vermekten gelir; detaylara çekilmeden önce. Ekipler bu temellerde erken anlaşınca ilk kullanılabilir sürüm haftalar önce ortaya çıkar.

Basit 5 adımlı iş akışı

• Ekran envanteri ve rollerle başlayın. Uygulamayı kimlerin kullandığını (admin, yönetici, üye, salt-okuma, fatura sahibi) ve her birinin ilk günde ne yapması gerektiğini listeleyin.
• 12 ekran iskeletini kopyalayın ve alanınıza göre yeniden adlandırın. “Users” → “Agents”, “Projects” → “Deals”, “Workspace” → “Clinic” vb. Yapıyı koruyun ki her seferinde temelleri yeniden tasarlamayın.
• Her ekran için veri sözleşmesini tanımlayın. Her ekran için girdiler (formlar, filtreler), çıktılar (tablolar, kartlar) ve kurallar (zorunlu alanlar, doğrulamalar, rol bazlı görünürlük) listesini yapın.
• Plan limitlerini ve ana hata metinlerini erken yazın. Bir kişi limite takıldığında, izin olmadığı durumda veya faturalama erişimi gerektiğinde ne olduğunu kararlaştırın. Kesin mesajları ve sonraki eylemi (yükselt, erişim iste, tekrar dene, destekle iletişime geç) taslak haline getirin.
• Demo hesabıyla tam yolculuğu test edin. Her rol için bir hesap kullanın ve uçtan uca tıklayın: kayıt ol, onboarding, bir gerçek kayıt oluştur, kullanıcı davet et, limite takıl, denetim/yardım kontrol et ve bir hatadan kurtulun.

Örnek: küçük bir CRM inşa ediyorsanız, bir “Satış Temsilcisi” demo kullanıcısı oluşturun; kişi ekleyebilsin ama veriyi dışa aktaramasın. UI, neden dışa aktarmanın engellendiğini ve nereye gitmeleri gerektiğini açıklasın.

Ekipleri yavaşlatan yaygın tuzaklar

Çoğu gecikme zor kodlamadan değil, UI zaten inşa edilirken netleşmemiş kararlardan kaynaklanır. Bu şablon zaman kazandıracaksa, bazı anlaşmalara erken ulaşmanız gerekir.

Ekiplerin sık düştüğü çukurlar:

• Roller ve plan limitleri kilitlenmeden ekranları tasarlamak; erişim kuralları değişince veya özellik ücretlendirilecek diye akışları yeniden inşa etmek zorunda kalmak.
• Önemli ayarları çok sayıda sayfaya yaymak, böylece kimse bildirimler, güvenlik veya veri ihracı gibi temelleri bulamıyor.
• Muğlak isimlerle çok fazla rol yaratmak (Owner, Super Admin, Admin+, Power User), her izin kararını tartışmalı hale getirir.
• Boş, yüklenme ve hata durumlarını “sonra”ya bırakmak; sonra veri yokken veya istek başarısız olunca ürün kırık gibi görünür.
• Admin kontrolleri ile son-kullanıcı tercihlerini karıştırmak; normal kullanıcıların korkutucu seçenekler görmesi ve adminlerin vakit kaybetmesi.

Basit bir kural yardımcı olur: kullanıcıda veri yoksa, erişim yoksa, internet yoksa veya kredi yoksa ne olacağını mutlak olarak belirleyin, mutlu yolu cilalarken bunu unutmayın.

Örnek: bir CRM’de baştan kabul edin ki Satış kendi fırsatlarını düzenleyebilir, Yöneticiler ekip raporlarını görüntüler ve Owner faturalamayı yönetir. Sonra ayarları “Profilim” vs “Çalışma Alanı admin” olarak ayırın; böylece faturalama ekranları sürpriz hatalar yerine net limit mesajları gösterir.

Koder.ai içinde çalışıyorsanız, bu kuralları önce Planning Mode’da yazmak ekran oluştururken tekrar işi önler.

MVP hazır demeden önce hızlı kontrol listesi

Yayınlamadan önce ilk kez gelen bir müşteri gibi hızlıca test yapın. Sadece UI’nin sunduğu seçeneklere tıklayın. Gizli bir URL’ye, veritabanı müdahalesine veya “bir admina sor” gerektiriyorsa MVP hazır değildir.

Bu şablonun önlemek istediği ortak boşlukları yakalamak için bu kontrol listesini kullanın:

• Her temel ekrana net bir yol (menü, profil menüsü veya bariz bir buton) ile ulaşabiliyor musunuz? (faturalama, yardım, denetim gibi “sıkıcı” sayfalar dahil)
• Tüm formlar gerçek ürünler gibi davranıyor mu: net alan hataları, başarı onayı ve ne yapılacağına dair yardımcı bir hata mesajı?
• Plan ve kullanım limitleri erken görünür mü (yükseltme sayfasında, ayarlarda ve ilgili eylemin yakınında), sadece kullanıcı bir duvara çarpınca değil?
• Admin-e özel eylemler sade kelimelerle etiketlenmiş ve izinlerle korunmuş mu (UI gizlemesi güvenlik değildir)?
• Tamamlanmamış yollarınız var mı: boş durumlar, yüklenme durumları ve kullanıcıyı ilerleten hata ekranları?

Basit bir test: yeni bir hesap oluşturun, sonra ikinci bir kullanıcı eklemeyi, bir rol değiştirmeyi ve veri dışa aktarmayı deneyin. Tüm bunları karışıklık olmadan yapabiliyorsanız navigasyon ve izinler büyük ihtimalle sağlamdır.

Örnek: 12 ekranı basit bir CRM uygulamasına uygulama

Yerel hizmet şirketi için küçük bir CRM hayal edin. Lead, kontak ve fırsatları takip ediyor; üç rol var: Owner, Sales ve Support.

1. Gün genelde veri modeli basit olsa bile aynı paylaşılan ekranları gerektirir:

• Kimlik doğrulama: yeni çalışanların admin yardımı olmadan girebilmesi için giriş, kayıt ve şifre sıfırlama.
• Onboarding ve profil: kısa bir “Şirket adı ve zaman dilimi” adımı, sonra isim ve bildirim tercihlerini ayarlamak için profil ekranı.
• Kullanıcılar ve roller: kullanıcı davet etme, üyeler listesi ve rol düzenleyici (Owner faturalamayı ve rolleri yönetir, Sales fırsatları düzenler, Support görüntüler ve yorum yapar).
• Ayarlar: şirket ayarları (pipeline aşamaları, e-posta şablonları) ve kişisel ayarlar (tema, bildirimler).
• Faturalama ve limitler: plan sayfası ve seat/kontak sayısını gösteren kullanım ekranı.

Gerçekçi bir plan kuralı: Pro plan 5 seat ve 2.000 kontak izin veriyor. Owner 6. kullanıcıyı davet etmeye çalıştığında net bir limit durumu gösterin, belirsiz bir hata değil:

"Seat limiti doldu (5/5). Alex’i davet etmek için planınızı yükseltin veya bir üyeyi kaldırın."

Yaygın bir hata senaryosu: Sales bir kontağı silmek ister ama Support o kontakte bağlı 2 açık ticket olduğunu görür. İşlemi engelleyin ve ne yapılacağını açıklayın:

"Kişiyi silemezsiniz. Bu kişi 2 açık destek ticket’ına bağlı. Ticketları kapatın veya yeniden atayın, sonra tekrar deneyin."

Bu şablonu sohbet tabanlı bir oluşturucuyla uyguluyorsanız, tutarlılık hız kadar önemlidir. Koder.ai (koder.ai), web, backend ve mobil uygulamaları sohbetten üretmeye yönelik tasarlandığından Planning Mode ve kaynak kodu dışa aktarma gibi özellikleri, bu ekran kalıplarını tanımladıktan sonra sayfa üretimini kolaylaştırır.