Workflow Change Request Agensi Digital
5 min read
Cara Membuat Workflow Change Request Agensi yang Tidak Mengganggu Proyek
Change request adalah permintaan klien yang mengubah deliverable, asumsi, timeline, atau biaya setelah proyek disepakati. Workflow change request yang baik membuat keputusan terlihat, bukan menghambat kerja. Tim tetap bisa membantu klien tanpa membiarkan revisi kecil berubah menjadi pekerjaan gratis.
Panduan ini cocok untuk agensi yang mengerjakan desain, konten, website, aplikasi, iklan, atau layanan retainer. Prinsipnya sederhana: setiap perubahan dicatat, dinilai, disetujui, lalu dijadwalkan.
Bedakan revisi dan perubahan scope
Revisi memperbaiki output yang masih berada dalam brief. Perubahan scope mengubah brief atau menambah pekerjaan baru. Contohnya, mengganti warna tombol dalam halaman yang sudah disetujui biasanya revisi. Menambah halaman checkout, integrasi baru, atau kanal kampanye adalah perubahan scope.
Buat definisi ini tertulis di proposal dan kickoff. Tanpa batas tersebut, klien dan tim memakai arti berbeda untuk kata revisi. Saat pekerjaan mulai melebar, rujuk kembali ke dokumen scope, bukan ke ingatan meeting.
Scope juga perlu terhubung dengan cara agensi menentukan harga jasa tanpa membakar margin. Perubahan pekerjaan harus terlihat dalam estimasi, kapasitas, dan margin proyek.
Pakai satu pintu permintaan
Jangan menerima change request penting lewat semua kanal. Chat pribadi, grup, email, dan meeting membuat permintaan mudah hilang. Tetapkan satu tempat pencatatan, misalnya project board atau formulir singkat.
Formulir minimal memuat:
Permintaan perubahan
Alasan bisnis atau masalah yang ingin diselesaikan
Output yang diharapkan
Deadline yang diinginkan
Referensi atau aset pendukung
Pihak yang memberi persetujuan
Jika permintaan masuk lewat chat, project manager menyalinnya ke sistem utama. Balasan singkat seperti “sudah dicatat, kami kirim dampak dan estimasinya” cukup untuk menjaga ekspektasi tanpa langsung menjanjikan hasil.
Nilai dampak sebelum memberi jawaban
Project manager tidak perlu langsung berkata ya atau tidak. Nilai lima dampak: deliverable, jam kerja, timeline, biaya eksternal, dan risiko kualitas. Gunakan kategori sederhana agar keputusan cepat.
Dampak rendah: tidak mengubah deadline dan kapasitas tim
Dampak sedang: menambah pekerjaan atau memindahkan prioritas
Dampak tinggi: mengubah arsitektur, milestone, biaya, atau deadlineUntuk perubahan sedang dan tinggi, minta pemilik fungsi terkait memberi estimasi. Desainer menilai desain, developer menilai teknis, dan account manager menilai komunikasi komersial. Hindari estimasi tunggal dari orang yang tidak mengerjakan bagian tersebut.
Buat opsi bila memungkinkan. Opsi pertama mempertahankan deadline dengan mengurangi prioritas lain. Opsi kedua menambah waktu. Opsi ketiga menambah biaya untuk menambah kapasitas. Klien memilih trade-off yang paling sesuai, sementara agensi tetap memegang kendali delivery.
Tulis approval sebelum mulai
Change request belum menjadi pekerjaan aktif sebelum ada persetujuan tertulis dari pihak berwenang. Dokumen approval harus menyebutkan perubahan, biaya tambahan jika ada, dampak deadline, asumsi, dan hal yang tidak termasuk.
Hindari kalimat “kami coba dulu” untuk perubahan yang memengaruhi scope. Kalimat itu sering dibaca sebagai komitmen tanpa biaya. Ganti dengan “kami evaluasi dampaknya dan kirim opsi sebelum pekerjaan dimulai”.
Perbarui board proyek setelah approval. Tandai siapa yang menyetujui dan kapan. Hubungkan task baru dengan brief atau tiket asal supaya tim punya jejak keputusan.
Jaga komunikasi tetap komersial dan manusiawi
Menolak pekerjaan gratis tidak harus terdengar kaku. Akui tujuan klien, jelaskan dampak, lalu tawarkan pilihan. Contoh: “Tambahan alur ini masuk di luar brief awal. Kami bisa menambah dua hari kerja tanpa mengubah milestone berikutnya, atau tetap di deadline dengan memindahkan laporan mingguan ke fase berikutnya.”
Format ini lebih sehat daripada mengirim angka tanpa konteks. Klien melihat keputusan yang tersedia, bukan merasa sedang dikenai penalti. Tim juga belajar bahwa setiap prioritas baru membutuhkan konsekuensi yang jelas.
Bila proyek memakai retainer, tetapkan aturan penggunaan kapasitas bulanan. Permintaan baru bisa masuk antrean selama kapasitas tersedia. Jika kapasitas habis, klien memilih menunda, mengurangi pekerjaan lain, atau membeli kapasitas tambahan. Model ini melengkapi workflow project delivery agensi dari brief sampai serah terima.
Jadikan data change request bahan perbaikan
Review change request setiap akhir bulan. Hitung jumlah permintaan per klien, penyebab paling sering, waktu evaluasi, jam tambahan, dan perubahan yang dibatalkan. Data ini menunjukkan apakah masalah berasal dari brief, proses approval, estimasi, atau komunikasi.
Jika perubahan yang sama muncul berulang, masukkan jawabannya ke template proposal, checklist kickoff, atau SOP. Agensi yang sedang membangun sistem internal juga dapat mempertimbangkan sistem manajemen agency agar permintaan, approval, dan kapasitas berada dalam satu alur. Untuk kebutuhan integrasi lintas tool, diskusi dengan tim software house yang biasa membuat sistem custom untuk agency bisa menjadi langkah awal, tanpa harus langsung membeli solusi.
Checklist sebelum change request dijalankan
Scope awal dan permintaan baru sudah dibandingkan
Dampak deliverable, jam, deadline, biaya, dan risiko sudah dinilai
Opsi trade-off sudah disampaikan
Pihak berwenang sudah menyetujui
Task, timeline, dan budget sudah diperbarui
Tim dan klien menerima ringkasan keputusan
Workflow change request bukan alat untuk mempersulit klien. Ia adalah cara menjaga janji tetap realistis saat kebutuhan berubah. Dengan satu pintu permintaan, estimasi lintas fungsi, dan approval tertulis, agensi bisa fleksibel tanpa mengorbankan margin dan kualitas.
Bacaan terkait
Sumber ringan: Atlassian, panduan umum pengelolaan perubahan proyek dan permintaan kerja, diakses September 2026. Rekomendasi di atas disusun sebagai praktik operasional, bukan standar wajib.