Talep Üzerine Hizmet Uygulaması Geliştirin: Temizlik ve Tamir Rehberi

Talep Üzerine Hizmet Uygulaması Gerçekte Nedir?

Bir on-demand hizmet uygulaması, gerçek dünya görevleri için bir rezervasyon ve yerine getirme ürünüdür—ev temizliği, beyaz eşya tamiri, el işçiliği ve devam eden bakım gibi. “On-demand” her zaman “hemen” demek değildir. Çoğu zaman, müşterilerin hızlıca hizmet talep edebilmesi, net bir fiyat veya tahmin görebilmesi ve karşılıklı telefon görüşmeleri olmadan onaylanmış bir zaman aralığı sağlaması anlamına gelir.

İki taraflı bir ürün: sadece müşteri uygulaması değil

Başarılı on-demand hizmet uygulamalarının çoğu iki taraflıdır:

• Müşteriler hizmetlere göz atar, bir zaman seçer, öder ve işi takip eder.
• Hizmet sağlayıcılar işleri kabul eder, programları yönetir, görevleri tamamlar ve ödeme alır.

Küçük bir sağlayıcı ekibiyle başlasanız bile, sağlayıcı tarafına yönelik araçlara (genellikle hafif bir uygulama veya web portalı) ve operasyonları kontrol altında tutmak için bir yönetici paneline ihtiyacınız olacaktır.

Beklentiyi ayarlayın: önce MVP, sonra genişleyin

Her özelliği aynı anda sunmak cazip gelebilir—abonelikler, kuponlar, rota optimizasyonu, birden fazla hizmet kategorisi. Temizlik uygulaması geliştirme veya tamir hizmeti uygulaması için, temel odaklı bir mobil uygulama MVP ile daha hızlı ilerlersiniz; kullanıcıların gerçekten ne yaptığını öğrenin ve karmaşıklığı yalnızca işe yaradığı yerde ekleyin.

Ana yapı taşları

Temizlik veya tamir için bir rezervasyon ve zamanlama uygulaması oluşturuyor olun, temel parçalar genellikle şunlardır:

• Rezervasyon: hizmet seçimi, adres, zaman aralıkları, iş detayları
• Ödemeler: kart ödemeleri, iadeler, bahşişler, faturalar
• Yönlendirme/eşleştirme: sağlayıcıları manuel veya otomatik atama
• İncelemeler: tamamlandıktan sonra değerlendirme ve geri bildirim
• Yönetici paneli: siparişler, sağlayıcılar, fiyatlandırma, müşteri desteği yönetimi

Bu bloklar temel “talep et → onayla → tamamla → öde → değerlendir” döngüsünü oluşturur; zaman içinde rafine edebilirsiniz.

Nişinizi Seçin ve Talebi Doğrulayın

Başarılı bir on-demand hizmet uygulaması, “herkes için her şey” değil, küçük ve net bir vaatte başlar. Hizmeti standartlaştırabileceğiniz ve tutarlı kalite sunabileceğiniz dar bir niş seçin.

Dar, tekrarlanabilir bir hizmetle başlayın

İyi başlangıç noktaları arasında standart ev temizliği (1–3 odalı paketler) veya küçük beyaz eşya tamiri (çamaşır makinesi, bulaşık makinesi, mikrodalga) bulunur. Bu alanlar iyidir çünkü nelerin dahil olduğunu tanımlayabilir, süre tahmini yapabilir ve net fiyatlandırma belirleyebilirsiniz.

Kendinize sorun: hizmeti istisnasız bir cümleyle tanımlayabiliyor musunuz? Hayırsa, daraltın.

Hizmet alanınızı ve müsaitliği tanımlayın

Özellikleri inşa etmeden önce nerede çalışacağınızı belirleyin:

• Şehir + bölgeler (ör. “Şehir Merkezi, Kuzey, Batı”) ve farklı seyahat ücretleri
• Sağlayıcı merkezinden seyahat yarıçapı
• Çalışma saatleri ve kesme saatleri (ör. aynı gün rezervasyonlar sadece 11:00 öncesi)

Bu, kullanıcıların uygulamayı bir kez denedikten sonra “Sağlayıcı yok” yüzünden erken kaybını önler.

Müşteri segmentleri ve sorun noktalarını belirleyin

1–2 birincil segment seçin ve onların en çok neye değer verdiğine göre tasarlayın:

• Yoğun aileler: öngörülebilir zamanlama, güvenilir sağlayıcılar, yeniden rezervasyon
• Kiracılar/genç profesyoneller: hızlı rezervasyon, şeffaf fiyatlar, kolay başlangıç
• Ev sahipleri/portföy yöneticileri: çoklu birim zamanlaması, faturalar, tekrar eden işler

