Sistem yang Membuat AI Otomatis Mengecek Penggunaan Kartu Setiap Malam, dan Hanya Memberi Notifikasi untuk 'Pengeluaran yang Perlu Didiskusikan'

Selamat pagi, saya Masakin.

Sebelumnya saya sudah memperkenalkan sistem yang menggabungkan AI dan freee untuk meninjau ulang keuangan rumah tangga setiap pagi. Kali ini adalah versi malamnya. Saya akan menulis tentang sistem yang membuat AI otomatis mengecek penggunaan kartu hari itu, sebelum tidur.

Kalau tinjauan pagi sifatnya “satu kesadaran dari tren kemarin”, sistem malam ini sedikit berbeda karakternya. Ini adalah sistem untuk menangkap “apakah ada pengeluaran hari ini yang sebaiknya diperiksa” pada hari yang sama. Kali ini saya akan membahas sampai rumus aturan penentuan dan kontrol detail saat eksekusi.

Awalnya Karena “Pengeluaran Besar Justru Sering Ditunda”

Pengeluaran kecil sehari-hari, tercatat secara alami di aplikasi keuangan rumah tangga. Tapi pengeluaran besar yang sifatnya sekali saja berbeda. Kadang terlupakan karena berpikir “nanti dibicarakan belakangan”.

Karena itu, saya membuat sistem yang khusus menangkap pengeluaran dengan jumlah besar, agar bisa disadari pada hari yang sama. Sistem ini tidak dijalankan manual oleh orang, tapi berjalan sebagai “scheduled task” yang dieksekusi otomatis pada waktu tertentu.

Hal yang Diperhatikan Justru Karena Eksekusi Otomatis

Karena berjalan otomatis pada waktu tertentu, tidak bisa meminta konfirmasi ke orang secara langsung saat itu. Karena itu, saya menetapkan aturan berikut sebagai prasyarat eksekusi.

• Meski salah satu proses pengambilan data gagal di tengah jalan, proses tidak dihentikan dan sisanya tetap dilanjutkan
• Kalau tidak bisa ditentukan, tidak dipaksakan dan cukup dilewati sambil dicatat di log
• Pada hari API eksternal gagal diambil, rekap normal dilewatkan dan sistem fallback ke tinjauan sederhana

Task otomatis ini didesain untuk mengutamakan “pasti menghasilkan sesuatu setiap hari” dibanding “berjalan sempurna”.

Menangani Pengeluaran dalam 3 Jenis

Kalau semua pengeluaran diperiksa dengan standar yang sama, hasilnya akan penuh notifikasi dan justru tidak dilihat lagi. Karena itu, saya membagi pengeluaran menjadi 3 jenis berikut.

Biaya tetap jumlahnya sama setiap bulan, jadi diperiksa berulang kali pun tidak ada gunanya. Pengeluaran yang sudah disepakati juga sudah dibicarakan sebelumnya, jadi tidak perlu notifikasi. Yang perlu diperiksa hanya “pengeluaran yang terjadi secara spontan” selain itu.

Contoh khas biaya tetap adalah sewa rumah atau biaya komunikasi. Justru karena jumlahnya hampir tidak berubah, ini dikeluarkan dari target pengecekan harian.

Untuk penyedia layanan yang penentuan subscription-nya ragu — apakah ini sekali beli atau pembelian berkala — saya tidak memaksa memasukkannya ke “subscription”, tapi mencatatnya sebagai baris terpisah berlabel “penentuan tertunda”. Kalau bagian ini dibiarkan ambigu, saya merasa keandalan rekap keseluruhan nanti akan goyah.

Namun, di antara pengeluaran yang dikecualikan dari pengecekan ini pun, ada perkecualiannya. Biaya tetap seperti biaya komunikasi, justru layak sesekali ditinjau ulang. Pengawasan harian bisa diotomatisasi, tapi tingkat biaya tetap itu sendiri hanya bisa diubah oleh saya sendiri.

Aturan Penentuan “Pengeluaran yang Perlu Didiskusikan”

Dari pengeluaran yang diperiksa, hanya yang melebihi jumlah tertentu yang diperlakukan sebagai “pengeluaran yang perlu didiskusikan”. Saya perlihatkan instruksi yang diberikan ke AI, sudah digeneralisasi.

Dari data transaksi kartu hari ini, ekstrak "pengeluaran yang perlu didiskusikan"
dengan langkah berikut.

