İçeriğe geç

Örnek Senaryolar

Üç örnek senaryo. Her biri bugün ne olduğunu, neyi değiştirdiğimizi, insanın nerede onay verdiğini ve pilotta neyi ölçtüğümüzü gösterir.

Aşağıdaki içerikler örnek senaryolardır; müşteri çalışması veya sonuç vaadi değildir. Gerçek kapsam ve başlangıç değerleri ücretli analizde belirlenir.

Ö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.

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.

Ö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.

İ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.

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

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.

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.

Örnek Senaryo

İnsana devirli destek yönlendirmesi

Örnek senaryo · müşteri çalışması değildir

Mevcut durum

Küçük bir destek ekibi tek bir e-posta kuyruğunu yönetiyor. Soruların önemli bir bölümü tekrar ediyor ve yanıtlar hızlı aranamayan iç belgelerde zaten mevcut.

Bugün nasıl işliyor

Her mesaj okunuyor, ilgili politika ortak belgelerde aranıyor, arama sonuç vermezse yanıt hafızadan yazılıyor ve hesaba özel her konu bir meslektaşa yönlendiriliyor.

Önerdiğimiz akış

Tek bir kuyruk sınıflandırılıyor, onaylı bir bilgi kümesi aranıyor ve yanıt, dayandığı belgelere kaynak göstererek taslak olarak hazırlanıyor. Güven eşiğinin altında kalan, hesaba özel veya politika açısından hassas her konu yanıtlanmak yerine devrediliyor.

İnsan kontrol noktaları

  • Pilot süresince her taslak yanıt, gönderilmeden önce bir temsilci tarafından incelenir.
  • Onaylı bir kaynağa dayanamadığında sistem yanıt vermez ve konuyu bir kişiye yönlendirir.
  • Hesabı değiştiren talepler sistem tarafından hiçbir zaman uygulanmaz, yalnızca yönlendirilir.

Pilotta neyi ölçeriz

  • Üzerinde anlaşılan başlangıç değerine göre ilk yanıt süresi
  • Üzerinde anlaşılan test kümesinde kaynak gösterimi doğruluğu
  • Dayanak kaynağı bulunmayan yanıtların oranı
  • Devredilmesi gereken vakalarda devretme isabeti
Teknik ayrıntılar ve varsayımlar

Hata ve gecikme noktaları

  • Kaynak her seferinde kontrol edilmediğinden yanıtlar ekip üyeleri arasında farklılaşıyor.
  • Tekrar eden sorular her seferinde aynı eforu tüketiyor.
  • Hesaba özel talepler, doğru kişi müsait olana kadar kuyrukta bekliyor.

Sistemler ve veri

Tek bir e-posta kuyruğu ve müşterinin önceden üzerinde anlaştığı belge kümesi. Bu kümenin dışına çıkılmaz ve taslak yanıt, kaynak listesini birlikte taşır.

Başlangıç varsayımları

  • Varsayılan hacim: tek kuyrukta ayda yaklaşık 300 mesaj. Yalnızca kapsam belirleme varsayımıdır.
  • Varsayılan tekrar oranı: soruların yaklaşık yarısı bilinen konuların varyasyonu. Bu, pilotta test edilecek bir varsayımdır, ölçülmüş bir başlangıç değeri değildir.
  • Varsayılan bilgi kümesi büyüklüğü: yaklaşık 40 belge. Kaynak gösterimi kalitesi değerlendirilebilsin diye bilinçli olarak küçük tutulmuştur.

Pilot kapsamı

Tek kuyruk, tek onaylı bilgi kümesi, yalnızca taslak yanıtlar ve devretme için sabit bir güven ve politika kuralı. Otonom gönderim, hesap değişikliği veya ek kanal yoktur.

Riskler, istisnalar ve yedek plan

  • Arama kalitesi üzerinde anlaşılan eşiğin altına düşerse taslak üretimi kapatılır ve kuyruk elle işlemeye döner.
  • Kapsam dışı konular genel bilgiden yanıtlanmaz, devredilir.
  • Kullanılan model sağlayıcısının erişilebilirliği, bu iş akışının dışındaki bir bağımlılıktır.

Canlıya almak için gerekenler

Bilgi kümesi için gözden geçirme periyodu tanımlanmış bir sahip, üzerinde anlaşılmış bir devretme politikası, mesaj içeriği için kayıt ve saklama sınırları, değişiklik sonrası yeniden çalıştırılan bir değerlendirme kümesi ve güvenli kapatma anahtarı.

