Proposal Writing

"Proposal bukan sekadar dokumen — ini adalah story tentang bagaimana kita akan menyelesaikan masalah klien."

---

Kapan & Untuk Siapa

	Keterangan
Kapan digunakan	Setelah Solution Design & Effort Estimation selesai, ketika perlu menyusun dokumen proposal formal untuk klien
Siapa yang pakai	Presales Consultant (penulis utama), Solution Architect (reviewer teknis), Sales Lead (reviewer komersial)
Prasyarat	Discovery Report, Solution Design Document, Effort Estimation telah di-review dan disetujui internal

---

Tujuan & Outcome

Tujuan	Outcome
Menyusun proposal yang meyakinkan dan profesional	Dokumen proposal yang siap dikirim ke klien
Menerjemahkan solusi teknis menjadi bahasa bisnis	Klien memahami value proposition dengan jelas
Memberikan transparansi investasi dan timeline	Klien dapat membuat keputusan yang informed
Menunjukkan pemahaman mendalam terhadap kebutuhan klien	Diferensiasi dari kompetitor

---

Definisi Istilah

Istilah	Definisi
Proposal	Dokumen formal yang berisi pemahaman kebutuhan, solusi yang ditawarkan, timeline, dan investasi
Executive Summary	Rangkuman 1 halaman yang mencakup problem, solution, outcome, dan diferensiasi
SOW (Statement of Work)	Dokumen teknis detail yang menjabarkan scope, deliverables, dan acceptance criteria — biasanya lampiran proposal
RFP Response	Proposal yang ditulis sebagai respon terhadap Request for Proposal formal dari klien (dibahas terpisah di halaman RFP & RFI Response)
Win Theme	Pesan kunci yang menjadi "benang merah" di seluruh proposal, menjawab pertanyaan "Mengapa Divistant?"
Compliance Matrix	Tabel yang memetakan setiap requirement klien ke bagian proposal yang menjawabnya
Pricing Model	Struktur harga yang dipilih: Fixed Price, T&M, atau Hybrid
Ghost Team	Tim yang akan diusulkan dalam proposal berdasarkan kebutuhan project
Boilerplate	Teks standar yang sudah divalidasi dan bisa di-reuse di berbagai proposal
Storyboard	Outline visual per halaman/section yang digunakan untuk merencanakan alur narasi proposal

---

Konten Utama

1. Prinsip Proposal Divistant

Setiap proposal Divistant harus memenuhi empat prinsip utama:

Prinsip	Penjelasan	Contoh
Client-First Language	Bicara tentang masalah mereka, bukan kehebatan kita	❌ "Kami memiliki 50+ developer berpengalaman" → ✅ "Tim Anda akan didukung oleh developer yang sudah menangani integrasi serupa di industri yang sama"
Outcome-Oriented	Jelaskan hasil yang akan dicapai, bukan hanya fitur	❌ "Kami akan membangun API gateway" → ✅ "Integrasi real-time yang mengurangi waktu proses order dari 2 hari menjadi 15 menit"
Clear & Concise	Hindari jargon teknis yang tidak perlu; gunakan bahasa yang decision maker pahami	Gunakan istilah bisnis di body, letakkan detail teknis di appendix
Visually Professional	Gunakan brand guidelines Divistant secara konsisten	Template resmi, color palette Divistant, consistent typography

---

2. Proposal Structure — 10 Section Standard

Setiap proposal Divistant mengikuti struktur 10 section berikut. Urutan ini dirancang untuk membangun narasi yang mengalir dari pemahaman masalah → solusi → investasi.

Overview Struktur & Panduan Panjang:

#	Section	Tujuan	Target Halaman	Penulis Utama
1	Cover Page	First impression profesional	1 halaman	Presales
2	Executive Summary	Ringkasan bagi decision maker	1 halaman (maks)	Presales (tulis terakhir)
3	Table of Contents	Navigasi dokumen	1 halaman	Auto-generated
4	Understanding of Requirements	Buktikan pemahaman kita	3-5 halaman	Presales
5	Proposed Solution & Architecture	Apa yang kita bangun & bagaimana	4-8 halaman	Solution Architect
6	Methodology & Approach	Cara kerja & delivery approach	2-4 halaman	Presales
7	Team & Credentials	Bangun trust pada tim	2-4 halaman	Presales
8	Timeline & Milestones	Kapan deliverables selesai	1-3 halaman	Presales + SA
9	Investment & Payment Terms	Transparansi biaya	2-3 halaman	Sales Lead
10	Why Divistant	Diferensiasi & closing statement	1-2 halaman	Presales
-	Appendices	Detail pendukung	Variabel	Tim

Total halaman guidance: 18-35 halaman (tanpa appendices)

• Deal < 200 juta: 12-18 halaman (compact)
• Deal 200 juta – 1 miliar: 20-30 halaman (standard)
• Deal > 1 miliar: 30-50 halaman (enterprise)

---

Section 1: Cover Page

Tujuan: First impression yang profesional. Klien membentuk persepsi dalam 5 detik pertama.

Elemen wajib:

Elemen	Posisi	Detail
Logo Divistant	Top-left atau top-center	Gunakan logo resmi dengan clear space
Logo klien	Top-right (jika diizinkan)	Minta approval sebelum pakai logo klien
Judul proposal	Center	Gunakan frasa outcome-oriented, bukan activity
Subtitle	Di bawah judul	Nama project atau brief description
Nama klien	Center atau below subtitle	Nama resmi perusahaan
Tanggal submission	Bottom-left	Format: DD Month YYYY (contoh: 15 Februari 2026)
Nomor versi	Bottom-left	v1.0, v1.1, dst
Label confidentiality	Bottom-center	"Confidential — Prepared exclusively for [Nama Klien]"
Nomor referensi	Bottom-right (opsional)	DIV/PROP/2026/001

Contoh Judul yang Baik vs Buruk:

❌ Buruk	✅ Baik	Mengapa Lebih Baik
ERP Implementation Proposal	Digital Transformation of Order-to-Cash Process	Fokus pada outcome bisnis
CRM Development Proposal	Unified Customer Experience Platform	Menggunakan bahasa klien
IT Consulting Proposal	Technology Roadmap for Operational Excellence	Menunjukkan value
System Integration Proposal	Seamless Integration for Real-Time Supply Chain Visibility	Spesifik dan compelling

Common Mistakes:

• Logo pixelated atau stretched
• Nama klien salah eja
• Tanggal tidak diupdate dari proposal sebelumnya
• Tidak ada label confidentiality

---

Section 2: Executive Summary (Maks. 1 Halaman)

Tujuan: Memberikan ringkasan lengkap bagi decision maker yang tidak akan membaca seluruh dokumen. Ini mungkin satu-satunya halaman yang dibaca oleh C-level.

Struktur PESO:

Elemen	Isi	Proporsi	Jumlah Kata
P — Problem	Masalah bisnis utama klien (dari Discovery)	20%	60-80 kata
E — Evidence	Data/fakta yang memperkuat urgensi	15%	45-60 kata
S — Solution	Ringkasan solusi yang ditawarkan	40%	120-160 kata
O — Outcome	Hasil bisnis yang diharapkan (kuantitatif)	25%	75-100 kata

Contoh Executive Summary (PESO):

[P] PT Maju Bersama saat ini menghadapi tantangan serius dalam proses order-to-cash yang masih manual dan terfragmentasi. Rata-rata dibutuhkan 5 hari kerja dari penerimaan order hingga pengiriman, dengan error rate mencapai 12% yang berdampak pada customer satisfaction.

[E] Berdasarkan assessment yang dilakukan bersama tim Anda pada Januari 2026, kami menemukan bahwa 68% waktu proses dihabiskan untuk input data manual dan rekonsiliasi antar sistem. Potensi revenue loss akibat keterlambatan pengiriman diestimasi mencapai IDR 2.4 miliar per tahun.

[S] Divistant mengusulkan implementasi end-to-end Order Management System yang terintegrasi dengan ERP existing (SAP S/4HANA) dan e-commerce platform Anda. Solusi ini mencakup automated order processing, real-time inventory visibility, dan intelligent routing yang dibangun di atas arsitektur microservices untuk scalability jangka panjang. Implementasi akan dilakukan dalam 3 fase selama 5 bulan menggunakan Agile methodology.

[O] Dengan solusi ini, PT Maju Bersama dapat mengharapkan: pengurangan waktu order-to-delivery dari 5 hari menjadi same-day, penurunan error rate dari 12% ke <1%, dan estimated annual saving sebesar IDR 1.8 miliar dari operational efficiency. ROI diproyeksikan tercapai dalam 14 bulan. Divistant memiliki track record sukses dalam 5 project serupa di industri distribusi Indonesia.

Aturan Penulisan:

• Tulis terakhir, setelah semua section lain selesai
• Maksimal 1 halaman (300-400 kata)
• Tidak ada jargon teknis
• Harus bisa berdiri sendiri sebagai dokumen terpisah
• Akhiri dengan 1 kalimat "Why Divistant" yang kuat
• Sertakan angka/metrik sebanyak mungkin — decision makers menyukai angka
• Jangan memulai dengan "Kami" — mulai dengan nama atau situasi klien

Common Mistakes:

• Terlalu panjang (> 1 halaman)
• Terlalu generic / bisa dipakai untuk klien mana saja
• Tidak ada angka / metrik yang spesifik
• Dimulai dengan deskripsi Divistant, bukan masalah klien
• Berisi jargon teknis yang tidak dipahami C-level

---

Section 3: Table of Contents

Tujuan: Memudahkan navigasi, terutama untuk proposal > 15 halaman.

Aturan:

• Auto-generated dari heading styles (jangan manual)
• Tampilkan sampai level 2 heading (Section + Sub-section)
• Sertakan page numbers
• Update sebelum final export ke PDF

Contoh Format:

Table of Contents

1. Executive Summary ................................. 2
2. Understanding of Requirements ..................... 3
   2.1 Business Context .............................. 3
   2.2 Current State Assessment ...................... 4
   2.3 Desired State & Requirements .................. 5
3. Proposed Solution & Architecture .................. 7
   3.1 Solution Overview ............................. 7
   3.2 Architecture Design ........................... 8
   3.3 Technology Stack .............................. 10
4. Methodology & Approach ........................... 12
5. Team & Credentials ............................... 14
6. Timeline & Milestones ............................ 16
7. Investment & Payment Terms ....................... 18
8. Why Divistant .................................... 20
Appendix A: Detailed CVs ............................ 22
Appendix B: Case Studies ............................. 25
Appendix C: Terms & Conditions ....................... 28

Tips: Untuk proposal < 12 halaman, Table of Contents bisa di-skip atau dijadikan simple list di halaman Executive Summary.

---

Section 4: Understanding of Requirements

Tujuan: Membuktikan bahwa kita benar-benar memahami situasi dan kebutuhan klien. Ini adalah section paling penting — jika klien merasa tidak dipahami, mereka tidak akan percaya solusi kita tepat.

Sub-sections:

4.1 Business Context (0.5-1 halaman)

Gambaran bisnis klien yang menunjukkan kita sudah "do our homework".

Elemen	Contoh
Industri & posisi pasar	"PT Maju Bersama adalah distributor FMCG terkemuka dengan jaringan 200+ retailer di Jawa dan Sumatera"
Business model	"Model distribusi multi-tier dengan 3 regional warehouse dan 15 distribution points"
Strategic direction	"Saat ini sedang dalam fase ekspansi ke Indonesia Timur, dengan target 50 retailer baru di 2026"
External context	"Persaingan e-commerce yang meningkat mendorong kebutuhan untuk same-day delivery"

Tips: Jangan copy-paste dari website klien. Tunjukkan pemahaman yang lebih dalam dari Discovery.

4.2 Current State Assessment (1-2 halaman)

Kondisi saat ini berdasarkan temuan Discovery, termasuk pain points.

Aspek	Format
Proses bisnis saat ini	Flowchart sederhana atau bullet description
Sistem & teknologi existing	Landscape diagram atau tabel
Pain points & challenges	Numbered list dengan impact per pain point
Data/metrics current state	Tabel before metrics

Contoh Pain Points Format:

Berdasarkan discovery session pada 10-12 Januari 2026, kami
mengidentifikasi tantangan utama berikut:

1. Proses order manual membutuhkan rata-rata 5 hari kerja
   dari PO received hingga goods delivered
   → Impact: Customer complaint rate 23%, potential churn

2. Data inventory tidak real-time — selisih antara system
   dan actual stock mencapai 15%
   → Impact: Stockout frequency 8x/bulan, lost sales
   estimated IDR 400 juta/bulan

3. Reporting membutuhkan 3 hari manual compilation dari
   5 sumber data berbeda
   → Impact: Management decisions based on stale data,
   2 FTE dedicated hanya untuk reporting

4.3 Desired State & Vision (0.5-1 halaman)

Visi klien tentang kondisi ideal — gunakan bahasa aspirational yang menginspirasi.

Current State	→	Desired State
Order processing 5 hari	→	Same-day order processing
12% error rate	→	< 1% error rate
5 separate systems	→	Single unified platform
Manual reporting 3 hari	→	Real-time dashboard
No customer self-service	→	Customer portal for tracking

4.4 Gap Analysis & Requirements Summary (1-2 halaman)

Mapping antara current state dan desired state, lalu diturunkan menjadi requirements.

Format Requirements Summary:

