Dokumen Teknis Aplikasi

Pendahuluan

Dokumen ini disusun sebagai panduan teknis untuk memahami alur penggunaan aplikasi Covera360, yaitu platform digital untuk proses bisnis asuransi dari hulu ke hilir. Fokus dokumen adalah menjelaskan bagaimana pengguna berinteraksi dengan sistem, bagaimana data mengalir antar modul, serta bagaimana komponen frontend dan backend saling terhubung dalam operasional harian.

Secara umum, aplikasi mencakup proses utama berikut: pengelolaan prospek (lead), konversi menjadi polis, verifikasi dan underwriting, penerbitan invoice, manajemen klaim, hingga audit dan pelaporan. Setiap proses dikendalikan oleh hak akses berbasis peran (misalnya agent, ops/admin, underwriter, manager) agar kontrol tata kelola tetap terjaga.

Dari sisi arsitektur, aplikasi terdiri dari:

• Frontend: antarmuka web operasional untuk user internal.
• Backend API: layanan transaksi dan governance (autentikasi JWT, validasi proses, audit log, generate dokumen).
• Penyimpanan dokumen: file pendukung (mis. KYC, PDF polis/invoice).

Dokumen teknis ini akan memecah flow aplikasi per modul dan per skenario penggunaan agar mudah dipahami oleh tim produk, engineering, QA, maupun operasional.

Daftar Isi

1. Pendahuluan
2. Flow Per Page: Prospek (Leads)
3. Flow Per Page: Policy
4. Flow Per Page: Invoices
5. Flow Per Page: Claims
6. Flow Per Page: Dashboard
7. Flow Per Page: Governance, Audit, dan Report
8. Daftar Istilah (Glossary)
9. Matriks Role vs Aksi (Ringkas)
10. Peta Fitur Keseluruhan Aplikasi (By Domain Proses)
11. Lampiran Detail Per Fitur (Format Operasional-Teknis)
12. Asumsi dan Batasan Dokumen
13. Penutup
14. Draft SOP Operasional per Role

Flow Per Page: Prospek (Leads)

Halaman Prospek adalah titik awal aktivitas penjualan. Pada halaman ini, user memonitor calon nasabah, melengkapi profil data, melakukan assignment owner (agen), lalu mendorong prospek yang siap menjadi pengajuan polis.

Tujuan Halaman

• Menyimpan dan menampilkan daftar lead yang masuk dari channel distribusi.
• Mengukur kesiapan data calon nasabah sebelum konversi ke polis.
• Mengatur kepemilikan lead (owner/agent) untuk akuntabilitas tindak lanjut.
• Menjadi sumber data awal untuk proses Policy Submission.

Role dan Hak Akses Utama

• Agent
  • Melihat lead yang menjadi tanggung jawabnya (scope terbatas).
  • Melengkapi data prospek dan melakukan update sesuai izin.
  • Membuat lead baru jika role memiliki izin create.
• Manager / Ops / Admin terkait
  • Melihat seluruh lead (scope all) bila role mengizinkan.
  • Melakukan reassignment owner.
  • Melakukan kontrol kualitas data sebelum konversi.

Catatan: visibilitas data mengikuti permission backend (scope owner vs scope all), bukan hanya aturan tampilan frontend.

Alur Operasional di Page Prospek

1. User membuka halaman Leads

   • Sistem mengambil data lead dari API transaksi dengan dukungan query pencarian dan pagination.
   • Jika user memiliki hak assign owner, sistem juga memuat daftar user agen.

2. User melakukan pencarian

   • Input search menggunakan debounce agar request lebih efisien.
   • Data tabel diperbarui berdasarkan kata kunci (nama, identitas lead, status, dsb).

3. Sistem menilai kelengkapan profil

   • Setiap lead ditampilkan dengan indikator persentase kelengkapan field wajib.
   • Tujuannya memberi sinyal apakah lead siap diproses ke tahap policy.

4. (Opsional) Reassign owner

   • User berizin dapat membuka picker owner, mencari agen, lalu menetapkan owner baru.
   • Perubahan owner disimpan ke backend dan langsung tercermin di tabel.

