Onlarca limanda çalışan ekipler için özel bir CRM arayüzü

Müşterinin talebi üzerine bu hikâye anonim olarak yayınlanmıştır. Şirket, liman ve kişi bilgileri paylaşılmamıştır.

Başlangıç noktası

Birden fazla ülkede onlarca liman işleten bir grup düşünün. Her limanın kendi ticari ekibi, kendi müşterileri ve kendi gündemi var. Merkez ise tamamına bakmak durumunda.

Standart bir CRM bu yapıda iki yönden birden zorlanıyor. Liman ekibine tüm grubun verisini gösterirseniz, aradığını bulamıyor. Sadece kendi verisini gösterirseniz, aynı müşteriyle başka limanda ne konuşulduğunu göremiyor. İkisinin arasını bulmak, arayüz meselesi.

Kurduğumuz yapı

Her ekranda “hangi liman” sorusu

Uygulamanın omurgası şu karar oldu: liman seçimi bir filtre değil, bir bakış açısı. Kullanıcı hangi limanları görüntülediğini seçiyor ve sayfanın tamamı ona göre daralıyor — kişiler, fırsatlar, riskler, son faaliyetler ve bunların sayıları dahil.

Bölge ve liman filtreleri birlikte kullanılamıyor; biri seçildiğinde diğeri temizleniyor. Bu kasıtlı bir kısıt: bölge geniş bir ağ atmak, liman ise tek bir noktaya odaklanmak için. İkisini aynı anda açık bırakmak, kullanıcının ne gördüğünü anlamasını zorlaştırıyordu.

Toplantı notları, dağınık değil gruplanmış

Ticari ekiplerin en çok ürettiği veri toplantı notu. Ama not, tek başına bir kayıt olarak durduğunda işe yaramıyor — hangi görüşmeye ait olduğu, kimlerin katıldığı ve hangi limanı ilgilendirdiği bilinmeli.

Notları toplantı bazında grupladık. Bir satırda toplantının tarihi, başlığı, kaç not içerdiği, bağlı olduğu şirket, ilgili limanlar ve katılımcılar görünüyor. Nottan doğrudan görev veya fırsat oluşturulabiliyor — yani not bir arşiv kaydı değil, bir başlangıç noktası.

Mükerrer kaydı en baştan engelleyen kişi sihirbazı

Yeni kişi oluşturma adım adım ilerleyen bir sihirbaza dönüştü: temel bilgiler, mükerrer kontrolü, kapsam tanımı ve onay.

Kritik adım ikincisi. Kullanıcı bilgileri girdikten sonra sistem benzer kayıtları arıyor ve bulduklarını kart halinde gösteriyor — unvan, şirket, e-posta ve ilgili limanlarla birlikte. Kullanıcı isterse mevcut kaydı açıp onun üzerinden devam ediyor.

Bu tasarımın mantığı şu: mükerrer kayıt sonradan temizlenen bir şey değil, oluşmadan önce engellenen bir şey olmalı. Sonradan birleştirme her zaman veri kaybı riski taşıyor.

Kapsam kararı: liman mı, global mi?

Her kişi ya belirli limanlara bağlı ya da grup genelinde görünür. Sihirbazın son adımında bu seçiliyor ve seçim, o kişinin kimler tarafından görüleceğini belirliyor.

Ayrıca belirli hesap tiplerinde sistem, kişinin unvanına bakarak bir departman öneriyor ve üst düzey yöneticiler için ayrı bir işaret sunuyor. Öneri, kullanıcı değiştirdiğinde “değiştirildi” olarak işaretleniyor — yani otomasyon kararı ele geçirmiyor, sadece hızlandırıyor.

Hesap sayfası: sayılar değil, anlatı

Hesap kaydına, serbest metin olarak yazılan stratejik bir bölüm ekledik: müşterinin stratejisi, kilit ilişkileri, geçmişi ve fırsatları.

Bu, alan doldurmaya alışkın bir CRM’de alışılmadık bir tercih. Ama bazı bilgiler alana sığmıyor. Bir müşteri ilişkisinin neden böyle olduğunu anlatan iki paragraf, on beş ayrı seçim listesinden daha fazlasını söylüyor — özellikle ekibe yeni katılan birine.

Telefondan da çalışıyor

Liman ekipleri masa başında değil. Ekranların telefonda nasıl davrandığı baştan tasarlandı, sonradan uyarlanmadı.

Sonuç

Asıl kazanç, kullanıcının “bu ekranda neden bu kayıtları görüyorum” sorusunu hiç sormaması. Görünürlük kuralları arayüzün içine yerleştirildiğinde, yetkilendirme bir engel olmaktan çıkıp bir kolaylığa dönüşüyor.

Neyi farklı yapardık

Bu ölçekte bir özel arayüz projesinde en büyük risk, her ekibin kendi istisnasını talep etmesi. Otuz limanın otuz farklı çalışma biçimi var ve her biri kendi alışkanlığını sisteme yazdırmak istiyor.

Bugün benzer bir projeye başlasak, hangi kararların merkezde sabit kalacağını ve hangilerinin limana bırakılacağını yazılı bir ilke olarak en başta netleştirirdik. Bu sınır baştan çizilmezse, her talep ayrı ayrı tartışılıyor ve proje takvimi talep sayısına bağlı hale geliyor.