26 Kas 2025·8 dk
Topluluk Kaynak Paylaşımı için Bir Mobil Uygulama Nasıl Oluşturulur
MVP özelliklerinden UX’e, güven, ödemeler ve büyümeye kadar topluluk kaynak paylaşımı için mobil uygulamayı nasıl planlayıp yayınlayacağınızı öğrenin.
MVP özelliklerinden UX’e, güven, ödemeler ve büyümeye kadar topluluk kaynak paylaşımı için mobil uygulamayı nasıl planlayıp yayınlayacağınızı öğrenin.
Bir topluluk paylaşım uygulaması, belirli bir grup insan için gerçek, yerel bir sorunu çözdüğünde başarılı olur. Özellikleri düşünmeden önce, hizmet edeceğiniz topluluğu ve onlara günlük olarak hangi sorunu çözdüğünüzü adlandırın. "Şeyleri paylaş" belirsizdir; "mahallede 30 dakika içinde bir matkap ödünç almak" ise net bir vaattir.
Ulaşıp destekleyebileceğiniz tek bir topluluk seçin. Yaygın başlangıç noktaları arasında tek bir mahalle, bir üniversite kampüsü veya birden çok ofisi olan bir işyeri bulunur. Her birinin farklı normları ve pratik ihtiyaçları vardır:
Başlangıçtaki topluluğunuz ne kadar sıkıysa, listelemeleri başlatmak, güven oluşturmak ve erken geri bildirim almak o kadar kolay olur.
İnsanların önce ne paylaşacağını belirleyin. Aletler, kitaplar, yolculuklar ve alanlar hepsi geçerli—ama her şeyi başlatmayın. Odaklanmış bir kategori, işe alıştırmayı kolaylaştırır ve kenar durumları azaltır.
Faydalı bir kural: yaygın, ara sıra ihtiyaç duyulan ve geri verilmesi kolay öğelerle başlayın. Örneğin, “aletler ve küçük ev ekipmanları” genellikle “yüksek değerli elektronikler” veya “uzun süreli mekan kiralamaları”ndan daha basittir.
Bir yılı değil, haftalar içinde ölçebileceğiniz bir başarı metriği tanımlayın. Bir kaynak paylaşım mobil uygulaması için başarı şunlar olabilir:
Birincil bir metrik seçin ve diğer her şeyi destekleyici olarak ele alın.
Kısıtlar, ilk sürümünüzün en iyi halini şekillendirir. Göz ardı edemeyeceklerinizi yazın:
Burada dürüst olmak, şişkin bir planı önler ve uygulama MVP kontrol listenizi gerçekçi tutar.
Ekran taslağı çizmeden veya teknoloji yığını seçmeden önce gerçekten bir ihtiyaç olduğunu kanıtlayın—ve farklı insanlar için “ihtiyaç”ın ne anlama geldiğini öğrenin. Bir topluluk paylaşım uygulaması, mevcut topluluk davranışına uyduğunda ve paylaşmayı yorucu yapan sürtünmeleri kaldırdığında başarılı olur.
Ödünç verenler, ödünç alanlar ve organizatör/moderatörler (HOA gönüllüleri, kütüphane personeli veya mahalle liderleri gibi) ile konuşun. Her grup farklı bir şeyi optimize eder:
Görüşmeleri kısa tutun (15–30 dakika) ve gerçek hikayelere odaklanın: “En son yerel olarak bir şey ödünç almaya çalıştığınız zamanı anlatın.” Somut örnekler, uygulamanızın desteklemesi gereken gizli iş akışını ortaya çıkarır.
Çoğu topluluk zaten paylaşır—sadece zarif değil. Bugün neye güvendiklerini belgeleyin: mahalle sohbet grupları, tablolar, kağıt imza formları, ilan panoları veya “bir arkadaşa sor” ağları. Amaç bunları kopyalamak değil; insanların neyi sevdiğini (hız, tanıdıklık) ve neyin kırıldığını (takip, hesap verebilirlik) tespit etmektir.
Tasarım yapabileceğiniz tekrarlayan problemlere bakın:
Uygulamanız bu sorunlardan en az birini belirgin şekilde azaltamıyorsa, benimseme zor olacaktır.
Talep sadece “Bunu kullanır mısınız?” değildir. Asıl soru “Ne sıklıkla kullanırsınız ve sizi ne durdurur?” olmalıdır. Şunları sorun:
Haftalık kullanacak birkaç istekli üye, “bir gün denerim” diyen çok sayıda kişiden genellikle daha değerlidir.
Öğrendiklerinizi, MVP'nizi yönlendirecek net, test edilebilir kullanıcı hikayelerine çevirin.
As a lender, I want to set pickup windows and rules so I don’t have to negotiate every time.
As a borrower, I want to see real availability and location so I can plan confidently.
As an organizer, I want a way to handle reports so disputes don’t derail the community.
Bu hikayeler, yap-ve-test kontrol listeniz olur—ekibinizi sadece demo'da iyi görünen özelliklerden değil, gerçek topluluk sonuçlarından odaklı tutar.
Özellikleri düşünmeden önce, hangi tür paylaşımı etkinleştirdiğinize karar verin. Seçeceğiniz model her şeyi şekillendirir: profiller, listelemeler, rezervasyon kuralları, ödemeler ve anlaşmazlıkların nasıl ele alınacağı.
Yaygın seçenekler şunlardır:
Bir modelle başlayıp sonra genişleyebilirsiniz, ancak MVP'de birkaç modeli karıştırmaktan kaçının—bu deneyimi ve desteği karmaşıklaştırır.
İki ana yol vardır:
Ne rezervasyona alınacak açıkça belirtin:
Her bir birim farklı takvim kuralları ve teslim adımları gerektirir.
Her yerde geçerli basit varsayılanlar yazın: ödünç süresi, uzatma istekleri, tolerans süreleri ve geç iade durumunda ne olacağı. Bu kurallar, borç alan onaylamadan önce görünür olmalıdır.
Niyetten teslimata en kısa yolu haritalayın:
Gözat/Arama → Detayları görüntüle → Uygunluğu kontrol et → İste/Rezervasyon → Onayla → Teslim alma/bırakma düzenle → İade/Tamamla → Puan/Şikayet
Akışınız bir sayfaya sığmıyorsa, inşa etmeden önce basitleştirmeniz gerektiğinin işaretidir.
Bir topluluk paylaşım uygulaması için MVP “daha küçük bir uygulama” değildir. En küçük ürün, tam döngüyü tamamlamalıdır: biri bir öğe listeler, bir komşu bulur, teslimat için anlaşırlar ve her iki taraf da yeniden yapmaya yeterince olumlu hisseder.
İlk başarılı paylaşımın sürtüncesini doğrudan kaldıran özelliklere odaklanın:
Daha hızlı ilerlemek istiyorsanız ama kapsamı kesmek istemiyorsanız, yineleme için optimize edilmiş bir inşa yaklaşımı kullanın. Örneğin, Koder.ai gibi platformlar sohbet içinde bu akışları tanımlayıp hızla çalışan bir uygulama oluşturmanıza yardımcı olabilir; ardından Planlama Modu, anlık görüntüler ve rollback ile rafine edebilirsiniz—haftalık değişen MVP'ler için kullanışlıdır.
İnsanların “evet” demesine yardımcı olan hafif önlemler ekleyin:
Yerel kısıtlar paylaşımı gerçekçi kılar:
Modeliniz hemen gerektirmiyorsa erteleyin:
MVP'niz 20–50 gerçek değiş tokuşu güvenilir şekilde destekleyemiyorsa, ölçeklenmeye hazır değildir.
Bir topluluk paylaşım uygulaması, zahmetsiz hissettirdiğinde başarılı olur. İnsanlar “alışveriş” yapmıyorlar—akşam yemeğinden önce bir merdiven ödünç almak veya okul sonrası bir puset vermek istiyorlar. UX'iniz sürtünmeyi kaldırmalı, belirsizliği azaltmalı ve bir sonraki adımı kolayca görünür kılmalıdır.
Gezinmeyi küçük bir birincil alan setiyle tahmin edilebilir tutun:
Bu bilgi mimarisi, kullanıcıların kas hafızası geliştirmesine ve düşünmeden bulmasına yardımcı olur.
Listelemeler uygulamanızın “envanteri”dir—oluşturmalarını hızlı yapın:
Listeleme akışının mesaj gönderir gibi fotoğrafla birlikte hızlı hissettirmesini hedefleyin; uzun bir form dolduruyormuş hissi vermesin.
Okunabilir metin, güçlü kontrast ve açık dokunulabilir butonlar zorunludur. Belirsiz etiketler yerine açık ifadeler kullanın (“Ödünç iste”) ve yalnızca renge güvenmeyin.
Teslimatlar genellikle garajlar, bodrumlar veya bina lobilerinde olur. Önemli ayrıntıları lokal olarak önbelleğe alın: paylaşılan adres, kararlaştırılan saat, öğe fotoğrafları ve basit bir teslim kontrol listesi. Mesaj gönderimini dayanıklı hale getirip bağlantı tekrar geldiğinde sıraya alınmasını sağlayın.
Çekirdek akışları Figma (veya benzeri) ile prototipleyin: gözat → öğe sayfası → istek → sohbet → onay. Birkaç gerçek komşuyla test edin, tereddüt ettikleri noktaları izleyin ve akış bariz olana dek yineleyin.
Bir topluluk paylaşım uygulaması, komşuyla merdiven ödünç vermekten memnuniyet duyulduğunda çalışır. Güven bir “ek özellik” değil; ürünün parçasıdır.
Profilleri dostane ve insanımsı tutun: isim, fotoğraf, kısa biyografi ve mahalle (veya sınırlı alan göstergesi). “Üyelik tarihi”, yanıt oranı ve tamamlanan teslimatlar gibi hafif güven sinyalleri ekleyin.
Bir iyi kural: güven oluşturmak için yeterli bağlam gösterin, ama aşırı paylaşmaktan kaçının. Mahalle düzeyinde konum genellikle tam adresten daha güvenlidir.
En azından e-posta ve telefon doğrulaması sağlayın. Yüksek güven gerektiren kategoriler için isteğe bağlı kimlik kontrolleri düşünebilirsiniz. Uygulamanız gerçek topluluklara bağlıysa, davetle katılma desteği sağlayın (örn. “doğrulanmış bir üyenin daveti” veya “topluluk kodu ile katıl”).
Doğrulamanın faydalarını net yapın: doğrulanmış üyeler daha yüksek borçlanma limitleri, hızlı onaylar veya özel rozetler alabilir.
Her ödünç/veriş sonrası her iki tarafı da hızlı bir puan ve kısa bir yorum yapmaya teşvik edin. Basit ve belirli tutun: “Öğe durumu”, “Zamanında teslim”, “İletişim”.
Sürekli olumlu davranış için rozetler ekleyin (yardımsever veren, güvenilir alan, hızlı yanıtlayan). Rozetler satın alınamaz, kazanılmalıdır.
Kullanıcıları engelleme, sorunları raporlama ve profil detaylarını kimlerin görebileceğini kontrol etme işlemlerini tek dokunuşla yapmayı sağlayın. Teslim akışı içinde buluşma yönergeleri sağlayın (kamuya açık yerler, gündüz buluşmaları, bir arkadaşla gelme, ayrıntıları uygulama içinde onaylama).
Kayıt sırasında—hiçkimse listelemeden önce—açık kurallar gösterin. Kısa, spesifik ve uygulanabilir tutun (yasaklı öğeler, saygılı iletişim, dakiklik ve bir rapordan sonra ne olacağı). Hafif bir “Kabul ediyorum” adımı beklentileri erkenden belirler.
Bu, birinin bir öğeyi keşfettiği, kuralları anladığı, bir zaman için rezerve ettiği ve her iki tarafın da minimum kafa karışıklığıyla teslimatı tamamladığı işlem çekirdeğidir.
İyi bir listeleme karşılıklı mesajlaşmayı azaltır. Birden fazla fotoğraf, net bir kategori ve basit bir durum seçici (örn. Yeni / İyi / Aşınmış) ekleyin. Teslim seçenekleri (veranda teslimi, yakında buluşma, bina lobisi) ve herhangi bir kuralı (kimlik gerekli, temizlik beklentileri, geç iade ücreti varsa) belirtin.
Küçük ama faydalı dokunuşlar: boyut/ağırlık notları, nelerin dahil olduğu (şarj cihazı, kılıf, aksesuarlar) ve “uygun değil” uyarıları.
Bir uygunluk takvimi çifte rezervasyonu önler. Sahiplerin rezervasyon pencerelerini ayarlamasına izin verin (örn. minimum 2 saat, maksimum 3 gün), ödünçler arasında tampon süre ve ön bildirim süresi (örn. “en az 4 saat önce rezerve edin”).
İstekte bulunmayı amaç, tarihler, teslim tercihi ve borçlunun kuralları kabul ettiğini onaylayan bir mesaj şablonu ile hızlı hale getirin.
Sahipler bir dokunuşla kabul/reddedebilmeli ve isteğe bağlı olarak yeni zamanlar önerebilmelidir. Teslim alma ve iade için hatırlatmalar ekleyin ve iade sonundan önce otomatik bir “hala yolunda mı?” kontrolü sağlayın.
Teslim ve iade sırasında hafif bir giriş/çıkış akışı kullanın: zaman damgası, konum ve öğe durumunun fotoğrafları. Temiz, parça kontrolü gibi kısa bir kontrol listesi yanlış anlamaları önler.
Bir şey ters gittiğinde, kullanıcıları raporlama sürecinden geçirin: bir sorun türü seçin, fotoğraf ve not ekleyin ve istedikleri çözümü belirtin (onarım, değişim, kısmi iade gibi). Basit bir durum izleyicisi ve beklenen yanıt sürelerini gösterin.
Bir topluluk paylaşım uygulaması iletişime bağlıdır. Zamanında varış, durum ve teslim detayları konusunda hızlı anlaşamıyorsanız talepler takılır ve güven erozyona uğrar. Amaç koordinasyonu zahmetsiz kılmak—uygulamayı gürültülü bir sohbet uygulamasına çevirmeden.
Kullanıcıların telefon numarası paylaşmasına gerek kalmadan yerleşik mesajlaşma sağlayın. Nazik güvenlik uyarıları (ör. kişisel iletişim bilgilerini paylaşma uyarısı) ekleyin ve e-posta/telefon gibi kalıpları algılayıp göndermeden önce kullanıcıyı uyarmayı düşünün.
Sohbeti işle üzerinde odaklayın:
Bildirileri bir sonraki adımı açan anlar için kullanın:
Kullanıcıların sıklığı kontrol etmesine izin verin (tümü, yalnızca önemli, yok) böylece aşırı bildirim yüzünden uygulamayı bırakmazlar.
İnsanların sürekli tekrar yazdığı güncellemeleri otomatikleştirin:
Bu durum olayları sohbet zaman çizelgesinde sistem mesajı olarak görünmelidir. Her iki tarafı da hizalar ve anlaşmazlık durumunda açık bir geçmiş sağlar.
Sohbetlerde, profillerde ve listelemelerde basit bir “Şikayet et” eylemi ekleyin. Şikayetler moderasyon gelen kutusuna kontekstle (mesajlar, rezervasyon zaman çizelgesi, önceki şikayetler) düşmeli ve açık eylemler sunmalıdır: uyarı, mesajlaşmayı kısıtlama, listeyi gizleme veya askıya alma.
Tutma için favoriler ve kaydedilmiş aramalar ile “bu öğeyi tekrar listele?” hatırlatmaları ekleyin.
Her topluluk paylaşım uygulaması ödemeye ihtiyaç duymaz. Eğer komşular ücretsiz ödünç veriyorsa, para sürtünme ekler. Ancak ücretli kiralamalar, güvenlik depozitoları veya operasyonları desteklemek için üyelik ücretleri gerekiyorsa ödemeler önem kazanır.
Başlangıçta tek bir net model seçin:
İlk sürümde hepsini bir arada kullanmaktan kaçının.
İnsanlar bir istekte bulunmadan önce maliyeti anlamalı. Basit bir kırılım gösterin:
Listedeki görünen fiyat, ödeme ekranında bekledikleriyle eşleşmeli—sürpriz ek ücretler olmamalı.
Ödemeler “ikinci aşama” olsa bile, MVP planlarken bir sağlayıcı seçin. Sağlayıcı kararları ürün kararlarını etkiler:
Daha sonra değişmek zor olabilir; kayıtlı ödeme yöntemlerini veya işlem geçmişini taşımanız gerekebilir.
İlk aşamada manuel uygulanabilecek basit kurallar yazın:
Açık politikalar, mesajlardaki tartışmaları azaltır ve moderatörlerin tutarlı karar vermesini sağlar.
Para el değiştiriyorsa, vergi, KYC/kimlik kontrolleri veya tüketici koruma kuralları için yerel gereksinimleri doğrulayın. Kısa bir muhasebeci veya hukukçu görüşmesi ileride pahalı yeniden işlerden kaçındırır.
Teknoloji seçimleriniz hızlı yinelemeyi, güvenli veri işlemini ve moderasyon/destek/güncellemeler gibi günlük gerçekleri desteklemeli. “En iyi” yığın genellikle ekibinizin yıllarca sürdürebileceği olan yığındır.
En akıcı performans ve platforma özgü UI gerekiyorsa native tercih edin (iOS için Swift, Android için Kotlin). Tek kod tabanında hızlı başlamak istiyorsanız çapraz-platform (Flutter veya React Native) seçin. Çoğu topluluk paylaşım uygulaması için profiller, listelemeler, sohbet, rezervasyon gibi özelliklerde çapraz-platform güçlü bir seçimdir.
Bir MVP bile genellikle birkaç güvenilir backend bileşeni gerektirir:
Managed platformlar (Firebase, Supabase, AWS Amplify) kurulum süresini kısaltırken, özel API (Node.js/NestJS, Django, Rails) karmaşık kurallar gerektiğinde daha fazla kontrol sunar.
Koder.ai gibi modern varsayımlarla daha hızlı yayın hedefliyorsanız, React web, Go backend ile PostgreSQL ve kaynak kodu dışa aktarımı, barındırma ve dağıtım iş akışları hızlandırıcı olabilir.
İlk günden moderasyon, kategori yönetimi ve kullanıcı desteği için bir yönetici aracı planlayın. Başlangıçta Retool/Appsmith gibi hafif iç panellerle başlayabilirsiniz.
Güvenli kimlik doğrulama (e-posta bağlantıları, OAuth veya iyi uygulanmış şifreler), giriş ve mesajlaşmada oran sınırlamaları, HTTPS zorunluluğu ve gerektiğinde hassas verileri şifreleme uygulayın. Kötüye kullanım soruşturmaları için önemli eylemleri loglayın.
Basit bir mimari (genellikle modüler monolit), net veri modelleri ve e-posta/push için arka plan işleri ile başlayın. Büyüme için tasarlayın ama ilk sürümde güvenilirlik ve değişime açıklığı önceliklendirin.
Birden fazla mahalle davet etmeden önce, uygulamanın bir gerçek topluluk için güvenilir şekilde çalıştığından emin olun. Küçük, kapalı bir beta sorunları yönetilebilir tutar ve daha hızlı öğrenmenizi sağlar.
İndirilmeler gibi gösterişçi olmayan, gerçek değeri yansıtan kısa bir metrik seti seçin. Yararlı KPI'ler:
Bu sayılar doğru yönde hareket ediyorsa alışkanlık inşa ediyorsunuz demektir.
Kullanıcıların karar verdiği veya takıldığı yerlere analiz etkinlikleri ekleyin. En azından takip edin:
Bu, basit bir huniyi izler: “öğe bulundu → istendi → alındı → iade edildi → geri bildirim bırakıldı”. Hunide bir kırılma olursa noktayı biliriz.
Nicel veriler ne olduğunu söyler; geri bildirim nedenini söyler. Uygulama içinde hafif seçenekler sunun (teslimattan sonra bir soruluk anket, sorunlar için destek formu). Ardından kısa topluluk geri bildirim oturumları (aylık görüşmeler veya moderatörlü sohbet) planlayın.
Her şeyi aynı anda iyileştirmeye çalışmayın. Kullanıcılar arama yapıyor ama istek göndermiyorsa daha iyi listelere veya daha net uygunluk bilgisine ihtiyacınız olabilir. İstekler teslimata dönüşmüyorsa takvim, hatırlatmalar veya güven sinyallerini güçlendirin. İyileştir, aynı toplulukta tekrar test et ve ancak sonra genişlet.
Bir topluluk paylaşım uygulaması tek seferlik bir “lansman” değildir—güveni tekrar tekrar kazanır. İlk sürümü yaşayan bir program olarak yönetin: net sahipler, haftalık kontroller ve sıkı bir geri bildirim döngüsü olsun.
HOA temsilcileri, kütüphaneciler, karşılıklı yardım organizatörleri gibi topluluk liderleriyle küçük pilotlar yürütün ve yerel ortaklarla (tamir atölyeleri, okullar, toplum merkezleri) işbirliği yapın. Her pilot grubuna ortak bir hedef verin—örn. “30 günde 50 başarılı ödünç alma”—ve tamamlama oranı, yanıt süresi ve tekrarlı kullanım ölçün.
Yeni kullanıcılar ilk dakikada değeri görmeli. Başlangıç listelerini tohumlayın (ekibinizin sahip olduğu veya ortaklardan bağışlanan öğeler) ve bir hoş geldin kontrol listesi verin:
24 saat içinde bir duraklama olursa nazik bir teşvik gönderin ve ilk başarılı teslimatı kutlayın.
Amacınızın davetlerle ilgi çekmek olmasına odaklanın: “3 komşunu davet et, daha fazla öğeye erişim aç” gibi. Davetleri temalı etkinliklerle eşleştirin (“Merdiven Haftası”, “Okula Dönüş Malzemeleri”) ve yerel etkinliklerde insanlar anında liste ekleyebilsin.
Eğer referans çalıştırıyorsanız, bunları ölçülebilir ve yönetmesi kolay yapın (benzersiz bağlantılar, net ödüller).
Kısa SSS yayınlayın ve yanıt süre beklentilerini belirleyin. Gelmeme, anlaşmazlık ve güvenlik sorunları için yükseltme kuralları tanımlayın. Basit bir “şikayet → 24 saat içinde inceleme” vaadi güveni artırır.
Mahalle bazında, sonra kategori bazında genişleyin. Temel metrikler yerinde (yüksek tamamlama oranı, düşük şikayet oranı) olmadığı sürece özellik eklemeyin. “Daha sonra” için bir backlog tutun ve büyürken sadeliği koruyun.
Belirli, yerel bir soruna bağlı bir vaatle başlayın (örn. “mahallemde 30 dakika içinde bir matkap ödünç al”). Sonra ulaşılabilir bir topluluk seçin (tek bir mahalle, kampüs veya işyeri) ve hızlıca liste ekleyip öğrenebilmek için bir ilk kaynak kategorisi seçin (araçlar, kitaplar, çocuk eşyaları gibi).
Dar bir toplulukla başlamak şunları kolaylaştırır:
İlk topluluk istikrarlı değişimler gösterdikten sonra yakındaki mahallelere veya yeni gruplara genişleyebilirsiniz.
İlk etapta yaygın, ara sıra ihtiyaç duyulan ve geri verilmesi kolay öğelerle başlayın (çoğu zaman araçlar ve küçük ev aletleri uygundur). Çekirdek döngü çalışana kadar yüksek değerli elektronikler veya uzun dönem mekan kiralamaları gibi kenar durumlar yaratacak kategorilerden kaçının.
Üç grubu görüşün:
Görüşmeleri 15–30 dakika tutun ve “Yerel olarak en son ne ödünç almaya çalıştığınızı anlatın” gibi gerçek hikayelere odaklanın.
İnsanların halihazırda kullandıklarını belgeleyin (sohbet grupları, tablolar, ilan panoları, “bir arkadaşına sor” ağları). Kopyalamayın; bunun yerine şunu belirleyin:
Uygulamanız, koordinasyon yükü veya “görünmezlik” gibi tekrarlayan bir sürtünmeyi ciddi şekilde azaltmalı.
MVP için bir modeli seçin:
Erken aşamada modelleri karıştırmaktan kaçının—her ek model UI, kural ve destek iş yükünü artırır.
Tam döngüyü tamamlayan bir MVP gerekiyor:
Kullanıcılar 20–50 gerçek değiş tokuşu güvenilir şekilde yapamıyorsa, ölçekleme için erken sayılır.
Kayıt sırasında süreci zorluk çıkaracak şekilde sertleştirmeden güven inşa edin:
Yüksek riskli kategoriler için daha güçlü doğrulamalar yalnızca gerektiğinde eklenmeli.
Sohbet uygulama içinde kalsın ve koordinasyonu destekleyin:
Kullanıcıların bildirim sıklığını kontrol etmesine izin verin, böylece aşırı bildirimten dolayı uygulamayı bırakmazlar.
Pilot topluluğunuzu genişletmeden önce şu KPI'leri izleyin:
Arama, istek, kabul/reddetme, teslim alma, iade, inceleme gibi ana huni olaylarını ölçümlendirip en büyük düşüş noktalarını düzeltin.