Depozitoları toplamak, bakiyeleri takip etmek ve randevulardan önce hatırlatmalar göndermek için rezervasyonlarda depozito ve taksit takipçisi kurun.
Depozitolar rezervasyonları daha güvenli hale getirir. Müşteriler no‑show yapma olasılığını azaltır, ve ciddiyeti olmayanlar daha erken elenir.
Sorunlar genellikle ilk ödemenin alınmasından hemen sonra başlar. Kalan bakiyeyi takip edecek güvenilir bir yeriniz yoksa, her rezervasyon küçük bir dedektiflik hikâyesine dönüşür.
Bakiye notlarda, DM'lerde veya bir tabloda yaşadığında üç şey hızla bozulur: rakamlar kayar, mesajlar kaçırılır ve farklı personel üyeleri farklı gerçekliklerden çalışır. Bir kişi sayfayı günceller, başka biri gelişte nakit alır ve kimse ne kadar borç kaldığını tam olarak bilmez.
Gerçek hayat daha fazla sürtünme ekler. Müşteri yeniden planlar, ekstra hizmet ekler, kalan ödemeyi iki parçada yapar veya makbuz ister. Bir anda kısmi ödemeler, iadeler ve yeni toplamlarla uğraşırsınız; takvimde ise bunun hiçbiri görünmez.
Sık görülen acı noktaları genelde aynıdır:
Çoğu ekipin istediği basit: randevular için depozito alın, her rezervasyona tek bir doğru bakiye tutun ve ödemeyi denge hatırlatmalarını doğru zamanda otomatik gönderin (örneğin randevudan 48 saat önce). Biri yüz yüze öderse sistem bunu kaydetmeli ve hatırlatmaları durdurmalı.
Bu ancak kurallarınız basitse basit hisseder. Bir şey inşa etmeden önce sistemin sizin için hangi kararları almasını istediğinizi yazın ki her rezervasyonda pazarlık yapmak zorunda kalmayın.
Depozitoyla başlayın. Sabit bir tutar mı olacak (örneğin $30) yoksa yüzde mi (örneğin %20)? Sabit anlatması daha kolay. Fiyatlar değişkense yüzde adil gelebilir. Sonra ne zaman tahsil edileceğine karar verin: rezervasyon anında, onaydan sonra veya tekliften sonra. Hemen almak no‑showları azaltır, ancak net iade kuralları gerektirir.
Sonra kalan bakiyenin ne zaman vadesinin dolacağını tek bir varsayılanla belirleyin. “Gelişte” en kolay olandır. “Randevudan 48 saat önce” son dakika iptallerini azaltır. Bazı işletmeler güvendikleri müşteriler için “hizmet sonrası” izin verir, ama bu istisna olmalı.
İadeler ve yeniden planlamalar bir‑iki cümleyle açıklanabilmeli. Örneğin: “Depozitolar randevudan 24 saat öncesine kadar iade edilebilir. Ondan sonra depozito alınır, ancak 7 gün içinde bir kez yeniden planlama yapabilirsiniz.” Basit kurallar tartışmaları önler.
Ayrıca “ödenmiş”in sizin işinizde ne anlama geldiğine karar verin. Kart, nakit ve havale kabul ediyorsanız her yöntemi net şekilde takip etmelisiniz. Makbuzlar hem müşteri hem kendi kayıtlarınız için önemli, bunu belirsiz bırakmayın.
Kurmanız gerekenler:
Kurallar yazıldıktan sonra, kurmak çoğunlukla konfigürasyondur.
Amaç her şeyi saklamak değil. Birinin “Ne kadar borçlu, ne zamana kadar ve onları uyardık mı?” diye sorduğunda güvenebileceğiniz birkaç gerçeği saklamaktır.
Rezervasyonla başlayın. Her rezervasyonun şunları içermesi gerekir:
Sonra ödeme takvimi. Modeliniz depozito + bakiye ise bunu iki satır halinde tutun. Her satırın bir tutarı ve bir vade tarihi olmalı. Sıkıcı tutun.
Ödemeleri tek bir sürekli toplam olarak değil, ayrı işlemler olarak kaydedin. Her işlem için tutar, zaman, yöntem (kart, nakit, havale) ve sağlayıcı ID'si (örneğin Stripe payment intent veya charge ID) saklayın. İadeler yapıyorsanız iade tutarı, zamanı ve sağlayıcı iade ID'sini de takip edin.
Hatırlatmalar mesajlar gibi izlenmeli: hangi şablon kullanıldı, planlanan gönderim zamanı, gerçek gönderim zamanı ve teslimat durumu (gönderildi, başarısız, geri döndü). Bu, “Bildirimi gönderdik mi?” sorusuna tahmin yürütmeden cevap vermenizi sağlar.
Son olarak bir denetim izi tutun: rezervasyonu, takvimi veya durumu kim ne zaman değiştirdi. Bu, müşteri neye karar verildiğini tartıştığında sizi kurtarır.
AppMaster içinde inşa ediyorsanız, bunlar Data Designer'da birkaç tabloya güzelce oturur ve mantık Business Process Editor'da tutulur; böylece bakiyeler ve hatırlatmalar her seferinde aynı kuralları izler.
Ödemeler yönetilebilir kaldığında herkes hızlıca bir soruya cevap verebilir: sonraki adım ne?
İki ayrı kavram kullanın:
Bu, “Tamamlandı” ile “Ödendi”yi karıştırmak gibi kafa karıştıran kombinasyonları önler.
Pratik bir ödeme durum seti şöyle görünür:
Tamamlandı ve İptal edildi rezervasyon sonuçları olarak kalsın, ödeme sonuçları olarak değil. Bir rezervasyon, kurallarınıza bağlı olarak Tamamlandı + Ödendi veya İptal Edildi + İade Edildi olabilir.
Durumu hareket ettiren tetikleyiciler tanımlayın ki personel “neyi tıklayacağını” hatırlamak zorunda kalmasın. Örneğin başarılı bir ödeme ödeme durumunu otomatik günceller; yeniden planlama vade tarihlerini ve hatırlatmaları yeniden hesaplar.
İki ödemeden fazlasına izin veriyorsanız, “İkinci ödeme”, “Üçüncü ödeme” gibi statüler oluşturmayın. Her ödemeyi kendi kaydı olarak saklayın ve kalan bakiyeyi toplamdan hesaplayın. Durum özet olur.
Ekranlarda ve mesajlarda durumu tek bir net sayı ile eşleştirin: “$120 ödendi, $80 Mayıs 12'ye kadar ödenecek.” Bu, karşılıklı yazışmaları durdurur.
En iyi rezervasyon ödeme iş akışı sıkıcı hisseder. Amaç budur. Net rakamlar, net durum ve işi yapan birkaç zamanlı mesaj.
Her rezervasyonu basit bir zaman çizelgesi gibi ele alın: oluşturuldu, depozito vadesi/ödendi, bakiye vadesi/ödendi, tamamlandı (veya iptal edildi). Her adım bir zaman damgası ve nasıl gerçekleştiği (çevrimiçi, nakit, kart, havale) ile kaydedilmeli.
Basit bir akış:
Örnek: müşteri 20 Mart için rezervasyon yapar. Depozito $20, bakiye $40. $20 alınırsa rezervasyon onaylanır. Sistem 13 Mart ve 19 Mart için hatırlatma programlar. $40 alındığında rezervasyon ödendi olarak işaretlenir ve hatırlatmalar durur.
AppMaster kullanıyorsanız Data Designer rezervasyonları, ödeme takvimlerini ve işlemleri tutabilir; Business Process Editor ise hesaplamaları, durum değişikliklerini ve planlı hatırlatma görevlerini kod yazmadan yönetir.
Otomatik ödeme bildirimleri daha fazla mesaj anlamına gelmemeli. Doğru mesajı doğru zamanda göndermek ve müşteri ödeme yapar yapmaz durdurmak amaç olmalı.
Genelde işe yarayan zamanlama:
Hatırlatmalar kısa olmalı, ama mutlaka şunları içermeli:
Müşterinin zaten ödemiş veya iptal etmiş olmasına rağmen hatırlatma göndermek en hızlı rahatsız eden şeydir. Bu şarttır: hatırlatmalar sadece rezervasyon aktif ve bakiye > 0 olduğunda gönderilir. Ödeme kaydedildiğinde gelecekteki tüm hatırlatmalar iptal edilmelidir.
Eskalasyon gerekiyorsa insan unsurunu koruyun. İlk mesaj yok sayılmış kabul edilir; son mesaj ise net, spesifik ve zaman sınırlı olmalıdır.
Çoğu sorun ödemelerden değil; belirsiz kurallardan, karışık durum güncellemelerinden ve gerçeğe uymayan hatırlatmalardan kaynaklanır.
Gerçeklik kontrolü: Biri saat 10:00'dan 15:00'a yeniden planladığında, 15:00 için 24 saat önce tek bir hatırlatma istersiniz; iki hatırlatma ve kafa karışıklığı değil.
Gerçek müşteriler sistemi kullanmadan önce 3–5 sahte rezervasyonla “rezerve et, öde, hatırlat” testi yapın. Farklı tarihler (yarın, gelecek hafta, gelecek ay) kullanın ki zamanlama hataları ortaya çıksın.
Her rezervasyon depozito tutarını, depozitonun vade tarihini (kullanıyorsanız) ve bakiye vade tarihini açıkça göstermeli. Bunlardan herhangi biri belirsizse personel tahmin eder ve müşteriler yanlış bilgi alır.
Yayında dikkat çeken kontroller:
Bir senaryo doğrulayın: $200'lık bir rezervasyon oluşturun, bugün için $50 depozito ve randevudan iki gün önce $150 bakiye. Depozitoyu ödendi olarak işaretleyin, sonra $30 ekstra ödeme ekleyin. Kalan bakiye $120 olmalı ve bir sonraki hatırlatma hâlâ randevu tarihine yönelik olmalı.
Bir kuaför 90 dakikalık renk hizmetini $200 olarak sunuyor. Kural açık: rezervasyonda %30 depozito alınır ($60) ve kalan bakiye randevudan 48 saat önce ödenir.
Müşteri Cuma 15:00 için rezervasyon yaptığında sistem iki parçalı bir ödeme planı oluşturur: Depozito (şimdi vadesi) ve Bakiye (Çarşamba 15:00'te vadesi). Depozito hemen ödendiği için rezervasyon onaylanır. Kalan bakiye hâlâ ödenmemiştir.
Salı sabahı müşteri randevuyu Cumartesi 13:00'e taşır. Depozito ödenmiş kalır, fakat bakiye vade tarihi yeni zamana göre Perşembe 13:00'e kayar (yeni zamandan 48 saat önce). Personelin hiçbir şeyi yeniden hesaplamasına gerek yoktur.
Hatırlatmalar yeniden planlamayla otomatik güncellenir. Eski Cuma slotuna göre “yarın bakiye” mesajı göndermek yerine plan en son randevu zamanına göre yeniden oluşturulur. Cumartesi sabahı personel güncel gerçekliği görür, kafa karışıklığı değil.
Bu sistem personel birkaç saniyede kontrol edebiliyorsa işe yarar. Günlük hedef basit: bugün neler oluyor, ne ödendi ve kimlere hatırlatma lazım bilmek.
Gelecek işlere odaklı tek bir temiz yönetici görünümüyle başlayın. Bugün ve sonraki 7–14 gün içindeki rezervasyonları, müşteri ve hizmet bilgilerini, randevu saatini, ödeme durumunu ve bakiye ile vade tarihini göstermeli.
Güncellemeleri hızlı yapın. Personel bir ödemeyi kaydedebilmeli, not ekleyebilmeli ve makbuz düzenleyebilmeli; menülerde dolaşmak zorunda kalmamalı.
Müşterilere de netlik sağlayın. Depozito ödendikten sonra basit bir özet gösterin: ne ödendi, ne kadar kaldı ve son tarih ne. Taksitler kabul ediliyorsa her ödemeyi ayrı satır olarak gösterin ki “ben zaten ödedim” tartışmaları olmasın.
Temel raporlama iki soruyu cevaplamalı: “Depozitolar olarak ne kadar topladık?” ve “Ne kadar hala tahsil edilmeyi bekliyor?” Hafif, filtrelenebilir ve tarih aralığı, personel ve hizmet türüne göre filtrelenebilir olsun.
Roller basit olmalı:
Depozito kuralları ve hatırlatmalar kağıt üzerinde çalışıyorsa, bunları küçük bir uygulamaya koymak tutarlılığı korumanın yoludur.
En küçük gerçekçi sürümle başlayın. Bir hizmet, bir depozito kuralı ve bir hatırlatma takvimi seçin. Akışı doğru yapmak, tüm kenar durumlarını kapsamaya çalışmaktan daha önemlidir.
İyi bir ilk sürüm genelde rezervasyon listesi, depozito ve bakiye gösteren bir ödeme görünümü, depozitoyu kaydetme eylemi, son ödemeyi kaydetme eylemi ve yeniden kullanılabilir bir hatırlatma şablonundan oluşur.
Müşterilere göstermeden önce politika metninizi sade dilde yazın ve birkaç gerçek kişiyle test edin. Onlara iptal ederseniz ne olacağını ve bakiye tarihinin ne zaman olduğunu geri anlatmalarını isteyin. Tereddüt ederlerse yeniden yazın.
Tüm sistemi kodsuz kurmak istiyorsanız, AppMaster (appmaster.io) bu iş akışını üretime hazır bir backend, web uygulaması ve mobil uygulamaya çevirme konusunda pratik bir seçenektir; veritabanı modeli ve hatırlatma mantığı tek bir yerde tutulur.
Temel stabil olduğunda iyileştirmeleri birer birer ekleyin: hizmete göre farklı depozito tutarları, bekleme listesi, bakiye için ödeme bağlantıları veya yalnızca gecikmiş bakiyeler için ekstra bir hatırlatma gibi.
Sabit depozito mu almalıyım yoksa yüzde mi?Basit bir varsayımla başlayın: düşük fiyatlı hizmetler için sabit bir depozito, fiyatları çok değişken olan hizmetler için yüzde bazlı bir depozito. Sabit depozitolar açıklaması daha kolaydır ve ödeme sırasında kafa karışıklığını azaltır; yüzde ise fiyatlar geniş bir aralıkta değişiyorsa adil hissedilir. Ne seçerseniz seçin, kuralı bir kez yazın ve her rezervasyona otomatik uygulayın.
Depozito ne zaman alınmalı: rezervasyon sırasında mı yoksa onaydan sonra mı?Rezervasyon sırasında ücret almak genellikle no‑show oranını en çok düşürür çünkü müşteride hemen bir bağlılık oluşturur. Eğer hizmetiniz sık sık manuel teklif veya onay gerektiriyorsa, müşterilerin sürpriz yaşamaması için depozitoyu doğrulamadan sonra alın. Önemli olan zamanlamayı tutarlı yapmak, böylece personel vaka bazında karar vermek zorunda kalmaz.
Kalan bakiyenin ödenmesi için en iyi varsayılan kural nedir?Genellikle işe yarayan bir kural: "bakiye randevudan 48 saat önce ödenir" — bu, son dakika iptallerini azaltır ve size takip için zaman verir. En basit deneyim isterseniz "gelişte" de olur, fakat bu durumda hizmet öncesi ödenmemiş bakiyelerle daha sık uğraşırsınız. Bir varsayılan seçin ve sadece güvendiğiniz müşteriler için istisna yapın.
Her rezervasyon için tek bir doğru bakiye sayısını nasıl tutarım?Her ödeme işlemini belirli bir rezervasyona bağlayın ve kalan bakiyeyi onaylanmış ödemelerin toplamından hesaplayın. Bu, personelin notlara veya mesajlara bakarak tahminde bulunmasını engeller ve bir müşteri birden fazla kısımda ödese bile rakamlar tutarlı kalır. Tek bir “ödenen miktar” alanını elle değiştirmekten kaçının.
Kısmi ödemeleri nasıl düzenli kaydederim?Her ödemeyi kendi işlem kaydı olarak tutun: tutar, zaman, yöntem ve çevrimiçi ödemeler kullanıyorsanız sağlayıcı referans ID'si. Böylece ödeme durumu zaten kaydedilmiş işlemlerin bir özeti olur; personelin durumu hatırlayıp elle değiştirmesine gerek kalmaz. Ayrıca bu yöntem, çift ödeme veya iadeleri temiz şekilde ele almayı kolaylaştırır.
Rezervasyonlar ve ödemeler için hangi statüleri gerçekten kullanmalıyım?Rezervasyon durumu ve ödeme durumunu ayrı kavramlar olarak tutun ki karışıklık olmasın. Örneğin bir rezervasyon onaylı veya tamamlandı olabilir; ödeme ise depozito ödendi, kısmen ödendi veya tam ödendi olabilir. Bu, personelin “sonraki adım ne” sorusuna cevap vermesini kolaylaştırır ve "tamamlandı ama ödenmedi" gibi kafa karıştıran durumların gözden kaçmasını önler.
Müşterileri rahatsız etmeden hatırlatmaları nasıl otomatikleştiririm?Sadece rezervasyon aktif ve kalan bakiye sıfırdan büyükse hatırlatma gönderin; ödeme kaydedildiğinde tüm gelecekteki hatırlatmaları hemen iptal edin. Çoğu ekip için bir hafta öncesinde bir uyarı ve randevudan 48 saat önce bir hatırlatma yeterlidir. En hızlı şekilde müşteri sinirlendiren şey, ödediği veya iptal ettiği hâlde hatırlatma almaktır.
Müşteri yeniden planladığında ödemelere ve hatırlatmalara ne olmalı?Önce randevu zamanını güncelleyin, sonra kalan bakiye vade tarihini yeniden hesaplayın ve hatırlatma programını yeni zaman damgasından yeniden oluşturun. Eski hatırlatmalar iptal edilmeli veya yok sayılmalı ki müşteri sadece güncel rezervasyon zamanına göre mesaj alsın. Burada bir denetim izi olması da faydalıdır; kim neyi ne zaman değiştirdiğini görebilirsiniz.
İade ve yeniden planlama kurallarını nasıl belirlemeliyim ki ihtilaf çıkmasın?Müşterilerin anlayacağı kısa bir kural yazın, sonra bunu tutarlı şekilde uygulayın ve onaylarda ile makbuzlarda gösterin. Pratik bir varsayılan: 24 saat öncesine kadar iade edilebilir, sonrasında depozito alınır, ve belirli bir süre içinde bir kez yeniden planlama hakkı verilir. Kural açıklamak için paragraf gerekiyorsa, ileride tartışma çıkar.
Gerçek müşteriler sistemi kullanmadan önce neyi test etmeliyim?Gerçekçi senaryolarla uçtan uca birkaç test yapın: aynı gün rezervasyonu, yeniden planlama, ek hizmet eklenmesi ve yüz yüze ödeme gibi. Bakiyenin doğru güncellendiğini, hatırlatmaların randevu zamanına göre tetiklendiğini ve ödeme alındığında hatırlatmaların hemen durduğunu doğrulayın. AppMaster kullanıyorsanız tabloları Data Designer'da modelleyip yeniden hesaplama ve hatırlatma mantığını Business Process Editor'da zorunlu kılabilirsiniz, böylece her seferinde aynı davranış elde edilir.
21 Oca 2026
8 dk
20 Oca 20268 dk
20 Oca 20268 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
