34 Pekerjaan Berulang yang Jalan Sendiri, dalam Tiga Lapisan

Saya membuat daftar semua pekerjaan berulang yang sekarang jalan tanpa ada yang menjalankannya. Jumlahnya 34.

Sembilan belas berupa Google Apps Script yang menempel di spreadsheet. Tiga berupa alur lead di n8n dan alur sejenisnya di satu VPS. Dua belas sisanya Routine terjadwal yang menjalankan Claude, membaca file di repo saya, lalu memutuskan sesuatu.

Ketiganya sering disebut dengan satu kata yang sama. Di kantor saya ketiganya tiga jenis pekerjaan yang berbeda, dengan urutan pembangunan yang tidak bisa dibalik.

Tiga lapisan, dan pembedanya siapa yang memutuskan

Saya memisahkan ketiganya dari siapa yang mengambil keputusan di dalamnya.

Lapisan pertama tidak pernah menilai apa pun. Dia membandingkan tanggal, menulis stempel di kolom, mengirim email, lalu berhenti.

Lapisan ketiga justru sebaliknya. Routine edavos-review-bulanan membaca folder akuisisi lalu menyusun penilaian, dan audit repo bulanan mencari file yang sudah tidak dirujuk siapa pun. Keduanya menghasilkan kalimat.

Lapisan ketiga bisa menilai karena bahan yang dibacanya sudah rapi sejak pagi hari. Yang merapikannya lapisan pertama.

Sebelum ada reminder, yang lewat itu dianggap normal

Kelas otomasi terbesar di lapisan pertama adalah reminder. HC untuk PKWT dan probation, milestone proyek yang lewat tenggat, tiket IT Support yang masih terbuka di akhir minggu, dan kontrak warranty serta license yang mendekati jatuh tempo.

Semuanya punya bentuk yang sama. Ada tanggal di sebuah kolom, ada orang yang seharusnya melihatnya, dan tidak ada satu pun jam dalam sebulan yang ditugaskan untuk melihat.

Setelah reminder dipasang, terlewat mulai punya jejak.

Yang menahan reminder supaya tidak mengirim dua kali adalah kolom stempel. Setiap baris punya Reminder 1, Reminder 2, dan Reminder 3 untuk internal. Script menulis tanggal ke sel itu setelah mengirim, dan jadwal berikutnya melewatinya karena selnya sudah terisi.

Konsekuensinya langsung dan kadang berguna. Mengosongkan sel itu berarti mengirim ulang.

Tiga script menembus keluar, dan ketiganya menahan diri dengan cara berbeda

Dari 19 Apps Script, tiga mengirim email ke alamat customer. Sisanya berhenti di internal Edavos.

Ketiganya dibedakan oleh apa yang harus terjadi sebelum email itu boleh berangkat.

WL-Warranty-License-Reminder jalan tiap hari pukul 08:00 WIB dan mengerjakan empat hal sekali jalan: menutup baris yang tanggalnya sudah lewat, mengirim reminder internal, mengirim reminder ke customer per grup kontrak, dan melaporkan baris yang kontaknya kosong.

Jendelanya bertingkat, dan internal selalu lebih dulu dari customer.

Sebelum ini, seseorang di tim sales harus membuka file, membaca baris per baris, mencari mana yang mendekati jatuh tempo, lalu menghubungi customer satu per satu. Sekarang emailnya berangkat sendiri.

Reminder yang cuma punya satu hari untuk terbit, dan tidak ada yang tahu

Sampai versi 1.0, Reminder 1 dan Reminder 2 memakai pembanding tanggal persis. Sisa hari harus sama dengan 90, atau sama dengan 60.

Artinya masing-masing reminder cuma punya satu hari dalam setahun untuk terbit.

Baris yang baru dimasukkan ke sheet saat sisa 75 hari melewatkan Reminder 1 selamanya. Trigger yang gagal jalan di hari yang tepat menghasilkan hal yang sama. Dan tidak ada yang menandainya, karena kolom stempelnya memang tidak pernah terisi, dan kolom kosong terlihat persis seperti kolom yang belum waktunya.

Yang membuat cacat ini mahal adalah hasilnya salah tanpa memunculkan error apa pun.

Di versi 1.1 semua jendela diubah jadi rentang, dan yang menahan pengiriman berulang diserahkan sepenuhnya ke kolom stempel. Reminder yang tertinggal sekarang menyusul kapan saja di dalam rentangnya.

Cacat kedua di versi yang sama lebih halus. Pengisian nama organisasi memakai pencocokan sebagian dua arah, sehingga nomor SO26-001 mengisi organisasi milik SO26-0019. Berbahayanya justru karena pengisian itu berjalan saat nomor SO masih setengah diketik, jadi tebakan salah itu terjadi persis di detik orang mengetik.

Sekarang pencocokannya harus persis setelah normalisasi. Nomor yang tidak ketemu dibiarkan kosong dan dilaporkan, tidak ditebak.

Bendera debug yang hidup terlalu lama

Menulis artikel ini membuat saya membaca ulang kode yang saya anggap selesai. Satu hal langsung terlihat.

