Dokumen Proposal & Requirement
Mengapa Proposal Bukan Formalitas?
"Never give a price without discovery."
Proposal atau requirement doc adalah pelindung utama kamu sebagai agency. Client punya kecenderungan alami untuk meminta lebih seiring proyek berjalan. Tanpa dokumen tertulis, tidak ada batas yang jelas.
One-Page Proposal
Proposal yang baik bukan novel — satu halaman yang ringkas, padat, dan mudah dipahami:
┌──────────────────────────────────────────────┐
│ ONE-PAGE PROPOSAL │
├──────────────────────────────────────────────┤
│ │
│ 📋 Problem Statement │
│ Apa masalah yang sedang dihadapi client? │
│ │
│ 💡 Proposed Solution │
│ Bagaimana automation menyelesaikannya? │
│ │
│ 📦 Deliverables │
│ Daftar konkret apa yang client terima │
│ │
│ 💰 Investment & Timeline │
│ Harga, jadwal, dan milestone │
│ │
│ 🤝 Client Responsibilities │
│ Apa yang perlu disediakan client │
│ │
│ ⛔ What's NOT Included │
│ Batasan scope yang jelas │
│ │
└──────────────────────────────────────────────┘Poin Kunci
Over-documentation kills momentum. Proposal satu halaman dibaca, menghilangkan ambiguitas, dan jadi referensi mudah sepanjang proyek.
Contoh Real-World
Berikut contoh struktur proposal nyata yang pernah digunakan:
| Bagian | Isi |
|---|---|
| Business Value Mapping | "Membuat sales agent, support agent, dan internal agent" |
| Pilot / MVP Scope | "2-3 sample brochure, WhatsApp test flow" |
| Risk & Mitigation | Identifikasi risiko dan strategi penanganan |
| Support & Maintenance | "Setiap workflow, prompt, integrasi — didokumentasikan" |
| Costing Approach | "Final cost depends on document volume" |
| Next Steps | "Share brochure, design hosting preferences, approve 2-week demo scope" |
Diagram & Flowchart dalam Proposal
Proposal terbaik menggunakan visual, bukan paragraf panjang:
Customer Query
│
├── WhatsApp ──┐
│ ├── Workflow ── RAG + Vector DB + LLM
└── Website ───┘ │
├── Lead? → Google CRM
└── Technical? → Product Info Response"Bahkan setelah tiga bulan, hanya dengan membuka proposal ini, saya bisa memahami semuanya. Bayangkan betapa senangnya client menerima dokumen seperti ini."
Mengapa Requirement Doc Menyelamatkan Anda
Client akan meminta lebih dari yang disepakati. Ini bukan soal niat buruk — ini sifat alami:
Discovery Call
│
▼
Requirement Doc ──── Client Review ──── Sign-off
│ │
▼ ▼
"Bisa tambah Telegram?" "Sudah di luar scope,
kita bisa fase berikutnya"Checklist Requirement Doc
- Map current process — Dokumentasikan frekuensi, siapa yang mengerjakan, waktu per eksekusi, jumlah orang terlibat, pain points
- Estimate monetizable value — Cost saving? Revenue uplift? Hybrid?
- Define deliverables & scope — Termasuk apa yang TIDAK termasuk
- Outline QA & rollout plan — Quality assurance, deployment, measurement window
- Specify costs client bears — API keys, subscription, hosting
- Specify maintenance & SLAs — Recurring cost, response time, support level
Kirim, Follow-up, Pastikan Alignment
Jangan hanya kirim sekali dan berharap client membaca:
| Langkah | Aksi |
|---|---|
| Kirim | Email/WhatsApp dengan dokumen terlampir |
| Follow-up | "Sudah sempat review proposal-nya?" |
| Konfirmasi | Pastikan client benar-benar di halaman yang sama |
| Sign-off | Approval tertulis sebelum mulai build |
Takeaway
Proposal yang baik bukan cuma alat komunikasi — ini jembatan antara discovery call dan build. Tanpa proposal, kamu membangun di atas asumsi. Dengan proposal, kamu membangun di atas kesepakatan.