ID	Requirement	Priority	Category	Source
REQ-01	Automated order intake from e-commerce & manual PO	Must Have	Functional	Discovery - Day 1
REQ-02	Real-time inventory sync across warehouses	Must Have	Functional	Discovery - Day 1
REQ-03	Integration with SAP S/4HANA (bi-directional)	Must Have	Integration	Discovery - Day 2
REQ-04	Customer self-service portal for order tracking	Should Have	Functional	Discovery - Day 2
REQ-05	Mobile app for delivery confirmation	Should Have	Functional	Discovery - Day 2
REQ-06	Business intelligence dashboard	Must Have	Analytics	Discovery - Day 1
REQ-07	Support for 500 concurrent users at peak	Must Have	Non-Functional	Technical assessment
REQ-08	Data migration from legacy system	Must Have	Technical	Discovery - Day 2

MoSCoW Prioritization:

• Must Have — Non-negotiable, tanpa ini project tidak deliver value
• Should Have — Penting tapi bisa di-phase jika waktu/budget terbatas
• Could Have — Nice to have, implement jika ada remaining capacity
• Won't Have (this phase) — Explicitly excluded, bisa jadi Phase 2

Tips Penting untuk Section 4:

• Gunakan bahasa klien, bukan bahasa internal Divistant
• Reference discovery findings secara eksplisit: "Berdasarkan diskusi dengan Pak Budi (CTO) pada 12 Januari..."
• Jika ada requirement yang kita interpretasikan berbeda, jelaskan asumsi kita
• Ini section yang paling sering dibaca klien pertama kali — invest waktu di sini
• Validasi section ini dengan klien sebelum menulis solusi (jika timeline memungkinkan)

Common Mistakes:

• Copy-paste requirement tanpa menunjukkan pemahaman konteks
• Terlalu teknis — ini harus bisa dipahami oleh business stakeholder
• Tidak menyebutkan sumber informasi (kapan Discovery, siapa yang diwawancara)
• Memasukkan requirement yang belum divalidasi klien

---

Section 5: Proposed Solution & Architecture

Tujuan: Menjelaskan apa yang akan kita bangun dan bagaimana cara kerjanya. Section ini menjembatani antara kebutuhan klien (Section 4) dan cara deliver (Section 6).

Sub-sections:

5.1 Solution Overview (0.5-1 halaman)

Ringkasan solusi dalam bahasa bisnis — harus bisa dipahami oleh CEO/CFO.

Template Opening Paragraph:

Untuk menjawab tantangan [pain point utama], Divistant mengusulkan [nama/deskripsi solusi] yang dirancang untuk [outcome utama]. Solusi ini terdiri dari [X komponen utama] yang bekerja secara terintegrasi untuk [benefit utama]. Dengan pendekatan [methodology singkat], implementasi dapat diselesaikan dalam [durasi] dengan [highlight differentiator].

Contoh:

Untuk menjawab tantangan fragmentasi proses order-to-cash, Divistant mengusulkan Unified Order Management Platform yang dirancang untuk mengotomasi dan mengintegrasikan seluruh alur dari penerimaan order hingga delivery confirmation. Solusi ini terdiri dari 4 komponen utama — Order Processing Engine, Inventory Management Hub, Integration Layer, dan Analytics Dashboard — yang bekerja secara terintegrasi untuk mengurangi cycle time dari 5 hari menjadi same-day. Dengan pendekatan Agile dalam 3 fase, implementasi dapat diselesaikan dalam 5 bulan dengan go-live bertahap untuk meminimalkan disruption operasional.

5.2 Solution Architecture Diagram (1-2 halaman)

Visual high-level yang menjelaskan bagaimana komponen saling terhubung.

Panduan Diagram:

Level	Audience	Isi	Dimana
Context (C4 Level 1)	C-level, semua	Sistem utama + external systems + users	Di section ini (wajib)
Container (C4 Level 2)	Manager, technical	Applications, databases, services	Di section ini (recommended)
Component (C4 Level 3)	Technical team	Komponen detail dalam tiap container	Appendix (opsional)
Code (C4 Level 4)	Developers	Class/module detail	Tidak di proposal

Elemen wajib dalam diagram:

• User/actor yang berinteraksi dengan sistem
• Komponen utama solusi (dengan label jelas)
• Sistem existing klien yang terintegrasi
• Data flow (arah panah + label)
• External services / third-party
• Legend / keterangan warna dan simbol

Tips Diagram:

• Gunakan warna konsisten: Divistant solution (biru), existing systems (abu), external (hijau)
• Setiap box harus punya label dan deskripsi 1 baris
• Maksimal 15 boxes di satu diagram — jika lebih, pecah menjadi 2 diagram
• Tambahkan numbered annotations yang dijelaskan di bawah diagram

5.3 Key Components (1-3 halaman)

Penjelasan setiap komponen utama — ini adalah "daging" dari section solusi.

Format per Komponen:

### [Nama Komponen]

**Fungsi:** [1-2 kalimat tentang apa yang dilakukan komponen ini]

**Fitur Utama:**
- [Fitur 1]: [penjelasan singkat + benefit]
- [Fitur 2]: [penjelasan singkat + benefit]
- [Fitur 3]: [penjelasan singkat + benefit]

**Menjawab Requirement:** REQ-01, REQ-02 (link ke Section 4)

**Value untuk Klien:** [1 paragraf tentang kenapa ini penting untuk bisnis klien]

Contoh:

### Order Processing Engine

**Fungsi:** Mengelola seluruh lifecycle order dari penerimaan
hingga fulfillment secara otomatis, menggantikan proses
manual yang saat ini membutuhkan 5 hari.

**Fitur Utama:**
- Multi-channel order intake: Menerima order dari
  e-commerce, email, dan manual entry dalam satu interface
  → mengeliminasi duplicate entry
- Automated validation & routing: Order divalidasi secara
  otomatis terhadap inventory dan credit limit, lalu
  di-route ke warehouse terdekat
  → mengurangi error rate dari 12% ke <1%
- Real-time status tracking: Setiap order dapat dilacak
  statusnya oleh internal team dan customer
  → mengurangi inquiry calls 60%

**Menjawab Requirement:** REQ-01, REQ-04, REQ-07

**Value untuk Klien:** Dengan Order Processing Engine,
tim operations Anda dapat fokus pada exception handling
alih-alih data entry manual. Berdasarkan benchmark di
project serupa, ini membebaskan 3-4 FTE yang bisa
dialokasikan ke aktivitas bernilai lebih tinggi.

5.4 Technology Stack (0.5-1 halaman)

Teknologi yang akan digunakan beserta justifikasi.

Layer	Technology	Justifikasi
Frontend	React.js + Next.js	Performance, SEO-friendly, component-based
Backend	Node.js + Express	Scalable, async processing, JSON-native
Database	PostgreSQL + Redis	Relational + caching for performance
Integration	Apache Kafka	Event-driven, reliable message queuing
Infrastructure	AWS (ECS + RDS + S3)	Scalability, reliability, pay-per-use
Monitoring	Datadog	Real-time monitoring, alerting
CI/CD	GitHub Actions	Automated testing & deployment

