Dashboard aging piutang dengan sekuens pengingat otomatis

Masalah yang diselesaikan dashboard ini (dan mengapa penting)

Aging piutang (AR) adalah gagasan sederhana: menunjukkan sudah berapa lama faktur belum dibayar. Alih-alih menatap daftar datar, Anda melihat faktur dikelompokkan berdasarkan waktu sejak tanggal jatuh tempo (atau sejak tanggal faktur), seperti 0-30 hari, 31-60, dan seterusnya. Satu tampilan itu menjawab dua pertanyaan harian dengan cepat: apa yang berisiko, dan siapa yang perlu diberi dorongan hari ini.

Kebanyakan sistem pengingat gagal saat tetap manual. Seseorang harus ingat memeriksa daftar, memutuskan apa yang dikirim, menyalin email pelanggan, dan menekan kirim. Pada minggu sibuk, tindak lanjut terlewat. Pada minggu sepi, orang bereaksi berlebihan dan mengirim terlalu banyak pesan, atau mereka lupa siapa yang sudah membalas. Hasilnya nada dan waktu yang tidak konsisten, dan itu bisa membuat pelanggan baik merasa terganggu.

Dashboard aging piutang memperbaiki ini dengan memasangkan visibilitas dan tindak lanjut yang konsisten:

• Visibilitas: semua orang melihat kebenaran yang sama - total jumlah jatuh tempo, pelanggan mana yang mulai bergeser, dan faktur mana yang macet.
• Tindak lanjut konsisten: pengingat dikirim sesuai jadwal yang dapat diprediksi dan sejalan dengan kebijakan Anda, bukan suasana hati.

Penyiapan yang baik membuat tim fokus pada beberapa faktur yang paling penting, mengurangi tebak-tebakan "Sudah kita tindaklanjuti?", mendorong pelanggan sebelum faktur menjadi masalah nyata, dan memperlakukan pelanggan yang andal berbeda dari yang sering telat.

“Berhenti otomatis saat dibayar” adalah bagian yang mencegah rasa malu. Begitu pembayaran dicatat (atau faktur ditandai dibayar), sistem membatalkan sisa pengingat untuk faktur itu. Jadi pelanggan yang membayar pagi ini tidak akan mendapat "Pemberitahuan terakhir" malam ini.

Jika Anda ingin membangunnya tanpa proyek engineering panjang, AppMaster adalah salah satu opsi praktis: Anda bisa memodelkan faktur dan pembayaran, membuat tampilan aging, dan menjalankan sekuens pengingat yang berhenti atau dijeda berdasarkan status pembayaran nyata.

Mulai dari tabel AR: data yang benar-benar Anda butuhkan

Pengingat Anda hanya sebaik data Anda. Sebelum membuat layar atau otomatisasi, definisikan satu tabel AR bersih yang dapat dipercaya oleh semua tampilan dan sekuens pengingat.

Mulailah dengan bidang minimum yang menjawab satu pertanyaan: berapa yang terutang, oleh siapa, dan kapan.

• Nomor faktur (atau ID faktur)
• Pelanggan (nama akun dan ID pelanggan unik)
• Jumlah terutang (saldo terbuka, bukan hanya total faktur asli)
• Tanggal jatuh tempo
• Status (Terbuka, Dibayar sebagian, Dibayar, Dalam sengketa, Dihapuskan)

Setelah itu berjalan, tambahkan hanya bidang yang mengurangi pengejaran manual dan memperjelas serah terima:

• Pemilik yang ditugaskan (orang atau tim yang bertanggung jawab)
• Tanggal pencatatan pembayaran (ketika saldo menjadi nol)
• Pengingat terakhir dikirim (tanggal/waktu dan saluran)
• Pengingat berikutnya terjadwal (tanggal/waktu)
• Catatan atau kode alasan (opsi pendek dan terkontrol seperti Dalam sengketa atau Menunggu PO)

Pembayaran sebagian dan kredit: putuskan sejak awal