5. Aksi lanjutan per lead

   • Lihat detail / edit data prospek.
   • Lanjut ke proses pengajuan polis jika data sudah memadai.

Input Data Kritis untuk Lanjut ke Polis

Sebelum lead dikonversi ke policy, data berikut harus valid/siap:

• Identitas dasar calon nasabah (contoh: NIK, tanggal lahir, alamat, kota).
• Relasi distribusi dan referensi underwriting (partner/source/kategori/region bila diwajibkan).
• Informasi produk yang diminati dan parameter nilai pertanggungan.

Jika profil belum lengkap, sistem akan menahan proses pembuatan policy dan mengembalikan pesan validasi.

Output dari Page Prospek

• Daftar prospek yang terstruktur dan terassign.
• Status kesiapan data prospek untuk konversi.
• Transisi ke page pengajuan policy dengan konteks lead terpilih.

Flow Per Page: Policy

Modul Policy adalah inti proses operasional asuransi. Flow ini dimulai dari pengajuan polis baru, dilanjutkan verifikasi/underwriting, aktivasi polis, perubahan endorsement, hingga penerbitan dokumen resmi.

Tujuan Halaman Policy

• Mengelola siklus hidup polis dari status awal sampai aktif/selesai.
• Menjamin transisi status mengikuti governance dan role authorization.
• Menyediakan dokumen legal/operasional (KYC, sertifikat polis, lifecycle audit).

Role dan Hak Akses Utama

• Agent
  • Membuat policy submission dari lead.
  • Melengkapi data policy sesuai izin.
  • Mengakses policy dalam scope kepemilikan.
• Checker / Underwriter / Ops Admin
  • Melakukan review KYC dan transisi ke tahap verifikasi.
  • Menolak atau meminta revisi saat dokumen/risk tidak sesuai.
• Manager
  • Memberi keputusan aktivasi/penolakan final sesuai aturan.
  • Mengelola aksi kritikal seperti cancellation tertentu.

Seluruh transisi status policy divalidasi di backend agar tidak bisa dilompati dari sisi UI.

Alur Operasional Policy (End-to-End)

1. Policy List

   • User melihat daftar policy dengan pencarian, status, dan metadata penting.
   • Scope data mengikuti role (owner-only atau all).

2. Create New Policy

   • Pengajuan policy baru bisa dari lead yang dipilih.
   • Backend melakukan validasi profil lead + guard MoU aktif.
   • Sistem dapat menghitung premi dasar otomatis berdasarkan parameter produk/lead.
   • Saat policy sukses dibuat, sistem menyiapkan data untuk proses lanjutan.

3. Policy Detail

   • Menampilkan ringkasan policy, data nasabah, dokumen KYC, dan panel aksi.
   • Terdapat Policy Lifecycle (audit trail) untuk jejak proses.
   • Lifecycle panjang ditangani dengan Load More berbasis pagination API.

4. Underwriting & Status Transition

   • Aksi status mengikuti urutan lifecycle (contoh: Pending -> Under Review -> Verified -> Active).
   • Setiap transisi diverifikasi role-nya di backend.
   • Catatan underwriting dapat disimpan sebagai bagian governance.

5. Endorsement

   • Digunakan untuk perubahan policy yang sudah berjalan (bukan membuat policy baru).
   • Field yang dapat diubah dibatasi sesuai konteks endorsement.
   • Wajib menyertakan alasan endorsement.

6. Print & Official PDF

   • Halaman print dipakai untuk preview dokumen policy.
   • Official PDF dihasilkan dari backend (Dompdf).
   • File PDF resmi dipakai untuk download konsisten dan siap dipakai untuk lampiran email.

Titik Kontrol Governance di Modul Policy

• Validation Gate: profil lead, relasi partner/MoU, dan field minimum.
• Role Guard: transisi status policy dibatasi per role.
• Audit Trail: setiap aksi penting dicatat ke audit logs.
• Document Control: dokumen KYC dan PDF policy berada pada storage dengan akses terproteksi token/JWT.

