Örnek Senaryo
Talep girişinden CRM kaydına
Örnek senaryo · müşteri çalışması değildir
Mevcut durum
B2B hizmet veren bir şirkete talepler hem web sitesi formundan hem de ortak bir e-posta kutusundan geliyor. Gün içinde iki kişi her iki kanalı da kontrol ediyor ve aradaki devir kimsenin sorumluluğunda değil.
Önerdiğimiz akış
Sınırları belli tek bir akış her iki kaynağı da yakalıyor, alanları doğrulayıp standartlaştırıyor, CRM içinde mevcut kaydı arıyor, yazılı yönlendirme kurallarını uyguluyor ve bir kişinin göndereceği yanıt taslağını hazırlıyor.
Referans çalıştırma sonuçları
Zorunlu bilgi eksik
Talep, herhangi bir şey yazılmadan önce reddedilir — eksik veriden kayıt oluşturulmaz.
Belirsiz şirket eşleşmesi
İki kayıt, farklı iletişim bilgileriyle aynı şirket gibi görünüyor. Vaka otomatik birleştirilmez, bir kişinin onayına bırakılır.
Sorunsuz talep
Doğrulanır, kontrol edilir ve tek seferde CRM içinde yeni bir kayıt olarak yazılır.
Ham çalıştırma
Gerçek bir çalıştırmadan
Referans yapımızdan gerçek bir çalıştırma: yeni bir talep geliyor, mükerrer ve mükerrere yakın kayıtlar otomatik yakalanıyor, belirsiz bir vaka bir kişinin onayına bırakılıyor ve her adım izlenebilir bir kayıt bırakıyor.
Sentetik referans yapımızdan alınmıştır — müşteri sonucu değildir.Tam boyut →
Bugün nasıl işliyor
Bir kişi mesajı okuyor, bilgileri elle CRM içine kopyalıyor, şirketin kayıtlı olup olmadığını tahmin ediyor ve takibi kimin üstleneceğini bir mesajla kararlaştırıyor.
İnsan kontrol noktaları
- Yanıtı bir kişi gönderir, sistem yalnızca taslağı hazırlar.
- Hassas veya yüksek değerli talepler, herhangi bir yanıt çıkmadan önce belirli bir sorumluya devredilir.
- Mükerrer olduğu düşünülen kayıtlar otomatik birleştirilmez, incelemeye işaretlenir.
Hata ve gecikme noktaları
- Mesai dışında gelen talepler, biri kutuyu açana kadar bekliyor.
- Aynı şirket, birbirine yakın farklı adlarla iki kez kaydediliyor.
- Talepte yer almadığı için zorunlu alanlar boş bırakılıyor.
- Sahiplik gayriresmi kararlaştırıldığından bazı talepler sahipsiz kalıyor.
Pilotta neyi ölçeriz
- Üzerinde anlaşılan başlangıç değerine göre ilk aksiyona kadar geçen süre
- Belirli bir sorumlusu olan taleplerin oranı
- Test kümesinde mükerrer kayıt oranı
- Zorunlu alan doluluk oranı
Teknik ayrıntılar ve varsayımlar
Daha fazla kanıt
Yeniden deneme ve kurtarma
Aynı çalıştırmadaki dördüncü bir gerçek vaka (F07/F08), ilk denemede başarısız olup yeniden denemede başarılı olan bir CRM yazımını gösteriyor — sonuçta yine tek bir kayıt oluşuyor, asla mükerrer değil.
Sistemler ve veri
Web sitesi formu, tek bir ortak e-posta kutusu ve desteklenen API ve webhooklar üzerinden CRM sistemleri. Yalnızca yönlendirme ve yanıt için gereken alanlar okunur, zenginleştirme müşterinin kullanmaya yetkili olduğu kaynaklarla sınırlıdır.
Başlangıç varsayımları
- Varsayılan hacim: iki kanaldan ayda yaklaşık 60 talep. Bu ölçülmüş bir veri değil, kapsam belirlemek için kullanılan bir varsayımdır.
- Varsayılan elle işlem süresi: bugün talep başına yaklaşık 6 dakika. Bu değer bir zaman etüdüne değil, sürecin birlikte adım adım gözden geçirilmesine dayanır.
- Varsayılan mükerrer kayıt oranı: her 10 kayıttan yaklaşık 1 tanesi. Yalnızca planlama varsayımı olarak alınmıştır.
Pilot kapsamı
Tek bir talep kaynağı, tek bir yönlendirme kural kümesi, tek bir CRM nesnesi ve yalnızca taslak yanıtlar. Giden kampanya, puanlama modeli veya pilot kural kümesi dışındaki CRM kayıtlarında değişiklik yoktur.
Riskler, istisnalar ve yedek plan
- CRM API erişilemezse akış kaydı kuyruğa alır ve kaydı düşürmek yerine bir kişiyi uyarır.
- Belirsiz veya bozuk gelen talepler elle giriş için istisna kuyruğuna alınır.
- Bu senaryo talep yönetimi ve veri kalitesiyle ilgilidir, satış sonuçlarına dair bir iddia içermez.
Canlıya almak için gerekenler
Belirlenmiş bir süreç sahibi, yazılı hale getirilmiş yönlendirme kuralları, en az yetki ilkesine göre verilmiş CRM erişimi, kuyruktaki verilerin saklama süresine dair bir karar ve akışı talepleri kaybetmeden devre dışı bırakan bir geri alma yöntemi.