“Mas, satu revisi kecil lagi ya.”
Reno membaca pesan itu pukul 21.16.
Dia membuka file.
Komentar pertama: ganti warna utama.
Komentar kedua: ubah layout.
Komentar ketiga: balik ke konsep awal.
Komentar keempat: “coba versi yang lebih premium tapi tetap fun.”
Reno menatap layar.
Lalu chat lagi masuk.
“Kalau bisa malam ini biar besok tinggal approve 🙏”
Temannya, Dimas, yang sedang duduk di sebelahnya di coworking space, ikut melihat.
“Ini revisi ke berapa?”
Reno menghitung.
“Enam.”
“Di proposal lo berapa?”
Reno diam.
Dimas mengangkat alis.
“Jangan bilang nggak ada.”
Reno menutup muka.
Freelancer sering takut membatasi revisi karena khawatir terlihat ribet.
Padahal kalimat sederhana seperti “harga termasuk dua putaran revisi berdasarkan brief yang disepakati” bisa menyelamatkan banyak jam kerja.
Batas revisi bukan cara melawan client.
Ia cara memastikan dua pihak punya definisi selesai yang sama.
Revisi dan perubahan arah bukan hal yang sama
Tidak semua perubahan client adalah revisi kecil.
Kalau logo awalnya minimal lalu client meminta ilustratif, itu perubahan arah.
Kalau halaman awalnya lima lalu menjadi delapan, itu penambahan scope.
Kalau tone awalnya formal lalu berubah menjadi playful, pekerjaan bisa perlu dikerjakan ulang.
Reno dulu memasukkan semua sebagai revisi.
Akibatnya, project yang diperkirakan empat hari berubah menjadi dua minggu.
Dimas bertanya:
“Kenapa lo nggak bilang scope berubah?”
“Takut client bilang gue perhitungan.”
“Lo memang harus perhitungan. Ini kerjaan.”
Itu poinnya.
Profesional bukan berarti selalu mengiyakan.
Profesional berarti bisa menjelaskan dampak perubahan secara tenang.
“Dua revisi” juga perlu definisi
Freelancer suka menulis:
“Termasuk dua kali revisi.”
Tapi dua kali itu apa?
Dua komentar?
Dua file?
Dua putaran feedback?
Reno belajar memakai istilah “dua putaran revisi”.
Satu putaran berarti client mengumpulkan feedback, lalu freelancer mengerjakan satu batch perubahan.
Kalau ada 12 komentar dalam satu dokumen dan semuanya masih sesuai brief, itu satu putaran.
Besok client datang lagi dengan 8 komentar baru, itu putaran kedua.
Definisi ini jauh lebih adil daripada menghitung setiap komentar sebagai satu revisi.
Minta feedback dikumpulkan
Masalah terbesar Reno dulu bukan jumlah feedback.
Tapi feedback datang satu-satu.
Pukul 10:
“Font-nya ganti.”
Pukul 11:
“Logo dibesarin.”
Pukul 13:
“CTA pindah.”
Pukul 17:
“Balik font awal deh.”
Freelancer akhirnya mengerjakan ulang hal yang sama.
Sekarang Reno menulis:
“Mohon feedback dikonsolidasikan oleh satu PIC dan dikirim dalam satu batch per putaran.”
Kalimatnya tidak panjang.
Efeknya besar.
Client internal mungkin punya lima orang yang memberi pendapat.
Freelancer tidak perlu menjadi arena voting.
Satu PIC mengurangi chaos
Project Reno pernah punya:
marketing manager,
brand manager,
owner,
adik owner,
dan “teman owner yang ngerti desain”.
Semuanya memberi komentar.
Kadang bertentangan.
Reno akhirnya bertanya:
“Untuk final decision, saya mengikuti approval siapa?”
Sunyi beberapa detik.
Marketing manager menjawab:
“Saya koordinasikan dulu.”
Bagus.
Freelancer perlu tahu siapa yang punya final say.
Kalau tidak, revisi bisa menjadi loop.
Batas revisi harus ditulis sebelum project dimulai
Membuat aturan setelah client sudah mengirim revisi ketujuh terasa seperti mengubah permainan di tengah.
Lebih baik sejak proposal.
Contoh sederhana:
“Fee mencakup dua putaran revisi minor yang masih sesuai brief. Perubahan konsep, tambahan deliverable, atau revisi setelah dua putaran akan dihitung sebagai additional scope.”
Tidak harus wording persis itu.
Yang penting prinsipnya jelas.
Jangan gunakan kata “unlimited revision” kalau sebenarnya tidak sanggup
Kata unlimited terlihat menarik untuk jualan.
Client merasa aman.
Freelancer merasa kompetitif.
Masalahnya, unlimited secara literal berarti tidak ada batas.
Kalau client minta revisi ke-18, siapa salah?
Reno pernah memakai “unlimited revisions until approved”.
Dimas membaca proposal lama.
“Ini lo yang nulis?”
“Iya.”
“Berarti lo mengundang penderitaan.”
Reno tertawa pahit.
Jika memang ingin memberi fleksibilitas, lebih aman batasi berdasarkan waktu atau scope.
Misalnya revisi selama tujuh hari setelah draft final selama tidak mengubah konsep utama.
Tetap ada pagar.
Revisi harus punya window waktu
Project bisa menggantung karena client lama memberi feedback.
Draft dikirim Senin.
Client hilang dua minggu.
Lalu muncul:
“Bisa selesai besok?”
Reno sekarang punya review window.
Misalnya feedback maksimal lima hari kerja agar timeline tetap berlaku.
Kalau feedback terlambat, deadline bergeser sesuai availability.
Ini bukan menghukum client.
Freelancer juga punya project lain.
Kalender tidak bisa dibekukan tanpa batas.
Perubahan kecil bisa punya efek besar
Client berkata:
“Cuma ganti ukuran.”
Di desain, mungkin semua layout harus menyesuaikan.
Client berkata:
“Cuma tambah satu section.”
Di website, responsif, copy, testing, dan mobile view ikut berubah.
Karena itu, freelancer jangan ikut memakai kata “cuma” sebelum menilai dampaknya.
Balas:
“Saya cek impact-nya dulu ya.”
Sederhana.
Hindari debat tentang apakah revisi “masuk akal”
Kalau client meminta sesuatu yang secara visual kurang bagus, freelancer boleh memberi rekomendasi.
Tapi jangan membuat setiap revisi menjadi adu ego.
“Menurut saya, opsi A lebih kuat karena keterbacaan.”
Lalu beri pilihan.
Kalau client tetap memilih B dan tidak melanggar hal serius, eksekusi sesuai scope.
Freelancer menjual keahlian.
Bukan hak veto permanen.
Batas revisi melindungi client juga
Client sebenarnya mendapat manfaat.
Karena batas membuat mereka lebih serius mengumpulkan feedback.
Meeting internal dilakukan.
Decision lebih cepat.
Project selesai.
Tanpa batas, semua orang bisa terus mencoba.
“Coba biru.”
“Coba hijau.”
“Coba balik biru.”
Eksperimen tidak pernah berakhir.
Batas menciptakan keputusan.
Kalau revisi habis, jangan langsung defensif
Reno menerima putaran ketiga.
Dia menulis:
“Kita sudah menyelesaikan dua putaran revisi sesuai proposal. Feedback terbaru masih bisa saya kerjakan sebagai additional revision dengan fee RpX dan tambahan waktu Y.”
Nada netral.
Tidak:
“Ini sudah kebanyakan.”
Tidak:
“Saya rugi.”
Tidak:
“Client lain nggak begini.”
Fokus pada kesepakatan.
Harga tambahan tidak perlu terasa seperti denda
Additional revision bukan punishment.
Itu pekerjaan baru.
Harga bisa berdasarkan jam, paket, atau scope.
Yang penting masuk akal.
Reno punya add-on:
satu putaran revisi tambahan.
Client bisa pilih.
Kalau tidak mau, project selesai di versi terakhir yang sudah disepakati.
Jangan lupa version control
Revisi banyak membuat file berantakan.
final.psd
final2.psd
final-revisi.psd
final-beneran.psd
final-beneran-fix.psd
Dimas melihat folder Reno.
“Ini arkeologi.”
Reno mulai memakai naming:
v01
v02
v03
date
status.
Tidak menarik.
Tapi mengurangi risiko salah kirim.
AI bisa mempercepat revisi, tapi tidak menyelesaikan scope creep
Tools AI bisa membantu ide, copy, variasi, atau production tertentu.
Tapi kalau client terus mengubah arah, pekerjaan tetap berkembang.
Kecepatan produksi bukan alasan memberi revisi tanpa batas.
Kalau dulu satu revisi butuh dua jam dan sekarang 30 menit, masih tetap penggunaan waktu.
Dan beberapa perubahan butuh judgment manusia, bukan sekadar generate ulang.
“Minor revision” perlu contoh
Reno menambahkan di proposal:
Minor:
warna, typo, spacing, adjustment sederhana.
Major:
perubahan konsep, layout utama, jumlah halaman, arah visual, atau deliverable.
Contoh membuat client lebih mudah memahami.
Tidak perlu definisi legal sempurna.
Cukup mengurangi ruang interpretasi.
Kalau brief awal kabur, revisi akan meledak
Kadang masalah bukan client cerewet.
Freelancer mulai terlalu cepat.
Brief hanya:
“Bikin yang keren.”
Reno sekarang menahan diri.
Target audience?
Objective?
Reference?
Must-have?
Must-avoid?
Format?
Decision maker?
Deadline?
Semakin jelas brief, semakin kecil revisi eksplorasi.
Waktu 30 menit di awal bisa menghemat tiga hari di akhir.
Moodboard atau prototype bisa menjadi checkpoint
Untuk project besar, jangan langsung buat final.
Buat arah.
Moodboard.
Wireframe.
Sketch.
Prototype.
Approve dulu.
Baru produksi.
Kalau client mengubah arah setelah checkpoint approved, lebih mudah menjelaskan bahwa ada scope baru.
Revisi tanpa batas sering muncul karena freelancer takut mengatakan “tidak”
Reno mengaku ke Dimas:
“Gue takut rating jelek.”
“Terus lo mau kerja gratis selamanya?”
“Ya nggak.”
“Berarti perlu middle ground.”
Batas yang disampaikan sejak awal lebih mudah diterima daripada penolakan mendadak.
Freelancer yang selalu bilang iya juga menciptakan expectation.
Client belajar bahwa semua bisa.
Client bagus biasanya menghargai kejelasan
Reno mencoba proposal baru.
Dua putaran revisi.
Satu PIC.
Feedback batch.
Timeline.
Additional scope fee.
Client membaca.
“Oke.”
Reno kaget.
Dimas bertanya:
“Kenapa?”
“Gue kira bakal diprotes.”
“Ternyata orang suka aturan kalau dari awal.”
Tidak semua client akan setuju.
Tapi setidaknya freelancer tahu sebelum project dimulai.
Kalau client meminta banyak opsi, itu juga produksi
Ada client yang tidak banyak revisi, tapi meminta terlalu banyak alternatif.
“Bikin lima opsi dulu ya.”
Lalu setelah lima dibuat:
“Bisa lima lagi?”
Secara teknis belum revisi.
Secara workload tetap besar.
Reno sekarang membedakan:
jumlah konsep awal,
jumlah revisi,
dan jumlah deliverable.
Tiga hal itu berbeda.
Kalau proposal mencakup dua konsep awal, konsep ketiga adalah tambahan scope.
Kejelasan ini penting karena freelancer sering hanya membatasi revisi tetapi lupa membatasi eksplorasi awal.
Revisi juga perlu memperhitungkan dependency
Kadang freelancer menunggu copy.
Kadang menunggu foto.
Kadang menunggu data.
Kalau materi berubah setelah desain sudah selesai, perubahan itu bukan selalu kesalahan freelancer.
Reno mulai menulis:
“Materi final dari client dibutuhkan sebelum produksi final. Perubahan materi setelah approval dapat memengaruhi timeline dan fee.”
Tidak perlu kaku.
Tapi dependency harus terlihat.
Jangan jadikan WhatsApp satu-satunya sumber revisi
Voice note.
Screenshot.
Komentar di PDF.
Chat.
Email.
Semua bercampur.
Freelancer akhirnya lupa mana yang final.
Reno memilih satu source of truth.
Untuk project kecil, satu dokumen feedback.
Untuk project besar, project management tool.
Chat tetap dipakai untuk komunikasi cepat.
Tapi revisi final harus masuk satu tempat.
Putaran revisi sebaiknya ditutup dengan approval
Setelah satu putaran selesai, minta konfirmasi.
“Apakah versi ini approved untuk lanjut ke tahap berikutnya?”
Approval menciptakan checkpoint.
Kalau dua minggu kemudian client ingin kembali ke versi sebelumnya, kita punya referensi keputusan.
Bukan untuk berkata “salah sendiri”.
Untuk memahami bahwa arah memang berubah.
Jangan lupa biaya opportunity
Saat Reno menghabiskan tiga malam untuk revisi gratis, dia tidak hanya kehilangan waktu.
Dia kehilangan kesempatan menerima project lain.
Atau istirahat.
Atau mengerjakan marketing.
Opportunity cost jarang terlihat di invoice.
Tapi itulah alasan batas revisi penting secara bisnis.
Freelancer yang kalendernya penuh revisi lama sulit tumbuh karena tidak punya ruang untuk pekerjaan baru.
Revisi terakhir akhirnya selesai
Client lama Reno mengirim putaran keenam.
Reno tetap mengerjakan karena project sudah telanjur berjalan tanpa aturan.
Tapi dia mengatakan:
“Untuk project berikutnya, saya akan pakai skema revisi maksimal dua putaran supaya timeline lebih terjaga.”
Client menjawab:
“Boleh.”
Tidak ada pertengkaran.
Reno menutup laptop pukul 22.30.
Dimas bertanya:
“Proposal baru sudah?”
“Sudah.”
“Kalimatnya?”
Reno membacakan.
Dimas mengangguk.
“Satu kalimat mahal.”
Reno tersenyum.
Sebenarnya bukan mahal.
Justru murah dibanding satu minggu kerja yang hilang karena tidak pernah mendefinisikan kapan revisi harus berhenti.
