Her ay onuncu gün civarında, muhasebe ekibi aynı talebi gönderir. Her müşteriden beş dosyaya ihtiyaçları vardır: bir banka ekstresi, bir makbuz arşivi, bir bordro raporu, bir satış özeti ve bir envanter belgesi. Şablon dost canlısı, kesin ve test edilmiştir. Müşteriyi ismiyle selamlar, dosyaları listeler ve net bir son tarih sunar. İlk gönderimde işe yarar. Müşteri düzenli bir liste görür ve yanıt verir.

Sorun ikinci e-posta ile başlar.

Bir müşterinin dört dosya gönderdiğini hayal edin. Beşinci banka ekstresi asla gelmez. Makbuz arşivi görünür ancak yanlış ayı kapsadığı için ekip tarafından reddedilir. Bordro raporu aslında üç gün önce Slack üzerinden gelmiştir ve birisi onu çoktan dosyalamıştır. Envanter belgesi bu müşteri için hiç geçerli değildir; bu detayı ancak ilk mesaj gönderildikten sonra fark edersiniz. Orijinal şablonu yeniden gönderirseniz, tekrar beş dosya istersiniz. Bu taleplerin dördü artık anlamsızdır. Biri ise aktif olarak yanıltıcıdır. Kelimeler iyidir. E-postanın sadece hafızası yoktur.

Bir e-posta şablonu isimleri, tarihleri ve talimatları iyi yönetir. Küçük, tek seferlik bir talep için bu genellikle yeterlidir. Bir kişi e-postayı gönderir, müşteri yanıtlar ve aynı kişi görevi tamamlar. Geçmiş, tek bir beyinde ve tek bir gelen kutusunda yaşar.

Sorunlar, bir sonraki mesajın ilk e-postadan sonra gerçekleşen olaylara bağlı olduğu durumlarda başlar. Şablon hala orijinal listeyi gösterir. Dün bir banka ekstresinin geldiğini bilmez. Bir bordro raporunun reddedildiğini bilmez. Bu veriler bir gelen kutusunda, muhtemelen birkaç gelen kutusunda yaşar ve hatırlatıcıyı oluşturan uygulama bunu okuma imkanına sahip değildir.

"Açık" Durumu Yeterli Olmadığında

Eğer tüm talebi "açık" gibi tek bir durum olarak takip ederseniz, önemli ayrıntıları kaybedersiniz. Öğeler birbirinden bağımsız olarak hareket eder. Bir sonraki iletişimin doğru olabilmesi için her birinin kendi durumuna ihtiyacı vardır:

  • Banka ekstresi: Eksik. Müşteri göndermedi.
  • Makbuz arşivi: Yüklendi ancak incelenmedi. Dahili bir kontrol beklemek üzere bir klasörde duruyor.
  • Bordro raporu: Reddedildi. Müşteri bir şey gönderdi ancak format veya ödeme dönemi yanlıştı.
  • Satış raporu: Başka bir kanal üzerinden alındı. Slack, telefon görüşmesi veya posta kopyası yoluyla geldi ve ekibiniz bunu çoktan kaydetti.
  • Envanter belgesi: Geçerli değil. Bu müşterinin bunu sağlamasına gerek yok ve sistem sormayı bırakmalıdır.

Bu ayrım olmadan, hatırlatıcınız kördür. Eksik bir dosya ile reddedilmiş bir dosyayı aynı şekilde ele alır. Elinizde olan bir dosyayı sanki hiç gelmemiş gibi işleme koyar. Bu, müşterinin vaktini boşa harcar ve güveni zedeler. İki veya üç alakasız hatırlatıcıdan sonra müşteriler metne göz gezdirip geçerler. Sisteminizin bozuk olduğunu varsayarlar.

Sadece İhtiyacınız Olanı İnşa Edin

İlk etapta devasa bir kurallar motoru inşa etmeyin. İlk günden yirmi koşullu dallanmaya sahip bir iş akışı otomasyonuna ihtiyacınız yok. Sadece şu soruyu yanıtlayacak kadar veri takip ederek başlayın: Müşteriden hala ne yapması bekleniyor?

Talep edilen her öğenin kalıcı bir sonucu olmalıdır. Bu, uygulama bir sonraki mesajı taslak haline getirirken okuyabileceği bir yerde, e-posta zincirinin dışında yaşayan bir kayıt anlamına gelir. Kaydın karmaşık olmasına gerek yoktur. Bir öğe adı, mevcut durumu, bir zaman damgası ve kısa bir not tutan yapılandırılmış bir tablo kadar basit olabilir. Önemli olan, verinin gelen kutusunun ötesinde hayatta kalmasıdır.

Bu durum e-postanın rolünü değiştirir. Şablon hala tonu ve yapıyı kontrol eder. Selamlama sıcak kalır, talimatlar net kalır. Ancak belge listesi talep verilerinden gelmelidir. Hatırlatıcı bir sorguya dönüşür. Listeyi, yalnızca müşteri eylemi gerektiren öğeleri gösterecek şekilde filtreleriz. Dahili inceleme bekleyen öğeleri hariç tutarız. Zaten kabul edilmiş öğeleri hariç tutarız.

Eğer bir yükleme reddedildiyse, hatırlatıcı bunu belirtmeli ve nedenini açıklamalıdır. Belgeyi, sanki müşteri göndermeyi unutmuş gibi sessizce genel bir listeye geri koymamalıdır. Müşteri bir şey yüklediğini bilir; aksini iddia etmek sizi düzensiz gösterir.

Devir Testi

Bu ekstra veri modeline ihtiyacınız olup olmadığını anlamanın basit bir yolu vardır. Şunu sorun:

Başka bir ekip üyesi, tüm e-posta zincirini okumadan bu talebi devralabilir mi?

Tek bir dosya için cevap önemli değildir. Birçok değişkenin olduğu, her ay tekrarlanan talepler için ise çok önemlidir. Eğer ana iletişim kişisi tatildeyse, bir meslektaşı neyin eksik olduğunu saniyeler içinde görebilir mi? Bir yönetici, on e-posta ve üç paylaşılan klasör açmadan müşterinin güncel olup olmadığını anlayabilir mi? Eğer bir reddedilme kaydı sadece bir yazışma dizisindeki, imzaların ve iletilerin altına gömülmüş dördüncü mesajda tutuluyorsa, o zaman sisteminiz insanları bir veritabanının yapması gereken işleri yapmaya zorluyor demektir.

Şablonlar mesajı iyileştirir. Takip edilen bir talep ise geçmişi korur. Biri nasıl konuştuğunuzu, diğeri ise ne bildiğinizi yönetir.

Betikler Değil, Sorgular

Kalem düzeyinde durumlara sahip olduğunuzda, e-posta oluşturma süreci betik yazımından sorgulamaya dönüşür. Eskiden bir paragraf yazar ve hala doğru olup olmadığını umardınız. Şimdi ise verilerinize sorarsınız: Bu kalemlerden hangileri hala müşteri aksiyonu gerektiriyor? Hatırlatıcıyı bu filtrelenmiş liste etrafında oluşturursunuz. Eğer herhangi bir aksiyon gerekmiyorsa, hiç hatırlatma göndermezsiniz. Eğer iki kalem aksiyon gerektiriyorsa ve biri belirli bir nedenle reddedildiyse, e-posta kendini bu gerçeklerin etrafında inşa eder.

Bu