Gerçek İhtiyaçlara Uyan Uygulama Gereksinimleri İçin Müşteri E-postaları

Neden müşteri mesajları işe başlamak için en iyi yer

Yanlış uygulamayı en hızlı şekilde inşa etmenin yolu tahminlerle başlamaktır. Takımlar bunu sürekli yapar. Kullanıcıların ne istediğini varsayar, akıllıca görünen özellikleri seçer ve kimsenin gerçekten ihtiyaç duymadığı bir şeyi haftalarca geliştirirler.

Müşteri mesajları çok daha iyi bir başlangıç noktasıdır. İnsanların ürününüz olmadan önce zaten ne yapmaya çalıştıklarını, nerede takıldıklarını ve yazmaya değer buldukları acının ne olduğunu gösterir. Bu, bir planlama toplantısındaki görüşlerden çok daha faydalıdır.

Değer dilin kendisindedir. Müşteriler nadiren problemleri ürün jargonuyla tanımlar. Genelde şunu derler: "Siparişleri kaybediyorum çünkü aynı detayları üç yere kopyalamam gerekiyor." Bu tek cümle size görevi, acıyı ve sorunun maliyetini söyler.

Genellikle birkaç gösterge en çok önem taşır:

• aynı problem farklı sözcüklerle tekrar ediyor
• insanlar zaten kullandıkları bir geçici çözümü tarif ediyor
• sorun zaman, para veya günlük odak kaybettiriyor
• mesaj yeterli bağlam veriyor, neyin yanlış gittiğini anlamaya yetiyor

Tek bir e-posta ilginç olabilir. On benzeri e-posta ise kanıttır. Tekrarlanan istekler, en çok bağıranı değil, en yaygın ihtiyacı hedeflemenize yardımcı olur.

Bu, teknik olmayan kurucular için özellikle faydalıdır. Düz bir dille bir uygulama şekillendiriyorsanız, kaba bir fikir gerçek destek konuşmaları veya kayıt notları ile desteklendiğinde çok daha güçlü olur. "Bir CRM yapın" demek yerine, "Bizi takip etmeyi hatırlatan, müşteri aramalarını kayıt altına alan ve potansiyel müşterilerin e-postada kaybolmasını engelleyen bir CRM yapın" diyebilirsiniz.

İşte müşteri mesajlarının iyi yaptığı şey: belirsiz bir fikri gerçekten etrafında inşa edebileceğiniz bir probleme dönüştürür.

Planlamadan önce ne toplayacaksınız

Ekran çizmeye veya özellik listesi yazmaya başlamadan önce gerçek acıyı gösteren mesajları toplayın. Her şeyi toplamanıza gerek yok. İnsanların ne yapmaya çalıştığını, nerede takıldığını ve sorunun maliyetini ortaya çıkaran birkaç tür not yeterlidir.

En faydalı materyal genellikle dört yerden gelir: destek e-postaları, satış veya kayıt notları, farklı kişilerden gelen tekrar eden istekler ve geçici çözümler, gecikmeler, atlanan adımlar ya da boşa giden zamandan bahseden mesajlar.

Belirli mesajlar her zaman muğlak şikayetlerden iyidir. "Dışa aktardıktan sonra faturaları bulamıyorum" faydalıdır. "Uygulamanız kötü" ise değildir. Mümkünse tam ifadeyi saklayın; çünkü tam ifade çoğunlukla yapılacak gerçek işi ortaya çıkarır.

Satış ve kayıt notları da önemlidir. İnsanlar orada genellikle hata bildirimlerinden daha açık hedefler belirtir. Bir potansiyel müşteri, lead'leri bir e-tabloda izlediğini, güncellemeleri e-postaya kopyaladığını ve her hafta saatler kaybettiğini söyleyebilir. Bu size mevcut süreçi, acıyı ve istedikleri sonucu verir.