Output dari Modul Policy

• Polis aktif yang siap ditagihkan (invoice) dan dilindungi coverage.
• Dokumen policy resmi (PDF) yang dapat diunduh atau dilampirkan.
• Jejak lifecycle lengkap untuk kebutuhan audit dan kepatuhan.

Flow Per Page: Invoices

Modul Invoices berfungsi sebagai kontrol finansial setelah policy berjalan. Fokusnya adalah memastikan tagihan premi terbentuk dengan benar, status pembayaran termonitor, dan dokumen invoice tersedia dalam format resmi untuk distribusi.

Tujuan Halaman Invoices

• Menyajikan daftar invoice beserta status pembayaran secara terstruktur.
• Memfasilitasi proses update status invoice sesuai otorisasi role.
• Menyediakan dokumen invoice yang dapat dicetak/diunduh dari backend.

Role dan Hak Akses Utama

• Agent (scope terbatas)
  • Melihat invoice miliknya (berdasarkan policy ownership).
  • Memantau due date dan status pembayaran.
• Finance / Ops / Manager (sesuai izin)
  • Melakukan update status invoice (mis. mark paid, overdue, partial).
  • Menjalankan kontrol rekonsiliasi pembayaran.
  • Mengakses dokumen invoice resmi untuk kebutuhan operasional.

Alur Operasional di Modul Invoices

1. Invoice List

   • User melihat daftar invoice dengan fitur search dan pagination.
   • Sistem menampilkan ringkasan finansial (outstanding, overdue) untuk monitoring cepat.
   • Scope data mengikuti role (owner-only vs all).

2. Invoice Detail

   • Menampilkan informasi lengkap tagihan:
     • identitas invoice,
     • data tertagih (bill to),
     • referensi policy,
     • nominal tagihan dan due date.
   • Menyediakan audit timeline untuk jejak perubahan status.

3. Status Update

   • Perubahan status invoice divalidasi oleh backend berdasarkan transition rules dan role.
   • Contoh transisi yang diatur: Unpaid -> Partial/Paid/Overdue, dll.
   • Setiap perubahan penting tercatat pada audit log.

4. Print & Download PDF Resmi

   • Tombol print dapat digunakan untuk kebutuhan cepat (layout halaman).
   • Untuk dokumen resmi, sistem menyediakan generate/download PDF dari backend:
     • PDF dibuat dari data database via Dompdf.
     • Frontend mengunduh langsung file backend (token/JWT protected), bukan sekadar save dari browser print.

Titik Kontrol Governance di Modul Invoices

• Role Guard: update status hanya oleh role yang berwenang.
• Transition Rule: status invoice tidak bisa lompat sembarang state.
• Auditability: mutasi invoice memiliki jejak log untuk kontrol internal.
• Document Integrity: invoice PDF resmi bersumber dari backend dan konsisten untuk penggunaan lintas channel (download, distribusi, lampiran).

Output dari Modul Invoices

• Daftar tagihan premi yang terkonsolidasi dan termonitor.
• Status pembayaran yang tervalidasi sesuai governance.
• Dokumen invoice resmi siap unduh dan siap distribusi.

Flow Per Page: Claims

Modul Claims menangani proses pengajuan dan evaluasi klaim dari policy aktif. Fokus utamanya adalah memastikan setiap klaim memiliki dasar data policy yang valid, bukti pendukung memadai, dan alur keputusan yang terdokumentasi.

Tujuan Halaman Claims

• Mencatat laporan klaim secara terstruktur dari policy yang masih berlaku.
• Memastikan validasi dasar klaim (policy aktif, tanggal kejadian, nominal klaim).
• Menyediakan alur tindak lanjut klaim untuk tim operasional.

Role dan Hak Akses Utama

• Agent / Frontline
  • Mengajukan klaim baru.
  • Melampirkan bukti awal klaim.
  • Memantau status klaim yang diajukan.