Tips: Jelaskan mengapa teknologi ini dipilih, bukan hanya apa. Klien ingin tahu reasoning-nya, terutama jika mereka sudah punya preferensi teknologi tertentu.

5.5 Integration Architecture (0.5-1 halaman)

Bagaimana solusi terhubung dengan sistem existing klien.

Source System	Target System	Method	Data Flow	Frequency
E-commerce Platform	Order Processing Engine	REST API	Orders, customer data	Real-time
Order Processing Engine	SAP S/4HANA	SAP RFC/BAPI	Sales orders, invoices	Near real-time (5 min)
Warehouse System	Inventory Hub	Event streaming (Kafka)	Stock movements	Real-time
Order Processing Engine	Customer Portal	WebSocket	Order status updates	Real-time

5.6 Security & Compliance (0.5-1 halaman)

Aspek	Pendekatan
Authentication	OAuth 2.0 + MFA for admin users
Authorization	Role-based access control (RBAC)
Data encryption	TLS 1.3 (transit), AES-256 (at rest)
Data privacy	Compliance dengan UU PDP (Personal Data Protection)
Audit trail	All data changes logged with timestamp & user
Backup & recovery	Daily automated backup, RPO 1 hour, RTO 4 hours
Penetration testing	Post-deployment pen test by independent party

Common Mistakes Section 5:

• Diagram terlalu teknis / terlalu banyak detail untuk audience proposal
• Tidak ada mapping antara komponen dan requirements
• Technology stack tanpa justifikasi (terkesan arbitrary)
• Tidak menyebutkan security sama sekali
• Over-promise: menyebutkan fitur yang sebenarnya out-of-scope

---

Section 6: Methodology & Approach

Tujuan: Memberikan confidence bahwa kita punya pendekatan yang terstruktur dan proven.

6.1 Methodology Selection (0.5 halaman)

Jelaskan mengapa methodology ini dipilih untuk project ini:

Methodology	Kapan Digunakan	Cocok Untuk
Agile (Scrum)	Scope bisa evolve, need fast feedback	Custom development, innovative solutions
Waterfall	Scope sangat fixed, compliance-heavy	Regulated industries, migration projects
Hybrid	Phase awal butuh discovery, selanjutnya iterative	Transformation projects, large implementations

Template Methodology Justification:

Untuk project ini, kami merekomendasikan pendekatan [methodology] berdasarkan pertimbangan berikut: (1) [alasan 1 terkait nature of project], (2) [alasan 2 terkait kebutuhan klien], dan (3) [alasan 3 terkait risk management]. Pendekatan ini memungkinkan [benefit utama] sambil tetap menjaga [aspek penting].

6.2 Phase Breakdown (1-2 halaman)

Bagian terpenting dari section ini — klien ingin tahu step-by-step.

Format Phase Detail:

Aspek	Isi
Phase name & number	Phase 1: Foundation & Core Setup
Duration	4 minggu (Sprint 1-2)
Objectives	Apa yang ingin dicapai di phase ini
Key Activities	List aktivitas utama
Deliverables	Dokumen/artifact yang dihasilkan
Milestone	Acceptance criteria untuk phase completion
Client Involvement	Apa yang dibutuhkan dari klien

Contoh Phase Breakdown (Agile):

Phase	Durasi	Objectives	Deliverables	Milestone
Phase 0: Inception	2 minggu	Align scope, setup tim & environment	Project Charter, Sprint Backlog, Dev Environment	Kickoff sign-off
Phase 1: Foundation	4 minggu (Sprint 1-2)	Core architecture, basic order flow	Working base system, API framework, CI/CD pipeline	Demo: end-to-end basic flow
Phase 2: Core Features	6 minggu (Sprint 3-5)	Order processing, inventory, integration	Automated order flow, SAP integration, inventory sync	Demo: full order-to-delivery flow
Phase 3: Advanced Features	4 minggu (Sprint 6-7)	Customer portal, analytics, notifications	Customer portal, dashboards, alert system	Demo: complete feature set
Phase 4: Testing & UAT	3 minggu	Quality assurance, user acceptance	Test reports, bug fixes, UAT sign-off	UAT acceptance sign-off
Phase 5: Go-Live & Hypercare	2 minggu	Production deployment, stabilization	Production system, knowledge transfer	Production sign-off

6.3 Quality Assurance Approach (0.5 halaman)

QA Activity	Kapan	Siapa	Output
Code review	Every pull request	Development team	Reviewed & approved code
Unit testing	During development	Developers	> 80% code coverage
Integration testing	End of each sprint	QA Engineer	Integration test report
System testing (SIT)	Phase 4	QA team	SIT report, defect log
User acceptance testing (UAT)	Phase 4	Client team + QA	UAT sign-off
Performance testing	Pre go-live	QA + DevOps	Performance test report
Security testing	Pre go-live	External auditor	Security assessment report

6.4 Communication & Governance (0.5 halaman)

Rituals	Frekuensi	Peserta	Output
Daily standup	Setiap hari kerja	Dev team + PM	Blocker resolution
Sprint review/demo	Setiap 2 minggu	Client stakeholders + team	Sprint demo, feedback
Sprint planning	Setiap 2 minggu	PM + PO + Dev team	Sprint backlog
Steering committee	Bulanan	Management kedua belah pihak	Status report, escalation
Status report (written)	Mingguan	PM → Client PM	Written progress report

6.5 Risk Management (0.5 halaman)

#	Risk	Probability	Impact	Mitigation
R1	Key personnel unavailable	Medium	High	Cross-training, backup resource identified
R2	Scope creep from changing requirements	Medium	High	Change request process, sprint boundary
R3	Integration complexity with SAP higher than expected	Medium	Medium	Technical spike in Phase 0, SAP expert on standby
R4	Client team availability for UAT	Low	High	UAT schedule agreed upfront, dedicated client PIC
R5	Data migration issues (data quality)	Medium	Medium	Data profiling in Phase 0, cleansing plan

Common Mistakes Section 6:

• Methodology description terlalu generic / textbook
• Tidak ada client involvement yang jelas (klien ingin tahu apa yang diharapkan dari mereka)
• Risk register terlalu generic atau terlalu panjang
• Tidak ada governance/communication plan

---

Section 7: Team & Credentials

Tujuan: Membangun kepercayaan bahwa tim kita mampu deliver.

7.1 Proposed Team Structure (0.5 halaman)

Gunakan org chart visual:

7.2 Key Personnel Profiles (1-2 halaman)

Format Bio:

[Nama] — [Role dalam Project]
[Foto — opsional tapi recommended]

Pengalaman: [X tahun] di bidang [spesialisasi]
Sertifikasi: [sertifikasi relevan]