Hedef segmentinizden 10–15 kişiyle görüşün. Son yardım alma deneyimlerine odaklanın: ne canlarını sıktı, ne ödediler ve neyi değiştirirlerdi.

Rakipler: düzeltebileceğiniz şikayetleri bulun

3–5 doğrudan rakip (uygulamalar ve yerel hizmetler) listesi çıkarın. Google, App Store, Yelp ve Reddit yorumlarını inceleyin. Basit bir tablo hazırlayın: “Şikayet” → “Bunu nasıl düzelteceğiz.” Yaygın temalar arasında geç kalma, belirsiz fiyatlandırma, zayıf destek ve tutarsız kalite bulunur.

Son olarak, talebi hafif bir testle doğrulayın: şehir için bir açılış sayfası + reklamlar ya da tam uygulamayı inşa etmeden önce insanların gerçekten ödeme yapacağını göstermek için manuel bir konserj hizmeti (WhatsApp rezervasyonları) deneyin.

İş Modeli: Pazar Yeri vs. Yönetilen Hizmet

İş modeliniz, müşterilere ne vaat ettiğinizi ve arka planda neyi kontrol etmeniz gerektiğini belirler. Temizlik ve tamir için yaygın iki yaklaşım pazar yeri (bağımsız sağlayıcılar) ve yönetilen hizmet (kendi ekibiniz veya sıkı yönetilen yükleniciler) modelleridir.

Pazar yeri: bağımsız sağlayıcılar

Müşterileri onaylanmış profesyonellerle bağlarsınız; sağlayıcılar müsaitliklerini belirler ve işi kendi kimlikleri altında tamamlar (uygulamada markanız öne çıksa bile).

Genellikle her işten bir komisyon alırsınız (ör. %10–25) ve olası rezervasyon ücretleri eklenebilir. Bu model daha hızlı ölçeklenebilir, ancak onboarding ve yaptırımlar zayıfsa kalite değişken olabilir.

Yönetilen hizmet: kendi ekibiniz

Hizmeti kendi operasyonunuz olarak satarsınız: standartları siz belirlersiniz, çalışanları eğitir ve genellikle yeniden işler ve müşteri desteğini daha doğrudan ele alırsınız. Gelir işin tam fiyatıdır; maliyetler işçilik, malzeme ve operasyonları içerir.

Bu, özellikle tekrar eden temizlikte daha tutarlı sonuçlar verebilir, ancak operasyonel olarak daha ağırdır: zamanlama, kapsama ve son dakika yer değişiklikleri sizin sorumluluğunuz olur.

Fiyatlandırma: sabit, saatlik veya teklif bazlı

• Sabit paketler (ör. “2+1 odalı detaylı temizlik”) hızlı ödeme ve öngörülebilir beklentiler için iyidir.
• Saatlik esnek işler için uygundur, ancak müşteriler fazla süre endişesi yaşayabilir—açık minimumlar ve süre takibi kullanın.
• Teklif bazlı tamirler için en uygunudur (bilinmeyen parça/zaman). Basit tutun: fotoğraf + belirti toplayın, sonra bir aralık verin veya incelemeden sonra onaylayın.

Sağlayıcı onboarding ve güven

Onboarding’i mini bir uyumluluk akışı gibi planlayın: kimlik ve belge toplama, gerekliyse adli sicil kontrolleri, sigorta doğrulama ve hizmet standartları, iletişim ve güvenlik üzerine kısa eğitim.

Ücretler, iptaller ve ödemeler (yüksek seviye)

Komisyon oranınızı, müşteri rezervasyon ücretinizi ve sağlayıcı ücretlerini (opsiyonel) tanımlayın. Açık bir kesme saati ile iptal kuralları belirleyin (ör. X saat içinde ücretsiz, ardından ücret). Ödemeler için zamanlamayı (anında vs. haftalık) ve iadeler/chargeback’ler için tutulacak tutarları belirleyin, böylece nakit akışı dengeli kalır.

Kullanıcı Roller ve Gerekli Ürünler

Bir on-demand hizmet uygulaması sadece “tek bir uygulama” değildir. Rezervasyonları güvenilir (ve desteklenebilir) kılmak için genellikle üç ürün gerekir: bir müşteri deneyimi, bir sağlayıcı deneyimi ve bir yönetici çalışma alanı. Her rolün farklı hedefleri ve ekranları vardır.

1) Müşteri uygulaması (alıcı)

Müşteri uygulaması üç soruyu yanıtlamayı kolaylaştırmalıdır: Ne rezerve edebilirim? Ne zaman? Ne kadar?