Pembayaran sebagian dan kredit perlu keputusan di awal, atau alur kerja jadi berantakan nanti.

Pendekatan sederhana adalah menyimpan total faktur di record faktur, lalu melacak pergerakan uang di tabel "transaksi" terpisah (pembayaran, memo kredit, penyesuaian). Record AR Anda bisa menyimpan saldo terbuka yang dihitung dan status “Dibayar sebagian.” Ini menghindari edit berantakan dan menjaga jejak audit.

Pilih satu sumber kebenaran untuk “dibayar”

Sepakati satu “sumber kebenaran” kapan pembayaran dicatat.

• Jika sistem akuntansi Anda otoritatif, perlakukan aplikasi Anda sebagai cermin yang memperbarui darinya.
• Jika Anda mencatat pembayaran di dalam aplikasi Anda, batasi siapa yang bisa menandai faktur sebagai Dibayar, dan wajibkan jumlah serta tanggal yang tercatat.

Di AppMaster, Anda bisa menegakkan ini dengan aturan database plus langkah persetujuan sederhana di Business Process Editor, sehingga pengingat berhenti karena alasan yang benar, setiap saat.

Bucket aging yang sesuai cara kerja tim Anda

Laporan aging AR yang baik harus mencerminkan cara orang sebenarnya membicarakan faktur lewat jatuh tempo. Jika tim Anda sudah bilang “itu di tumpukan 31-60,” dashboard Anda harus mencerminkan itu. Ini menjaga serah terima tetap rapi dan membantu Anda menemukan masalah yang tepat dengan cepat.

Kebanyakan tim baik-baik saja dengan:

• Current (belum lewat jatuh tempo)
• 1-30 hari lewat jatuh tempo
• 31-60 hari lewat jatuh tempo
• 61-90 hari lewat jatuh tempo
• 90+ hari lewat jatuh tempo

Untuk menempatkan faktur ke bucket, hitung Hari lewat jatuh tempo:

Hari lewat jatuh tempo = (tanggal hari ini) - (tanggal jatuh tempo)

Jika hasilnya negatif, faktur belum jatuh tempo. Banyak tim memisahkan itu dari “Current,” karena “Current” sering berarti jatuh tempo hari ini atau segera, sementara “Belum jatuh tempo” benar-benar lebih dini. Pemisahan kecil ini bisa mencegah pengingat canggung ke pelanggan yang masih punya waktu.

Aging berdasarkan tanggal jatuh tempo vs tanggal faktur

Pilih satu metode dan pakai di mana-mana: dashboard, logika pengingat, dan pelaporan.

• Umur berdasarkan tanggal jatuh tempo jika Anda ingin penagihan adil dan konsisten dengan syarat pembayaran. Ini pilihan paling umum untuk dashboard aging piutang.
• Umur berdasarkan tanggal faktur jika bisnis Anda mengharapkan pembayaran segera (umum di beberapa ritel atau layanan) atau jika tanggal jatuh tempo tidak dapat diandalkan.

Kompromi praktis adalah menyimpan kedua bidang, tetapi mengelompokkan berdasarkan tanggal jatuh tempo. Saat tanggal jatuh tempo hilang, gunakan tanggal faktur sebagai cadangan dan beri tanda supaya seseorang memperbaiki datanya.

Kasus khusus yang butuh status sendiri

Bucket saja tidak cukup. Anda juga perlu status yang mengesampingkan aging supaya tim tidak mengejar orang yang salah.

• Dalam sengketa: pelanggan mengajukan masalah, jeda pengingat sampai diselesaikan.
• Ditahan: jeda internal (misalnya menunggu PO yang dikoreksi).
• Janji bayar: pelanggan berkomitmen ke tanggal, tunda dorongan berikutnya.
• Dibayar, belum diposting: pembayaran diterima tetapi belum dicatat, hindari outreach duplikat.