Bendera DEBUG masih bernilai benar di produksi, padahal komentar di kode saya sendiri menyuruh sebaliknya. Di salah satu script yang menembus ke alamat customer. Saya mematikannya hari itu juga.

Yang dimatikan cuma pencatatan ke Execution Log. Tidak ada email yang berubah, tidak ada keputusan script yang berubah, dan pencatatan error memang tidak pernah lewat bendera itu. Bendera itu sisa sesi debugging lama yang tidak pernah saya matikan.

Yang layak diperhatikan adalah berapa lama dia bertahan. Tidak ada yang rusak karenanya, tidak ada email yang gagal, dan tidak ada satu pun keluhan. Dia hidup lama persis karena tidak pernah mengganggu siapa pun.

Satu hal lagi saya temukan dan sengaja tidak saya ubah, karena bentuknya memang disengaja.

Kolom stempel mencatat bahwa script memutuskan untuk mengirim, bukan bahwa pengirimannya berhasil. Stempel ditulis di jalur yang sama dengan pengiriman, jadi keduanya tidak pernah bisa dibedakan dari sheet. Satu-satunya bukti sebuah email berangkat adalah salinan BCC yang masuk ke kotak masuk saya.

Memperbaikinya berarti memisahkan dua peran yang sekarang ditumpuk di satu kolom. Satu penanda niat kirim, satu kunci penahan kiriman ganda. Selama keduanya satu sel, tidak ada tempat untuk menaruh log pengiriman, dan itu sebabnya log itu tidak pernah ada.

Reminder IT Support dan maintenance sudah menulis stempelnya setelah pengiriman berhasil. Itu membuat saya berhenti sejenak. Perbaikannya sudah ada di rumah, di script sebelah, dan tidak pernah saya pindahkan.

Itu pola yang saya kenali di banyak tempat. Perbaikan tidak menyebar sendiri antar sistem yang tidak saling memanggil.

Inventarisnya sendiri sudah ketinggalan

Sheet inventaris yang saya pakai menyusun tulisan ini berisi 24 baris. Dua di antaranya, maintenance VPS dan maintenance WordPress bulanan, adalah pekerjaan yang sekarang dikerjakan Claude Routine. Keduanya tercatat dua kali.

Itu cacat yang wajar dan tetap cacat. Inventaris dibuat saat lapisan ketiga belum ada, dan tidak ada apa pun yang memaksanya menyusul.

Pola yang sama muncul di tempat lain. Setiap keputusan yang saya catat di decision log yang saya pakai punya baris tinjau dan baris batal kalau, yaitu kondisi kegagalan yang dirumuskan pada hari keputusannya dibuat. Tidak ada satu pun yang membacanya kembali.

Ada 11 entry jatuh tempo Oktober, 21 entry November, dan 12 entry Desember. Perbaikannya sebuah skrip yang membaca semua decision log dan mencetak yang jatuh tempo bulan ini, dipanggil dari audit bulanan. Skrip itu melapor saja dan tidak menilai apa pun.

Di mana AI-nya, dan kenapa lapisan pertama tetap ada

Ketiga lapisan ini dibangun dengan bantuan AI. Apps Script-nya saya tulis bersama Claude, termasuk saat mencari tahu kenapa jendela 90 hari itu tidak pernah terbit. Rancangan kolom, urutan node n8n, dan sebagian besar keputusan strukturnya lahir dari sesi yang sama.

Yang berbeda antar lapisan adalah apakah AI ikut jalan setiap hari.

Di lapisan pertama tidak. Yang berangkat pukul delapan pagi adalah perbandingan tanggal dan kolom stempel, dan itu memang yang saya inginkan untuk pekerjaan yang menyentuh customer. Perilakunya bisa saya baca dari kode, dan hasil kemarin sama dengan hasil besok untuk masukan yang sama.

Di lapisan ketiga iya, dan di situ letak gunanya. Routine bulanan membaca folder akuisisi dan menyusun penilaian yang tidak bisa saya tulis jadi aturan if, karena saya sendiri tidak tahu bentuk temuannya sebelum datanya dibaca.

Lapisan ketiga tetap tidak bisa menggantikan lapisan pertama, dan alasannya ada di urutan pembangunannya. Routine yang menilai kontrak jatuh tempo akan membaca sheet yang sama, dan sheet itu rapi karena ada script membosankan yang mengisi stempel dan menutup baris kedaluwarsa tiap pagi.

Lapisan pertama yang membuat lapisan ketiga punya bahan yang layak dibaca.

Yang bisa Anda kerjakan dalam satu jam

Buka spreadsheet kosong, lalu daftarkan pekerjaan berulang di tim Anda dengan empat kolom: nama pekerjaan, siapa yang mengerjakan, berapa sering, dan berapa lama sekali jalan.

Urutkan daftarnya dengan frekuensi, lalu lihat yang paling atas.

Di daftar saya, yang paling layak diotomatiskan duluan adalah pekerjaan lima menit yang harus terjadi tiap hari dan tidak pernah punya pemiliknya sendiri.