1. Kecualikan transaksi yang sudah diklasifikasikan sebagai biaya tetap/subscription
2. Kecualikan transaksi yang sudah terdaftar di daftar kesepakatan sebelumnya
3. Dari transaksi yang tersisa, ekstrak yang jumlahnya per transaksi
   sama atau lebih dari jumlah tertentu (patokan sekitar ¥10.000)
4. Transaksi yang diekstrak, buat daftar dengan 3 item: "jumlah", "tempat", "waktu"

Jika tidak ada transaksi yang melebihi jumlah tertentu,
jawab hanya "tidak ada yang perlu didiskusikan hari ini".

Jumlah yang jadi patokan, saya rasa tingkat yang tepat berbeda-beda untuk setiap keluarga. Yang penting bukan “berapa jumlahnya”, tapi “menentukan patokan itu sebelumnya”. Kalau tidak ada patokan, akhirnya setiap kali harus dibahas ulang “apakah ini seharusnya didiskusikan atau tidak”.

Menangani Keterlambatan Sinkronisasi sebagai Angka

Integrasi kartu di SaaS keuangan rumah tangga, keterlambatan refleksi beberapa hari itu adalah hal yang normal. Setelah libur panjang, keterlambatannya bisa lebih lama lagi. Kalau ini diperlakukan sebagai “anomali”, notifikasinya akan penuh dengan deteksi salah. Karena itu, saya mengubah keterlambatan ini menjadi indikator numerik berikut.

• latest_txn_date: tanggal transaksi terakhir yang teramati untuk kartu itu
• lag_days: tanggal hari ini dikurangi latest_txn_date (dalam hari)
• lag_status: diklasifikasikan menjadi 4 tingkat berikut berdasarkan besarnya lag_days

Poinnya adalah tidak langsung menyimpulkan stalled, yaitu tidak terefleksikan dalam jangka waktu lama, sebagai “gangguan integrasi”. Kenyataannya, kasus “hanya karena kartu itu memang tidak dipakai untuk sementara” lebih sering terjadi.

Membedakan “Hanya Tidak Dipakai” dan “Gangguan Integrasi”

Ketika stalled terdeteksi, sebelum menyimpulkan, saya memeriksa pola transaksi 30 hari terakhir.

• Ada 1 transaksi atau lebih dalam 30 hari terakhir, dan hanya periode terbaru saja yang kosong 10 hari atau lebih → sekadar tidak dipakai untuk jangka waktu lama. Integrasi itu sendiri masih berfungsi
• Transaksi benar-benar 0 dalam 30 hari terakhir, padahal ada ingatan sebenarnya memakainya → dicurigai ada gangguan integrasi

Tapi, meski kondisi kedua terjadi, saya tidak langsung menyimpulkan “gangguan” begitu saja. Baru diperlakukan sebagai gangguan integrasi kalau 3 kondisi berikut terpenuhi semua.

1. stalled terjadi bersamaan pada beberapa kartu sekaligus
2. Ada catatan pemakaian sebenarnya, misalnya struk atau memo, tapi tidak muncul di SaaS keuangan rumah tangga
3. Bisa dikonfirmasi secara visual ada tampilan error sinkronisasi di layar SaaS keuangan rumah tangga itu

Selama 3 kondisi ini belum lengkap, saya perlakukan secara netral sebagai “kartu tidak dipakai selama N hari, kelanjutan tren berhemat”, tanpa memicu alert yang berlebihan. Sebelum ada pemilahan ini, saya sering cemas “apakah integrasinya rusak” hanya karena kartu itu memang tidak dipakai.

Menetapkan Batas Maksimum Jumlah Pemanggilan API Eksternal

Karena ini adalah task otomatis, saya menetapkan batas maksimum jumlah pemanggilan per eksekusi, agar tidak terjebak dalam loop yang memanggil API tanpa henti karena sebab tertentu.

• Menghitung dulu perkiraan jumlah pemanggilan untuk pola normal, misalnya pengambilan data hari itu atau akumulasi sejak awal bulan
• Meski terjadi error di luar perkiraan, hentikan retry begitu mencapai batas maksimum, dan langsung fallback sebagai “pengambilan gagal”
• Mengutamakan “menghentikan proses karena sudah mencapai batas jumlah” dibanding menunggu timeout

Kalau tidak ada batas yang ditetapkan, ada risiko terus mengulang retry saat terjadi error otentikasi misalnya, dan terus mengirim request yang sia-sia. Saya merasa, justru sistem yang berjalan otomatis yang paling perlu pengaman semacam ini.