En azından müşteriler hizmetlere göz atabilmeli (ör. detaylı temizlik, musluk tamiri), açık fiyatlandırma veya tahminler görebilmeli, bir zaman aralığı seçebilmeli ve uygulama içinden ödeme yapabilmelidir. Rezervasyondan sonra, sipariş takibi ("onaylandı", "yolda", "devam ediyor" gibi durum güncellemeleri), destek ile iletişim kurma ve sağlayıcıyı derecelendirme yollarına ihtiyaçları vardır.

2) Sağlayıcı uygulaması (işçi)

Sağlayıcıların ihtiyacı olan şey hız ve netliktir. Temel akışları: iş al → kabul/ret → adrese git → iş durumu güncelle → işi tamamla → ödeme al.

İyi bir sağlayıcı deneyimi ayrıca uygulama içi sohbet veya arama (gizlilik korumalı), iş detayları (kapsam, fotoğraflar, notlar) ve kazançları, ücretleri ve yapılacak transferleri gösteren bir ödeme görünümü içerir.

3) Yönetici paneli (operatör)

Yönetici paneli işin kontrol altında kalmasını sağlar. Ekibinizin yönetmesini sağlamalıdır:

• Hizmet kataloğu ve ek hizmetler
• Sağlayıcı onboarding, belgeler ve müsaitlik
• Fiyatlandırma kuralları, hizmet alanları ve promosyonlar
• Sipariş gözetimi, anlaşmazlıklar, iadeler ve manuel düzeltmeler
• Müşteri destek araçları (notlar, zaman çizelgeleri, mesaj geçmişi)

Sağlayıcı tarafı web portalı ile başlayabilir mi?

Çoğu zaman evet—bu MVP maliyetini düşürebilir. Küçük bir sağlayıcı havuzuyla başlıyorsanız, duyarlı bir web portalı iş kabulü, durum güncellemeleri ve ödemeler için yeterli olabilir.

Daha sonra, push bildirimleri, navigasyon kısayolları ve çevrimdışı dostu UX gibi özellikler gerekli olduğunda sağlayıcı uygulamasına yükseltebilirsiniz.

Temizlik veya Tamir için MVP Kapsamı

MVP'nizin bir görevi vardır: mümkün olan en az karmaşıklıkla gerçek, ücretli rezervasyonlara uçtan uca izin vermek. Bir müşteri hizmet isteyebiliyorsa, bir sağlayıcı kabul edip tamamlayabiliyorsa ve bir şey ters giderse müdahale edebiliyorsanız—MVP işlevini görür.

MVP hedefini tanımlayın ("tamam" ne demek)

Pratik bir MVP hedefi: 50–200 ücretli siparişi öngörülebilir operasyonla tamamlamak. Bu hacim, müşterilerin gerçekten ne satın aldığını, sağlayıcıların neyi güvenilir şekilde teslim edebildiğini ve süreçte nerede sorun çıktığını öğrenmek için yeterlidir.

Müşteri için zorunlu MVP özellikleri

Müşteri tarafını rezervasyon güvenine odaklayın:

• Kayıt / giriş (e-posta veya telefon)
• Hizmet seçimi (ör. “1+1 temizlik” veya “lavabo tamiri”) ile net fiyat kuralları
• Adres ve temel notlar (giriş talimatları, park, tamir için fotoğraflar)
• Zamanlama (tarih/saat aralığı seçimi)
• Ödeme (kart veya cüzdan) ve makbuz
• Sipariş geçmişi, durum ve destek iletişimi

Sağlayıcı için zorunlu MVP özellikleri

Sağlayıcıların gelmesi ve ödeme alması için basit araçlar:

• Müsaitlik (çalışma saatleri, izin günleri)
• İş kabul/red (sebep seçeneği ile)
• Durum güncellemeleri: yolda → başladı → tamamlandı
• Temel iş detayları: adres, zaman, notlar, müşteri iletişimi (mümkünse maskelenmiş)

Yönetici için zorunlu MVP özellikleri

Yönetici paneliniz erken operasyonlarda “güvenlik ağı”dır:

• İş yönetimi: görüntüle, ata/yeniden ata, iptal et, yeniden planla
• Sağlayıcı yönetimi: onboarding durumu, belgeler, performans notları
• Manuel düzenlemeler: iadeler/indirimler, ödeme düzeltmeleri, denetim için notlar

Sonraya bırakılacaklar (güzel ama gerekli değil)

Bir sonraki rezervasyonu tamamlamaya yardımcı olmayan her şeyi erteleyin:

• Üyelikler, referans programları, basit kupon dışında gelişmiş promosyon motorları
• Dinamik fiyatlandırma ve karmaşık ek hizmetler
• İleri seviye eşleştirme, puana dayalı yönlendirme, çok duraklı rota optimizasyonu
• Uygulama içi sohbet (başlangıçta SMS/e-posta güncellemeleri yeterli olabilir)

İyi bir MVP arka planda biraz manuel çalışabilir, ama müşteri için zahmetsiz ve sağlayıcı için net olmalıdır.

Temel Kullanıcı Akışları ve Basit UX

Harika bir on-demand hizmet uygulaması daha çok özellikle değil, rezervasyonun açık, hızlı ve güvenli hissettirmesiyle kazanır—özellikle küçük ekranda. Herhangi bir “güzel” tasarıma başlamadan önce uçtan uca kullanıcı akışını haritalayın ve işler ters gittiğinde uygulamanın ne yapacağını belirleyin (çünkü gidecektir).

Rezervasyon akışı, adım adım

Ana yolu lineer ve öngörülebilir tutun:

Hizmet → detaylar → zaman → ödeme → onay.

Her adımda sorun: İşi doğru planlamak için minimum hangi bilgiye ihtiyacımız var? Temizlik için bu, oda/banyo sayısı ve malzeme durumu olabilir. Tamir için cihaz türü, arıza belirtileri ve fotoğraflar gerekebilir.

Uygulanabilir bir akış şöyle görünür:

• Hizmet seçin (Temizlik, Sıhhi Tesisat, Elektrik)
• Detay ekleyin (adres, notlar, fotoğraflar, giriş talimatları)
• Zaman seçin (mevcut slotlar, süre tahmini, erken varış bilgisi)
• Ödeyin (kart/cüzdan, promosyon kodu, bahşiş seçeneği varsa)
• Onaylayın (özet, sağlayıcı ETA kuralları, yeniden planlama/iptal politikası)

Net paketler ve ek hizmetler (fiyatı basit tutmak için)

Kullanıcılar toplam maliyeti tahmin edemediklerinde tereddüt eder. Yapıyı yok saymak yerine hizmet paketleri ve ek hizmetler sunun.

Örnekler:

• Temizlik: “Standart Temizlik” vs. “Derin Temizlik”, “Fırın içi” veya “Buzdolabı içi” gibi ekler, “Malzeme getirilsin” seçeneği
• Tamir: “Teşhis ziyareti” ve ek olarak “mesai dışı ziyaret”, “ikinci teknisyen” veya yaygın parçalar için tahmini ekler

Fiyat mantığını görünür kılın: nelerin dahil olduğunu, neyin süreyi artıracağını ve hangi durumların onay gerektireceğini gösterin.

Her ekranda güven için tasarlayın

Güven UX’in bir parçasıdır. Bunu profil sekmesinde saklamak yerine akışa entegre edin:

• Sağlayıcı profilleri fotoğraf, tecrübe, diller ve hizmet alanı ile
• Rozetler (adli sicil kontrolü, doğrulanmış belgeler, en yüksek puanlı)
• Gerçek hissettiren incelemeler (iş türü ve tarih ile)
• Açık fiyatlandırma ve politikalar (iptal süreleri, “malzemeler dahil”in ne anlama geldiği)

Ana ekranlar ve tasarlamanız gereken “olumsuz yollar”

Çoğu MVP mutlu yolda değil, kenar durumlarda başarısız olur. Şu ekran ve durumları planlayın:

• Boş durumlar (müsait yok, bölgede sağlayıcı yok) için alternatif eylemler
• Hatalar (ödeme başarısız, slot artık mevcut değil) ve net kurtarma yolları
• Yeniden planlama (kullanıcı veya sağlayıcı tarafından) onay ve hatırlatmalarla
• İptaller ve iadeler şeffaf sonuçlar ve zaman çizelgeleri ile

Bu temeller doğruysa, uygulamanız gelişmiş özellikler eklenmeden önce bile güvenilir hissedecektir.

Teknoloji Seçimleri: Uygulama, Arka Uç ve Entegrasyonlar

Teknoloji kararları iki kısıtla eşleştirildiğinde daha kolaydır: bütçe ve ne kadar hızlı piyasaya sürmek istediğiniz. Temizlik veya tamir için müşteriler gösterişli animasyonlardan ziyade güvenilir rezervasyon, güncellemeler ve ödeme bekler—bu yüzden ölçeklenebilir en basit yığını seçin.

iOS/Android için native vs. çapraz platform

En iyi performans ve platforma özel üstünlük için native (iOS için Swift, Android için Kotlin) premium seçenektir—ancak iki uygulama geliştirip sürdürmeniz gerekir.