Relevant Experience:
• [Project 1 — 1 kalimat: client industry, scope, outcome]
• [Project 2 — 1 kalimat: client industry, scope, outcome]
• [Project 3 — 1 kalimat: client industry, scope, outcome]

Role dalam project ini:
[2-3 kalimat tentang tanggung jawab spesifik di project ini]

Tips:

• Pastikan orang yang diusulkan realistis available — koordinasi dengan Resource Manager
• Jika belum pasti, gunakan role description tanpa nama: "Senior Java Developer (8+ years, certified AWS)"
• Highlight pengalaman yang paling relevan dengan project ini
• Sertakan backup plan jika key personnel tidak available

7.3 Relevant Case Studies (1-2 halaman)

Pilih 2-3 case study yang paling relevan dengan project ini.

Format Case Study in Proposal:

Elemen	Contoh
Client (anonymous jika perlu)	"Leading FMCG distributor with 300+ retail partners"
Industry	Distribution / FMCG
Challenge	Manual order processing, 7-day cycle time
Solution	End-to-end order management system with ERP integration
Technology	React, Node.js, SAP integration
Duration	4 months
Results	85% reduction in cycle time, 95% accuracy, IDR 2.1B annual saving
Testimonial	"Divistant understood our business deeply..." — CTO

Pemilihan case study yang tepat:

• Prioritaskan kesamaan industri > teknologi > ukuran
• Sertakan metrics/angka yang quantifiable
• Jika ada testimonial, selalu sertakan
• Jika klien boleh dihubungi sebagai referensi, sebutkan

7.4 Certifications & Partnerships (0.5 halaman)

Tabel sederhana yang menunjukkan expertise yang relevan.

---

Section 8: Timeline & Milestones

Tujuan: Memberikan gambaran jelas kapan deliverables akan selesai.

8.1 Visual Timeline (1 halaman)

Gunakan Gantt chart atau timeline visual yang mudah dibaca.

Contoh Timeline Format:

8.2 Milestone Table (0.5-1 halaman)

#	Milestone	Target Date	Deliverable	Acceptance Criteria	Payment Trigger
M1	Project Kickoff	Week 1	Project Charter, Sprint Backlog	Signed by both parties	20% (upon signing)
M2	Design Complete	Week 4	Solution Design Document	Client sign-off on design	—
M3	Core Development Complete	Week 12	Working core system	Sprint demo accepted	30%
M4	Feature Complete	Week 16	All features developed	Sprint demo accepted	20%
M5	UAT Complete	Week 19	UAT sign-off document	All critical/major bugs resolved	20%
M6	Go-Live	Week 21	Production system live	Go-live checklist 100%	10% (after hypercare)

8.3 Assumptions & Dependencies

#	Assumption / Dependency	Impact jika Tidak Terpenuhi
A1	Client team available untuk 4 jam/minggu (PO + IT PIC)	Timeline delay 1-2 minggu per sprint
A2	SAP API documentation tersedia di Week 1	Integration phase delay
A3	Test environment tersedia di Week 2	Development start delay
A4	UAT team (5 orang) dedicated selama Phase 4	UAT phase extension
A5	No major scope changes after Design sign-off	Additional effort via Change Request

Common Mistakes Section 8:

• Timeline terlalu optimistic (tidak ada buffer)
• Tidak menunjukkan dependencies
• Tidak menyebutkan asumsi yang mempengaruhi timeline
• Milestone tidak linked ke payment (jika fixed price)

---

Section 9: Investment & Payment Terms

Tujuan: Transparansi biaya dan cara pembayaran. Ini section yang paling di-scrutinize oleh Finance/Procurement.

9.1 Pricing Model Selection

Model	Kapan Digunakan	Pros	Cons
Fixed Price	Scope jelas & stabil	Predictable budget, clear deliverables	Less flexible, change request process
Time & Material	Scope evolving, Agile	Flexible, pay for actual effort	Less predictable total cost
Hybrid	Mixed certainty per phase	Best of both worlds	More complex to manage

9.2 Investment Summary (headline first, detail below)

Contoh — Fixed Price:

┌────────────────────────────────────────────────────────┐
│           RINGKASAN INVESTASI                          │
│                                                        │
│  Total Investasi: IDR 850.000.000                      │
│  (Delapan ratus lima puluh juta Rupiah)                │
│                                                        │
│  Sudah termasuk: Development, testing, deployment,     │
│  project management, 2 minggu hypercare                │
│                                                        │
│  Belum termasuk: Infrastructure cost, third-party      │
│  licenses, travel (jika diperlukan)                    │
│                                                        │
│  Berlaku hingga: 15 Maret 2026 (30 hari)              │
└────────────────────────────────────────────────────────┘

Contoh — T&M:

┌────────────────────────────────────────────────────────┐
│           RINGKASAN INVESTASI                          │
│                                                        │
│  Estimasi Investasi: IDR 700.000.000 — 900.000.000    │
│  (Berdasarkan estimasi effort 680-870 man-days)        │
│                                                        │
│  Billing: Monthly based on actual effort               │
│  Rate card: Terlampir                                  │
│                                                        │
│  Cap (opsional): IDR 950.000.000 (not-to-exceed)      │
│                                                        │
│  Berlaku hingga: 15 Maret 2026 (30 hari)              │
└────────────────────────────────────────────────────────┘

9.3 Investment Breakdown

Format — Per Phase (Fixed Price):

Phase	Scope	Effort (man-days)	Investasi (IDR)	% of Total
Phase 0: Inception	Kickoff, planning, environment setup	20	80.000.000	9%
Phase 1: Foundation	Core architecture, basic flow	60	180.000.000	21%
Phase 2: Core Features	Order processing, integration	100	290.000.000	34%
Phase 3: Advanced	Portal, analytics, notifications	70	180.000.000	21%
Phase 4: Testing & UAT	SIT, UAT, bug fixing	30	70.000.000	8%
Phase 5: Go-Live	Deployment, hypercare	15	50.000.000	6%
Total		295 man-days	850.000.000	100%

Format — Per Role (T&M):

Role	Rate/Day (IDR)	Est. Days	Est. Cost (IDR)
Project Manager	3.500.000	60	210.000.000
Solution Architect	4.000.000	30	120.000.000
Tech Lead	3.500.000	80	280.000.000
Senior Developer (x2)	2.800.000	160	448.000.000
Junior Developer	1.800.000	80	144.000.000
QA Engineer	2.200.000	40	88.000.000
Total		450 days	1.290.000.000

Note: Angka di atas hanya contoh illustrative, bukan rate card aktual.

9.4 Payment Schedule

Fixed Price:

Termin	Trigger	%	Amount (IDR)	Due
1	Contract signing	20%	170.000.000	Upon signing
2	Phase 1 complete (M2)	30%	255.000.000	14 hari dari invoice
3	UAT sign-off (M5)	30%	255.000.000	14 hari dari invoice
4	Go-live + hypercare complete (M6)	20%	170.000.000	14 hari dari invoice
Total		100%	850.000.000