Geçici çözümler en güçlü işaretlerden biridir. Birisi her Cuma veriyi elle dışa aktarıyorsa, notları ikinci bir araçta tutuyorsa veya her hafta aynı sorunu bir ekip arkadaşından düzeltmesini istiyorsa, ihtiyaç zaten gerçektir. Maliyet zaten vardır.

Her mesajla biraz bağlam kaydedin. Göndereni, ne yapmaya çalıştıklarını, ne sıklıkta olduğunu ve sonucunu not edin. "Küçük ajans, haftalık, fatura gecikmelerine neden oluyor" gibi kısa bir satır sonraki planlamayı çok kolaylaştırır.

Hızlı inşa ediyorsanız, bu adım dağınık geri bildirimlerin rastgele özelliklere dönüşmesini engeller. Koder.ai gibi hızlı platformlarda bile daha iyi girdi çok daha iyi bir ilk sürümle sonuçlanır.

Gelen kutusunda kalıpları nasıl tespit edersiniz

Müşteri mesajlarını bir amaçla okuyun: tekrarları bulun.

Tek bir kızgın e-posta acil hissettirebilir, ama iyi ürün kararları kalıplardan gelir. Her mesajı bir ipucu gibi ele alın. Henüz mükemmel özellik fikirleri aramıyorsunuz. Aynı acının tekrar edip etmediğine bakıyorsunuz.

Önce mesajları problem bazında gruplayın, müşteriler problemi farklı şekillerde anlatsa bile. Bir kişi "Geçmiş siparişlerimi bulamıyorum" derken başka biri "Geçen ay ne satın aldığımı görmem lazım" diyebilir. İkisi de aynı soruna işaret eder: sipariş geçmişine erişim zor.

Basit bir etiket seti yardımcı olur:

• bilgiyi bulamama
• çok fazla elle yapılan adım
• eksik erişim veya izinler
• paylaşımı veya dışa aktarmayı zorlaştıran durum
• mobil kullanım rahatsız edici

Bunu yaptıktan sonra tek seferlik istekleri tespit etmek kolaylaşır. Bir müşteri çok spesifik bir rapor formatı istiyorsa bunu not edin. Bu, iki hafta içinde 12 kullanıcı tarafından bahsedilen bir sorunun ağırlığına sahip olmamalıdır.

Mümkün olduğunda müşterinin kendi sözlerini notlarda tutun. Gerçek dil, daha sonra özellik adlandırırken, ekran metinleri yazarken veya problemi ekibe açıklarken yardımcı olur. Ayrıca sizi dürüst tutar. "Daha hızlı fatura onayı gerekiyor" "iş akışı optimizasyonu"ndan çok daha açıktır.

Sıklık önemlidir ama alaka daha da önemlidir. Sadece kaç kere göründüğünü değil, kimin bu problemi yaşadığını takip edin. Günlük kullanıcıların beş kez bahsettiği bir acı, hiç başlamamış deneme kullanıcılarının on kez bahsettiği acıdan daha önemli olabilir.

En iyi kalıpların genellikle arkalarında iki şey vardır: tekrar ve önem. Birkaç ofis yöneticisi, destek elemanı ve kurucu aynı eksik adımdan yakınıyorsa, bu kalıp dikkat edilmeyi hak eder.

Kalıpları nasıl net gereksinimlere dönüştürürsünüz

Mesajları gruplayınca, her küme için problemi çözüme değil, probleme odaklanan tek bir basit cümle yazın.

Örneğin: "Müşteriler randevuları unuttuğu için doğru zamanda hatırlatma almıyor."

Problemi tek cümleyle net ifade edemiyorsanız, gereksinim muhtemelen hâlâ çok belirsizdir.

Sonraki adım kullanıcıların yapmaya çalıştığı işi adlandırmaktır. Pratik olun. Yukarıdaki örnekte iş "bildirimleri yönetmek" değildir. Gerçek iş "personelin takip etmek zorunda kalmadan müşterilerin randevularını hatırlamasını sağlamak"tır.