• Ops / Claims Handler / Manager
  • Melakukan review dan verifikasi klaim.
  • Menjalankan keputusan proses klaim sesuai kebijakan internal.
  • Menjaga kepatuhan dokumentasi dan jejak audit klaim.

Alur Operasional Modul Claims

1. Claim List

   • User melihat daftar klaim dengan status, nominal, dan metadata policy terkait.
   • Search dan filter digunakan untuk mempercepat investigasi kasus.

2. Create Claim

   • User memilih policy referensi (dengan searchable picker).
   • Sistem memvalidasi data wajib:
     • policy_id,
     • incident_date,
     • claim_amount.
   • Validasi tambahan:
     • tanggal kejadian harus berada dalam periode policy.
   • User mengisi kronologi kejadian dan unggah bukti.
   • Klaim disimpan dengan status awal (contoh:Pending) untuk diproses.

3. Claim Detail / Processing

   • Tim penanganan meninjau bukti dan data kejadian.
   • Keputusan lanjutan diproses sesuai workflow internal (review, approve/reject, dsb. tergantung implementasi role dan status pada modul claims).
   • Aktivitas penting dicatat untuk auditability.

Integrasi Antar Modul

• Dengan Policy
  • Klaim hanya bisa diajukan terhadap policy aktif/valid.
  • Data policy menjadi referensi utama untuk cakupan dan periode pertanggungan.
• Dengan Governance/Audit
  • Setiap perubahan status atau keputusan klaim idealnya memiliki jejak audit.
• Dengan Dokumen
  • Bukti klaim tersimpan di storage terproteksi dan diakses melalui endpoint aman.

Titik Kontrol Governance di Modul Claims

• Eligibility Check: policy aktif dan incident date berada pada rentang valid.
• Data Completeness: nominal klaim, kronologi, dan bukti pendukung.
• Controlled Status Transition: perubahan status klaim mengikuti role dan SOP.
• Traceability: seluruh aksi penting tercatat untuk kebutuhan investigasi dan kepatuhan.

Output dari Modul Claims

• Registrasi klaim yang tervalidasi.
• Dasar data untuk proses investigasi dan keputusan klaim.
• Jejak proses klaim untuk monitoring operasional dan audit.

Flow Per Page: Dashboard

Halaman Dashboard berfungsi sebagai ringkasan kondisi bisnis dan operasional secara cepat. Dashboard bukan hanya tampilan statistik, tetapi titik orientasi awal user sebelum masuk ke workflow detail per modul.

Tujuan Halaman Dashboard

• Menyajikan KPI utama lintas modul (leads, policy, invoice, claim, dsb).
• Memberi sinyal kondisi yang membutuhkan perhatian cepat (contoh: overdue invoice, claim pending, policy menunggu review).
• Mempercepat navigasi user ke area tindakan prioritas.

Role dan Hak Akses

• Agent
  • Melihat ringkasan performa pada scope data miliknya.
  • Menggunakan dashboard sebagai titik masuk aktivitas harian follow-up.
• Manager / Ops / Admin
  • Melihat agregasi lintas tim/unit (sesuai permission).
  • Menggunakan dashboard untuk pengambilan keputusan cepat dan kontrol operasional.

Alur Operasional di Dashboard

1. Load KPI Ringkas

   • Sistem mengambil ringkasan indikator utama dari API report/summary.
   • Angka ditampilkan sebagai snapshot kondisi saat ini.

2. Interpretasi Prioritas

   • Komponen indikator dengan tren negatif/alert menjadi prioritas tindak lanjut.
   • User diarahkan dari insight ke aksi (mis. ke page invoices, claims, atau policies).

3. Navigasi Cepat ke Modul Terkait

   • Dashboard menjadi hub untuk membuka detail data berdasarkan KPI yang dipilih.
   • User melanjutkan tindakan di page operasional masing-masing.

Output dari Dashboard

• Gambaran kesehatan pipeline bisnis dan operasional.
• Daftar prioritas kerja harian berbasis data aktual.
• Arah navigasi cepat ke modul eksekusi.

Flow Per Page: Governance, Audit, dan Report