T&M:

Invoicing dilakukan secara bulanan berdasarkan timesheet yang disetujui oleh Client Project Manager. Payment terms: 14 hari kerja dari tanggal invoice.

9.5 Scope Boundaries — In Scope vs Out of Scope

Ini sangat penting untuk menghindari dispute di kemudian hari.

✅ In Scope	❌ Out of Scope
Custom development per requirement list	Infrastructure procurement & setup
SAP integration (order & inventory modules)	SAP customization / ABAP development
Data migration from legacy system	Data cleansing of source data
2 minggu hypercare post go-live	Ongoing maintenance after hypercare
User training (train-the-trainer, 2 sessions)	End-user training nationwide
Standard security hardening	Penetration testing by third party
Documentation (technical + user guide)	Marketing or promotional materials

9.6 Assumptions yang Mempengaruhi Harga

#	Assumption	Jika Tidak Terpenuhi
1	Requirements stabil setelah Design phase sign-off	Change request (akan di-quote terpisah)
2	Client menyediakan test data untuk UAT	Additional 1-2 minggu untuk data preparation
3	Tidak ada perubahan regulasi signifikan selama project	Impact assessment + CR jika ada
4	Infrastruktur production ready di Week 16	Go-live delay

Common Mistakes Section 9:

• Headline number tidak prominent (buried in text)
• Tidak ada in-scope / out-of-scope yang jelas
• Payment terms tidak clear (kapan invoice, kapan due)
• Assumptions tidak disebutkan → jadi sumber dispute
• Validity period lupa dicantumkan

---

Section 10: Why Divistant

Tujuan: Diferensiasi dari kompetitor — mengapa klien harus memilih kita. Ini closing argument.

Framework "3 Differentiators":

Pilih 3 differentiator yang paling relevan untuk klien ini:

Differentiator	Contoh Angle	Evidence
Industry expertise	Pengalaman di industri yang sama	"5 project di industri distribusi dalam 2 tahun terakhir"
Technical capability	Keahlian di teknologi yang dipilih	"Tim certified AWS + SAP integration"
Methodology & quality	Track record delivery on-time	"95% project delivered on-time, avg CSAT 4.5/5"
Local presence & support	Tim lokal Indonesia	"Tim 100% berbasis di Indonesia, response time < 4 jam"
End-to-end capability	Dari discovery sampai operate	"Single partner dari assessment sampai managed services"
Proven track record	Case study serupa yang sukses	"Similar project: 85% cycle time reduction, IDR 2.1B saving"

Template "Why Divistant" Section:

Mengapa Divistant?

1. [Differentiator 1 — judul singkat] [2-3 kalimat penjelasan dengan bukti/angka]

2. [Differentiator 2 — judul singkat] [2-3 kalimat penjelasan dengan bukti/angka]

3. [Differentiator 3 — judul singkat] [2-3 kalimat penjelasan dengan bukti/angka]

Komitmen Kami [1 paragraf closing yang kuat, menunjukkan commitment dan next steps]

Tips:

• Gunakan bukti, bukan klaim: "95% project delivered on-time" > "Kami selalu deliver tepat waktu"
• Sesuaikan differentiator dengan pain points klien — bukan generic company strengths
• Jangan merendahkan kompetitor — fokus pada kelebihan kita
• Akhiri dengan call-to-action: "Kami siap memulai diskusi lebih lanjut dan menjawab pertanyaan Anda"

---

Appendices

Konten opsional (pilih yang relevan):

Appendix	Kapan Disertakan	Target Audience
Detailed CVs of key personnel	Enterprise proposal, klien yang request	HR / Procurement
Full case studies	Klien butuh confidence	Business stakeholders
Technical architecture details (C4 Level 3)	Klien dengan strong IT team	CTO / IT Manager
Draft SOW / Terms & Conditions	Fixed price, formal procurement	Legal / Procurement
Company profile	First engagement dengan klien	All
Certifications & awards	Regulated industry, government	Compliance
Client testimonials / references	Competitive bid	Decision makers
Glossary of terms	Complex technical proposal	All
Compliance matrix	RFP response	Procurement
ROI calculation detail	Value-conscious klien	CFO / Finance

Tips Appendices:

• Jangan memasukkan appendix hanya untuk menambah volume — setiap appendix harus ada alasan
• Reference appendix dari body proposal: "Untuk detail, lihat Appendix B"
• Appendix tetap harus mengikuti formatting & branding standard

---

3. Panduan Proposal per Tipe Layanan

Meskipun struktur 10 section berlaku untuk semua, setiap tipe layanan memiliki penekanan berbeda:

Tipe Layanan	Section yang Diperkuat	Section yang Diringkas	Halaman
Consulting / Advisory	Understanding (4), Methodology (6)	Architecture (5)	12-18
ERP/CRM Implementation	Solution (5), Timeline (8), Investment (9)	— (semua penting)	25-35
Custom Development	Solution (5), Architecture diagram, Team (7)	—	20-30
Managed Services	Methodology/SLA (6), Team (7), Investment (9)	Architecture (5)	15-22
Staff Augmentation	Team (7), Rate card (9)	Solution (5), Methodology (6)	10-15
PoC / Quick Engagement	Solution (5), Timeline (8)	Team (7), Why Divistant (10)	5-10

---

4. Proposal Writing Workflow

Alur kerja penulisan proposal dari awal hingga submission:

Detail per Step:

Step 1: Prepare (1 hari)

• Kumpulkan semua input: Discovery Report, Solution Design, Effort Estimation
• Tentukan Win Theme (max 3 pesan kunci)
• Buat outline proposal (storyboard per section)
• Assign section writers jika kolaborasi
• Pilih template yang sesuai (standard, enterprise, RFP response)

Win Theme Worksheet:

#	Win Theme	Evidence/Proof	Dimana di Proposal
1	[Theme 1]	[data/case study]	Exec Summary, Section 4, Section 10
2	[Theme 2]	[data/case study]	Section 5, Section 7, Section 10
3	[Theme 3]	[data/case study]	Section 6, Section 7, Section 10

Step 2: Draft (3-5 hari kerja)

• Tulis section by section mengikuti outline
• Urutan penulisan yang recommended:
  1. Section 4 (Understanding) — fondasi, tulis pertama
  2. Section 5 (Solution) — bangun di atas understanding
  3. Section 6 (Methodology) — cara deliver solusi
  4. Section 8 (Timeline) — kapan
  5. Section 9 (Investment) — berapa
  6. Section 7 (Team) — siapa
  7. Section 10 (Why Divistant) — closing
  8. Section 2 (Executive Summary) — tulis TERAKHIR
  9. Section 1 (Cover) + Section 3 (ToC) — finishing
• Setiap section harus menjawab: "Apa value bagi klien dari informasi ini?"
• Check setiap paragraf apakah mengandung Win Theme

