İki Taraflı Hizmet Pazaryeri Uygulaması Nasıl Geliştirilir?

İşlemi Kurmanın Üç Yolu 

Her pazaryeri asıl işlemi aynı şekilde yönetmiyor ve üç gerçek yapı çok farklı geliştirme karmaşıklığı taşıyor. 

Yaya doğrudan iletişimli bir dizin olarak çalışıyor; ailelerin bakıcıları aramasına ve filtrelemesine, ardından doğrudan mesajlaşıp işe almasına izin veriyor. Gerçek çalışma ilişkisi sonrasında uygulama dışında sürüyor, güvenilir bir kişisel tavsiyenin işleyişine yakın. Hey Gorgeous ise tam işlemli bir rezervasyon akışı çalıştırıyor; arama, rezervasyon, kapora ve ödemeyi ilk ziyaretten ödeme ekranına kadar uygulama içinde yönetiyor. Treffpunkt'ın Transfer Market'i üçüncü bir kalıp; futbolcuları ve kulüp yöneticilerini hiçbir ödeme işlemi olmadan birbirine bağlayan, daha geniş bir sosyal uygulamanın içine gömülü bir teklif katmanı. 

İşlem modelini seçmek build'deki her şeyin şeklini belirliyor: 

• İlişki işlemden daha önemliyse doğrudan iletişimli bir dizin seçin, çünkü Yaya'nın bakıcı işe alımını yönettiği gibi güven ve süregelen uyum anlık rezervasyondan daha ağır basıyor 

• Hizmet önceden fiyatlandırılıp planlanacak kadar standartsa, Hey Gorgeous'ın güzellik randevularını yönettiği gibi tam işlemli rezervasyon seçin 

• Hedef bağımsız bir pazaryeri kurmak değil zaten bir kitlesi olan bir ürüne hafif bir eşleştirme eklemekse gömülü bir teklif katmanı seçin 

Bunlar sonsuza kadar sabit seçimler değil. Güven ve hacim build'i haklı çıkardığında bir dizin sonradan rezervasyon ekleyebilir. Talep gerçekten varsa gömülü bir teklif katmanı da daha tam bir pazaryerine büyüyebilir. Kategorinin dürüstçe destekleyebileceği en hafif modelle başlamak genelde daha güvenli bahis. 

İlk Sürümün Kapsamını Nasıl Belirlersin 

Çoğu pazaryeri uygulaması özellik setinden değil sıralamadan çöküyor. Bir tarafı bilinçli olarak tohumlayan bir ilk sürüm, ikisine birden açılıp ortada buluşmalarını uman bir sürümden daha iyi. 

• İşlem modelini önce seçin, çünkü bir dizin ile tam bir rezervasyon akışı aynı ekranların farklı versiyonları değil, gerçekten farklı build'ler 

• Lansmandan önce hangi tarafın tohumlanacağına karar verin, çünkü arz neredeyse her zaman önce gelmeli; henüz rezerve edilecek hiçbir şeyi olmayan müşterilere yönelik bir pazarlama atağından çok, bir avuç gerçek sağlayıcı daha önemli 

• Güven sinyalini, değerlendirme, doğrulama veya ikisini de, geniş çapta açılmadan önce tasarlayın, çünkü işlem yapan iki yabancı tipik bir sosyal uygulamanın herhangi bir tarafından daha fazla güvenceye ihtiyaç duyar 

Her iki tarafa aynı anda açılan ekipler, genelde lansmandan sonra da arzı manuel olarak toplamak zorunda kalıyor; bu, boş bir sağlayıcı listesi ilk gelen müşterilere uygulamayı bozuk gibi gösterdiğinde oluyor. 

Gerçekçi Bir Geliştirme Takviminin Görünümü 

Bu kategorideki teslim edilen örnekler dört ile altı ay sürdü ve bu pencereyi dört aşama oluşturuyor. 

• Keşif ve kapsam belirleme, ekibin herhangi bir ekran tasarlanmadan önce işlem modelini, güven sinyallerini ve tohumlama planını kilitlediği aşama 

• Ana geliştirme, takvimdeki en büyük blok, profillerin, arama veya filtrelemenin ve mesajlaşma veya rezervasyonun o kilitli kapsam üzerinde bir araya geldiği aşama 

• İki taraflı test, her iki rolü de oynayan tek bir ekip üyesi yerine gerçek sağlayıcılar ve gerçek müşterilerle yürütülür, çünkü güven dinamikleri yalnızca gerçek yabancılar arasında ortaya çıkıyor 

• Lansman ve izleme, canlıdaki ilk birkaç hafta, tohumlama planının gerçek arz ve gerçek talebin gerçekten buluşup buluşmadığına karşı test edildiği dönem 

Gerçek iki taraflı test yapmayı atlamak, iç bir yürüyüşte dengeli görünen bir pazaryerinin her iki taraftan gerçek kullanıcılar geldiği anda dengesiz hissetmesinin en yaygın sebebi.

Bütçeyi ve Süreyi Belirleyen Dört Faktör 

Bir pazaryeri uygulamasının bütçesini en çok bu dört faktör belirliyor: 

• Kategori genişliği, çünkü Yaya bir platformda bakıcı, özel ders veren, temizlikçi ve wellness koçunu destekliyor, bu da uygulama içi ödeme olmadan bile kapsam ekledi 

• Ödeme ve emanet karmaşıklığı, çünkü Hey Gorgeous'ın yaptığı gibi kapora ve tam ücret yönetmek, mesaj tabanlı bir dizinin hiç ihtiyaç duymadığı gerçek geliştirme süresi ekliyor 