Modul governance memastikan seluruh aktivitas penting dapat ditelusuri, tervalidasi, dan dipantau sebagai bagian dari kontrol internal serta kepatuhan.

Tujuan Modul Governance/Audit/Report

• Menyediakan jejak aksi pengguna pada entitas kritikal (lead, policy, invoice, claim, agreement).
• Memudahkan investigasi perubahan data dan keputusan operasional.
• Menyediakan laporan ringkas untuk monitoring performa dan kepatuhan.

Komponen Utama

• Audit Log
  • Mencatat event create/update/delete dan action penting lainnya.
  • Menyimpan informasi aktor, timestamp, dan perubahan data relevan.
• Governance Report
  • Menampilkan ringkasan metrik operasional dan keuangan untuk kebutuhan manajerial.
• Policy/Invoice/Claim Lifecycle
  • Timeline di detail page masing-masing sebagai representasi audit yang lebih kontekstual.

Alur Operasional Governance

1. Event terjadi di modul transaksi

   • Contoh: status policy berubah, invoice di-mark paid, klaim diajukan.

2. Backend mencatat audit

   • Event dicatat oleh service/model audit log.
   • Metadata aksi tersimpan untuk keperluan traceability.

3. User meninjau pada page lifecycle/audit

   • Data audit ditampilkan di timeline entitas.
   • Untuk volume besar, data bisa dipaginasi agar tetap ringan.

4. Manajemen meninjau laporan

   • Laporan governance dipakai untuk evaluasi kinerja proses dan kepatuhan SOP.

Titik Kontrol Governance

• Role-based Action: aksi sensitif hanya dilakukan role berizin.
• Immutable Trail: histori perubahan menjadi referensi investigasi.
• Operational Transparency: setiap keputusan utama dapat dijelaskan dengan bukti data.

Output dari Modul Governance

• Bukti jejak operasional yang dapat diaudit.
• Insight kinerja proses lintas modul.
• Dasar evaluasi perbaikan SOP dan kontrol risiko.

Daftar Istilah (Glossary)

• Lead / Prospek
  Calon nasabah yang datanya masuk ke pipeline penjualan dan belum menjadi polis aktif.

• Policy / Polis
  Kontrak pertanggungan asuransi yang diterbitkan berdasarkan data nasabah dan produk.

• Underwriting
  Proses evaluasi risiko sebelum polis dapat diverifikasi/diaktifkan.

• KYC (Know Your Customer)
  Verifikasi identitas dan data nasabah untuk kepatuhan dan mitigasi risiko.

• Endorsement
  Perubahan terhadap polis yang sudah berjalan (bukan pembuatan polis baru).

• Invoice
  Tagihan pembayaran premi yang terkait dengan polis tertentu.

• Claim / Klaim
  Permintaan ganti rugi dari tertanggung berdasarkan kejadian yang dijamin polis.

• Audit Log / Lifecycle
  Catatan kronologis aktivitas sistem/user terhadap entitas operasional.

• Scope Owner
  Batas visibilitas data hanya untuk entitas yang dimiliki user (mis. agent owner).

• Scope All
  Visibilitas data lintas owner/tim sesuai role dan permission.

• Governance
  Mekanisme kontrol proses, otorisasi, dan jejak perubahan untuk menjaga kepatuhan operasional.

Matriks Role vs Aksi (Ringkas)

Catatan: Matriks ini bersifat panduan fungsional. Implementasi final mengikuti permission backend yang aktif.

Penutup

Dokumen ini merupakan baseline flow penggunaan aplikasi berdasarkan modul utama saat ini. Seiring bertambahnya fitur, perubahan SOP, atau penyesuaian permission role, dokumen perlu diperbarui agar tetap akurat sebagai referensi teknis dan operasional.

Peta Fitur Keseluruhan Aplikasi (By Domain Proses)

Bagian ini merangkum keseluruhan fitur aplikasi berdasarkan domain proses bisnis utama agar mudah dipahami lintas tim (bisnis, operasional, teknis).

1) Operasi Penjualan

Prospek

