GAS Scheduling

Saya kenal Elizabeth dari rantai referral, bukan cold pitch. Saat kami akhirnya bicara, vendor lain sudah memberinya harga. Saya tidak melawan di harga; saya mengubah apa yang saya tunjukkan. Alih-alih penawaran di atas kertas, saya bangun prototipe yang berfungsi — sesuatu yang bisa ia klik sendiri — atas inisiatif sendiri, sebelum ada kesepakatan apa pun. Ketika obrolannya mulai serius, ia sudah pernah menyentuh barangnya.

Pekerjaan saya sebelum membangun apa pun cuma satu: mendengarkan. Saya bilang ke Elizabeth, saya tidak bisa mendesain sistem yang tepat tanpa memahami bisnisnya dulu — operasinya, bentuk hari-harinya, apa yang sebenarnya dikerjakan para manajernya. Ia menjawab dengan pesan-pesan panjang dan satu dokumen briefing. Dari situ sistemnya tumbuh. Setiap bagiannya — peran-peran yang ada, apa yang bisa dilihat tiap orang, bagaimana notifikasi dikirim, bagaimana invoice disiapkan — semuanya lahir dari kata-katanya tentang bagaimana bisnisnya benar-benar berjalan. Bentuk software-nya mengikuti bentuk pekerjaannya, dengan sengaja, bahkan di bagian-bagian yang tak terlihat olehnya.

Ada beberapa keputusan di dalam sistem ini yang layak disorot, karena masing-masing mengatakan sesuatu tentang keseluruhannya.

Ambil contoh double-booking. Di sini ia diperlakukan sebagai tembok, bukan peringatan. Seorang provider boleh meminta beberapa shift di hari yang sama — yang pertama dikonfirmasi, dialah yang menang. Tapi begitu satu sudah terkonfirmasi, tidak ada permintaan lain yang bisa menyelinap masuk. Admin sekalipun tidak bisa diam-diam menimpanya. Aturan yang sama ditegakkan di tiga tempat sekaligus: saat seseorang mengklik, sekali lagi saat konfirmasi berjalan, dan satu pemeriksaan terakhir di dalam database sendiri yang menangkap apa pun yang lolos dari dua sebelumnya. Ini berlebihan, dan disengaja. Saya tahu aturan yang sama kini berada di tiga tempat — itu semacam utang teknis, dan saya catat di roadmap sebagai sesuatu yang akan dirapikan nanti, ketika ada fitur lain yang memberi alasan untuk merapikannya. Disengaja, bukan ceroboh.

Prinsip kedua: "freedom before commitment, locked after" — bebas sebelum kesepakatan, terkunci setelahnya. Sebelum sebuah shift dikonfirmasi, provider dan manajer bergerak bebas. Setelah terkonfirmasi, dua pihak bergantung pada shift itu tetap ada. Hanya admin yang boleh membatalkannya, dan hanya dengan alasan yang tercatat. Di bawah kebijakan itu ada mekanik yang lebih senyap: setiap kali ada yang mencoba mengubah shift yang sudah terkonfirmasi, sistem memeriksa apakah ada yang berubah sejak terakhir kali dibaca. Tanpa pemeriksaan itu, dua admin yang bergerak bersamaan bisa tanpa sengaja menghidupkan kembali shift yang sudah dibatalkan — membangunkan janji yang sudah mati. Aturannya terbaca seperti kebijakan. Kodenya terbaca seperti disiplin seorang akuntan.

Notifikasi bekerja dalam batch, dengan satu pengecualian untuk keadaan darurat. Layanan email yang saya pakai membatasi semua pengguna di dua pesan per detik. Kirim lebih cepat dari itu, pesannya mulai ditolak. Jadi sistem mengirimnya satu per satu dengan jeda kecil — sebagian agar tetap di bawah batas, sebagian karena provider tidak mau menerima sepuluh email sekaligus saat jadwalnya berubah. Pengecualiannya: shift yang dimulai dalam tujuh hari ke depan melompati antrian dan langsung dikirim. Itulah kasus di mana keterlambatan benar-benar mahal.

Invoice, dalam sistem ini, bukan barang yang terpisah. Ia adalah timesheet yang sama, hanya disusun ulang. Setiap timesheet mengelompokkan jam kerja seorang provider per minggu. Setiap invoice mengelompokkan jam-jam yang sama itu per lokasi dan per minggu, menjumlahkannya, lalu mengekspornya ke QuickBooks untuk pembukuan. Karena keduanya berasal dari data yang sama, tidak ada risiko keduanya keluar dari sinkron. Mereka tidak mungkin berbeda. Mereka memang sama.

Cerita reliability paling berguna di seluruh proyek ini ada di sini. Orang yang mengurus pembukuan punya izin untuk membaca catatan timesheet, tapi tidak untuk mengubahnya. Saat ia mengklik "tandai sebagai invoiced", lapisan keamanan database diam-diam menolak perubahannya — tanpa pesan error apa pun — dan layar tetap menampilkan bahwa aksinya berhasil. Padahal tidak ada yang benar-benar ditandai. Perbaikannya: aksi itu kini dialihkan lewat jalur yang lebih ketat. Database sekarang mengonfirmasi persis berapa baris yang tersentuh, dan protes keras kalau angkanya tidak cocok. Kegagalan yang tadinya senyap ditulis ulang menjadi kegagalan yang langsung terlihat. Sebagian besar kerja reliability bentuknya seperti ini. Bukan fitur baru — menghapus satu jenis kebingungan.