• Doğrulama derinliği, çünkü ev içi yardım gibi güvene dayalı kategoriler genelde bir güzellik randevusundan daha derin sağlayıcı incelemesi istiyor 

• İşlemin uygulama içinde mi kalacağı yoksa ilk iletişimden sonra platform dışına mı taşınacağı, çünkü bu karar tek bir özelliği değil tüm para kazanma modelini şekillendiriyor 

Hey Gorgeous dört ayda tam ödemeyle ama tek bir hizmet kategorisiyle lansmana çıktı. Yaya ise uygulama içi ödeme olmadan ama dört sağlayıcı kategorisiyle altı ay sürdü. Bu ikisi için asıl belirleyici ödeme karmaşıklığı değil kategori genişliğiydi. Bu, bir ekip ödeme entegrasyonunun otomatik olarak daha zor problem olduğunu varsayarsa kolayca gözden kaçabilir. 

Geliştirme Ücretinin Dışında Kalan Maliyetler 

Geliştirme ücreti uygulamayı kapsar. Sonrasında çalıştırma maliyeti neredeyse tamamen işlemin gerçekte nerede gerçekleştiğine bağlı. 

• Ödeme işleme ücretleri, Hey Gorgeous'ınki gibi tam rezervasyon modelinde her işlemde gerçek bir yüzde kesintisi, Yaya'nınki gibi bir dizin modelinde ise buna eşdeğer hiçbir maliyet yok 

• Doğrulama ve geçmiş kontrolü maliyetleri, her yeni sağlayıcı için tekrarlanıyor ve kategorinin güven hassasiyetine göre ölçekleniyor 

• Müşteri desteği ve anlaşmazlık çözümü, rezervasyon modelinde işlem hacmiyle büyüyor, dizin modelinde ise uygulama ödemeyi değil sadece iletişimi kolaylaştırdığı için daha hafif kalıyor 

Bir dizin modeli çalıştırması daha ucuz ama ürünün kendisine gömülü açık bir gelir kalemi yok. Bir rezervasyon modeli çalıştırması daha maliyetli ama işlem ücreti zaten paranın hareket ettiği yerde duruyor. Bu fark, lansmandan sonra para kazanma sorusu nihayet cevaplanmak zorunda kaldığında keşfedilecek değil bilinçli olarak kararlaştırılacak bir şey. 

Bu Uygulamalar Canlıda Nerede Aksıyor 

İki taraflı soğuk başlangıç problemi başlıca risk, ama bir ekibin çözmesi gereken son sorun nadiren o oluyor. 

• Arz tarafında gelmeme veya iptaller, çünkü bir müşterinin tüm pazaryerine olan güveni tek bir sağlayıcıyla yaşadığı kötü bir deneyimde kırılabilir 

• Güven ve güvenlik olayları, ev içi ve çocuk bakımı yardımı gibi kategorilerde başka hemen hemen her pazaryeri türünden daha çok gerçek ağırlık taşıyor 

• Ödeme anlaşmazlıkları, parayı doğrudan yöneten her model için; kapora ve iptallerin ilk gerçek anlaşmazlıktan önce açık bir politikaya ihtiyacı var, sonrasında değil 

• İlk iletişimden sonra platform dışına çıkma, özellikle bir dizin modelinde; bir aile ve bir bakıcı bir kez iletişim bilgisi paylaştıktan sonra tekrar işlem görünürlüğü kaybolabiliyor 

Bunların hiçbiri bir ekip her iki tarafı da meslektaşlarla oynattığında görünmüyor, çünkü meslektaşlar zaten birbirine güveniyor ve testin başarılı olmasını zaten istiyor. Gerçek yabancılar bu ikisini de otomatik olarak sunmuyor. Gerçek para veya gerçek güven söz konusu olduğunda, pazaryeri amaçlandığı gibi kullanılınca ortaya çıkıyor. Bu yüzden gerçek katılımcılarla iki taraflı test, başka hemen hemen her kategoriden daha çok önem taşıyor. 

Teslim Ettiğimiz Hizmet Pazaryeri Uygulamaları 

Neon Apps, her biri farklı bir hizmet türüne uyan farklı işlem modelleriyle pazaryeri deneyimleri geliştirdi. 

Yaya, Hey Gorgeous ve Treffpunkt aynı yelpazenin üç farklı noktasında duruyor; en hafif eşleştirme katmanından tam işlemli bir rezervasyon akışına kadar. Yaya, BAE'de ev içi işe alımdan acente aracısını çıkarıyor; ailelerin dört kategori boyunca bakıcıları aramasına, filtrelemesine ve doğrudan mesajlaşmasına izin veriyor, değerlendirmeler tekrarlı kullanımla güven inşa ediyor. Hey Gorgeous tüm rezervasyon yolculuğunu, bulma, rezerve etme, ödeme ve geri dönme, birkaç dokunuşa sıkıştırıyor. Kapora sistemi sağlayıcılar için gelmemeleri ölçülebilir şekilde azalttı, hatırlatmalar da müşteri tarafında aynısını yaptı. Treffpunkt modelin en hafif versiyonunu seçti; pazaryeriyi ana ürün olarak kurmak yerine mevcut bir futbol topluluğuna bir transfer pazarı ekledi. Bu seçim kapsamını topluluğun kendisine odaklı tuttu, pazaryeri özelliği zaten var olan bir kitlenin üzerine bindi. SaaS platform geliştirme sürecini bir hizmetin gerçekte hangi işlem derinliğine ihtiyaç duyduğu etrafında planlamak her build'i doğru kapsamda tuttu. Üçünden hiçbiri sadece tanıdık bir kalıp olduğu için tam bir ödeme akışına varsaymadı.