• Mengelola calon nasabah dari berbagai sumber/channel.
• Mendukung pencarian, pagination, dan assignment owner (agen) berbasis permission.
• Menampilkan indikator kelengkapan profil untuk kesiapan konversi ke polis.
• Menjadi titik awal alur penjualan menuju policy submission.

2) Siklus Hidup Polis

Polis

• Membuat pengajuan polis dari lead yang memenuhi syarat.
• Menjalankan lifecycle status (Pending, Under Review, Verified, Active, dst) dengan role guard.
• Menyimpan dokumen KYC dan menampilkan lifecycle/audit trail per polis.
• Mendukung endorsement (perubahan polis berjalan) dengan alasan perubahan.
• Menyediakan dokumen polis resmi (preview + generate/download PDF backend).

Klaim

• Registrasi klaim berdasarkan polis aktif.
• Validasi tanggal kejadian terhadap periode pertanggungan.
• Unggah bukti klaim dan catatan kronologi kejadian.
• Menjadi input untuk proses investigasi dan keputusan klaim operasional.

Perpanjang (Renewal)

• Memfasilitasi proses perpanjangan polis mendekati akhir periode.
• Menghubungkan data polis eksisting dengan opsi pembaruan coverage/premi sesuai kebijakan.
• Menjadi jalur menjaga persistensi nasabah dan kesinambungan perlindungan.

3) Strategi Jaringan

Mitra

• Pengelolaan partner distribusi (broker, bank, channel partner).
• Menyimpan profil partner, performa, dan relasi operasional.

Tim

• Pengelolaan struktur tim operasional/penjualan.
• Mendukung pengaturan anggota tim dan alokasi tanggung jawab.

Kontrak MoU

• Mengelola kontrak kerja sama aktif dengan mitra.
• Menjadi guard penting untuk proses bisnis (contoh: pembuatan polis mensyaratkan MoU aktif).

4) Tata Kelola

Produk

• Konfigurasi katalog produk asuransi (jenis, tier, premi, rule, benefit).
• Menjadi referensi utama proses quote, policy, dan underwriting.

Komisi

• Pengelolaan struktur dan output komisi berdasarkan transaksi.
• Mendukung transparansi perhitungan bagi kanal distribusi terkait.

Report

• Menyediakan ringkasan metrik bisnis dan operasional lintas modul.
• Menjadi dasar monitoring performa dan pengambilan keputusan.

Log Audit

• Jejak aktivitas create/update/delete dan action penting pada entitas inti.
• Mendukung investigasi, kontrol internal, dan kepatuhan.

Management User

• Pengelolaan user, role/group, dan permission akses.
• Menentukan scope data (owner vs all) serta otorisasi aksi sensitif.

Master Referensi

• Menyediakan data referensi sistem (kategori, wilayah, source, dsb).
• Menjaga konsistensi data lintas modul transaksi.

5) Bantuan dan Preferensi

Pengaturan

• Pengaturan preferensi aplikasi (termasuk language/locale dan konfigurasi operasional terkait user).
• Menyediakan area bantuan kontekstual agar user memahami langkah kerja tiap page.

Ringkasan Alur Antardomain

1. Prospek dikumpulkan dan diperkaya datanya.
2. Prospek siap diproses menjadi Polis.
3. Polis aktif memicu proses finansial (Invoice/Komisi) dan layanan pasca-terbit (Klaim/Perpanjang).
4. Seluruh aktivitas dikontrol oleh Tata Kelola (produk, user, audit, report, referensi).
5. User dibantu oleh modul Pengaturan/Bantuan untuk pengalaman operasional yang konsisten.

Lampiran Detail Per Fitur (Format Operasional-Teknis)

Bagian ini menyajikan ringkasan detail per fitur dalam format baku agar konsisten dipakai untuk implementasi, QA checklist, dan onboarding tim.

A. Operasi Penjualan

A.1 Prospek (Leads)

• Tujuan
  • Mengelola data calon nasabah sampai siap dikonversi menjadi policy.