Modelkan status ini di tabel AR Anda sehingga dashboard dan otomatisasi alur kerja penagihan bisa memfilternya dari antrean standar secara otomatis. Di tool seperti AppMaster, itu biasanya berarti menambah field status dan memeriksanya di tampilan serta logika bisnis.

Tampilan dashboard: ringkasan, antrean pemilik, dan detail pelanggan

Dashboard yang baik melakukan satu hal dengan baik: memberi tahu apa yang perlu perhatian sekarang tanpa memaksa menelusuri faktur satu per satu. Tiga tampilan mencakup kebanyakan tim: gambaran besar, antrean kerja harian, dan timeline per pelanggan.

1) Tampilan ringkasan (layar “kita di mana?”)

Ringkasan Anda harus menjawab pertanyaan yang sama setiap kali dibuka: berapa banyak yang terbuka, berapa banyak yang lewat jatuh tempo, dan siapa yang mendorong risiko.

Jaga tetap sederhana:

• Total saldo terbuka dan total saldo lewat jatuh tempo
• Pembagian lewat jatuh tempo menurut bucket (mis. 1-30, 31-60, 61-90, 90+)
• Pelanggan paling tertunggak (berdasarkan jumlah, bukan jumlah faktur)
• Angka cepat “baru lewat sejak minggu lalu” untuk mendeteksi masalah baru lebih awal

Tampilan ini untuk manajer dan siapa pun yang melakukan pengecekan cepat sebelum rapat.

2) Antrean pemilik (layar “apa yang harus saya lakukan hari ini?”)

Antrean pemilik mengubah laporan menjadi daftar tugas. Setiap orang harus melihat hanya akun yang mereka miliki, dengan tindakan berikutnya ditunjukkan jelas.

Tetap pada bidang “harus ditindak”: pelanggan, total tertunggak, faktur tertunggak tertua, tanggal sentuhan terakhir, langkah berikutnya, dan status sederhana seperti “Pengingat 2 terjadwal” atau “Perlu panggilan.”

Jika Anda membangun ini di AppMaster, tampilan tabel bersih plus beberapa field terhitung (seperti hari lewat jatuh tempo dan tanggal pengingat berikutnya) seringkali sudah cukup.

3) Detail pelanggan (layar “apa ceritanya?”)

Saat seseorang menjawab, “Kami sudah membayar,” tim Anda membutuhkan konteks dengan cepat. Tampilan detail pelanggan harus menggabungkan faktur dan komunikasi di satu tempat: faktur terbuka, riwayat pembayaran, catatan, sentuhan terakhir, dan langkah yang direncanakan berikutnya.

Simpan beberapa filter dekat agar orang bisa fokus dengan cepat, misalnya wilayah, tipe pelanggan, ambang jumlah (mis. hanya tunjukkan akun lebih dari $1.000 terlambat), rentang tanggal jatuh tempo, dan pemilik.

Skenario sederhana: Maria memiliki 40 akun. Di antreannya, ia memfilter ke “lebih dari $500” dan “jatuh tempo dalam 14 hari terakhir.” Dia mengklik satu pelanggan dan langsung melihat dua faktur terbuka, catatan bahwa mereka meminta nomor PO baru, dan pengingat email yang dijadwalkan besok. Dia memperbarui catatan, mengatur langkah berikutnya ke “Tunggu PO,” dan record tetap rapi bagi siapa pun yang menutupinya nanti.

Sekuens pengingat: apa yang dikirim dan kapan

Sekuens pengingat yang baik terasa konsisten, bukan agresif. Tujuannya membuat pembayaran mudah dan terduga, sambil memberi tim jalur jelas untuk tindak lanjut. Ketika ini dibangun ke dalam dashboard aging piutang, Anda bisa mengaitkan setiap pesan dengan apa yang faktur butuhkan sekarang.

Pertahankan tahap sederhana:

• Pengingat ramah: dorongan ringan sebelum atau tepat setelah tanggal jatuh tempo
• Tindak lanjut tegas: langkah jelas berikutnya dan tanggal “harap bayar sebelum” yang spesifik
• Pemberitahuan terakhir: upaya terakhir sebelum Anda beralih ke penanganan manual