Bu ayrım erken aşamada gereksiz özellikler inşa etmenizi önler. Amaç kullanıcıların başarması gereken sonucu yakalamaktır, onların önerdiği her çözümü değil.

Şimdi kalıbı, teknik olmayan bir kişinin anlayabileceği kısa bir gereksinime çevirin. Hatırlatma örneği için ilk sürüm şunları içerebilir:

• personel randevudan önce otomatik hatırlatmalar gönderebilsin
• personel hatırlatmanın ne zaman gönderileceğini seçebilsin
• personel hatırlatmanın gönderilip gönderilmediğini görebilsin
• hatırlatma rezervasyonda zaten kayıtlı iletişim bilgilerini kullansın

Neler dahil edilmediğine dikkat edin. Framework'ler, veritabanı tasarımı veya mesaj kuyruğundan bahsetmiyoruz. Bu daha sonra gelir. İlk önce gereksinimin kullanıcının ne yapmasını sağlaması gerektiğini netleştirin.

Her gereksinimi yazdıktan sonra onu gerçek bir mesaja kadar takip edin. Hangi e-posta, destek konuşması veya kayıt notunun bunun önemli olduğunu kanıtladığını sorun. Gerçek müşteri ifadesini gösteremiyorsanız, o maddeyi "belki sonra" listesine taşıyın.

Hızlı bir test yardımcı olur:

• Teknik olmayan bir ekip üyesi bunu anlayabiliyor mu?
• Tek bir net sonucu tanımlıyor mu?
• Tekrarlanan müşteri diline mi dayanıyor?
• Onu çıkarmak birinci sürümü daha az kullanışlı kılar mı?

Dörtüne de evet ise muhtemelen sağlam bir gereksinime sahipsiniz.

Birinci sürüme ne koyacağınıza nasıl karar verirsiniz

Gerçek isteklerden oluşan bir yığını olduğunda, sıradaki iş çoğunu reddetmektir.

İyi bir ilk sürüm tüm ürünün küçültülmüş bir kopyası değildir. İnsanların sürekli tanımladığı ana acıyı açıkça çözen en küçük düzeltmedir.

Basit bir sıralama yöntemi burada iyi işler. Dört şeye bakın:

• problemin ne sıklıkta ortaya çıktığı
• kullanıcının ne kadar acil hissettiği
• ana işi yapmalarını engelleyip engellemediği
• eklenen değere göre inşa etmenin zorluğu

En iyi birinci sürüm maddeleri genellikle ilk üçünü iyi puanlar ve dördüncüde makul kalır.

Diyelim ki müşteri mesajları sürekli "destek çağrısından sonra takipleri kaybediyorum" diyor. Faydalı bir ilk sürüm; kişi notları, bir takip hatırlatıcısı ve basit bir durum etiketi içerebilir. Muhtemelen ekip izinleri, gelişmiş raporlar veya beş farklı dışa aktarım formatına ilk günde ihtiyacı yoktur. Bunlar daha sonra önemli olabilir, ama çekirdek sorunu ilk etapta çözmezler.

Fokuslanmış bir ilk sürüm bir cümlede kolayca açıklanabilmelidir. Basitçe anlatamıyorsanız muhtemelen çok fazlasını yapmaya çalışıyordur.

Bu, hızlı inşa ederken daha da önemlidir. Düz metinden yazılım oluşturmayı sağlayan araçlar işleri hızlandırabilir, ama hız sadece kapsam net olduğunda faydalıdır. Koder.ai kullanan kurucular için temiz gereksinimler genellikle çok daha kullanışlı bir ilk sürüme götürür.

Basit bir örnek

Küçük bir satış ekibinin sürekli aynı destek e-postasını gönderdiğini hayal edin. Mesaj "Daha iyi bir CRM'e ihtiyacımız var" değil. Çok daha basit: "Bir lead'i takip etmeyi unuttum ve şimdi anlaşma soğudu."

