Dua tahun lalu, gw hampir meledak kantor pas mau deliver project website e-commerce buat client retail. Semua udah rampung. UAT selesai, QA clean, tim dev udah pada siap-siap pulang lebih cepet. Tinggal deploy.

Eh, baru tau ternyata username sama password hosting gak diserahin siapa-siapa. Gw nelfon PM klien, dia bilang "iya bucu, besok pagi dikasih ya". Besok paginya? Nunggu email dari IT departemennya. Hari berikutnya? IT nya cuti mendadak.

Gak sampe 48 jam,交付 project telat dua hari. Client marah-marah, reputasi agency ancur, dan tim gw stress berat cuma gara-gara hal sepele:

Nggak pernah nanya soal akses teknis.

Padahal, semua ini bisa dicegah kalau dalam persiapan project klien atau saat pre-kickoff, gw berani nunjuk dan bilang: "Siapa orangnya, dan mana akunnya?"

Biasanya, founder atau PM agensi kayak gw ini fokus banget ngebahas budget, timeline umum, dan fitur. Kita sibuk nego harga. Padahal, yang bikin project buntu itu bukan harganya, tapi celah informasi yang gak dibicarakan pas tanda tangan PO.

PO itu cuma alat legal buat tagihan. Itu bukan jaminan operasional. Kalau lo kira setelah tanda tangan aman, salah besar. Nah, buat ngerapihin ekosistem kerja sebelum money masuk, lo butuh 5 pertanyaan ini. Bukan buat nyebelin klien, tapi buat nunjukin kalo lo pro level dewa.

1. Siapa Final Approver untuk Tiap Stage (Dan Siapa Backup-nya)?

Ini yang paling umum terjadi: Lo kirim draft design, dikirim ke Manager Marketing. Dia miringin kepala dikit, lalu kirim balik ke Direktur. Direktur minta revisi. Lo revisi. Lho, tapi kok malah jadi ga sesuai ekspektasi Manager Marketing yang tadinya setuju?

Itu namanya approval loop of death. Waktu habis, energi habis.

Tanyakan secara spesifik:
> "Pak/Bu, kalau kita submit desain homepage, apakah Bapak sudah boleh langsung approve, atau harus lewat Ibu Sarah dulu di tim marketing? Kalau Bapak lagi meeting abroad selama seminggu, siapa yang punya wewenang sign-off sementara?"

Jawaban ini bakal kasih lo peta hierarki. Jangan cuma tanya "siapa bosnya", tapi tanyakan mekanisme decision making-nya. Kadang di beberapa klien korporat, struktur approval-nya itu rigid dan panjang. Kalau lo tahu duluan, lo bisa prepare timeline buffer atau cari celah buat kerja sambil jalan (parallel processing).

Di SatuTim, kita biasanya catat struktur ini di kolom metadata Brief biar tim development gak bingung harus nunggu approval siapa pas mau start coding.

2. Apa Protokol Jika Ada Blocker Internal dari Pihak Klien?

Seringkali, tanggung jawab klien itu gantung di banyak pihak. Misal, mereka harus nunggu persetujuan bagian Finance buat beli aset berbayar, atau IT Department yang bandel buat kasih akses API.

Kalaupun projectnya berjalan lancar di awal, tiba-tiba di tengah jalan macet total karena birokrasi internal klien. Biasanya solusinya? Diam seribu bahasa. Tim vendor diam, klien diam. Sampai deadline meleset.

Pertanyaan kritis yang sering dilewatkan:
> "Bagaimana kalau misalkan proses pengajuan budget vendor untuk tools tambahan macet di Finance lebih dari 5 hari? Apakah kita lanjutkan pekerjaan tanpa tools itu dulu (menyangga timeline), atau kita stand-by sambil nunggu kelarannya?"

Atau lebih brutal lagi:
> "Jika ada dokumen legal yang belum clear sampai H-7 sebelum launch, apa mekanisme escalasinya?"

Dengan bertanya ini, lo memaksa klien memikirkan skenario terburuk bareng-bareng. Lo nunjukin bahwa lo peduli sama timeline, bukan cuma jualan jasa. Ini bentuk manajemen timeline proyek yang preventif. Jangan tunggu mereka yang memberi tahu lo tentang hambatan. Proaktoip ambil alih risiko itu sejak dini.

3. Seberapa Jelas Definisi "Selesai" atau "Success"?

"Saya pengen websitenya simpel tapi modern dan elegan."

Lo denger kalimat ini berkali-kali, kan? Masalahnya, definisi "elegan" tiap orang beda. Desain lo mungkin minimalis dan bersih, klien lo pikir kurang pop-up dan ceria.