Pilihan kanal sama pentingnya dengan kata-kata. Email lebih baik untuk faktur, tanda terima, dan konteks. SMS lebih baik untuk dorongan singkat yang cepat dibaca. Jika bisa, simpan preferensi pelanggan (hanya email, hanya SMS, keduanya) dan default ke email ketika Anda tidak punya izin untuk mengirim SMS.

Aturan waktu harus cukup sederhana sehingga siapa pun bisa menjelaskannya. Pengaturan umum: 3 hari sebelum jatuh tempo (ramah), 3 hari setelah jatuh tempo (tegas), lalu mingguan sampai 30 hari lewat jatuh tempo. Untuk faktur bernilai tinggi, singkatkan jeda setelah tanggal jatuh tempo. Untuk pelanggan jangka panjang, beri lebih banyak kelonggaran.

Jaga pesan singkat, sopan, dan spesifik. Setiap pengingat harus menjawab tiga pertanyaan: apa yang jatuh tempo, kapan jatuh tempo, dan bagaimana cara membayar.

Checklist isi sederhana:

• Satu baris subjek atau kalimat pembuka yang jelas: “Faktur #1043 kini lewat jatuh tempo”
• Jumlah, tanggal jatuh tempo, dan nomor faktur
• Satu atau dua opsi pembayaran (kartu, transfer bank) dan siapa yang dihubungi
• Tanpa menyalahkan - anggap itu terlewat
• Langkah jelas berikutnya (“Kami akan menindaklanjuti lagi hari Jumat”)

Jika Anda membangun ini di AppMaster, Anda bisa menyimpan template untuk setiap tahap dan kanal, lalu memilih yang tepat berdasarkan tanggal jatuh tempo dan preferensi pelanggan.

Logika otomatisasi: jadwalkan dorongan dan hentikan saat dibayar

Tujuannya sederhana: pengingat harus dimulai saat faktur menjadi dapat ditagih, dan harus berhenti saat faktur tidak lagi demikian. Jika otomatisasi tidak bisa melakukan kedua hal itu dengan andal, dashboard Anda berubah menjadi sumber kebisingan.

Pemicu praktis adalah salah satu dari:

• Saat faktur dibuat dengan status Terbuka, atau
• Saat faktur berubah menjadi Terbuka setelah disetujui

Pemicu kedua penting jika faktur dimulai sebagai Draft atau Pending dan baru menjadi nyata kemudian.

Cara menjadwalkan pengingat tanpa menyebalkan

Alih-alih “kirim setiap X hari,” kaitkan pesan ke tanggal jatuh tempo dan bucket saat ini. Itu menjaga irama konsisten bahkan jika tanggal faktur berubah, dan sesuai cara berpikir tim penagihan.

Aturan yang bersih bisa terlihat seperti:

• Sebelum tanggal jatuh tempo: dorongan ringan (mis. 3 hari sebelum)
• 1-7 hari lewat jatuh tempo: 1 pengingat
• 8-30 hari lewat jatuh tempo: 1-2 pengingat (tersebar)
• 31+ hari lewat jatuh tempo: sentuhan lebih sedikit, lebih tegas, dan pertimbangkan mengalihkan ke tugas panggilan
• Hitung ulang jadwal jika tanggal jatuh tempo atau status berubah

Di AppMaster, ini dipetakan rapi ke Business Process yang berjalan pada event faktur plus job terjadwal yang memeriksa apa yang harus dikirim hari ini.

Kondisi hentikan dan pemeriksaan keselamatan

Aturan berhenti harus diperiksa tepat sebelum pengiriman, bukan hanya saat penjadwalan. Dengan begitu, jika pembayaran dicatat lima menit lalu, sistem tidak akan mengirim pesan canggung.

Kondisi berhenti umum:

