Jangan Pernah Ketik 'Siap Bang' Tanpa Hitung Dulu

Kemarin client chat: "Gini bang, bisa gak kita tambahin satu field lagi di form pendaftaran? Nggak lama kok, cuma input nomor HP."

Lo otomatis ngetik: "Boleh juga ya".

Dan lo langsung mati suri batin. Karena lo tahu field baru ini bukan cuma tambah input box. Artinya: Validasi backend berubah, testing script harus direvisi, dan developer yang tadinya mau push release besok malem harus ngeblock calendar buat fix edge-case baru.

Apa yang terjadi setelah itu? Biasanya salah satu dari tiga skenario ngeselin:

  1. Tim overwork 48 jam demi nutupin hole yang lo bikin sendiri.
  2. Release molor, client nangis pas deadline mau masuk, dan lo jadi bajungan di mata mereka.
  3. Kode diburu-buru, bermasalah di production, dan PR-an jadi berlipat ganda.
Ini konteks umum di kebanyakan komunikasi klien agency. Kita terjebak budaya "Service Hero". Lo pikir bilang "iya" itu baik. Lo pikir menjaga mood klien itu prioritas. Padahal, setiap kali lo bilang "Boleh" tanpa konteks, lo lagi mencuri kredibilitas tim lo dan menyembunyikan risiko.

Beneran loh. Klien yang paling kesel bukan vendor yang nunjukin konsekuensi, tapi vendor yang bilang "oke" terus tiba-tiba project molor atau hasilnya jelek karena terburu-buru.

Framework Impact Assessment: Matikan Drama, Munculkan Pilihan

Solusinya? Gak perlu bikin proposal PDF seketebal bantal. Gak perlu birokrasi kaku yang bikin klien merasa didoktrin.

Ganti impuls "Boleh" dengan Impact Assessment. Intinya simpel: Setiap permintaan baru punya harga. Lo gak boleh nyelem dulu tanpa liat nilai tukarnya.

Saat lo nerima request, jangan langsung bilang ya atau no. Tanyakan dampaknya ke 3 dimensi ini:

1. Dampak Timeline

Semua request baru pasti menggeser waktu. Pertanyaannya bukan "Bisa gak?", tapi "Mau digeser berapa hari?" atau "Fitur apa yang mau kita cut supaya jadwal tetap aman?"

2. Dampak Sumber Daya

Who pays for this? Kalau tim lo full capacity, nambahin fitur kecil berarti nge-reassign orang dari tugas lain. Atau artinya hire kontraktor tambahan?

3. Dampak Prioritas/Kualitas

Ada budget time dan budget code. Makin banyak request, makin tipis perhatian tim buat ngepolish detail. Apa klien sadar kalau request tambahan ini berpotensi ningkatin bug rate?

Contoh konkret kasus nyata:

Kasus e-commerce setup beberapa bulan lalu. Sprint ke-3, client ngeh bahwa filter pencarian produk kurang advanced. Dia chat: "Mas, tolong bikinin filter by harga range sama stok ya, urgent banget."

Dulu, gw mungkin langsung panik dan bilang "Siap mas". Sekarang? Gw balikin dengan Impact Assessment via chat:

> "Done mas, request note-catat di ticket. Just need alignment dulu: Buat nambahin filter complex ini, estimasi development +3 hari. Akibatnya, fitur 'Checkout Flow Optimization' (yang jadi KPI diskon akhir bulan) harus kita tangguhin ke sprint depan. Atau kita gas filternya sekarang dan Checkout delay H+3. Mas prefer opsi mana?"

Hasilnya? Client diam bentar, cek kalender promosinya sendiri, dan bilang: "Oh gitu... Oke lah, filternya kita tangguhin. Fokus ke Checkout dulu."

Selesai. Krisis dihindari. Klien happy karena dia dapet insight buat management decision, bukan dipaksa terima barang setengah matang. Lo gak jadi robot penolak, lo jadi partner strategis.

Script Chat Siaga Tembak: Dari 'Boleh' Jadi 'Trade-off'

Lo gak perlu mikirin struktur dari nol. Ini gw share script yang udah gw cobain dan jalan buat handle berbagai jenis client. Copy-paste, sesuaikan tone, tinggal send.

Kasus A: Client Minta Perubahan Kecil Tengah Sprint

Gunakan ini buat ngingetin soal tanpa sounding like "sotoy".

> "Siap bang. Done catat di ticket ya.
Cuma quick heads up: Perubahan ini bakal nambah estimasi ~2 jam. Karena resource dev lagi full di module Payment, ada kemungkinan testing phase mundur 1 hari. Gak problematik buat go-live? Kalau oke, kita gas!"

Kenapa ini jalan: Lo ngasih opsi. Lo nunjukin konsekuensi kecil. Klien biasanya bilang "Yaudah gapapa" atau "Waduh, maksa ya, skip aja". Dalam kedua kasus, lo menang. Lo gak nanggung rugi.

