Article

Müşteri Geri Bildirimi Takibi: Feature İsteklerini Yönetin (58 karakter

Müşteri geri bildirimleri Slack'e, e-postaya, notlara dağılırsa kaybolur. Alios'ta müşteri geri bildirimi takibini node'lar ve durumlarla nasıl kuracağınızı öğrenin.

Müşteri Geri Bildirimi Takibi: Feature İsteklerini Yönetin (58 karakter

Müşteri Geri Bildirimi Takibi: Feature İsteklerini Yönetin

Bir müşteri demo sırasında "bu özellik olsa harika olurdu" diyor. Satış temsilcisi not alıyor. Toplantı bitiyor, not Slack'e atılıyor. Ürün ekibi o mesajı görüyor, emoji koyuyor. Bir sonraki sprint planlamasında kimse o mesajı hatırlamıyor.

Üç ay sonra aynı müşteri aynı isteği tekrar dile getiriyor. "Bunu daha önce de söylemiştim" diyor. Haklı.

Müşteri geri bildirimi takibi yapılmadığında kaybolan sadece bir feature isteği değil. Kaybolan müşterinin "beni dinliyorlar" hissi.

Feedback Neden Dağılıyor?

Geri bildirim genellikle birden fazla kanaldan geliyor: müşteri görüşmeleri, destek talepleri, demo sonrası e-postalar, NPS yorumları, satış notları. Her kanal ayrı bir yer. Hiçbiri birbirine bağlı değil.

Toplanan feedback bile çoğu zaman yapılandırılmamış halde duruyor. "Raporlama modülü daha iyi olmalı" gibi bir not tek başına anlamsız. Kaç müşteri istedi? Hangi segmentten? Şu anki roadmap'le çakışıyor mu? Bu soruların cevabı olmadan feedback önceliklendirilemez.

Bir de "ne oldu?" sorunu var. Müşteri bir istek iletti, sonrasında ne yapıldığını bilmiyor. Takip edildi mi? Backlog'a mı girdi? Reddedildi mi? Bu belirsizlik müşteri güvenini aşındırıyor.

Alios'ta Feedback Node'larıyla Takip Akışı

Alios'ta müşteri geri bildirimi takibi için her feedback ayrı bir node olarak açılır. Bu node'un içinde feedbackin tüm yaşam döngüsü yaşar: geldiği andan kapatıldığı ana kadar.

Her feedback node'u şu bilgileri taşır:

Başlık: Feedbackin tek cümlelik özeti. "Raporlama modülüne CSV export ekle" gibi — "raporlama iyileştirilsin" gibi değil.

Açıklama: Müşteri tam olarak ne dedi? Hangi bağlamda? Hangi kanaldan geldi? Kopyalanabiliyorsa müşterinin kendi cümlesi.

Kaynak: Kim söyledi, hangi müşteri segmentinden, hangi tarihte.

Durum: Gelen feedback beş aşamadan birinde yaşar:

📥 Yeni → gözden geçirilmedi
🔍 İnceleniyor → ürün ekibi değerlendiriyor
📋 Backlog'a Alındı → onaylandı, sıraya girdi
🚧 Geliştiriliyor → aktif sprint'te
✅ Tamamlandı → yayınlandı, müşteri bilgilendirildi
❌ Reddedildi → neden reddedildiği açıklamada yazıyor

Sorumlu: Bu feedbacki kim takip ediyor? Ürün müdürü mü, geliştirici mi, müşteri başarı ekibi mi?

Feedback Geldiğinde Ne Yapılır?

1. Node açılır — başlık ve açıklama yazılır
2. Kaynak bilgisi eklenir (müşteri adı, kanal, tarih)
3. Durum: "Yeni" olarak işaretlenir
4. Sorumlu atanır
5. Haftalık review'da "Yeni" node'lar incelenir
6. Her node "İnceleniyor" veya "Reddedildi" statüsüne taşınır

Bu akış oturduğunda hiçbir feedback karanlıkta kalmıyor. Slack mesajına gömülmüyor, not defterinde unutulmuyor.

Birden Fazla Müşteri Aynı Şeyi İstiyorsa

Aynı feature isteği farklı müşterilerden geldiğinde ayrı node açmak yerine mevcut node'un açıklamasına yeni kaynak eklenir:

📥 FEEDBACK: CSV Export — Raporlama Modülü

Kaynak 1: Müşteri A — Demo görüşmesi — 3 Mart
Kaynak 2: Müşteri B — Destek talebi — 11 Mart
Kaynak 3: Müşteri C — NPS yorumu — 18 Mart

Toplam talep: 3 müşteri / 2 farklı segment

Bu birikim ürün kararlarını veriye dayalı hale getiriyor. "Bu feature'ı neden yapıyoruz?" sorusunun cevabı node'da duruyor.

Kapanış Kriterleri: Bir Feedback Ne Zaman Kapanır?

Feedback node'larının sonsuza kadar açık kalmaması için her durum geçişinin net kriteri olmalı.

"Tamamlandı" kapanışı için:

  • Feature yayınlandı

  • Müşteriye bilgi verildi — "istediğiniz özellik yayında" mesajı gönderildi

  • Varsa müşteri onayı veya tepkisi node'a eklendi

"Reddedildi" kapanışı için:

  • Neden reddedildiği açıklamaya yazıldı — "roadmap'e uymadı", "teknik maliyet yüksek", "yeterli talep yok" gibi

  • Reddedilen feedback sahiplerine kısa bir bilgi verildi — müşteri ilişkileri açısından önemli

  • Node kapatıldı ama silinmedi — ileride referans olabilir

"Backlog'da Bekliyor" için zaman aşımı:

  • 90 günü geçen backlog node'ları review'a alınır

  • Hâlâ geçerli mi? Öncelik değişti mi? Kapatılacak mı?

Bu kriterler olmadan feedback listesi büyür, kimse bakmaz, sistem işlevsiz hale gelir.

Son Düşünce

Müşteri geri bildirimi takibi sadece ürün kararlarını değil, müşteri ilişkilerini de etkiliyor. Feedback alan ama geri dönmeyen şirketler zamanla müşterinin "söylemenin anlamı yok" moduna geçmesine neden oluyor.

Alios'ta her feedbacki node olarak açmak, durumunu güncel tutmak ve kapanış kriterlerini uygulamak — bu üç alışkanlık müşteri geri bildiriminin kayboluşunu büyük ölçüde önlüyor. Müşteri ne istediğini söylüyor, ekip nerede olduğunu biliyor, süreç görünür kalıyor.

Related articles

More articles

Explore other guides connected to this workflow.