Çoğu MVP için çapraz platform (Flutter veya React Native) pratik seçimdir: tek kod tabanı, daha hızlı yineleme ve daha düşük maliyet. Dezavantaj, cihaz tuhaflıkları veya karmaşık özellikler için bazen ekstra iştir.

Kural: ilk sürüş “rezerve et, öde, takip et, değerlendirme” ise çapraz platform genellikle yeterlidir.

Arka uç temelleri (sunucunuzun yapması gerekenler)

Basit bir on-demand uygulaması bile sağlam bir arka uç gerektirir. En azından planlayın:

• Hesaplar ve roller: müşteri, sağlayıcı, admin
• İşler/rezerveasyonlar: talep, kabul/atama, başlatma, tamamlama, iptal
• Sağlayıcı müsaitliği: çalışma saatleri, izin günleri, hizmet alanı
• Fiyat mantığı: temel ücretler, ek hizmetler, minimum ücretler, vergiler
• Ödemeler: yetkilendirme, tahsilat, iadeler, ödemeler ve ücretler

Hız için Firebase/Supabase kullanabilir veya daha karmaşık iş akışları ve raporlama bekliyorsanız özel bir API (Node.js/Django/Rails) kurabilirsiniz.

Hızla pazara çıkarken kontrolü de elinizde tutmak istiyorsanız, Koder.ai gibi platformlar MVP için pratik olabilir: müşteri uygulamasını, sağlayıcı portalını ve admin panelini sohbet odaklı bir iş akışıyla tanımlarsınız, Planning Mode’da yineleyip hazır olduğunuzda kaynak kodu dışa aktarabilirsiniz.

Yeniden icat etmeyin: kanıtlanmış entegrasyonlar

Ortak yapı taşları için yerleşik servisleri kullanın:

• Haritalar ve geokodlama: Google Maps veya Mapbox
• Push bildirimleri: Firebase Cloud Messaging / Apple Push
• E-posta/SMS: SendGrid + Twilio (veya yerel SMS sağlayıcıları)
• Ödemeler: Stripe (çoğu zaman en basit), gerekli ise bölgesel ödeme sağlayıcıları

Bu araçlar riski azaltır ve daha hızlı yayınlamanıza yardımcı olur.

Veri modeli temellerini önceden tasarlayın

Kodlamadan önce temel tablolar/koleksiyonları taslağı:

• Users (profil, iletişim, rol)
• Providers (yetenekler, belgeler, puan, hizmet yarıçapı)
• Services (kategoriler, süre, fiyat kuralları)
• Bookings (zaman aralığı, adres, durum, atanan sağlayıcı)
• Payments (tutarlar, iadeler, ödeme durumu)
• Reviews (yıldız, yorum, rezervasyona bağlı)

Bunu erken doğru yapmak, özellikle rezervasyon durumu değişiklikleri ve ödeme mutabakatı etrafında daha sonra sancılı göçleri önler.

Zamanlama, Tahliye ve Sağlayıcı Eşleştirme

Zamanlama, on-demand uygulamalarını ya zahmetsiz ya da sinir bozucu hissettiren alandır. Temizlik ve tamir işlerinde “zor kısım” takvim değil—trafik, araç/alet, beceri ve gecikmeleri gerçek dünya kısıtlarına dönüştürmektir.

Kötü rezervasyonları önleyen zamanlama kurallarını tanımlayın

Sisteminizin koruması gerekenleri önce karar verin:

• Ön bildirim süresi: müşterinin en erken ne zaman rezervasyon yapabileceği (ör. “en az 2 saat sonra” veya “sadece ertesi gün”)
• Zaman dilimleri vs. kesin zaman: temizlikçiler sabit dilimlerle iyi çalışır (9–12, 12–15), tamirler belirsizlik için varış penceresi (10–12) isteyebilir
• İş süresi: hizmet türüne göre varsayılanlar, ek banyolar/derin temizlik/parça takılması gibi eklerle süre uzatılabilir
• İşler arası tampon: park, devir notları ve kaçınılmaz taşmalar için süre ekleyin. 15–30 dakikalık tampon gecikmeleri ciddi şekilde azaltır.

Bu kuralları erken kodlamazsanız, müşteriler imkansız zamanlar rezervasyon eder ve destek sürekli özür dilemek zorunda kalır.

Yönlendirme: önce manuel, veri geldikçe otomatik

İki pratik tahliye modu vardır:

Manuel atama (operatör/admin sağlayıcıyı seçer) MVP için idealdir; kenar durumları, VIP müşteriler, zor işler ve yeni sağlayıcılar için uygundur.

