Salah satu sumber konflik terbesar antara freelancer dan klien bukan soal kualitas kerja atau harga — tapi soal batas pekerjaan. Klien merasa sudah bayar tapi banyak yang belum selesai. Freelancer merasa sudah kerja lebih dari yang disepakati. Masalah ini hampir selalu bisa dicegah dengan satu dokumen: Scope of Work.
Apa itu Scope of Work?
Scope of Work (SOW) adalah dokumen yang mendefinisikan secara spesifik apa yang akan dikerjakan, oleh siapa, dalam berapa lama, dan dengan deliverable apa dalam sebuah proyek atau kontrak kerja sama.
SOW bukan proposal. SOW bukan invoice. SOW adalah dokumen operasional yang menjadi acuan kerja selama proyek berlangsung.
Kalau proyek adalah sebuah perjalanan, SOW adalah peta yang disepakati sebelum berangkat, termasuk rute mana yang diambil dan tempat mana yang tidak akan dikunjungi.
Apa Saja Isi Scope of Work?
SOW yang baik memuat komponen-komponen berikut:
Deskripsi Proyek
Penjelasan singkat tentang apa yang dikerjakan dan tujuannya. Satu sampai dua paragraf sudah cukup.
Deliverables
Daftar konkret dari apa yang akan diserahkan di akhir proyek. Ini harus spesifik dan terukur.
Contoh yang kurang baik: "Website yang bagus." Contoh yang baik:
- Landing page dengan 5 seksi (hero, fitur, harga, testimoni, CTA)
- Halaman login dan registrasi
- Dashboard pengguna dengan 3 tampilan utama
- File desain Figma
- Kode sumber di GitHub
Timeline dan Milestone
Kapan setiap bagian pekerjaan selesai. Milestone memecah proyek menjadi tahapan yang bisa diperiksa satu per satu, sehingga tidak ada kejutan di akhir.
Contoh:
- Minggu 1–2: Desain wireframe dan prototype, disetujui klien
- Minggu 3–5: Development frontend
- Minggu 6: Integration dan testing
- Minggu 7: Revisi berdasarkan feedback klien
- Minggu 8: Launch
Yang Termasuk dan Tidak Termasuk
Ini bagian yang paling penting dan paling sering dilewati. Tulis secara eksplisit apa yang ada dan tidak ada dalam proyek ini.
Contoh tidak termasuk:
- Konten (foto, teks, copywriting)
- Hosting dan domain
- Pemeliharaan setelah launch
- Fitur yang belum disebutkan di atas
Revisi
Berapa kali revisi yang termasuk dalam harga? Apa yang dihitung sebagai revisi minor vs major? Tanpa ini, "satu kali revisi" bisa berubah menjadi revisi tak berujung.
Syarat Pembayaran
Kapan dan bagaimana pembayaran dilakukan. Biasanya dibagi per milestone.
Asumsi
Apa yang kamu asumsikan akan disediakan oleh klien? Contoh: klien menyediakan semua konten paling lambat minggu pertama, klien menyediakan akses ke sistem yang perlu diintegrasikan.
Perbedaan SOW dengan PRD
SOW dan PRD sering tertukar, tapi fungsinya berbeda:
| | Scope of Work | PRD | |---|---|---| | Fokus | Batas dan lingkup pekerjaan | Kebutuhan produk | | Siapa yang membaca | Klien dan freelancer/kontraktor | Tim produk dan developer | | Isinya | Deliverables, timeline, harga, revisi | User stories, fitur, acceptance criteria | | Kapan dibuat | Sebelum kontrak ditandatangani | Sebelum development dimulai |
Untuk proyek digital, keduanya idealnya ada. SOW mengatur hubungan bisnis dan legal antara kamu dan klien. PRD mengatur apa yang dibangun secara teknis. SOW menjawab "apa yang kita sepakati?" — PRD menjawab "apa yang kita bangun?"
Kenapa SOW Sering Tidak Dibuat?
Banyak freelancer melewati SOW karena beberapa alasan:
Merasa terlalu formal. Proyek kecil terasa tidak perlu dokumen panjang. Padahal SOW bisa sesingkat satu halaman A4.
Takut klien kabur. Beberapa freelancer khawatir kalau terlalu banyak dokumen, klien jadi tidak jadi pakai jasanya. Padahal klien yang serius justru lebih nyaman dengan freelancer yang profesional dan terstruktur.
Tidak tahu cara membuatnya. Banyak freelancer baru yang belum pernah membuat SOW dan tidak tahu harus mulai dari mana.
Konsekuensinya selalu sama: proyek melebar, konflik soal scope, dan pekerjaan yang tidak dibayar.
Template SOW Sederhana
# Scope of Work
Proyek: [Nama Proyek]
Klien: [Nama Klien]
Tanggal: [Tanggal]
## Deskripsi Proyek
[2-3 kalimat tentang proyek]
## Deliverables
- [Item 1]
- [Item 2]
- ...
## Yang Tidak Termasuk
- [Item 1]
- [Item 2]
- ...
## Timeline
- [Tanggal]: [Milestone 1]
- [Tanggal]: [Milestone 2]
- ...
## Revisi
Termasuk [N] kali revisi minor per milestone.
Revisi major di luar scope dihitung sebagai pekerjaan tambahan.
## Pembayaran
- [%] di awal sebelum pekerjaan dimulai
- [%] setelah milestone pertama disetujui
- [%] setelah final delivery
## Asumsi
- Klien menyediakan [X] paling lambat [tanggal]
- ...
Hubungannya dengan Brief Klien dan PRD
Alur dokumen yang ideal untuk proyek freelance digital:
- Brief klien — klien menjelaskan kebutuhannya (sering masih mentah dan tidak lengkap)
- PRD — brief diubah menjadi dokumen kebutuhan produk yang terstruktur
- SOW — berdasarkan PRD, dibuat scope pekerjaan, timeline, dan harga
- Prototype — alur produk divisualisasikan sebelum development dimulai
- Development — baru dimulai setelah semua dokumen di atas disetujui
Spectr membantu di langkah 1 sampai 4: mengubah brief klien menjadi PRD dan prototype secara otomatis, sehingga kamu bisa langsung fokus ke SOW dan mulai kerja lebih cepat.
Punya brief klien yang perlu diubah jadi dokumen yang terstruktur? Coba Spectr gratis.
