Change request tanpa tagihan: kenapa revisi tidak harus dikunci ulang
Banyak vendor website mengunci requirement dan desain, lalu menagih setiap change request. Ini asal siklus itu, kenapa sekarang bisa dipotong, dan di mana batasnya tetap perlu.
Change request tidak harus kena tagihan atau membuat requirement dan desain dikunci ulang, selama perubahannya masih di dalam scope yang disepakati di awal. Yang tetap dihitung terpisah adalah fitur baru, dan batas itu perlu ditulis sebelum proyek mulai, bukan saat sudah ribut.
Siklus lama yang dialami banyak agency
- Requirement dikunci.
- Desain harus final sebelum coding.
- Development dimulai.
- Klien minta perubahan.
- Agency kena charge.
- Requirement dan desain dikunci ulang, lalu kembali ke nomor 1.
Setiap putaran memakan waktu dan margin. Agency terjepit di antara klien yang ingin perubahan dan vendor yang menagih.
Kenapa siklus itu dulu masuk akal?
Dulu mengubah website yang sudah dibangun memang mahal: banyak pekerjaan diulang dengan tangan, jadi vendor melindungi diri dengan mengunci tahap demi tahap. Sekarang biaya perubahan jauh lebih kecil. Di salah satu proyek kami, 6 permintaan revisi dari satu klien semuanya live di hari yang sama.
Apa yang termasuk revisi, apa yang fitur baru?
| Revisi (tanpa tagihan) | Fitur baru (dihitung terpisah) |
|---|---|
| Ganti teks, gambar, warna, huruf | Halaman di luar daftar proposal |
| Ubah susunan bagian di halaman | Login anggota atau area khusus |
| Ganti arah desain sebelum live | Pembayaran online, kalau belum ada di scope |
| Tambah atau kurangi isi di halaman yang sudah ada | Integrasi dengan sistem lain |
Tiga aturan supaya "tanpa batas" tidak jadi jebakan
- Tanpa batas apa? Semua halaman dan fitur yang ada di proposal. Desain, isi, dan susunannya boleh diubah sebanyak klien mau.
- Kapan dikerjakan? Satu daftar sekali kirim, dikerjakan sampai live, baru daftar berikutnya.
- Sampai kapan? Ada batas waktu yang jelas. Di Pitkru: selama build sampai 30 hari setelah live, setelah itu lewat paket bulanan. Aturan lengkapnya ada di aturan revisi Pitkru.
Tanpa batas revisi, bukan tanpa batas fitur.
Cara menjelaskannya ke klien
Kirim aturan revisi bersama proposal, bukan setelah ada masalah. Klien biasanya menerima batas yang disebut di awal. Yang membuat hubungan rusak adalah batas yang baru muncul saat klien sudah meminta perubahan. Kalau klien minta fitur baru, kirim harganya dengan cepat. Di Pitkru, harga fitur baru dikirim maksimal 1 hari kerja, dan pekerjaan lain tetap jalan tanpa dikunci ulang.
Agency yang menjual website lewat partner perlu aturan ini tertulis di kontrak partner juga. Lihat apa yang harus ada di kontrak white-label.
Tanya jawab
Apa bedanya revisi dan fitur baru?
Revisi mengubah apa yang sudah ada di proposal: teks, gambar, warna, susunan, isi halaman. Fitur baru menambah sesuatu yang belum ada, misalnya halaman di luar daftar, login anggota, atau pembayaran online.
Kenapa revisi tanpa batas ada batas waktunya?
Supaya proyek punya akhir. Di Pitkru, revisi tanpa batas berlaku selama build sampai 30 hari setelah live. Setelah itu perubahan masuk paket bulanan.
Kenapa revisi dikirim satu daftar sekali kirim?
Supaya tidak ada perubahan yang saling menimpa. Satu daftar dikerjakan sampai live, baru daftar berikutnya. Klien juga terbiasa mengumpulkan masukan dulu sebelum mengirim.