Otomatik eşleştirme yeterli sağlayıcı ve tekrar eden örüntüler oluştuğunda değerlidir. Basit bir puanlama yaklaşımı: önce uygun sağlayıcıları filtrele, sonra mesafe, müsaitlik, puan ve kabul oranına göre sırala.

Gerçek dünya kısıtlarını dikkate alın (fazla mühendislik yapmadan)

İptaller ve yeniden işler önlemek için eşleştirme şu kriterleri dikkate almalı:

• Seyahat süresi: sadece yarıçap değil—önceki işten varış tahmini kullanın
• Beceriler ve sertifikalar: ör. “gaz cihazı”, “küf tedavisi”, “derin temizlik”
• Ekipman ve parçalar: bazı sağlayıcılar vakum/steamer getirebilir; tamir işler parça gerektirebilir

İlk versiyon kural tabanlı ve şeffaf olsun. Müşteriler “akıllı” eşleştirmeden çok güvenilirliği önceler.

Yeniden planlama ve iptaller için net onaylar

Her iki tarafı da açık akışlarla destekleyin:

• Yeniden planlama: sonraki uygun seçenekleri gösterin ve neyin değişeceğini (zaman, sağlayıcı, fiyat) onaylatın
• İptal: ücretleri (varsa), kesme saatlerini (ör. 24 saat öncesine kadar ücretsiz) ve iadelerin ne zaman görüneceğini açıkça gösterin

Her program değişikliği bir onay mesajı tetiklemeli ve sağlayıcının takvimini çifte rezervasyonu önlemek için hemen güncellemelidir.

Ödemeler, İadeler ve Sağlayıcı Ödemeleri

Ödemeler, hizmet uygulamalarında ya hızlı güven kazanma ya da sonsuz destek biletleri yaratma yeridir. Ödemeyi rezervasyon sisteminizin bir parçası gibi ele alın: her rezervasyonun net bir ödeme durumu olsun ve her durum kullanıcının ve sağlayıcının sonraki adımlarını belirlesin.

Riskinize uygun ödeme akışını seçin

Genellikle üç seçenek iş görür:

• Ön ödeme: rezervasyon anında tahsilat. Sabit fiyatlı hizmetler için en iyisi.
• Yetkilendir ve sonra tahsil et: rezervasyon sırasında tutar bloklama, iş sonrası tahsilat. Nihai tutar değişebiliyorsa kullanışlı.
• Hizmet sonrası ödeme: tamamlamadan sonra tahsilat. Kullanıcı için sürtünme düşük, ama yoklama ve tahsilat riski yüksek.

Ne seçerseniz seçin, her rezervasyon için payment_status (ör. unpaid, authorized, paid, failed, refunded, partially_refunded) ve denetim için zaman damgaları saklayın.

İadeler, kısmi iadeler ve iptal mantığı

“Tam iade” varsayımını sert kodlamayın. Yaygın senaryoları ifade eden iade mantığı kurun:

• Sağlayıcı atanmadan iptal: tutar iptal/otomatik iade edilir
• Atamadan sonra iptal: isteğe bağlı iptal ücreti alınır; kalan kısım iade edilir
• Hizmet anlaşmazlığı: tamamlanan iş için bir kısmı tutulup kısmi iade yapılabilir

İadeleri rezervasyona bağlı kayıtlar olarak modelleyin (refund_amount, reason_code, initiated_by, provider_impact) ki destek ve finans daha sonra uzlaştırabilsin.

Sağlayıcı ödemeleri: öngörülebilir, izlenebilir, yapılandırılabilir

Sağlayıcıların iki önemi vardır: ne zaman ödeme alacakları ve bunun nasıl hesaplandığı. Destekleyin:

• Varsayılan olarak haftalık ödemeler, ayrıca anlık ödemeler opsiyonel
• Ödeme eşikleri (ör. $X altındaki tutarlar ödenmesin)
• Sağlayıcı bazında ödeme geçmişi (ödeme tarihi, dahil edilen rezervasyonlar, ücretler, net tutar)
• Rezervasyon ödemesi ile sağlayıcı ödemesi arasında net ayrım (bir rezervasyon ödenmiş olabilir; sağlayıcı ödemesi beklemede olabilir)

Makbuzlar ve faturalar

Tahsilat sonrası ve her iade olayında bir makbuz gönderin. Hizmet, ekler, ücretler, indirimler gibi kalemleri yansıtan faturalar oluşturun ve invoice_id ile invoice_status verilerini rezervasyona bağlayın for temiz raporlama.

İletişim, Güncellemeler ve İncelemeler