Birkaç hafta sonra kalıp kolayca görülür. Bir kişi telefon görüşmesinden sonra takibi kaybettiğini söyler. Başkası bir müşterinin fiyat sorduğunu ama üç gün boyunca kimsenin cevaplamadığını söyler. Başkası notlarının e-posta ve e-tabloda dağınık olduğunu, bu yüzden hatırlatmaların kaçtığını söyler.

Gelen kutusu gerçek acıya işaret ediyor. Ekip büyük bir sistem, pipeline'lar, tahminler ve yönetici ayarlarına ihtiyaç duymaz. Bir sonraki kime ne zaman ulaşılacağını hatırlamanın temel yoluna ihtiyaçları vardır.

Kayıt notları bunu destekler. Kullanıcılar zaten iletişim adlarını, kısa notları ve sonraki adımları dağınık yerlerde tutuyor. Eksik olan basit bir hatırlatma akışıdır.

Böylece birinci sürüm küçük tutulur:

• bir iletişim listesi
• notları kaydetmek için bir yer
• sonraki takip için bir hatırlatma

Bu, çekirdek sorunu test etmek için yeterlidir.

İnsanlar bunu her gün kullanmaya başlarsa, sonraki istekler eklenmesi gerekenleri gösterecektir. Belki kullanıcılar tekrar hatırlatmalar isteyecek. Belki paylaşılan iletişimler isteyecekler. Belki e-posta şablonlarına ihtiyaç duyacaklar. Bu fikirler göz ardı edilmez; daha sonra eklenmek üzere ayrı bir listede saklanır.

Böylece ilk sürüm, gerçek mesajlarda görülen tekrarlayan acıya odaklı kalır.

İlk yapıyı bulanıklaştıran hatalar

Yapılan yaygın hatalardan biri, en yüksek sesli müşteriye göre inşa etmektir, en yaygın probleme göre değil. Tek bir kişi çok spesifik bir iş akışı isteyebilir, ama eğer başka kimsenin aynı derdi yoksa o istek birinci sürümü tanımlamamalıdır.

Diğer hata, önerilen bir özelliği gerçek ihtiyaç olarak görmektir. Müşteriler sıklıkla doğrudan çözüme atlar: panolar, filtreler ve uyarılar isterler. Bu fikirler faydalı olabilir ama acıyı anlamadan önce bunlar hala varsayımdır.

Daha iyi soru şudur: Bu istekte bulunmadan önce ne zordu? Gerçek problem "acele siparişleri sürekli kaçırıyorum" ise, uyarılar yardımcı olabilir ama günlük bir özet veya daha net bir sıra da işe yarayabilir. Acı etrafında inşa edin, ilk gelen özellik fikri etrafında değil.

Takımlar ayrıca çok farklı kullanıcıları erken üründe karıştırınca zorlanır. Yöneticiler, satış personeli ve son kullanıcıların hepsi farklı şeylere ihtiyaç duyuyorsa, hepsine aynı anda hizmet etmeye çalışmak genellikle kafa karıştırıcı bir uygulama yaratır.

Önce bir ana kullanıcı seçin. Sonra onların ana bloklanan görevini tek düz cümleyle tanımlayın. Sadece o görevin daha hızlı, daha net veya daha az hatayla gerçekleşmesine yardımcı olacak özellikleri tutun.

Başka bir kolay tuzak da ana iş iyi çalışmadan kenar durumları eklemektir. Sorumlu hissettirse de erken kullanıcılar uygulamayı genelde tek bir şeye göre değerlendirir: çekirdek görevi sürtünme olmadan tamamlayabiliyorlar mı?

Müşteriler sürekli yavaş randevu rezervasyonundan bahsediyorsa, işe tatil kuralları, karmaşık onay zincirleri ve nadir istisnalarla başlamayın. Önce rezervasyonu kolaylaştırın.