• Pembayaran dicatat (jumlah dibayar menutupi saldo, atau status menjadi Dibayar)
• Faktur ditutup atau dihapuskan
• Status sengketa atau ditahan disetel (alihkan ke manusia)
• Pelanggan memilih keluar dari email/SMS
• Detail kontak hilang (tidak ada email/telepon)

Satu contoh sederhana: sebuah faktur mencapai 8 hari lewat jatuh tempo, jadi sistem merencanakan SMS. Saat pengiriman, sistem memeriksa saldo lagi, melihat pembayaran diposting, membersihkan langkah sisa dalam sekuens, dan mencatat “dihentikan: dibayar” sehingga tim Anda bisa mempercayai apa yang terjadi.

Kontrol dan pelacakan supaya tidak berantakan

Begitu pengingat mulai keluar, cara tercepat kehilangan kepercayaan adalah tidak tahu apa yang terjadi dan kenapa. Setiap faktur harus punya riwayat yang jelas, dan setiap dorongan harus bisa dijelaskan dengan sekilas.

Jejak audit ringan biasanya cukup. Lacak peristiwa yang mengubah pengalaman pelanggan, bukan setiap edit kecil. Untuk setiap faktur, simpan timeline yang menjawab: apa yang berubah, siapa yang melakukannya, dan apa yang dikirim.

Catat hal dasar:

• Perubahan status (Terbuka, Dalam sengketa, Janji bayar, Dibayar, Dihapuskan) dengan pengguna dan cap waktu
• Pengiriman pengingat (kanal, nama template, nomor percobaan, hasil)
• Pembaruan pembayaran (jumlah, tanggal, sumber, dan siapa yang mengonfirmasi)
• Edit kunci (jumlah, tanggal jatuh tempo, detail kontak pelanggan)
• Aksi manual (pengingat dijeda, sekuens dihentikan, eskalasi ke manusia)

Pengiriman yang gagal perlu penanganan sendiri, atau Anda akan terus mencoba ke lubang hitam. Perlakukan email yang bounce dan SMS yang gagal sebagai sinyal untuk memperbaiki data kontak, bukan “coba lagi selamanya.” Tandai percobaan sebagai gagal, simpan alasannya, dan buat langkah jelas bagi seseorang untuk meninjaunya.

Kebijakan yang bisa diterapkan:

• Coba ulang sekali setelah jeda pendek (hanya untuk kegagalan sementara)
• Jika gagal lagi, jedakan sekuens dan beri tanda pada faktur
• Beri tahu pemilik untuk memverifikasi email/telepon
• Jika data kontak diperbarui, lanjutkan dari langkah berikutnya (bukan langkah pertama)
• Jika bounce keras, hentikan pengingat email dan pindah ke kanal lain

Catatan adalah tempat “kebenaran manusia” tinggal. Tambahkan hasil terstruktur cepat agar pelaporan tetap bersih (tanggal janji bayar, panggilan dicoba, pelanggan bilang faktur salah, pembayaran sebagian disepakati, rincian sengketa). Pertahankan teks bebas juga, tapi utamakan beberapa dropdown agar bisa difilter nanti.

Tetapkan izin sejak awal. Tidak semua orang boleh mengubah jumlah atau tanggal jatuh tempo, dan "menghentikan pengingat" harus dapat diaudit. Di AppMaster, ini cocok dengan akses berbasis peran plus Business Process yang memungkinkan edit sensitif hanya untuk peran yang disetujui, sambil tetap membiarkan perwakilan menambahkan catatan dan menandai hasil tanpa menyentuh field finansial.

Kesalahan umum yang membuat pelanggan marah (dan cara menghindarinya)

Tak ada yang membakar goodwill lebih cepat daripada pengingat yang mengabaikan apa yang sudah dilakukan pelanggan. Kebanyakan keluhan tentang otomatisasi bukan karena pengingatnya sendiri. Mereka karena data buruk atau aturan yang tidak jelas.

Mengirim pengingat untuk faktur yang sudah dibayar

