Otomatik hatırlatıcı dizileriyle Alacak Yaşlandırma Panosu

Bu pano hangi problemi çözüyor (ve neden önemli)\n\nAlacak yaşlandırma (AR) basit bir fikir: faturaların ne kadar süredir ödenmediğini gösterir. Düz bir listeye bakmak yerine, faturaları vade tarihinden bu yana geçen süreye göre gruplanmış görürsünüz: 0–30 gün, 31–60 ve devamı. Bu görünüm iki günlük soruyu hızlıca yanıtlar: ne risk altında ve bugün kimlere hatırlatma atılmalı.\n\nHatırlatma sistemlerinin çoğu manuel kaldıklarında başarısız olur. Birinin listeyi kontrol etmeyi, ne gönderileceğine karar vermeyi, müşterinin e-postasını kopyalamayı ve gönder tuşuna basmayı hatırlaması gerekir. Yoğun haftalarda takipler kayar. Yavaş haftalarda insanlar aşırıya kaçıp çok fazla mesaj gönderir veya kimin yanıt verdiğini unutur. Sonuç tutarsız ton ve zamanlamadır; bu da iyi müşterileri rahatsız edebilir.\n\nBir alacak yaşlandırma panosu görünürlükle tutarlı takipleri eşleştirerek bunu düzeltir:\n\n- Görünürlük: herkes aynı gerçeği görür — toplam gecikmiş tutar, hangi müşterilerin sürüklendiği ve hangi faturaların takılı kaldığı.\n- Tutarlı takip: hatırlatmalar ruh halinize değil, politikanıza uygun, öngörülebilir bir takvimde gider.\n\nİyi bir kurulum ekipten yapılacakları sade tutar: önemli birkaç faturaya odaklanmayı sağlar, “Takip ettik mi?” belirsizliğini azaltır, faturayı gerçek bir probleme dönüşmeden önce müşteriye hatırlatır ve güvenilir müşterileri sürekli gecikme yapanlardan farklı muamele eder.\n\n"Ödendiğinde otomatik dur" kısmı utanç verici durumları önler. Bir ödeme kaydedildiği (veya fatura ödendi olarak işaretlendiği) anda sistem o faturaya ait kalan hatırlatmaları iptal eder. Böylece sabah ödeyen bir müşteri aynı gece "Son bildirim" almaz.\n\nBunu uzun bir mühendislik projesi olmadan kurmak istiyorsanız, AppMaster pratiktir: faturaları ve ödemeleri modelleyebilir, yaşlandırma görünümleri oluşturabilir ve gerçek ödeme durumuna göre duraklayan veya duran hatırlatma dizileri çalıştırabilirsiniz.\n\n## AR tablosuyla başlayın: gerçekten ihtiyacınız olan veriler\n\nHatırlatmalar veriniz kadar iyidir. Ekranlar veya otomasyon kurmadan önce, her görünümün ve hatırlatma dizisinin güvenebileceği temiz bir AR tablosu tanımlayın.\n\nCevaplayan tek soruyu karşılayan minimum alanlarla başlayın: ne borçlu, kim tarafından ve ne zaman.\n\n- Fatura numarası (veya fatura ID'si)\n- Müşteri (hesap adı ve benzersiz müşteri ID'si)\n- Borç tutarı (açık bakiye, sadece orijinal tutar değil)\n- Vade tarihi\n- Durum (Open, Partially paid, Paid, Disputed, Written off)\n\nBu çalıştıktan sonra, sadece elle takipleri azaltan ve devralmaları netleştiren alanları ekleyin:\n\n- Atanmış sahip (sorumlu kişi veya ekip)\n- Ödeme kaydedilen tarih (bakiye sıfırlandığında)\n- Son hatırlatma gönderildi (tarih/saat ve kanal)\n- Bir sonraki hatırlatma planlandı (tarih/saat)\n- Notlar veya sebep kodu (kısa, kontrollü seçenekler: Disputed veya Awaiting PO gibi)\n\n### Kısmi ödemeler ve krediler: erkenden karar verin\n\nKısmi ödemeler ve krediler baştan karar gerektirir, yoksa iş akışı sonra karışır.\n\nBasit bir yaklaşım fatura toplamlarını fatura kaydında tutmak ve para hareketlerini ayrı bir "transactions" tablosunda izlemektir (ödemeler, kredi notları, düzeltmeler). AR kaydınız hesaplanmış açık bakiyeyi ve "Partially paid" durumunu tutabilir. Bu, dağınık düzenlemelerden kaçınır ve denetim izini korur.\n\n### “Ödendi” için bir gerçek kaynağı seçin\n\nÖdeme kaydedildiği zaman için tek bir "gerçek kaynağı" konusunda uzlaşın.\n\n- Muhasebe sisteminiz yetkiliyse, uygulamanızı ondan güncelleyen bir ayna gibi ele alın.\n- Ödemeleri uygulama içinde kaydediyorsanız, kimlerin faturayı Paid olarak işaretleyebileceğini kilitleyin ve kayıtlı tutar ile tarih isteyin.\n\nAppMaster'da bunu veritabanı kurallarıyla ve Business Process Editor'de basit bir onay adımıyla zorunlu kılabilirsiniz; böylece hatırlatmalar her seferinde doğru sebeple durur.\n\n## Ekip nasıl konuşuyorsa ona uygun yaşlandırma kovaları\n\nİyi bir AR yaşlandırma raporu, insanların gecikmiş faturaları konuştuğu şekilde olmalıdır. Ekip zaten "31–60 kovasında" diyorsa, panonuz bunu yansıtmalı. Bu teslimleri temiz tutar ve doğru sorunları hızla görmenize yardımcı olur.\n\nÇoğu ekip için iyi çalışanlar:\n\n- Current (vadesi gelmemiş)\n- 1–30 gün gecikmiş\n- 31–60 gün gecikmiş\n- 61–90 gün gecikmiş\n- 90+ gün gecikmiş\n\nBir faturayı bir kovaya yerleştirmek için gecikme günlerini hesaplayın:\n\nGecikme günleri = (bugünün tarihi) - (vade tarihi)\n\nSonuç negatifse fatura henüz vadesi gelmemiş demektir. Birçok ekip bunu "Current"ten ayrı tutar, çünkü "Current" genellikle bugün vadesi olan veya yakında vadesi gelecekleri ifade ederken, "Not yet due" gerçekten erken olanları gösterir. Bu küçük ayrım, hâlâ zamanı olan müşterilere rahatsız edici hatırlatmalar gitmesini engeller.\n\n### Vade tarihine göre yaşlandırma vs fatura tarihine göre yaşlandırma\n\nBir yöntem seçin ve her yerde kullanın: pano, hatırlatma mantığı ve raporlama.\n\n- Vade tarihine göre yaşlandırma ödeme koşullarınızla tutarlı ve adil olduğu için en yaygın tercihtir.\n- Fatura tarihine göre yaşlandırma işiniz hemen ödeme bekliyorsa veya vade tarihleri güvenilir değilse tercih edilebilir.\n\nPratik bir uzlaşma her iki alanı da saklamak, ama kovaları vade tarihine göre belirlemek olabilir. Vade tarihi eksikse fatura tarihine geri dönün ve veriyi düzeltmesi için işaretleyin.\n\n### Kovalardan bağımsız özel durumlar\n\nYalnızca kovalar yeterli değildir. Ekip yanlış kişileri takip etmesin diye yaşlandırmayı geçersiz kılacak durumlara da ihtiyacınız vardır.\n\n- Disputed: müşteri sorun bildirdi, çözülene kadar hatırlatmaları duraklatın.\n- On hold: dahili bekleme (örneğin düzeltilmiş bir PO bekleniyor).\n- Promise to pay: müşteri bir tarih taahhüt etti, bir sonraki hatırlatmayı geciktirin.\n- Paid, not posted: ödeme alındı ama henüz kaydedilmedi, çift mesaj göndermeyin.\n\nBu durumları AR tablonuzda modelleyin ki pano ve tahsilat otomasyonu standart kuyruktan bunları otomatik olarak filtreleyebilsin. AppMaster gibi bir araçta bu genellikle bir durum alanı eklemek ve görünümlerde ile iş mantığında kontrol etmeyi gerektirir.\n\n## Pano görünümleri: özet, sahip kuyruğu ve müşteri detayı\n\nİyi bir pano bir şeyi iyi yapar: hangi faturaların hemen ilgilenilmesi gerektiğini size söyler, tek tek faturalar arasında kazma yapmayı zorunlu kılmaz. Üç görünüm çoğu ekip için yeterlidir: genel görünüm, günlük iş kuyruğu ve tek müşteri zaman çizelgesi.\n\n### 1) Özet görünümü ("durumumuz ne?")\n\nÖzet her açıldığında aynı soruları yanıtlamalı: ne kadar açık bakiye var, ne kadar gecikmiş ve riske kimler neden oluyor.\n\nBasit tutun:\n\n- Toplam açık bakiye ve toplam gecikmiş bakiye\n- Yaşlandırma kovalarına göre gecikmiş dağılımı (1–30, 31–60, 61–90, 90+)\n- En fazla gecikmiş müşteriler (miktara göre, fatura sayısına göre değil)\n- "Geçen haftadan beri yeni gecikmeler" sayısı gibi hızlı bir gösterge\n\nBu görünüm yöneticiler ve toplantı öncesi hızlı kontrol yapan herkes içindir.\n\n### 2) Sahip kuyruğu ("bugün ne yapmalıyım?")\n\nSahip kuyruğu bir raporu yapılacaklar listesine çevirir. Her kişi sadece kendisine atanmış hesapları görmeli ve bir sonraki eylem net şekilde gösterilmelidir.\n\n"Yapılması gereken" alanlara sadık kalın: müşteri, toplam gecikme, en eski gecikmiş fatura, son temas tarihi, bir sonraki adım ve "Reminder 2 scheduled" veya "Call needed" gibi basit bir durum.\n\nAppMaster'da bunu temiz bir tablo görünümü ve birkaç hesaplanmış alan (gecikme günleri, bir sonraki hatırlatma tarihi gibi) ile çözebilirsiniz.\n\n### 3) Müşteri detayı ("hikaye ne?")\n\nBiri "Zaten ödedik" dediğinde ekibe hızlıca bağlam lazım. Müşteri detay görünümü faturaları ve iletişimi bir araya getirmeli: açık faturalar, ödeme geçmişi, notlar, son temas ve planlanan bir sonraki adım.\n\nBirkaç filtreyi elinizin altında tutun: bölge, müşteri tipi, tutar eşiği (örneğin sadece 1.000$ üzeri gecikmeler), vade aralığı ve sahip.\n\nBasit bir senaryo: Maria'nın 40 hesabı var. Kuyruğunda "500$ üzeri" ve "son 14 gün" filtresi aktif. Bir müşteriye tıkladığında anında iki açık fatura, yeni PO numarası talebi içeren bir not ve yarın planlı bir e-posta hatırlatmasını görür. Notu günceller, sonraki adımı "PO bekle" olarak ayarlar ve kayıt başka biri devraldığında temiz kalır.\n\n## Hatırlatma dizileri: ne gönderilmeli ve ne zaman\n\nİyi bir hatırlatma dizisi tutarlı, saldırgan değilmiş gibi hissettirmelidir. Amaç ödemeyi kolay ve tahmin edilebilir yapmak, aynı zamanda ekibe net bir takip yolu vermektir. Panoya entegre edildiğinde, her mesaj faturanın o an gerçekten neye ihtiyacı olduğuyla ilişkilendirilebilir.\n\nAşamaları sade tutun:\n\n- Dostça hatırlatma: vade öncesi veya hemen sonrası için hafif bir uyarı\n- Kesin takip: net bir "lütfen şu tarihe kadar ödeyin" talebi\n- Son bildirim: manuel işleme geçmeden önce son deneme\n\nKanal seçimi sözcüklerden en az onun kadar önemlidir. E-posta faturalar, makbuzlar ve bağlam için daha iyidir. SMS kısa ve çabuk okunacak uyarılar için daha uygundur. Mümkünse müşteri tercihlerini saklayın (sadece e-posta, sadece SMS, her ikisi) ve SMS için onay yoksa e-postayı varsayılan yapın.\n\nZamanlama kuralları herkesin açıklayabileceği kadar basit olmalı. Yaygın bir düzen: vadeden 3 gün önce (dostça), vadeden 3 gün sonra (kesin), sonra 30 güne kadar haftalık. Yüksek tutarlı faturalar için vadeden sonraki aralığı kısaltın. Uzun vadeli müşterilere daha fazla tolerans verin.\n\nMesajlar kısa, kibar ve net olsun. Her hatırlatma üç soruyu yanıtlamalı: ne borçlu, ne zaman vadesi geçmiş ve nasıl ödenir.\n\nBasit içerik kontrol listesi:\n\n- Bir net konu satırı veya ilk cümle: "Invoice #1043 now past due" tarzı (yerelleştirilebilir)\n- Tutar, vade tarihi ve fatura numarası\n- Bir veya iki ödeme seçeneği (kart, banka transferi) ve kimle iletişime geçileceği\n- Suçlayıcı olmayan bir dil — varsayım: "gözden kaçmış olabilir"\n- Net bir sonraki adım: "Cuma tekrar takip edeceğiz" gibi\n\nAppMaster'da her aşama ve kanal için şablonlar saklayabilir, sonra vade tarihi ve müşteri tercihlerine göre doğru şablonu seçebilirsiniz.\n\n## Otomasyon mantığı: hatırlatmaları zamanla ve ödendiğinde durdur\n\nAmaç basit: bir fatura tahsil edilebilir hale geldiğinde hatırlatmalar başlamalı, ve o olmaktan çıktığında durmalıdır. Otomasyon her ikisini de güvenilir yapamıyorsa pano gürültü kaynağına döner.\n\nPratik tetiklerden biri şudur:\n\n- Fatura Open olarak oluşturulduğunda, veya\n- Fatura onay sonrası Open durumuna geçtiğinde\n\nİkinci tetikleme, faturalar Draft veya Pending olarak başlıyorsa önemlidir; sadece gerçek hale geldiğinde hatırlatma başlamalıdır.\n\n### Spam yapmadan hatırlatmaları nasıl zamanlarsınız\n\n"Her X gün gönder" demek yerine, mesajları vade tarihine ve mevcut kovaya bağlayın. Bu, vade tarihi değişse bile düzeni tutar ve tahsilat ekiplerinin düşünme biçimine uyar.\n\nTemiz bir kural seti şöyle olabilir:\n\n- Vade öncesi: nazik bir hatırlatma (örneğin 3 gün önce)\n- 1–7 gün gecikme: 1 hatırlatma\n- 8–30 gün gecikme: aralıklı 1–2 hatırlatma\n- 31+ gün gecikme: daha az ama daha kesin temaslar; aramaya geçmeyi düşünün\n- Vade veya durum değişirse takvimi yeniden hesaplayın\n\nAppMaster'da bu, fatura olaylarında çalışan bir Business Process'e ve bugün gönderilecekleri kontrol eden zamanlanmış bir işe kolayca uyar.\n\n### Durdurma koşulları ve güvenlik kontrolleri\n\nDurdurma kuralları gönderimden hemen önce kontrol edilmelidir, yalnızca planlarken değil. Böylece ödeme beş dakika önce kaydedildiyse sistem garip bir mesaj göndermez.\n\nYaygın durdurma koşulları:\n\n- Ödeme kaydedildi (ödeme açık bakiyeyi karşıladı veya durum Paid oldu)\n- Fatura kapatıldı veya tahsil edilmedi olarak yazıldı (written off)\n- İtiraz veya bekleme durumu (insana yönlendir)\n- Müşteri e-posta/SMS'den çıkmış\n- İletişim bilgileri eksik (e-posta/telefon yok)\n\nBasit bir örnek: fatura 8 gün gecikti, sistem bir SMS planlar. Gönderim anında bakiye tekrar kontrol edilir, bir ödeme görüldüğü için kalan diziler temizlenir ve "stopped: paid" olarak kaydedilir; ekip ne olduğunu güvenle görebilir.\n\n## Kontroller ve izleme, işin karışmaması için\n\nHatırlatmalar gitmeye başladığında, güveni kaybetmenin en hızlı yolu ne olduğunu ve nedenini bilmemektir. Her faturanın net bir geçmişi olmalı ve her gönderim bir bakışta açıklanabilir olmalıdır.\n\nHafif bir denetim izi genellikle yeterlidir. Müşteri deneyimini değiştiren olayları izleyin, her küçük düzenlemeyi değil. Her fatura için şu soruların yanıtını veren bir zaman çizelgesi tutun: ne değişti, kim yaptı ve ne gönderildi.\n\nTemel olayları kaydedin:\n\n- Durum değişiklikleri (Open, In dispute, Promise to pay, Paid, Written off) kullanıcı ve zaman damgasıyla\n- Hatırlatma gönderimleri (kanal, şablon adı, deneme numarası, sonuç)\n- Ödeme güncellemeleri (tutar, tarih, kaynak ve kim onayladı)\n- Önemli düzenlemeler (tutar, vade tarihi, müşteri iletişim bilgileri)\n- Manuel işlemler (hatırlatmalar duraklatıldı, dizi durduruldu, insan müdahalesine yükseltildi)\n\nBaşarısız gönderimler kendi işlemine ihtiyaç duyar, yoksa sonsuza dek yeniden denemeye devam edersiniz. Geri dönen e-posta ve başarısız SMS erişimleri, iletişim verisini düzeltmek için bir sinyaldir. Denemeyi başarısız olarak işaretleyin, nedeni saklayın ve birinin incelemesi için net bir sonraki adım oluşturun.\n\nÇalışabilir bir politika:\n\n- Geçici başarısızlıklar için kısa bir gecikmeden sonra bir kez yeniden dene\n- Tekrar başarısız olursa diziyi duraklat ve faturayı işaretle\n- Sahibi e-posta/telefonu doğrulaması için uyar\n- İletişim verisi güncellenirse diziyi bir sonraki adımdan sürdür (ilk adımdan değil)\n- Kesin bounce varsa e-posta hatırlatmalarını durdur ve başka bir kanala geç\n\nNotlar "insan gerçeğinin" yaşadığı yerdir. Raporlama temiz kalsın diye hızlı yapılandırılmış sonuçlar ekleyin (taahhüt edilen ödeme tarihi, arama denendi, müşteri fatura yanlış diyor, kısmi ödeme anlaşıldı, itiraz detayları). Serbest metin de tutun ama filtreleyebilmek için öncelikle birkaç açılır liste kullanın.\n\nİzinleri erkenden belirleyin. Herkes tutar veya vade tarihini değiştirememeli; "hatırlatmaları durdur" yetkisi denetlenebilir olmalı. AppMaster'da bu, role dayalı erişim ve hassas düzenlemelere yalnızca onaylı rollerin eriştiği bir Business Process ile iyi eşleşir; temsilciler not ekleyip sonuç işaretleyebilir ama mali alanları değiştiremez.\n\n## Kızgın müşterilere yol açan yaygın hatalar (ve nasıl önlenir)\n\nMüşterinin zaten yaptığı şeyi görmezden gelen bir hatırlatma, itimayeyi hızlıca yakar. Otomasyonla ilgili şikayetlerin çoğu hatırlatma içeriğiyle değil, kötü veri veya belirsiz kurallarla ilgilidir.\n\n### Zaten ödenmiş faturalar için hatırlatma göndermek\n\nBu genellikle ödeme durumu geciktiğinde veya "ödendi" bilgisi bir yerde, "açık" bilgisi başka yerde tutulduğunda olur. Bunu tek bir alanı gerçek kaynağı yaparak düzeltin (genellikle fatura durumu) ve mesaj gönderilmeden hemen önce taze bir kontrol yapın.\n\nAR yaşlandırma panosu kullanıyorsanız, durum güncellemesini hatırlatma ile aynı iş akışının parçası gibi ele alın, ayrı bir düşünce olmasın.\n\n### Çok fazla kova ve çok fazla aşama\n\nAşırı tasarım gürültü yaratır, müşteriler spam gibi hisseder. Çoğu ekip için üç ila beş kova ve iki ila üç hatırlatma aşaması yeterlidir. Daha fazlasına ihtiyaç varsa genelde sorun belirsiz mesaj içeriği veya belirsiz sahipliktir, yeni bir adım eksikliği değil.\n\n### Sahip yok\n\nHiç kimsenin faturaya sahip olmadığı durumlarda herkes başkasının ilgileneceğini varsayar. Müşteri, bölge veya fatura yaratıcısına göre basit bir atama kuralı "hayalet faturaların" beklemesini önler.\n\n### Şikayetleri önleyen pratik düzeltmeler\n\n- Gönderim anında fatura durumunu tekrar kontrol edin ve ödeme kaydedildiğinde dizileri hemen durdurun.\n- Kovaları basit tutun (örneğin: 1–7, 8–14, 15–30, 30+) ve mesajları 2–3 aşamada sınırlandırın.\n- Her faturanın hatırlatma dizisine girmeden önce bir sahibi olmasını zorunlu kılın.\n- İtirazlar, krediler ve kısmi ödemeler için "duraklatma"nın ne anlama geldiğini tanımlayın.\n\n### İtirazlar, krediler ve kısmi ödemeler: kuralı açık yapın\n\nKısmi ödemeler otomasyonun en çok çöktüğü yerdir. Hatırlatmaların kalan bakiyeye yönelik mi gönderileceğine (güncellenmiş dil ile) yoksa insan onayı bekleyene kadar duraklatılacağına karar verin.\n\nİtirazlar için "On Hold - Dispute" gibi açık bir durum kullanın ki hatırlatmalar otomatik olarak durdurulsun.\n\nAppMaster'da bu kurallar genelde gönderim öncesi kontrol edilebilen durum, bakiye ve bekletme nedenlerinin alan olarak tutulmasıyla en kolay uygulanır.\n\n## Hatırlatmaları açmadan önce kısa kontrol listesi\n\nOtomatik e-posta ve SMS hatırlatmalarını etkinleştirmeden önce gerçekçi verilerle kısa bir deneme çalıştırın. Küçük bir kurulum hatası yardımcı bir uyarıyı kafa karıştırıcı bir mesaja veya daha kötüsü yanlış kişiye gönderilen bir mesaja dönüştürebilir.\n\nHer açık faturanın işlem yapılabilir olduğundan emin olarak başlayın. Eğer faturanın vade tarihi yoksa dizi yanlış zamanda tetiklenir. Eğer sahibi yoksa kimse sorumluluk almaz.\n\nSon kapı olarak bu kontrol listesini kullanın:\n\n- Her açık faturanın vade tarihi ve sahibi var. Eksikse o faturanın hatırlatmalarını düzeltilene kadar engelleyin.\n- Yaşlandırma toplamlarınız muhasebe toplamlarıyla eşleşiyor. Kısmi ödemeleri, kredileri ve itirazlı faturaları nasıl sayacağınızı baştan kararlaştırın ve bilinen bir dönemle doğrulayın.\n- En az bir durdurma koşulu test edildi ve doğrulandı. "Ödendi" açık ama ayrıca "fatura iptal", "tahsil edilmedi" veya "alacak ajansına gönderildi" gibi senaryoları da test edin.\n\n- Test ödemesi planlı hatırlatmaları iptal ediyor. Örnek bir fatura oluşturun, bir hatırlatma planlanmasına izin verin, sonra bir ödeme kaydedin ve gelecekte mesaj gitmediğini doğrulayın.\n- Opt-out ve tercih edilen kanal kuralları gözetiliyor. Müşteri SMS tercih ediyorsa e-posta göndermeyin. Opt-out varsa tüm önemsiz hatırlatmaları hemen durdurun.\n\nTam açmadan önce küçük bir grup faturayla kontrollü bir test yapın. Örneğin: bugün vadesi olan, 7 gün gecikmiş ve 21 gün gecikmiş üç fatura oluşturun. Önce sadece dahili test kontaklarına gönderin, metin ve zamanlamayı doğrulayın, sonra gerçek müşterilere geçin.\n\nAppMaster'da kontrolleri iş akışına yakın tutun: fatura oluşturulurken zorunlu alanları doğrulayın ve Business Process içinde "ödeme kaydedildiğinde" fatura durumunu güncelleyip bekleyen e-posta ve SMS hatırlatmalarını iptal edin.\n\n## Örnek: sürekli kovalamaya gerek kalmadan küçük bir ekip tahsilat yapıyor\n\nKüçük bir hizmet şirketinin bir finans sahibi Mia ve bir satış lideri Jordan var. Bir AR yaşlandırma panosu kullanıyorlar, böylece e-spreadsheetlere bakmak zorunda kalmadan bugün ne vadesi geldiğini görebiliyorlar.\n\nBir müşteri, Northwind Dental, üç açık faturaya sahip:\n\n- Fatura #1021: 1.200$ ve 12 gün gecikmiş (1–30 kovası)\n- Fatura #1033: 800$ ve 37 gün gecikmiş (31–60 kovası)\n- Fatura #1040: 450$ ve henüz vadesi gelmemiş (Current)\n\nMia her sabah sahip kuyruğuyla başlar. Kuyruk ona atanmış hesaplarla filtrelenmiş ve önceliğe göre sıralanmış, böylece ne yapacağına karar vermek için zaman kaybetmez.\n\nRutin basittir:\n\n- 31–60 içindeki hiçbir şey önce kişisel bir e-posta alır\n- Taahhüt edilen ödeme tarihi olan faturalar hatırlatma öncesi kontrol edilir\n- Yüksek tutarlı hesaplar sadece mesaj değil, arama görevi de alır\n- Son zamanlarda itiraz olan hesaplar duraklatılır ve doğru ekip arkadaşına yönlendirilir\n\nNorthwind Dental için 37 günlük fatura bugün bir dizi adımını tetikler. Saat 09:00'da sistem fatura numarası, tutar ve net bir sonraki adımı (ödeme tarihiyle cevap verin veya şimdi ödeyin) referans gösteren bir e-posta planlar. İki iş günü içinde hiçbir etkinlik yoksa SMS takip planlar. Yeni 12 günlük fatura daha hafif bir akışta kalır, daha az hatırlatma alır.\n\nSaat 11:18'de Northwind Fatura #1033'ü öder. Ödeme kaydedildiği anda otomasyon o faturaya bağlı gelecekteki hatırlatmaları iptal eder. Hesaba ertesi gün gitmesi planlanan SMS gönderilmez. Mia müşteri detay görünümünde durum değişimini ve dizinin ödendiği için durdurulduğuna dair zaman çizelgesi notunu görür.\n\nEn iyi yanı, Mia kuralları hatırlamak zorunda değil: pano ona yapılacakları gösterir ve iş akışı zamanlamayı yönetir.\n\nGüvenli bir yaygınlaştırma planı tahmin edilebilir tutar:\n\n- Farklı kovalar arasından 10–20 müşteriyle pilot başlatın\n- Yanıtları, itirazları ve opt-out'ları haftalık gözden geçirip metni ayarlayın\n- Temiz sonuçlar görmeden bir dizi adım daha eklemeyin\n\n- "Ödemede durdur" mantığı kanıtlandığında tüm AR listesine genişletin\n\nBu uçtan uca çözümü kod yazmadan AppMaster'da kurabilirsiniz: Data Designer ile faturaları ve ödemeleri modelleyin, UI builders ile pano ekranlarını oluşturun, Business Process Editor'de hatırlatma ve durdurma kurallarını tanımlayın ve yerleşik mesajlaşma entegrasyonlarıyla mesaj gönderin.