Son olarak, müşterilerin zaten kullandığı dili görmezden gelmeyin. Onların ifadeleri problemi nasıl gördüklerini ve neyin tanıdık geleceğini söyler. Her e-posta "takip hatırlatıcısı" diyorsa ve siz bunu "etkileşim tetikleyicisi" olarak yeniden adlandırırsanız, netlik yaratabileceğiniz yerde kafa karışıklığı yaratırsınız.

İnşa etmeden önce son bir kontrol yapın

İnşa etmeye başlamadan önce durun ve planınızı gerçekten sahip olduğunuz kanıtlara karşı test edin.

Tekrarlayan kanıt arayın. Tek güçlü bir e-posta ilginçtir. Aynı hayal kırıklığını üç veya daha fazla mesajla ifade edenler bir kalıptır.

Kullanıcıyı ve problemi sade bir dille adlandırın. "Daha iyi iş akışı yönetimi" yazmayın. "Küçük dükkan sahipleri siparişleri e-posta dizilerinde gömüldüğü için kaybediyor" gibi yazın.

Her özelliği bir acı noktasına eşleştirin. Bir özellik sadece havalı göründüğü için varsa, kesin.

Ürünü bir kısa cümleyle açıklamaya çalışın. Cümle uzamaya devam ediyorsa, kapsam muhtemelen çok geniştir.

Sonra bekleyebilecekleri çıkarın. Birinci sürüm son ürününüz değildir. Şimdi ana acıyı çözen parçaları tutun ve geri kalanını daha sonra için ayırın.

"Bu uygulama serbest çalışan tasarımcıların onay için e-posta ile peşinden koşmadan teklif göndermesini sağlar" gibi bir cümle açıktır. Eğer teklif sorununu düzeltmeden önce ekip sohbeti, analiz ve müşteri portalı eklerseniz, kapsam sapmıştır.

Kalıbı bulduktan sonra ne yapmalı

Aynı problem tekrar tekrar ortaya çıktığında, notlarınızı kısa bir özet haline getirin: sorun kimde, ne yavaşlatıyor ve bunun yerine hangi sonuç isteniyor.

Basit olabilir: "Yeni müşteriler faturaların nerede saklandığını sürekli soruyor ve destek aynı soruları yanıtlamak için çok zaman harcıyor."

Bundan sonra sade bir özellik listesi yazın. Tekrarlayan acıyı doğrudan çözen birkaç şeye odaklanın. Sorun fatura karışıklığıysa, birinci sürüm sadece aranabilir bir fatura sayfası, e-posta bildirimleri ve basit bir durum görünümü gerektirebilir.

İnşa etmeden önce taslağı birkaç gerçek kullanıcıya gösterin. Tam bir demo gerekmez. Kaba bir mockup, kısa bir yürütme veya kısa bir mesaj genellikle "Bu, bize yazdığımız problemi çözer mi?" diye sormak için yeterlidir.

Cevap genellikle eksik olanı, gereksiz olanı ve kağıt üzerinde iyi görünen ama gerçek kullanımda işe yaramayanı söyler.

İlk sürümü hızlıca test edebilecek kadar küçük tutun. Bu, ister bir geliştirme ekibiyle çalışın ister Koder.ai gibi bir platform kullanarak düz dil gereksinimlerini uygulamaya dönüştürün fark etmez. İlk sürümün kalitesi hâlâ gerçek problemin ne kadar net tanımlandığına bağlıdır.

Lansmandan sonra gelen kutusunu okumaya devam edin. İlk sürüm planlamanın sonu değildir. Yeni e-postalar, destek cevapları ve geri bildirim notları sorunun tamamını mı yoksa sadece bir kısmını mı çözdüğünüzü söyleyecektir.

Lansmanı bir sonraki araştırma turu olarak görün. Yeni istekleri kaydedin, tekrarları etiketleyin ve kullanıcıların sonraki davranışlarına göre ayarlayın. İşte odaklı küçük bir ilk sürümün insanların kullanmaya devam ettiği bir şeye dönüşmesinin yolu.