Sepanjang proses membangun, struktur database berubah bentuk sekitar lima puluh kali. Hampir semua perubahan itu menambahkan sesuatu — informasi baru, cara baru untuk mencari sesuatu, nilai awal baru. Hampir tidak ada yang dibangun lalu dibongkar. Tapi dua asumsi fondasi pecah keras di tiga minggu pertama. Keduanya berasal dari sebab yang sama. Saya mulai dari titik awal yang generik — dibangun cepat dengan bantuan Claude Code — yang membawa asumsi-asumsi standar bawaan sebuah template software, dan asumsi-asumsi itu tidak selamat saat berhadapan dengan praktik staffing anestesi yang sebenarnya.

Yang pertama, login. Desain awalnya berasumsi sistem akan berjalan di perangkat bersama di klinik — provider memilih namanya dari dropdown lalu memasukkan kode pendek, manajer memasukkan passcode untuk lokasinya. Dalam minggu pertama, itu dibuang dan diganti dengan login email dan password per orang. Seluruh model identitas dibangun ulang dari awal.

Yang kedua, timesheet. Struktur awalnya dibentuk untuk pekerja per jam — clock-in, clock-out, istirahat dicatat, jam dihitung. Alasan saya mengubahnya saya tulis sebagai catatan di dalam perubahannya sendiri, dalam prosa biasa: provider GAS adalah profesional terpercaya yang melaporkan jam kerjanya sendiri. Mereka tidak clock-in atau clock-out. Mereka tidak menghitung istirahat. Struktur lama itu dibangun untuk jenis pekerja yang tidak dimiliki GAS. Perubahan ini menyelaraskan database dengan bentuk pekerjaan yang sebenarnya.

Kedua koreksi itu murah karena terjadi di awal. Itulah polanya: bangun fondasi yang tebal dengan cepat, pangkas asumsi yang keliru saat ia berhadapan dengan bisnis yang sebenarnya, lalu maju lurus. Penalaran paling jernih di seluruh proyek ini tidak hidup di ringkasan perubahan. Ia hidup di prosa yang saya tulis di dalam file-file perubahannya sendiri, di catatan desain, dan di dokumen-dokumen yang menjelaskan alasan keputusan. Tulisan semacam itu — pelan, dengan kata-kata sendiri, sambil masih berada di dalam pekerjaannya — itulah wujud bukti dari sistem yang dipikirkan matang-matang.

Tujuh puluh delapan hari setelah live, sistem sudah memproses 191 shift. 128 di antaranya terkonfirmasi. Tingkat keberhasilan shift terbuka terisi naik dari 56% ke 67% dalam enam minggu. Jajaran provider aktif berlipat ganda, dari sembilan menjadi delapan belas. Waktu yang dibutuhkan manajer untuk merespons sebuah permintaan turun dari sekitar 28 jam menjadi di bawah 8 jam. April jadi bulan tersibuk: 50 shift, kira-kira tiga kali lipat Maret.

Angka paling menarik di sini bukan volumenya, melainkan rasionya. Pola baru: seorang provider melihat shift yang terbuka, ia memintanya, manajernya menyetujui. Pola ini terjadi 54 kali. Pola lama — admin menugaskan shift ke seseorang secara manual — hanya terjadi 5 kali. Sebelas banding satu. Sistem ini tidak sekadar mendigitalkan cara tim biasa bekerja. Ia memindahkan pekerjaan dari admin ke orang-orang yang paling dekat dengannya. Cara tim bekerja berubah.

Elizabeth, founder yang memesan sistem ini untuk meringankan beban administratifnya, sampai sekarang masih menjadi salah satu dari tiga pengambil shift tersibuk di sistemnya sendiri. Waktu yang dikembalikan sistem ini kepadanya tidak dipakai untuk bekerja lebih sedikit, tapi untuk mengerjakan pekerjaan yang memang sejak dulu ia dilatih untuk melakukannya.

Sistem ini hari ini berjalan di tujuh lokasi. Tiga di antaranya masih sepi, menunggu manajernya mulai memakai. Ada ruang untuk tumbuh — headroom itu dirancang sejak awal — tapi untuk sementara, pertumbuhannya ada di jumlah provider dan jumlah shift, belum di geografi baru.

Ada satu insiden yang ingin saya ceritakan. Saat testing, empat provider sungguhan menerima email sungguhan. Saya meninggalkan beberapa kontak asli di database testing. Saya menyadarinya saat melihat log di layar, dan langsung menghentikan prosesnya. Tapi sebagian email sudah terlanjur terkirim. Saya minta perantara mengabari para provider bahwa itu cuma testing. Tanggapannya: tawa, plus "it's okay." Tidak ada kerugian nyata. Saya mengirim email susulan, meminta mereka mengabaikan email sebelumnya. Di penghujung hari itu, database testing sudah tidak menyimpan satu pun kontak asli. Satu-satunya nama asli yang tersisa hanya milik saya sendiri dan Elizabeth. Sisanya placeholder semua. Cerita kecil, tapi pelajarannya permanen.

Kalau ditanya apa yang akan saya lakukan berbeda, jawaban jujurnya: tidak ada. Bukan karena tidak ada yang bisa dipelajari — tapi karena koreksi yang perlu terjadi sudah terjadi selama proses membangun, ketika mengubahnya masih murah. Dua koreksi di minggu pertama itulah buktinya: bukan kegagalan penilaian, tapi cara kerja yang tidak meneruskan asumsi keliru hanya demi terlihat sudah memutuskan sejak awal.