Örnek Senaryo

E-ticaret sipariş istisnası akışı

Örnek senaryo · müşteri çalışması değildir

Mevcut durum

Birden fazla kanalda satış yapan bir çevrimiçi satıcı. Siparişlerin çoğu sorunsuz ilerliyor, ancak bir kısmı eksik adres, yetersiz stok, ödeme sorunu veya hiç okutulmayan bir sevkiyat yüzünden takılıyor.

Bugün nasıl işliyor

Bir kişi günde bir iki kez sipariş listelerini gözden geçiriyor, takılanları fark ediyor, ayrıntı için her kanalı ayrı açıyor, müşteriye yazıyor ve takibi aklında tutmaya çalışıyor.

Önerdiğimiz akış

Sipariş olayları gerçekleştikçe alınıyor, istisna tipleri yazılı kurallara göre tespit ediliyor, tüm bağlamı içeren bir iç görev açılıyor ve müşteri mesajı taslak olarak hazırlanıyor. Aynı işlem tekrar denense bile ikinci kez uygulanmaz.

İnsan kontrol noktaları

  • Sistem hiçbir zaman iade işlemi başlatmaz, bunun için açık insan onayı gerekir.
  • Sipariş iptali için, kanala herhangi bir işlem gönderilmeden önce insan onayı gerekir.
  • Herhangi bir fiyat değişikliği bir kişi tarafından onaylanır, otomatik uygulanmaz.
  • Pilot süresince müşteri mesajları doğrudan gönderilmez, incelenmek üzere taslak olarak hazırlanır.

Pilotta neyi ölçeriz

  • Olaydan ilk insan aksiyonuna kadar geçen süre
  • İşlenen istisna başına elle yapılan adım sayısı
  • Test kümesinde mükerrer işlem oranı
  • Müşterinin destek hattına yazmadan önce bilgilendirildiği istisnaların oranı
Teknik ayrıntılar ve varsayımlar

Hata ve gecikme noktaları

  • Hiçbir şey istisnaları öne çıkarmadığı için sorunlar geç fark ediliyor.
  • İki kişi aynı siparişi ele aldığında aynı mesaj iki kez gidiyor.
  • Bir istisna açıkken kanallar arasında stok sayıları birbirinden uzaklaşıyor.
  • Kendilerine bilgi verilmediği için müşteriler destek hattına yazıyor.

Sistemler ve veri

Satış kanallarından desteklenen API ve webhooklar üzerinden gelen sipariş ve stok olayları, bir iç görev listesi ve ekip için bir bildirim kanalı. Yalnızca istisnayı sınıflandırmak ve açıklamak için gereken sipariş alanları okunur.

Başlangıç varsayımları

  • Varsayılan hacim: kanallar genelinde ayda yaklaşık 1.200 sipariş. Ölçülmüş bir veri değil, kapsam varsayımıdır.
  • Varsayılan istisna oranı: siparişlerin yaklaşık yüzde 4 kadarı. Yalnızca kuyruğu boyutlandırmak için kullanılmıştır.
  • Bugünkü varsayılan tespit gecikmesi: birkaç saat. Bu değer kayıtlı veriye değil, listelerin ne sıklıkla kontrol edildiğine dayanır.

Pilot kapsamı

Tek kanalda, olaydan taslak bildirime uzanan tek bir istisna hattı ve geri alınamaz her işlemde insan onayı. Fiyat otomasyonu, kanal genelinde stok yeniden yazımı veya otomatik iade yoktur.

Riskler, istisnalar ve yedek plan

  • Kanal API sınırları ve sağlayıcı kesintileri birer bağımlılıktır. Olaylar okunamadığında akış, yapacak iş olmadığını varsaymak yerine ekibi uyarır.
  • İş akışı kanallar arasında fazla satış riskini azaltmak için tasarlanmıştır, bu riski ortadan kaldırmak için değil.
  • Bir işlem için idempotency sağlanamıyorsa o işlem elle yapılmaya devam eder.

Canlıya almak için gerekenler

Operasyon sahibiyle üzerinde anlaşılmış yazılı istisna kuralları, onay verecek kişileri belirleyen bir onay yolu, kalıcı idempotency anahtarları, sipariş verisi için saklama kararı ve istisnaları sahipsiz bırakmadan akışı durduran bir geri alma yöntemi.