Di fase persiapan project klien, jangan terima definisi subjektif. Minta konkret.

> "Untuk project ini, ukuran keberhasilan yang kami capai adalah apa? Apakah berdasarkan jumlah pageview yang naik 20%, atau conversion rate checkout naik 1%, atau murni kepuasan UI/UX visual saja?"

Kalau bisa dapat angka, great. Kalau nggak, minta contoh referensi.
> "Boleh lihat satu website favorit Pak/Bu yang dianggap 'oke banget' menurut kriteria ini? Nanti kita bedah elemen mana yang mau ditiru dari sisi struktur, bukan plagiat kontennya."

Ini penting banget buat nge-filter scope creep. Kalau nanti ada request tambahan yang keluar dari definisi success awal, lo bisa bilang dengan tenang: "Ini bagus, tapi ini di luar scope tujuan utama kita tadi ya. Mungkin bisa masuk di Phase 2?"

Lebih enak negosiasi di awal daripada di akhir saat project mau kelar dan klien mikir segala sesuatu "gratis".

4. Berapa Batas Maksimal Revisi Gratis, dan Apa Bedanya dengan Perubahan Fitur?

Red flag terbesar agency: Revisi tanpa batas.

Klien (atau bahkan Sales sendiri) kadang janji lisan: "Yaudah, revisi seenaknya aja lah."

Di kertas, terlihat manis. Di lapangan, ini neraka. Klien akan mikir, "Ah, saya coba ubah fontnya dulu. Trus warnanya? Oh iya, gambar hero-nya diganti juga yuk." Tanpa sadar, logika proyek berubah total cuma karena revisi kecil-kecilan yang memakan waktu dev tim berjam-jam.

Masukkan klausul tegas di template kontrak jasa atau sebagai lampiran email sebelum PO:

> "Project ini sudah termasuk paket revisi sebesar [X] kali untuk setiap milestone major. Revisi minor (typo, warna, posisi elemen) tanpa batas. Setiap perubahan yang mengubah fungsi logic atau menambah halaman baru akan dihitung sebagai Change Request (CR) terpisah."

Jangan malu buat batasin ini. Justru dengan membatasi revisi, klien akan lebih serius saat memberikan feedback pertama kali. Mereka bakal diskusi dalam tim mereka dulu sebelum nulis komen ke lo. Kualitas feedback meningkat, waktu pengerjaan berkurang. Win-win.

5. Siapa Kontak Darurat untuk Escalation Saat Deadline Mepet?

Skenario ini pasti terjadi. Misal, kita mau delivery tanggal 20 September. Hari Jumat tanggal 17, kita realize ada bug kritis atau konten dari klien masih belom masuk full.

Biasanya, PM tim vendor panic. Nelfon PM klien, tapi PM klien lagi lembur. Chat di WA diabaikan karena sibuk rapat. Dan akhirnya, tanggal 20 kita telat deliver, padahal seharusnya bisa kelar.

Tanya ini pas meeting awal:
> "Nanti kalau misalnya di H-3 delivery kita ketemu masalah krusial yang butuh keputusan cepat dari pihak Bapak/Ibu, nomor WhatsApp atau kontak person darurat siapa yang sebaiknya kami hubungi?"

Ini bukan tanda kita nggak siap. Ini tanda kita punya SOP. Dengan punya jalur eskalasi langsung, lo bisa bypass birokrasi ketika keadaan genting. Dan seringkali, klien justru merasa lebih aman tahu ada jalur darurat yang jelas daripada harus menebak-nebak.

---

Jadi kesimpulannya, lima pertanyaan ini bukan soal mencari ulah. Ini soal menyingkirkan ambiguitas. Kebanyakan project gagal karena asumsi. Asumsi bahwa klien akan balas chat cepat. Asumsi bahwa mereka paham definisi "selesai". Asumsi bahwa akses server itu instan.

Mulai sekarang, setiap kali lo duduk buat negosiasi PO, jangan cuma bahas nominal. Sisihkan 15 menit buat membahas 5 celah ini. Tulis jawaban mereka di dokumentasi shared (bisa pake fitur discussion async di SatuTim biar rapih dan gak hilang).

Kalau semua poin ini udah dapet jawaban, lo baru boleh tanda tangan PO. Karena sekarang, risikonya udah transparan, dan tanggung jawab udah jelas bagi siapa.

Coba minggu ini, buka satu file kontrak lo yang lagi pending. Cek, apakah lo udah berani nunjuk dan nanya soal "backup approver" dan "kontak darurat"? Atau kita biarin saja nasib menentukan sukses project itu?

Kalau jawabannya "masih gamau nanya, takut kliennya kabur", maybe that’s your real problem.