A
Background
Latar Belakang
A mid-sized operational company where approval workflows for purchases, overtime requests, and material requisitions crossed multiple departments. IT infrastructure was limited — no internal approval system, no workflow tool. Budget for new software was constrained.
Sebuah perusahaan operasional menengah di mana alur persetujuan untuk pembelian, permintaan lembur, dan requisisi material melintasi beberapa departemen. Infrastruktur IT terbatas — tidak ada sistem persetujuan internal, tidak ada alat workflow. Anggaran untuk perangkat lunak baru sangat terbatas.
B
Operational Problem
Masalah Operasional
Operational approval processes — purchase requests, overtime, material requests — were handled entirely by email. No structured tracking, no pending-status visibility, and no audit trail for compliance or escalation.
Proses persetujuan operasional — permintaan pembelian, lembur, permintaan material — ditangani sepenuhnya melalui email. Tidak ada pelacakan terstruktur, tidak ada visibilitas status pending, dan tidak ada jejak audit untuk kepatuhan atau eskalasi.
C
Existing Workflow
Alur Kerja Saat Ini
Submitters sent emails to approvers and waited. Follow-up happened via WhatsApp. Approval status was tracked in personal notes or not at all. Nobody could answer "how many requests are pending right now" without manually reviewing email threads.
Pemohon mengirim email ke pemberi persetujuan dan menunggu. Tindak lanjut terjadi melalui WhatsApp. Status persetujuan dilacak dalam catatan pribadi atau tidak sama sekali. Tidak ada yang bisa menjawab berapa permintaan yang sedang pending tanpa meninjau thread email secara manual.
1
Requestor fills in a Word/Excel form and emails it to the approver
2
Approver replies via email with approval or rejection
3
No central visibility — each request tracked in personal inbox
4
Follow-up via WhatsApp when no reply received
5
Monthly compliance reports compiled by manually reviewing email history
1
Pemohon mengisi formulir Word/Excel dan mengirimnya via email ke pemberi persetujuan
2
Pemberi persetujuan membalas via email dengan persetujuan atau penolakan
3
Tidak ada visibilitas terpusat — setiap permintaan dilacak di kotak masuk pribadi
4
Tindak lanjut via WhatsApp ketika tidak ada balasan yang diterima
5
Laporan kepatuhan bulanan disusun dengan meninjau riwayat email secara manual
D
Bottleneck & Risk
Bottleneck & Risiko
Requests fell through gaps between inbox folders. Approvers on leave had no backup workflow. The compliance team had no real-time visibility. Escalation required manually identifying who held the pending request. The process was opaque to everyone except the direct participants.
Permintaan jatuh melalui celah antar folder kotak masuk. Pemberi persetujuan yang sedang cuti tidak memiliki alur cadangan. Tim kepatuhan tidak memiliki visibilitas real-time. Eskalasi membutuhkan identifikasi manual tentang siapa yang memegang permintaan pending. Proses ini tidak transparan bagi siapa pun kecuali peserta langsung.
Requests were lost in inboxes. Approval cycles delayed operations. Compliance reporting required manual reconstruction. Bottlenecks were invisible until operational consequences surfaced.
Permintaan hilang di kotak masuk. Siklus persetujuan menunda operasional. Pelaporan kepatuhan membutuhkan rekonstruksi manual. Bottleneck tidak terlihat hingga konsekuensi operasional muncul.
E
Why the Existing System Failed
Mengapa Sistem Lama Gagal
Email was chosen because it was familiar and zero-cost. But email is optimized for communication, not workflow state management. There was no concept of "pending," "approved," or "rejected" as queryable states. Every status check required human intervention.
Email dipilih karena familiar dan tanpa biaya. Tapi email dioptimalkan untuk komunikasi, bukan manajemen status alur kerja. Tidak ada konsep "pending," "disetujui," atau "ditolak" sebagai status yang bisa di-query. Setiap pengecekan status membutuhkan intervensi manusia.
F
Solution Approach
Pendekatan Solusi
Use Google Sheets as the data backend with Apps Script for workflow logic — avoiding database infrastructure entirely. Provide a structured submission and approval interface accessible from any browser without IT involvement.
Menggunakan Google Sheets sebagai backend data dengan Apps Script untuk logika alur kerja — menghindari infrastruktur database sepenuhnya. Menyediakan antarmuka pengajuan dan persetujuan terstruktur yang dapat diakses dari browser mana pun tanpa keterlibatan IT.
G
System Architecture
Arsitektur Sistem
Apps Script-powered approval workflow with structured form submission, automated email notifications, role-based approval interface in Google Sheets, request status tracking, and operational reporting exports.
Alur kerja persetujuan berbasis Apps Script dengan pengajuan form terstruktur, notifikasi email otomatis, antarmuka persetujuan berbasis peran di Google Sheets, pelacakan status permintaan, dan ekspor laporan operasional.
Google Sheet acts as the central database — one row per request. Apps Script handles form submission validation, automated email dispatch to approvers, and status updates when approvers click approve/reject links. Firebase Auth provides role-based access without server infrastructure.
Google Sheet berfungsi sebagai database pusat — satu baris per permintaan. Apps Script menangani validasi pengajuan form, pengiriman email otomatis ke pemberi persetujuan, dan pembaruan status saat pemberi persetujuan mengklik tautan setuju/tolak. Firebase Auth menyediakan akses berbasis peran tanpa infrastruktur server.
H
Technologies Used
Teknologi yang Digunakan
Apps Script
Google Sheets
Firebase Auth
JavaScript
I
Workflow Visualization
Visualisasi Alur Kerja
01
Submission
Pengajuan
Requestor fills web form — data written to Google Sheet with timestamp and status "Pending"
Pemohon mengisi form web — data ditulis ke Google Sheet dengan timestamp dan status "Pending"
02
Notification
Notifikasi
Apps Script sends approval email with direct action links to the designated approver
Apps Script mengirim email persetujuan dengan tautan tindakan langsung ke pemberi persetujuan yang ditunjuk
03
Approval Action
Tindakan Persetujuan
Approver clicks Approve or Reject — Sheet updates automatically, requestor notified
Pemberi persetujuan klik Setuju atau Tolak — Sheet diperbarui otomatis, pemohon diberi tahu
04
Reporting
Pelaporan
Dashboard tab shows all pending, approved, and rejected requests in real time
Tab dashboard menampilkan semua permintaan pending, disetujui, dan ditolak secara real time
J
Operational Impact
Dampak Operasional
Metric
Metrik
Before
Sebelum
After
Sesudah
Status Visibility
Visibilitas Status
Check inbox manually
Self-service dashboard
Follow-up Method
Metode Tindak Lanjut
WhatsApp ping
Automatic reminder
Compliance Report
Laporan Kepatuhan
2–3 hours manual
Export in 1 click
Deployment Cost
Biaya Implementasi
N/A
Zero infrastructure
Pending approvals visible in real-time to all relevant roles
Follow-up via WhatsApp reduced as status became self-service visible
Audit trail maintained automatically in structured Sheets records
Deployed without any infrastructure changes or IT ticket
Persetujuan pending terlihat real-time oleh semua peran terkait
Tindak lanjut via WhatsApp berkurang karena status sudah bisa dilihat sendiri
Jejak audit dipertahankan secara otomatis dalam catatan Sheets yang terstruktur
Diimplementasikan tanpa perubahan infrastruktur atau tiket IT
K
Future Development
Pengembangan ke Depan
Multi-level approval chains where requests escalate automatically after timeout. Integration with financial system for budget validation before approval. Mobile-optimized approval interface for approvers on the go.
Rantai persetujuan multi-level di mana permintaan eskalasi otomatis setelah timeout. Integrasi dengan sistem keuangan untuk validasi anggaran sebelum persetujuan. Antarmuka persetujuan yang dioptimalkan untuk mobile bagi pemberi persetujuan yang sedang bergerak.