Ini biasanya terjadi saat pembaruan status pembayaran tertinggal, atau saat Anda melacak “dibayar” di satu tempat dan “terbuka” di tempat lain. Perbaiki dengan menjadikan satu field sumber kebenaran (seringkali status faktur), dan hanya mengirim pengingat setelah pemeriksaan segar tepat sebelum pesan keluar.

Jika Anda menggunakan dashboard aging piutang, perlakukan pembaruan status sebagai bagian dari alur kerja yang sama dengan pengingat, bukan sebagai pemikiran terpisah.

Terlalu banyak bucket dan terlalu banyak tahap

Overengineering menciptakan kebisingan, dan pelanggan merasa spam. Tiga sampai lima bucket cukup untuk kebanyakan tim, dan dua sampai tiga tahap pengingat biasanya mencukupi. Jika Anda butuh lebih, masalahnya sering kali isi pesan yang tidak jelas atau kepemilikan yang tidak jelas, bukan kurangnya langkah.

Tidak ada pemilik yang jelas

Saat tidak ada yang memiliki faktur, semua orang menganggap orang lain yang menanganinya. Aturan penugasan sederhana (berdasarkan pelanggan, wilayah, atau pembuat faktur) mencegah “faktur hantu” dari duduk di limbo.

Perbaikan praktis yang mencegah keluhan

• Periksa ulang status faktur saat pengiriman, dan hentikan sekuens segera saat pembayaran dicatat.
• Jaga bucket sederhana (mis. 1-7, 8-14, 15-30, 30+) dan batasi pesan ke 2-3 tahap.
• Wajibkan pemilik pada setiap faktur sebelum bisa masuk sekuens pengingat.
• Definisikan apa arti “jeda” untuk sengketa, kredit, dan pembayaran sebagian.

Sengketa, kredit, dan pembayaran sebagian: buat aturan eksplisit

Pembayaran sebagian adalah titik di mana otomatisasi sering rusak. Putuskan apakah pengingat menargetkan sisa saldo (dengan bahasa yang diperbarui), atau dijeda sampai manusia mengonfirmasi rencana.

Untuk sengketa, gunakan status jelas seperti “Ditahan - Sengketa” sehingga pengingat berhenti otomatis tanpa seseorang harus mengingatnya.

Di AppMaster, aturan ini paling mudah ditegakkan ketika status, saldo, dan alasan penahanan adalah field yang dapat Anda periksa di Business Process tepat sebelum mengirim email atau SMS apa pun.

Checklist cepat sebelum menyalakan pengingat

Sebelum Anda mengaktifkan pengingat email dan SMS otomatis, lakukan dry run singkat dengan data realistis. Kesalahan pengaturan kecil bisa mengubah dorongan berguna menjadi pesan yang membingungkan, atau lebih buruk, pesan ke orang yang salah.

Mulailah dengan memastikan setiap faktur terbuka bisa ditindaklanjuti. Jika faktur tidak punya tanggal jatuh tempo, sekuens akan memicu pada waktu yang salah. Jika tidak punya pemilik, ia akan mengapung tanpa yang bertanggung jawab.

Gunakan checklist ini sebagai gerbang akhir:

• Setiap faktur terbuka punya tanggal jatuh tempo dan pemilik. Jika salah satu hilang, blokir pengingat untuk faktur itu sampai diperbaiki.
• Total aging Anda cocok dengan total akuntansi (berdasarkan aturan yang disepakati). Putuskan sejak awal bagaimana Anda menghitung pembayaran sebagian, kredit, dan faktur sengketa, lalu validasi terhadap periode yang diketahui.
• Setidaknya satu kondisi berhenti diuji dan diverifikasi. “Dibayar” jelas, tapi juga uji “faktur dibatalkan,” “dihapuskan,” atau “dikirim ke koleksi.”
• Pembayaran uji membatalkan pengingat yang terjadwal. Buat faktur contoh, biarkan pengingat terjadwal, lalu catat pembayaran dan konfirmasi tidak ada pesan berikutnya yang keluar.
• Aturan opt-out dan kanal yang disukai dihormati. Jika pelanggan memilih SMS, jangan kirimi email. Jika mereka opt-out, hentikan semua dorongan non-esensial segera.