• Role
  • Agent, Ops/Admin, Manager (sesuai permission).
• Input
  • Data identitas calon nasabah, minat produk, referensi channel/partner.
• Proses
  • Listing + search + pagination.
  • Validasi kelengkapan profil.
  • Assignment owner (jika berizin).
  • Transisi ke policy submission.
• Output
  • Lead siap konversi dan terassign dengan jelas.

B. Siklus Hidup Polis

B.1 Polis

• Tujuan
  • Menjalankan lifecycle policy dari submit hingga aktif/closed.
• Role
  • Agent, Checker/Underwriter/Ops, Manager.
• Input
  • Lead valid, produk valid, dokumen KYC, status workflow.
• Proses
  • Create policy.
  • Review underwriting + transisi status sesuai role.
  • Monitoring lifecycle (audit timeline).
• Output
  • Policy tervalidasi, terdokumentasi, siap lanjut ke finansial dan layanan.

B.2 Klaim

• Tujuan
  • Mencatat dan memproses klaim dari policy aktif.
• Role
  • Agent/frontline, Ops claims, Manager.
• Input
  • Policy referensi, tanggal kejadian, nilai klaim, kronologi, bukti.
• Proses
  • Registrasi klaim + validasi periode policy.
  • Review operasional sesuai workflow klaim.
• Output
  • Klaim teregistrasi dan siap diproses/diinvestigasi.

B.3 Perpanjang (Renewal)

• Tujuan
  • Menjalankan perpanjangan policy yang mendekati jatuh tempo.
• Role
  • Agent, Ops/Underwriter, Manager.
• Input
  • Data policy existing, periode akhir, opsi pembaruan.
• Proses
  • Identifikasi policy renewal.
  • Penyesuaian data/ketentuan sesuai kebijakan.
  • Aktivasi policy lanjutan.
• Output
  • Coverage berlanjut tanpa putus perlindungan.
• API terkait
  • Mengikuti endpoint policy/invoice terkait implementasi renewal yang aktif.

C. Strategi Jaringan

C.1 Mitra

• Tujuan
  • Mengelola kanal distribusi dan profil partner.
• Role
  • Ops/Admin, Manager.
• Input
  • Data identitas mitra, kontak, status, relasi bisnis.
• Proses
  • CRUD partner + evaluasi performa.
• Output
  • Data partner terstandardisasi.

C.2 Tim

• Tujuan
  • Mengatur struktur tim operasional/penjualan.
• Role
  • Admin, Manager.
• Input
  • Nama tim, struktur anggota, relasi user.
• Proses
  • CRUD tim + mapping anggota.
• Output
  • Struktur organisasi operasional yang jelas.

C.3 Kontrak MoU

• Tujuan
  • Menjaga kontrak aktif sebagai guard operasional distribusi.
• Role
  • Admin, Manager, Governance.
• Input
  • Data kontrak, periode, partner, status aktif.
• Proses
  • CRUD MoU + verifikasi status aktif.
  • Dipakai sebagai guard pembuatan policy.
• Output
  • Kepatuhan kerja sama distribusi.

D. Tata Kelola

D.1 Produk

• Tujuan
  • Menjadi referensi inti rule asuransi dan parameter premi.
• Role
  • Product admin, Underwriter, Manager.
• Input
  • Jenis produk, tier, rate, rules, benefits.
• Proses
  • CRUD konfigurasi produk.
• Output
  • Basis standar perhitungan dan validasi policy.

D.2 Komisi

• Tujuan
  • Mengelola transparansi komisi distribusi.
• Role
  • Finance, Ops, Manager.
• Input
  • Data transaksi policy/invoice dan rule komisi.
• Proses
  • Kalkulasi/rekap komisi.
• Output
  • Laporan komisi terstruktur.

D.3 Report

• Tujuan
  • Menyediakan insight performa lintas modul.
• Role
  • Manager, Ops, Finance.
• Input
  • Agregasi data transaksi dan governance.
• Proses
  • Query ringkasan KPI dan laporan analitik.
• Output
  • Dashboard/report sebagai bahan keputusan.