Step 3: Review (1-2 hari kerja)

• Technical Review — Solution Architect memverifikasi akurasi teknis
• Commercial Review — Sales Lead memverifikasi pricing & terms
• Client Empathy Check — Baca ulang dari sudut pandang klien:
  • Apakah mereka akan mengerti tanpa konteks internal kita?
  • Apakah pain points mereka terasa dipahami?
  • Apakah investment terasa justified oleh value yang ditawarkan?
• Quality Check — Grammar, formatting, konsistensi

Step 4: Revise (1-2 hari kerja)

• Address semua review comments
• Polish bahasa — singkirkan jargon, persingkat kalimat
• Pastikan konsistensi angka (effort di Section 5 = angka di Section 9)
• Final formatting & brand check

Step 5: Submit (0.5 hari)

• Final QC menggunakan Proposal Submission Checklist
• Approval sign-off sesuai Approval Matrix
• Kirim ke klien (email + hardcopy jika diperlukan)
• Update Opportunity di BizOps CRM: stage → "Proposal Sent"
• Set follow-up reminder (3-5 hari setelah kirim)

---

5. Approval Matrix

Setiap proposal harus mendapat approval sebelum dikirim ke klien:

Nilai Proposal	Approver	Review Scope
< 100 Juta	Sales Manager	Komersial + scope
100 - 500 Juta	Sales Director	Komersial + scope + resource allocation
500 Juta - 1 Miliar	Managing Director	Full review + strategic alignment
> 1 Miliar	Managing Director + Board	Full review + financial risk assessment

Escalation: Jika approver tidak available dalam 1 hari kerja, eskalasi ke level berikutnya.

---

6. Pricing Guidelines

Rate Card Reference

Gunakan rate card terbaru dari Finance. Berikut guidance umum:

Role Level	Engagement Model	Guidance
Junior (0-2 yr)	T&M / Staff Aug	Standard rate
Mid (3-5 yr)	T&M / Project	Standard rate
Senior (5-8 yr)	T&M / Project / Advisory	Premium rate
Lead/Architect (8+ yr)	Advisory / Project	Premium rate

Note: Rate card aktual tersedia di Finance shared folder. Jangan hard-code angka di proposal — selalu reference dari rate card terbaru.

Discount Guidelines

Kondisi	Discount Maks	Approval
Strategic account / long-term potential	10%	Sales Director
Multi-year contract (≥2 tahun)	15%	Managing Director
Bundle deal (≥3 services)	10%	Sales Director
First project — new client	5%	Sales Manager

Aturan: Tidak ada discount tanpa approval tertulis. Discount harus di-justify dengan business case.

Margin Minimum

Tipe Project	Gross Margin Minimum
Fixed Price	30%
Time & Material	25%
Managed Services	35%
Staff Augmentation	20%
Advisory	40%

Pricing Presentation Options

Untuk deal > 500 juta, pertimbangkan menyajikan opsi:

Opsi	Scope	Investasi	Value
Essential	Core requirements only (Must Have)	IDR 650 juta	Solve primary pain point
Recommended	Core + Should Have	IDR 850 juta	Comprehensive solution
Premium	All requirements + Could Have	IDR 1.1 miliar	Future-proof, complete

Tips: Selalu highlight opsi "Recommended" — ini anchor klien ke middle option.

---

7. Writing Quality Standards

Language Guidelines

Do:

• Gunakan active voice: "Tim kami akan mengimplementasikan..."
• Gunakan angka spesifik: "Mengurangi waktu proses 60%"
• Gunakan bahasa klien (terminology yang mereka pakai saat Discovery)
• Short paragraphs (max 4-5 baris)
• Bullet points untuk list, paragraphs untuk narasi

Don't:

• Passive voice berlebihan: "Akan dilakukan implementasi oleh tim"
• Klaim tanpa bukti: "Kami adalah yang terbaik di Indonesia"
• Jargon internal: "Kami akan deploy ke staging environment untuk SIT sebelum UAT"
• Wall of text tanpa visual break
• Copy-paste dari proposal lain tanpa customization

Visual Standards

• Gunakan template PowerPoint/Word resmi Divistant
• Sertakan minimal 1 diagram per 5 halaman
• Architecture diagram wajib di Section 5
• Timeline visual (Gantt/roadmap) wajib di Section 8
• Consistent color coding: gunakan Divistant brand palette

---

8. BizOps CRM Integration

Update Opportunity di BizOps saat proposal progress:

Stage Updates:

Proposal Milestone	CRM Stage	Action di BizOps
Mulai drafting	Proposal/Quotation	Update stage, attach outline
Draft selesai, masuk review	Proposal/Quotation	Attach draft (internal only)
Approval diperoleh	Proposal/Quotation	Log approval di Notes
Proposal dikirim ke klien	Proposal Sent	Update stage, attach final proposal, log tanggal kirim
Follow-up setelah kirim	Negotiation/Review	Log feedback klien di Notes

Notes Format untuk Proposal Tracking:

== PROPOSAL STATUS ==
Proposal Title: [Judul Proposal]
Version: [v1.0 / v1.1 / dst]
Win Theme: [1-3 key messages]
Status: [Drafting / In Review / Approved / Sent / Follow-up]
Sent Date: [tanggal kirim]
Follow-up Date: [tanggal follow-up]
Client Feedback: [ringkasan feedback]

== PROPOSAL DETAILS ==
Pricing Model: [Fixed / T&M / Hybrid]
Total Value: [IDR ...]
Discount Applied: [% — approval ref]
Validity: [30 hari dari tanggal kirim]
Approver: [nama] — approved [tanggal]

---

Template & Aset

📘 Know (Untuk dipelajari)

• Proposal Writing Best Practices — APMP (Association of Proposal Management Professionals)
• "Writing Winning Proposals" framework dari Shipley Associates
• Divistant Brand Guidelines (available di shared drive)

📊 Show (Untuk digunakan)

• Proposal Template — Standard — Template Word untuk proposal standar (<500M)
• Proposal Template — Enterprise — Template Word untuk proposal enterprise (>500M, lebih detail)
• Executive Summary Template — Template 1-halaman untuk executive summary
• Pricing Calculator — Spreadsheet untuk kalkulasi pricing berdasarkan rate card
• Proposal Outline Template — Template outline untuk Step 1 (Prepare)
• Win Theme Worksheet — Template untuk mendefinisikan dan tracking win themes

📤 Share (Untuk dikirim ke klien)

• Final proposal (PDF format, bukan editable)
• Executive Summary (bisa dikirim terpisah sebagai teaser)
• Company Profile (jika diminta)

---

Skenario Umum

Skenario 1: Proposal Standar — Project Fixed Price < 500M

Situasi: Klien retail membutuhkan integrasi e-commerce dengan ERP existing. Scope jelas, timeline 3 bulan.

Pendekatan:

1. Gunakan template Standard
2. Win Theme: "Pengalaman integrasi e-commerce + pemahaman retail Indonesia"
3. Pricing: Fixed price per milestone (30/30/30/10)
4. Timeline: Focus pada speed — klien ingin go-live sebelum Ramadan
5. Section 10 highlight: case study retail serupa + certified integration partner

Hasil: Proposal 15-20 halaman, approval dari Sales Director, SLA 5 hari kerja.

Skenario 2: Proposal Enterprise — Digital Transformation > 1M

Situasi: Bank regional ingin modernisasi core banking system. Multi-year, melibatkan banyak stakeholder.

Pendekatan:

1. Gunakan template Enterprise
2. Win Theme: "Proven methodology + compliance expertise + local support"
3. Pricing: Hybrid — Phase 1 fixed price (assessment), Phase 2+ T&M
4. Sertakan phasing roadmap 3 tahun
5. Section 7: detailed CVs, sertifikasi keamanan, pengalaman banking
6. Tambahkan appendix: compliance mapping (OJK, UU PDP), risk assessment

Hasil: Proposal 40-50 halaman + appendices, approval dari MD + Board, SLA 9 hari kerja.

Skenario 3: Proposal Cepat — Urgent Request dengan Timeline Ketat

Situasi: Klien existing meminta proposal tambahan untuk phase 2, deadline 2 hari.

Pendekatan:

1. Leverage existing proposal sebagai base
2. Fokus pada delta: apa yang baru/berbeda dari phase 1
3. Singkat: 8-10 halaman
4. Skip detailed appendices — reference phase 1 proposal
5. Executive Summary + Solution + Timeline + Investment saja
6. Minta approval paralel (chat/call, bukan tunggu formal)

Hasil: Proposal ringkas 8-10 halaman, approval via call dari Sales Director, SLA 2 hari kerja.

Skenario 4: Proposal Ditolak — Re-proposal setelah Feedback

Situasi: Proposal pertama ditolak karena harga terlalu tinggi dan timeline terlalu panjang.

Pendekatan:

1. Analisis feedback klien secara detail — apa exact concern-nya?
2. Jangan langsung potong harga — cari value engineering opportunities
3. Opsi: reduce scope (phasing), optimasi resource mix, adjust timeline
4. Buat versi baru dengan opsi Essential/Recommended/Premium
5. Tambahkan ROI analysis untuk justify investasi (lihat halaman Value Engineering & ROI)
6. Request meeting untuk present revisi (jangan hanya kirim dokumen)

Hasil: Revised proposal dengan 3 opsi, approval sesuai matrix, include presentation deck.

---

Checklist

Proposal Pre-Submission Checklist

Content Quality:

• Win Theme konsisten di seluruh dokumen
• Executive Summary ≤ 1 halaman dan bisa berdiri sendiri
• Executive Summary mengikuti struktur PESO
• Understanding section menggunakan bahasa klien
• Semua requirement klien ter-address (compliance matrix jika RFP)
• Architecture diagram included dan mudah dipahami
• Technology stack disertai justifikasi
• Security & compliance ter-address
• Methodology section termasuk QA approach
• Communication & governance plan included
• Risk register realistis dengan mitigation
• Timeline realistis dan aligned dengan estimasi effort
• Pricing konsisten antara Section 9 dan estimasi di Section 5/6
• In-scope dan out-of-scope disebutkan secara eksplisit
• Assumptions terdokumentasi
• Payment terms jelas dan linked ke milestones

Commercial Quality:

• Pricing sesuai rate card terbaru
• Margin minimum terpenuhi
• Discount (jika ada) sudah diapprove
• Payment terms jelas dan realistis
• Validity period disebutkan (default 30 hari)
• Pricing options disajikan (jika applicable)

Professional Quality:

• Spell check & grammar check passed
• Nama klien benar di seluruh dokumen (no leftover dari template lain)
• Tanggal dan nomor versi up-to-date
• Formatting konsisten (fonts, headers, spacing)
• Semua placeholder [xxx] sudah diisi
• Cover page lengkap (logo, judul, tanggal, confidentiality)
• Page numbers correct
• Table of contents updated
• Semua diagram readable dan tidak pixelated
• Cross-references antar section akurat

Process Quality:

• Technical review completed (SA sign-off)
• Commercial review completed (Sales Lead sign-off)
• Client empathy check done
• Approval diperoleh sesuai Approval Matrix
• PDF version generated (non-editable)
• BizOps CRM updated: stage, attachments, notes
• Follow-up date sudah di-set (3-5 hari setelah kirim)

---

Tanggung Jawab (RACI)

Aktivitas	Presales Consultant	Solution Architect	Sales Lead	Sales Director	Managing Director
Menyusun outline & win theme	R	C	A	I	I
Menulis Section 2 (Exec Summary)	R	C	C	I	I
Menulis Section 4 (Understanding)	R	C	I	I	I
Menulis Section 5 (Solution)	C	R	I	I	I
Menulis Section 6 (Methodology)	R	C	I	I	I
Menulis Section 7 (Team)	R	C	C	I	I
Menulis Section 8 (Timeline)	R	C	I	I	I
Menulis Section 9 (Investment)	C	I	R	A	I
Menulis Section 10 (Why Divistant)	R	C	C	I	I
Technical review	I	R	I	I	I
Commercial review	I	I	R	A	I
Client empathy check	R	C	C	I	I
Final approval (<100M)	I	I	A	I	I
Final approval (100-500M)	I	I	R	A	I
Final approval (>500M)	I	I	R	C	A
Submission ke klien	R	I	A	I	I
Follow-up tracking	C	I	R	I	I

Legenda: R = Responsible, A = Accountable, C = Consulted, I = Informed

---

Referensi

Halaman Terkait di Presales Playbook:

• Discovery Process — Input utama untuk Section 4 (Understanding)
• Solution Design — Input utama untuk Section 5 (Solution & Architecture)
• Effort Estimation & Pricing — Input utama untuk Section 8 (Timeline) dan Section 9 (Investment)
• Service Catalog — Reference untuk capabilities dan service descriptions
• Value Engineering & ROI — Memperkuat value proposition dan justify pricing
• RFP & RFI Response — Struktur alternatif untuk formal RFP context
• Technical Demo & PoC — Sering dilakukan sebelum/bersamaan dengan proposal
• Tools & Templates — Lokasi semua proposal templates

Framework & Standards:

• APMP Proposal Management Body of Knowledge
• Shipley Proposal Guide
• C4 Model for Software Architecture (diagrams)
• MoSCoW Prioritization
• Divistant Brand Guidelines
• Divistant Rate Card (Finance shared folder)

---

Prinsip: "The best proposal doesn't just describe a solution — it tells the story of the client's transformation." Proposal yang menang bukan yang paling tebal, tapi yang paling menunjukkan pemahaman terhadap klien dan keyakinan bahwa kita bisa deliver.