Pilih proyek ketika masalah, batas pekerjaan, dan kondisi selesainya cukup jelas. Pertimbangkan retainer ketika ada kebutuhan berulang yang nyata, kapasitas yang harus tersedia, dan mekanisme evaluasi berkala.
Keduanya dapat dipakai dalam satu hubungan kerja. Yang perlu dijelaskan adalah pekerjaan apa yang dibayar, siapa yang mengerjakan, dan bagaimana nilainya diperiksa. Bentuk tagihan saja tidak menjawab pertanyaan tersebut.
Mulai dari karakter pekerjaan
Migrasi URL yang sudah direncanakan memiliki titik awal, daftar objek, dependensi, dan pemeriksaan setelah penerapan. Karakter ini cocok disusun sebagai proyek, dengan batas dukungan setelah selesai yang jelas.
Sebaliknya, situs yang rutin menambah produk mungkin membutuhkan peninjauan template, pemeriksaan perubahan, dan koordinasi konten secara berulang. Kebutuhan tersebut bisa mendukung retainer jika volume dan tanggung jawabnya disepakati.
Jangan mengubah semua pekerjaan menjadi retainer hanya karena pengukuran berlangsung lama. Bedakan waktu tunggu pengamatan dari aktivitas yang memang memerlukan kapasitas kerja.
Gunakan matriks sederhana
| Kondisi | Bentuk yang layak dipertimbangkan | Hal yang harus jelas |
|---|---|---|
| Satu masalah dengan batas selesai | Proyek | Objek, hasil, dan penerimaan |
| Masalah belum terdiagnosis | Tahap diagnosis | Pertanyaan serta keluaran keputusan |
| Perubahan situs rutin | Retainer | Kapasitas, antrean, dan prioritas |
| Proyek disusul kebutuhan pemantauan | Gabungan | Batas perpindahan tahap |
| Implementasi belum tersedia | Diagnosis dahulu | Siapa yang akan menerapkan |
Tabel ini membantu menyusun pembicaraan, bukan aturan bahwa setiap situs harus mengikuti pola yang sama.
Pisahkan audit dari implementasi
Contoh ilustratif: audit menemukan masalah navigasi pada template kategori toko online. Menyerahkan temuan dengan bukti merupakan hasil audit. Mengubah komponen, memeriksa regresi, dan menerapkan ke situs merupakan pekerjaan implementasi.
Jika proposal hanya menyebut “optimasi kategori”, kedua pihak bisa menganggap tanggung jawabnya berbeda. Tulis secara eksplisit apakah penyedia memberi rekomendasi, membuat perubahan, atau membantu developer internal.
Pisahkan pula pemeriksaan penerapan dari pengamatan hasil pencarian. Perubahan yang benar secara teknis tidak otomatis menghasilkan peningkatan pada periode tertentu.
Definisikan selesai untuk proyek
Gunakan hasil yang dapat diperiksa: daftar URL tercakup, perubahan diterapkan, kasus uji dilalui, dan dokumentasi diserahkan. Hindari mendefinisikan selesai hanya dari hasil eksternal yang tidak sepenuhnya dikendalikan penyedia.
Jika ada masa dukungan, jelaskan cakupannya. Memperbaiki cacat dari perubahan yang dibuat berbeda dari menambah fitur atau mengaudit bagian situs baru.
Simpan keputusan tentang pekerjaan tambahan. Scope yang berubah boleh diterima, tetapi dampaknya terhadap jadwal dan biaya perlu dibahas sebelum dikerjakan.
Definisikan kapasitas untuk retainer
Retainer perlu menjawab jenis pekerjaan yang termasuk, kapasitas yang tersedia, cara memprioritaskan permintaan, dan bagaimana pekerjaan yang belum selesai dibawa ke periode berikutnya.
Contohnya, tim menyepakati antrean prioritas untuk pemeriksaan rilis dan revisi konten. Setiap periode dimulai dengan kebutuhan yang paling penting, bukan kewajiban menghasilkan jumlah dokumen yang sama ketika masalahnya berbeda.
Jelaskan juga apa yang terjadi ketika tidak ada perubahan besar. Pemantauan harus memiliki objek dan respons yang nyata. “Memantau SEO” tanpa sumber data, kondisi pemeriksaan, atau tindakan lanjutan sulit dievaluasi.
Buat titik evaluasi yang berguna
Evaluasi kerja sama menggunakan bukti pelaksanaan dan pembelajaran: apakah temuan dapat ditindaklanjuti, apakah hambatan disampaikan, apakah perubahan diperiksa, dan apakah keputusan berikutnya menjadi lebih jelas.
Hasil bisnis tetap relevan, tetapi perlu dibaca dengan batas atribusinya. Keterlambatan implementasi, perubahan penawaran, dan kapasitas layanan dapat memengaruhi hasil yang diamati.
Jika retainer tidak lagi memiliki kebutuhan berulang yang masuk akal, pembahasannya bisa bergeser ke proyek tertentu atau dukungan sesuai kebutuhan. Jangan mempertahankan format hanya karena sudah lama digunakan.
Siapkan perpindahan dan penutupan
Pastikan hasil kerja, akses, catatan perubahan, dan pekerjaan tertunda dapat diserahkan. Hubungan yang baik tetap membutuhkan dokumentasi agar pemilik situs tidak kehilangan konteks ketika personel berubah.
Sebelum menyetujui kerja sama, tulis satu kalimat: “Pada akhir tahap ini, kami akan menerima … dan memeriksanya dengan …”. Jika kalimat itu masih kabur, perjelas scope lebih dahulu. Pilihan proyek atau retainer akan menjadi jauh lebih mudah setelahnya.