D.4 Log Audit

• Tujuan
  • Menjaga traceability perubahan data.
• Role
  • Ops/Admin, Manager, Compliance.
• Input
  • Event operasional dari seluruh entitas utama.
• Proses
  • Logging event create/update/delete/action kritikal.
• Output
  • Jejak audit siap investigasi.

D.5 Management User

• Tujuan
  • Mengatur user, role, dan hak akses.
• Role
  • Superadmin/Admin.
• Input
  • Data user, group/role, status akun.
• Proses
  • CRUD user + pengaturan akses.
• Output
  • Kontrol akses konsisten dan aman.

D.6 Master Referensi

• Tujuan
  • Menjadi sumber referensi data baku lintas modul.
• Role
  • Admin/Ops.
• Input
  • Data kategori, region, source, referensi lain.
• Proses
  • CRUD referensi.
• Output
  • Konsistensi data sistem.

E. Bantuan dan Preferensi

E.1 Pengaturan

• Tujuan
  • Menyediakan kontrol preferensi user dan konfigurasi dukungan operasional.
• Role
  • Seluruh user (sesuai porsi), Admin untuk konfigurasi tertentu.
• Input
  • Preferensi user (mis. bahasa), konfigurasi setting yang tersedia.
• Proses
  • Update preferensi dan pemuatan guidance kontekstual.
• Output
  • Pengalaman penggunaan lebih konsisten dan personal.

Asumsi dan Batasan Dokumen

• Dokumen ini disusun berdasarkan implementasi fitur dan alur yang tersedia saat penulisan terakhir.
• Mapping role dan permission bersifat panduan; implementasi final mengikuti konfigurasi permission aktif di backend.
• Beberapa flow (misalnya renewal lanjutan atau varian workflow klaim tertentu) dapat memiliki perbedaan sesuai kebijakan bisnis yang berjalan.

Draft SOP Operasional per Role

• Agent

  • Validasi kelengkapan data prospek sebelum submit (nama, kontak, produk, region).
  • Lakukan follow-up prospek maksimal 1x24 jam setelah lead dibuat.
  • Pastikan dokumen pendukung awal (KTP/KK jika dibutuhkan flow) terunggah dengan format benar.
  • Gunakan jalur endorsement untuk perubahan polis aktif; hindari membuat polis baru tanpa kebutuhan bisnis.

• Ops Admin

  • Verifikasi kesesuaian data input Agent dengan dokumen pendukung sebelum status dinaikkan.
  • Jalankan maker-checker pada perubahan status kritikal (policy, claim, invoice) sesuai matriks role.
  • Pastikan dokumen PDF resmi (policy/invoice) berhasil tergenerate dan tersimpan sebelum proses distribusi.
  • Catat alasan reject/return secara jelas agar Agent dapat melakukan perbaikan terarah.

• Finance

  • Rekonsiliasi status invoice (Unpaid/Paid) berdasarkan bukti pembayaran yang tervalidasi.
  • Proses payout komisi hanya untuk transaksi yang sudah memenuhi syarat status bisnis.
  • Simpan jejak approval dan bukti transaksi untuk kebutuhan audit internal/eksternal.
  • Lakukan review periodik aging invoice sebagai dasar tindakan penagihan.

• Manager / Approver

  • Review exception case (klaim besar, endorsement material, dispute pembayaran) sebelum approval final.
  • Pantau KPI operasional mingguan: conversion rate, SLA underwriting, aging invoice, claim turnaround.
  • Pastikan kepatuhan terhadap SOP lintas tim melalui audit trail dan sampling kasus.
  • Putuskan tindakan korektif (proses, training, atau aturan akses) bila ditemukan pola deviasi berulang.

• SLA Minimum yang Disarankan

  • Follow-up lead awal: maksimal 1x24 jam.
  • Review underwriting standar: maksimal 2 hari kerja.
  • Update status invoice setelah verifikasi pembayaran: maksimal 1 hari kerja.
  • Respons awal klaim setelah submit: maksimal 1 hari kerja.