Lakukan satu uji terkontrol dengan beberapa faktur sebelum rollout penuh. Misalnya: buat tiga faktur yang jatuh tempo hari ini, 7 hari lewat, dan 21 hari lewat. Kirim pengingat hanya ke kontak uji internal dulu, verifikasi kata-kata dan waktu, lalu beralih ke pelanggan nyata.

Jika Anda membangun ini di AppMaster, pertahankan pemeriksaan dekat dengan alur kerja: validasi field yang dibutuhkan saat faktur dibuat, dan di Business Process pastikan “pembayaran dicatat” memperbarui status faktur dan membatalkan email serta pengingat SMS yang sudah antre.

Contoh: tim kecil mengumpulkan pembayaran tanpa terus mengejar

Sebuah perusahaan jasa kecil punya satu pemilik keuangan, Mia, dan satu sales lead, Jordan. Mereka menggunakan dashboard aging piutang sehingga bisa melihat apa yang jatuh tempo hari ini tanpa memindai spreadsheet.

Satu pelanggan, Northwind Dental, punya tiga faktur terbuka:

• Faktur #1021 sebesar $1.200 terlambat 12 hari (bucket 1-30)
• Faktur #1033 sebesar $800 terlambat 37 hari (bucket 31-60)
• Faktur #1040 sebesar $450 belum jatuh tempo (bucket Current)

Mia memulai setiap pagi di tampilan antrean pemilik. Itu difilter ke akun yang ditugaskan ke dia dan diurutkan menurut prioritas, sehingga dia tidak membuang-buang waktu menebak harus melakukan apa terlebih dulu.

Rutinnya sederhana:

• Apa pun di 31-60 mendapat email personal terlebih dulu
• Faktur dengan tanggal janji bayar diperiksa sebelum didorong lagi
• Akun bernilai tinggi mendapat tugas panggilan, bukan hanya pesan
• Akun dengan sengketa baru dijeda dan dialihkan ke rekan yang tepat

Untuk Northwind Dental, faktur 37 hari memicu langkah sekuens hari ini. Pada jam 9:00, sistem menjadwalkan email yang merujuk nomor faktur, jumlah, dan langkah jelas berikutnya (balas dengan tanggal pembayaran atau bayar sekarang). Jika tidak ada aktivitas setelah dua hari kerja, sistem menjadwalkan tindak lanjut SMS. Faktur yang lebih baru 12 hari tetap pada jalur yang lebih ringan, dengan lebih sedikit dorongan.

Pada 11:18, Northwind membayar Faktur #1033. Begitu pembayaran dicatat, otomatisasi membatalkan pengingat masa depan yang terkait faktur itu. Akun tidak mendapat SMS yang seharusnya dikirim besok. Mia melihat perubahan status di tampilan detail pelanggan, bersamaan dengan catatan timeline bahwa sekuens dihentikan karena pembayaran.

Yang terbaik adalah Mia tidak perlu mengingat aturan. Dashboard menunjukkan apa yang tersisa untuk dilakukan, dan alur kerja menangani penjadwalan.

Rencana rollout yang aman membuatnya dapat diprediksi:

• Pilot dengan 10–20 pelanggan di berbagai bucket
• Tinjau balasan, sengketa, dan opt-out mingguan lalu sesuaikan kata-kata
• Tambah langkah sekuens hanya setelah melihat hasil yang bersih
• Perluas ke seluruh daftar AR setelah logika berhenti-saat-dibayar terbukti

Anda bisa membangun ini ujung-ke-ujung tanpa kode di AppMaster: modelkan faktur dan pembayaran di Data Designer, buat layar dashboard di UI builder, definisikan aturan pengingat dan berhenti di Business Process Editor, dan kirim pesan melalui integrasi pesan bawaan.