Membedakan “Anomali yang Berlanjut” dan “Anomali Baru”

Saya juga menerapkan aturan notifikasi ketika pengeluaran dalam bulan itu melebihi persentase tertentu dari perkiraan. Tapi kalau ini langsung dipakai untuk notifikasi harian, begitu sekali melebihi batas, notifikasi yang sama akan terus muncul setiap malam sampai akhir bulan. Ini membuat “hari baru melewati ambang batas” dan “hari yang sudah melebihi dan tetap melebihi” jadi tidak bisa dibedakan.

Karena itu, saya menghitung sudah berapa hari kelebihan ini berlanjut, dan menyertakannya dalam bentuk “hari ke-X kelebihan berlanjut”. Dengan bisa membedakan anomali baru dan anomali yang sedang berlanjut, situasinya jadi lebih mudah dipahami dengan benar saat ditinjau ulang tiap minggu.

Notifikasi Sengaja Dibuat Datar

Bahkan pada hari ditemukan “pengeluaran yang perlu didiskusikan”, isi notifikasinya saya buat datar. Hanya menampilkan jumlah dan tempat pemakaian, tanpa memberi penilaian baik atau buruk.

Yang menentukan adalah kami sendiri. Peran AI saya batasi hanya sampai “membuat sadar akan pengeluaran yang mungkin terlewat”.

Yang Saya Rasakan Setelah Mencoba

Efek terbesarnya adalah hilangnya perselisihan “bilang atau tidak bilang” soal pengeluaran besar. Karena informasinya dibagikan pada hari yang sama, momentum untuk membicarakannya jadi tidak mudah terlewat.

Di sisi lain, penentuan jumlah patokan tidak bisa sempurna sejak awal. Kalau terlalu rendah, notifikasinya terlalu banyak dan jadi formalitas belaka, kalau terlalu tinggi, pengeluaran yang berarti justru terlewat. Setelah beberapa kali disesuaikan, akhirnya menetap di tingkat sekarang.

Cocok untuk Orang Seperti Apa

• Orang yang sudah mengintegrasikan kartu di aplikasi keuangan rumah tangga, tapi ada jeda waktu dalam membagikan pengeluaran besar
• Keluarga yang ingin memperjelas “batas untuk berdiskusi soal pengeluaran”
• Orang yang tidak keberatan melakukan tuning bertahap terhadap deteksi salah atau deteksi berlebihan dari task otomatis

Rangkuman

Mengecualikan biaya tetap dan pengeluaran yang sudah disepakati, dan hanya menangkap pengeluaran besar selain itu. Penyaringan sederhana seperti ini menurut saya adalah kunci agar notifikasi tidak jadi formalitas belaka.

Sudut pandang mengubah keterlambatan sinkronisasi menjadi angka untuk membedakan “hanya tidak dipakai” dan “gangguan”, serta pengaman berupa batas maksimum jumlah pemanggilan API, keduanya terasa sepele tapi saya rasakan sangat berpengaruh dalam menjaga otomatisasi ini berjalan stabil.

Yang ditangkap sistem ini hanyalah pengeluaran yang berubah-ubah. Di sisi lain, biaya tetap seperti biaya komunikasi memiliki sifat yang berbeda. Dibanding diperiksa berulang kali, bukankah meninjau ulang sekali saja efeknya lebih tahan lama? Bersamaan dengan otomatisasi ini, saya berpikir untuk melihat juga ke arah itu.

Artikel ini mengandung iklan afiliasi. Jika Anda mendaftar produk atau layanan melalui tautan di situs ini, kami mungkin menerima komisi dari perusahaan mitra. Selain itu, pengelola adalah karyawan Rakuten Group dan mungkin menerima imbalan melalui program referral karyawan. Konten dan penilaian artikel dibuat berdasarkan pengalaman nyata dan riset pengelola, terlepas dari ada atau tidaknya iklan, namun kami harap Anda membaca dengan memahami hubungan di atas. Untuk detailnya, silakan lihat Sangkalan & Info Afiliasi. Sangkalan & Info Afiliasi

Artikel ini menggunakan terjemahan mesin. Untuk syarat resmi, silakan cek halaman multibahasa di situs resmi Rakuten Mobile.

Jika Anda memiliki kekhawatiran tentang area jangkauan atau kondisi sinyal Rakuten Mobile, Anda dapat berkonsultasi melalui formulir permintaan perbaikan sinyal resmi.