Açık, zamanında iletişim tek seferlik rezervasyonu tekrar müşteriye dönüştürür. Temizlik ve tamir işlerinde insanlar esasen iki şey ister: kim geleceği ve ne zaman geleceği konusunda kesinlik, ve ne yapıldığını gösteren kanıt. Uygulamanız bunu birkaç odaklı özellik ile sağlayabilir.

Uygulama içi sohbet ve maskelenmiş arama

Müşteriler ve sağlayıcılar, erişim detayları, park yeri, malzemeler veya son dakika soruları için uygulama içi sohbet kullanmalı. Bu, kişisel numaralara geçişi engeller.

Acil durumlar için (“Dışarıdayım”, “Su vanası burada”) maskelenmiş arama sunun: uygulama aramayı bağlar ama gerçek telefon numaralarını gizler. Bu, gizliliği korur, platform dışı anlaşmaları azaltır ve iş ile ilgili iletişimin kaydını tutar.

Kaygıyı azaltan push bildirimleri

Push bildirimleri müşterinin doğal zaman çizelgesi sorularını yanıtlamalıdır:

• Rezervasyon onaylandı (tarih/saat ve sağlayıcı adı ile)
• Sağlayıcı yolda / yakında varıyor
• İş başladı ve tamamlandı
• Zaman değişiklikleri, iptaller veya yeniden atamalar (açık sebep ile)

Metinleri kısa ve tutarlı tutun; her bildirim belirli bir ekrana (rezervasyon detayları) bağlanmalı, sadece ana sayfaya değil.

Tamirler için fotoğraf yüklemeleri ve iş kanıtı

Fotoğraflar tamir iş akışlarında özellikle değerlidir:

• Ön fotoğraflar: müşteriler rezervasyon sırasında sorun fotoğrafları yükler, sağlayıcı doğru aleti getirir
• Sonrası/iş sırasında fotoğraflar: sağlayıcı tamamlanan işi kanıtlamak için yükler

Bu, anlaşmazlıkları azaltır, takip desteğini hızlandırır ve tekrar ziyaretleri kolaylaştırır.

İncelemeler, puanlama ve moderasyon

Basit bir inceleme akışı—tamamlamadan hemen sonra tetiklenen—hızla güven oluşturur. Yıldız puanını bir veya iki kısa soru ile eşleştirin (dakiklik, kalite, temizlik gibi).

Başından itibaren yönetici moderasyon araçları planlayın: işaretleme, kötü amaçlı içeriği kaldırma, kamuya yanıt verme ve iptal/iade durumlarında inceleme anlaşmazlıklarını ele alma. İncelemeler yalnızca gerçek tamamlanmış rezervasyonlara bağlanmalı.

Güvenlik, Gizlilik ve Güven Özellikleri

Güvenlik ve güven temelleri temizlik veya tamir uygulamaları için “iyi olur” değil—insanların yabancıyı evine alırken rahat hissetmelerinin nedenidir. Bu temelleri erken oluşturun ki bir olay sonrası altyapıyı sonradan düzeltmek zorunda kalmayın.

Gönderilmesi gereken minimum güvenlik

Her rol için güçlü kimlik doğrulama (müşteri, sağlayıcı, admin) ile başlayın. Güçlü parola kuralları, yöneticiler için opsiyonel 2FA ve girişleri hız sınırlama ile koruyun.

Rol tabanlı erişim kontrolü (RBAC) elzemdir: müşteriler sadece kendi rezervasyonlarını görmeli, sağlayıcılar sadece kendilerine atanan işleri görmeli ve yöneticiler yalnızca ihtiyaç duydukları verilere erişmelidir.

Yönetici eylem günlüklerini baştan ekleyin: kim fiyat değiştirdi, sağlayıcı profiline kim baktı, kim iade yaptı gibi. Günlükler aranabilir ve bozulmaz biçimde saklanmalı.

Kullanıcı verilerini koruyun (ve sağlayıcı görünürlüğünü sınırlayın)

Veriyi transferde şifreleyin (HTTPS/TLS her yerde) ve hassas ayrıntıları sağlayıcılara yalnızca gerektiğinde gösterin. Örneğin, iş kabul edilene kadar yalnızca mahalleyi veya yaklaşık alanı gösterin; kesin adres rezervasyon onaylandığında ortaya çıksın.

Veri minimizasyonu prensibini uygulayın: hizmeti sunmak için gerekmedikçe veri istemeyin. Doğum tarihi gerekmiyorsa sormayın.

Operasyonel güvenlik ve olay yönetimi

Sağlayıcı doğrulama akışı oluşturun: kimlik kontrolleri, telefon/e-posta doğrulama ve gerekliyse adli sicil kontrolleri ile lisans/sigorta yüklemeleri. “Doğrulandı” statüsünü açıkça gösterin ki müşteriler ne anlama geldiğini anlasın.

