ÇALIŞMA DETAYI
Restoran keşfi ve işletme yönetimi
Kullanıcı keşfi ile işletme tarafındaki geri bildirim ihtiyacını aynı kurguda buluşturma çalışması.
Bu çalışma bir ürün tanıtımı değil; belirli bir operasyon problemini nasıl ele aldığımın özeti.
Başlangıç noktası
Restoran keşfi çoğu platformda yalnızca arama üzerinden ele alınır.
Oysa gerçek kullanımda insanlar:
Örnek Senaryo:
Kullanıcı X Instagram'da bir Pizza mekanını gördü, "sonra giderim" dedi ama unuttu. 2 hafta sonra tekrar aramak zorunda kaldı. Kullanıcı Y favori listesinde 50+ restoran birikti; hangisini neden kaydettiğini hatırlayamadı. İşletme Z gelen yorumları WhatsApp'tan takip etmeye çalıştı; hangi yoruma cevap verdiğini unuttu ve müşteri memnuniyeti düştü.
- •bir yeri görür ama sonra unutur
- •"sonra giderim" dediği mekanları kaybedip tekrar arar
- •yorum okur ama bağlamını anlayamaz
- •işletme tarafında ise gelen yorumlar dağınık ve tepkisiz kalır
Keşif, tek bir an değil; devam eden bir ilişki olarak ele alındı.
Temel tıkanmalar
Kullanıcı tarafında
- •Keşfedilen restoranlar tekrar bulunamıyor
- •Favoriler ve listeler net ayrışmıyor
- •Yorumlar bağlamsız kalıyor
- •Konum bazlı keşif yüzeysel kalıyor: çünkü konum sinyali tek başına niyeti yakalamaz; listeleme davranışıyla birleşmeli.
İşletme tarafında
- •Yorumlar dağınık ve yönetilemez
- •Görünürlük metriği yok
- •Promosyonlar kullanıcıya tutarlı biçimde ulaşmıyor
- •İşletme sahibi için "merkezi kontrol" yok
Bu çalışmadaki 3 ana karar
Neden tek “favori” yerine çoklu liste kurgusu?
Problem
Kullanıcılar mekanları keşfeder ama geri dönmez. “Tek favori” zamanla çöpe döner; kişi neden kaydettiğini ve ne için kaydettiğini kaybeder.
Karar
Bu yüzden “tek favori” yerine çoklu liste mantığına gittik: niyete göre ayrışan listeler, geri dönüşü bir arşive bağlar.
Ortaya çıkan yapı
Keşif tek seferlik kalmaz; kullanıcı için tekrar bulunabilir, düzenlenebilir bir karar geçmişine dönüşür.
Kaydedilen Yerler
Kişisel arşiviniz
Favorilerim
Randevu Fikirleri
Kahve Mekanları
Halka Açık Liste
Çoklu liste mantığı, “gördüm → kaybettim” döngüsünü kırmak için tasarlandı.
Neden kullanıcı deneyimi ile işletme operasyonunu ayırdık?
Problem
Bu tür platformlarda iki farklı ihtiyaç aynı yerde “eritilmeye” çalışılır: kullanıcı hızlı karar ister; işletme geri bildirim ve görünürlük kontrolü ister. Aynı akış her iki tarafa da yetmez.
Karar
Rol ayrımı netleştirildi: kullanıcı tarafı keşif/kayıt döngüsüne, işletme tarafı yorum takibi ve görünürlük yönetimine odaklandı.
Ortaya çıkan yapı
İşletme için "panel demo" değil; operasyonel kontrol alanı oluştu. Panel, yorumları 'okuma' değil 'sınıflama + takip' olarak ele alır. Kullanıcı tarafı da gereksiz karmaşıklık taşımadı.
24
Yorumlar
3
Aktif Kampanyalar
8.2k
Görünürlük
12
Rezervasyonlar
Yorum “metin” değil; bağlamlı bir operasyon sinyalidir
Problem
Yorumlar çoğu üründe “metin yığını”na döner: kullanıcı için bağlamsız kalır, işletme için aksiyon üretmez.
Karar
Yorumları bağlamıyla ele aldık: kullanıcı için güven sinyali, işletme için takip/yanıt/iyileştirme sinyali.
Ortaya çıkan yapı
Yorumlar sadece “okunmaz”; sınıflanır, takip edilir, işletme tarafında yönetilebilir hale gelir.
Kullanıcı Görünümü
Bella Vista
Harika bir deneyim! Yemekler çok lezzetli, servis hızlı ve personel çok nazik. Kesinlikle tekrar geleceğiz.
İşletme Görünümü
Harika bir deneyim! Yemekler çok lezzetli, servis hızlı ve personel çok nazik. Kesinlikle tekrar geleceğiz.
Aynı veri, iki role farklı bağlamla hizmet eder.
Ortaya çıkan yapı
Bu yapı sayesinde:
- ✓Keşif, tekrar bulunabilir bir karar geçmişine bağlanır (çoklu liste)
- ✓Kullanıcı ile işletme ihtiyaçları birbirini boğmaz (rol ayrımı)
- ✓Yorumlar metin olmaktan çıkar, operasyonel sinyale dönüşür
Bu çalışmayla birlikte keşif, kayıt ve geri bildirim aynı yapıda buluştu. Kullanıcı tarafındaki karar izi ile işletme tarafındaki takip ve görünürlük yönetimi birbirini besleyen bir işleyişe dönüştü.
Bu çalışma, kullanıcı tarafındaki keşif ile işletme tarafındaki yönetim ihtiyacını aynı işleyişte buluşturdu.
Eğer ürününüzde keşif, kayıt ve geri bildirim hâlâ kopuk ilerliyorsa; hangi noktada değer kaybolduğunu birlikte çıkarabiliriz.
Örnek çalışma
Başvuru, değerlendirme ve kurul hattını tek sistem mantığında birleştiren operasyon kurgusu
Başvuru, hakem ve kurul hattı tek operasyon omurgasında değildi; süreçler e-posta ve dosyalar arasında dağınıktı.
Sistem kararlarını inceleyin→Örnek çalışma
Stok, sipariş ve tedarik akışlarını tek operasyon omurgasında toplayan yapı
Stok hareketleri, sipariş yaşam döngüsü ve kritik uyarılar tek veri yapısında toplanmıyordu.
Sistem kararlarını inceleyin→Süreci birlikte değerlendirelim
Eğer süreçleriniz dışarıdan çalışıyor gibi görünse de içeride belirsizlik, tekrar ve sürtünme üretiyorsa; ilk çerçeveyi birlikte çıkarabiliriz.