Kasus B: Change Request Process & Negosiasi Harga Tambahan

Disini lo hadapi situasi dimana perubahan emang butuh duit atau luar scope. Ini momen emas buat negosiasi harga tambahan dengan basis objektivitas, bukan subjektif.

> "Gini pak, permintaan tambahan ini teknisnya masuk kategori enhancement, bukan bug fix/koreksi. Estimasi effort butuh 1 hari kerja dedicated.

Untuk eksekusi ini, kita bisa two ways:

  1. Kita add ke invoice adjustment sebesar RpX (berdasarkan rate harian yang udah disepakati).
  2. Atau kita queue ke milestone berikutnya.
Pilih mana yang lebih cocok sama budget/schedule paket kita saat ini?"

Tips: Angka RpX itu wajib ada. Klien cenderung menolak nominal yang muncul tiba-tiba di akhir project. Lebih baik mereka bayar lunas di tengah perjalanan dengan justifikasi yang jelas (Impact Assessment yang sudah mereka approve).

Kasus C: Client "Gesi" atau Mau Semua Fitur Sekalian

Bahaya. Ini scope creep level boss.

> "Pak, list request baru totalnya sekarang nambah jadi 50% dari scope original. Kalau kita eksekusi semuanya sekaligus, timeline bakal extend 6 minggu dan budget butuh revisi signifikan.

Agar kita tetep bisa launch tepat waktu, saya sarankan kita break down jadi Phasing:

  • Phase 1 (Launch): Fitur A, B, C (Core requirement).
  • Phase 2 (Plus): Fitur D, E (Request baru). Direncanakan 2 minggu pasca-launch.

Gimana menurut Bapak? Soalnya concern gw, kalau dipaksakan concurrent, risiko stabilitas sistem naik cukup tinggi."

Transparansi Bikin Klien Respek (Bukan Marah)

Banyak founder takut kalau mulai menerapkan pola ini, klien bakal ngerasa dilayanin kayak pabrik kaku. Anggapan ini keliru.

Justru, klien premium—termasuk klien startup founder sejati—lebih respek sama vendor yang punya standar profesional.

Ketika lo nerusin trade-off, lo sedang melakukan dua hal hebat:

  1. Melindungi kualitas output. Lo nunjukin kalau lo peduli sama hasil akhir yang stable, bukan sekadar ngerjain task.
  2. Memberdayakan klien. Klien juga punya pressure dari atasan atau investor mereka. Pas lo nunjukin dampak perubahan, lo bantu mereka me-manage expectation ke stakeholder mereka sendiri. Lo jadi alat bantu keputusan mereka.

Di SatuTim, kita selalu anjurkan tim buat log semua percakapan request di Brief/Discussion section, bukan cuma simpan di chat WA yang nanti hilang tenggelam. Jadi pas ada dispute "kok tadi dikata cepet", lo tinggal screenshot history Impact Assessment yang udah approval. Transaksi kepercayaan terbangun, bukan transaksi permusuhan.

Atasi Scope Creep Lewat Mindset, Bukan Cuma Tools

Tools kayak SatuTim, Jira, atau Asana mah cuma wadah. Masalah utamanya ada di kepala PM atau Account Manager yang masih takut bilang "Wait, let me check impactnya".

Mulai hari ini, coba ubah reflex lo.

Saat notifikasi client bunyi dan mereka ngetik "Bisa gak...", jangan ketik "Boleh" dulu. Tarik napas. Cek kalender tim. Cek sisa bandwidth. Lalu ketik:

[Acknowledge] + [Impact Quantified] + [Choice Provided]

Contoh:
> "Bisa mas. Tapi ini butuh geser deadline +2 hari. Oke ga?"

Gampang. Ringan. Profesional.

Dan lo bakal sadar, setelah lo konsisten pake framework ini selama 1 bulan, hal aneh mulai terjadi:

  • Klien mulai mikir dua kali sebelum nge-request hal sepele.
  • Budget project lebih aman karena change request tercatat jelas.
  • Team lo tidur lebih nyenyak karena gak ada kejutan last-minute yang ngebakar overtime.

Ini bukan tentang jadi jahat. Ini tentang jadi dewasa dalam bisnis.

Coba minggu ini: Ambil satu request client yang lagi tumpuk di chat. Jangan jawab iya. Balas pakai rumus Impact Assessment. Lihat reaksi-nya.

Kalau respon-nya agresif, mungkin bukan masalah workflow, tapi mungkin memang klien yang tidak respect sama proses. Tanda bagus buat evaluasi relasi.

Tapi kalau klien cuma bilang "Oke, gas geser aja", selamat. Lo baru aja naik kelas. Lo bukan lagi vendor yang gampang dibeli, lo udah jadi partner strategis yang nilainya bisa ditransaksikan.