Hem müşteriler hem sağlayıcılar için uygulama içi olay raporlama (güvenlik sorunu, hasar, gelmeme) ekleyin. Ciddi raporları zaman damgalı kanıtlarla öncelikli yönetici kuyruğuna yönlendirin.

Saklama, yedekler ve "kimin neyi görebileceği"

Basit bir erişim matrisi (rol → izin verilen veri) tanımlayın ve belgeleyin.

Saklama kuralları belirleyin (ör. eski sohbetleri X aydan sonra sil) ve şifrelenmiş yedekler ile restore prosedürlerini test edin. Yedek erişimini sınırlayın ve her erişimi kaydedin.

Test, Lansman, Metrikler ve Büyüme Planı

Harika bir MVP gerçek hayatta kırılmasa bile başarısız olabilir—kullanıcılar yavaş ağlarda iken, sağlayıcı bildirimleri kaçırdığında veya ödeme iade gerektirdiğinde. Test ve lansmanı ürünün bir parçası gibi ele alın.

Pratik bir test kontrol listesi (MVP)

Pazarlamaya başlamadan önce temellerin sıkıcı derecede güvenilir olduğundan emin olun:

• Rezervasyon akışı: rezervasyon oluştur, yeniden planla ve tüm tarafların aynı zaman ve adresi gördüğünü doğrula.
• Ödemeler: kart yetkilendirme/tahsilat çalışıyor, başarısız ödemeler düzgün kurtarılıyor, makbuzlar gidiyor ve ödeme durumu güncelleniyor.
• İptaller + iadeler: kullanıcı kesme öncesi/sonrası iptal ediyor, sağlayıcı iptal ediyor ve kısmi/tam iadeler beklenen şekilde işliyor.
• Kenar durumlar: çift rezervasyon, sağlayıcı gelmeme, kullanıcı adrese son anda değişiklik, saat dilimi uyumsuzlukları, son slot erişimi.
• Yavaş/kararsız ağlar: sınırlı bağlantılarda test edin; uygulamanın sonsuz döngüye girmediğinden ve tekrar denemelerin güvenli olduğundan emin olun (çoğaltılmış ücret yok).
• Bildirimler: push/SMS/e-posta zamanında geliyor, derin bağlantılar doğru ekranı açıyor ve kaçırılan bildirimler işi bloke etmiyor.

Yönetici paneliniz varsa: manuel iş oluşturma, sağlayıcı atama geçersiz kılma, iadeler ve anlaşmazlık notlarını da test edin.

Tam lansmandan önce pilot koşun

Bir alan (mahalle veya küçük bir şehir) ve küçük bir sağlayıcı grubu ile başlayın. Amaç ölçek değil—öğrenmek:

• Gerçek tahliye zamanlamasını doğrulayın (atama süresi)
• Operasyon boşluklarını yakalayın (değişiklik olduğunda müşteriyle kim iletişime geçer?)
• Hizmet sürelerini, fiyat kurallarını ve iptal politikasını ayarlayın

Pilotu basit tutun: sınırlı saatler, sınırlı hizmet listesi ve net beklentiler. Bu size temiz veri ve daha az destek başlığı sağlar.

Düzeltmeniz gerekenleri söyleyen metrikler

Haftalık küçük bir metrik seti izleyin:

• Dönüşüm oranı: ziyaret → fiyat görüntüleme → rezervasyon → ödendi
• Tekrar oranı: 30/60 gün içinde yeniden rezervasyon yapanlar
• İptal oranı: sebebe göre ayrıştırılmış
• Atama süresi: rezervasyondan sağlayıcı kabulüne kadar geçen süre (% kaçının manuel müdahale gerektirdiği)

Erken hafif olay takibi ekleyin; analitiği sonradan yeniden yaratmak zordur.

Lansman sonrası büyüme yol haritası (iteratif tutun)

Çekirdek akışlar stabil olduktan sonra iyileştirmeleri sıraya koyun:

1. Otomasyon: daha akıllı eşleştirme kuralları, otomatik yeniden atama, daha az yönetici dokunuşu
2. Abonelikler: düzenli temizlik/bakım planları ile öngörülebilir gelir
3. Referanslar: her iki tarafa da kredi veren programlar, dolandırıcılık kontrolleri ile
4. Çoklu şehir genişlemesi: yalnızca birim ekonomisi ve operasyonlar tekrarlanabilir olduğunda

Tahminler veya pilot planlama yardımı istiyorsanız /pricing'e bakabilir veya /contact üzerinden ulaşabilirsiniz.