AI Underwriting: Kenapa Stack Bersatu Atasi AMS Tunggal

Musim pembaharuan polisi hujung tahun selalunya jadi “ujian tekanan” paling jujur untuk operasi insurans. Pada minggu-minggu terakhir Disember, volume submission naik, klien mahukan sebut harga cepat, dan pasukan ops pula terperangkap antara inbox, fail PDF, dan data yang perlu disalin dari satu sistem ke satu sistem. Realitinya begini: bukan pasukan anda yang lambat—workflow yang berpecah-belah yang buatkan semuanya lambat.

Dalam siri “AI dalam Insurans dan Pengurusan Risiko”, saya kerap nampak satu pola yang sama: organisasi beli AMS (agency management system) untuk urus polisi, kemudian beli tool rating/quoting untuk sebut harga—tapi masih gagal memendekkan masa dari quote → bind → servis selepas bind. Punca utama bukan teknologi itu “tak bagus”. Punca utamanya: tools berdiri sendiri tak mencipta aliran kerja end-to-end.

Artikel asal membandingkan pendekatan “full stack” yang menggabungkan enjin quoting/rating (RQB) dengan platform operasi (Expert Insured/EI). Saya akan bawa idea itu ke konteks yang lebih luas: bagaimana integrasi AI dan automation dalam underwriting & pengurusan risiko benar-benar memberi kesan, apa yang biasanya orang tersilap beli, dan bagaimana nak menilai sama ada anda perlukan stack bersatu.

Masalah sebenar tools standalone: data bergerak, kerja tak bergerak

Jawapan terus: AMS dan tool rating yang berasingan menjadikan data berpindah, tetapi kerja tidak mengalir. Anda mungkin berjaya hasilkan sebut harga lebih cepat, namun kelulusan, binding, pengeluaran dokumen, COI, endorsement, audit, pembatalan, dan perakaunan masih tersekat.

“Kopi-paste” ialah risiko operasi yang mahal

Bila pasukan perlu menyalin data dari email → rater → AMS → dokumen, anda bukan saja buang masa, anda juga:

• Meningkatkan risiko kesilapan input (alamat risiko, klasifikasi, had, tarikh efektif)
• Menambah pendedahan E&O (errors & omissions)
• Menghasilkan “kebenaran berganda” (data versi A dalam AMS, versi B dalam spreadsheet)

Dalam pengurusan risiko, ini dipanggil operational risk: risiko yang berpunca daripada proses manusia dan sistem yang tidak terselaras. AI bukan sekadar untuk “buat quote laju”—AI patut mengurangkan operational risk melalui standardisasi dan pengesanan anomali.

Inbox bukan sistem kerja

Ramai organisasi “menjadi” berfungsi melalui inbox dan chat. Tapi inbox tak ada:

• Queue tugasan yang jelas
• Audit trail yang kemas
• SLA/turnaround tracking
• Pengagihan kerja berdasarkan beban dan kemahiran

Bila anda bergantung pada inbox, anda sebenarnya sedang membina operasi di atas sesuatu yang tak direka untuk operasi.

Apa yang dimaksudkan dengan “stack bersatu” dalam underwriting berasaskan AI

Jawapan terus: stack bersatu menggabungkan quoting + binding + servicing + task orchestration dalam satu aliran kerja, dengan AI sebagai “otak” yang membaca, mengelas, menghala, dan mencetuskan tindakan.

Dalam contoh RQB + EI, aliran kerjanya lebih kurang begini:

1. Submission masuk (email atau portal)
2. AI membaca dokumen dan mengklasifikasikan permintaan
3. Quote dihantar ke pelbagai carrier melalui integrasi API (atau proses digital yang setara)
4. Bila klien setuju, arahan bind memicu kemas kini polisi dalam sistem ops
5. Sistem ops mencipta tugasan automatik untuk COI, endorsement, audit, pembatalan, dan perakaunan
6. Pasukan ops (in-house atau BPO) bekerja dalam sistem yang sama, bukan melalui email berasingan

Kenapa ini relevan untuk AI dalam pengurusan risiko

AI yang paling berguna dalam insurans bukan semata-mata model canggih. Yang paling memberi ROI biasanya ialah AI yang:

• Mengurangkan variasi proses (standardization)
• Mengurangkan “hand-off friction” antara pasukan
• Memendekkan masa keputusan underwriting
• Mengurangkan ralat dan rework

Satu ayat yang mudah dipetik: “AI yang baik bukan menggantikan manusia—ia mengurangkan kerja yang memaksa manusia buat kesilapan.”

Kesan praktikal: daripada “cepat quote” kepada “cepat berkhidmat”

Jawapan terus: nilai terbesar stack bersatu ialah selepas bind—ketika kebanyakan organisasi mula perlahan.

Quote → Bind → COI: metrik yang orang jarang ukur

Ramai ukur masa untuk keluarkan sebut harga. Lebih sedikit yang ukur:

• Masa untuk siap bind selepas klien setuju
• Masa untuk keluarkan COI (certificate of insurance)
• Masa untuk proses endorsement pertama
• Bilangan sentuhan (touchpoints) setiap kes

Bila operasi berpecah, perkara yang paling “menyakitkan” ialah kerja kecil yang banyak: COI, perubahan alamat, tambah insured, pembetulan tarikh, pembatalan, audit. Stack bersatu menukar kerja ini daripada “manual follow-up” kepada workflow bertugasan.

Kebolehlihatan (visibility) mengurangkan risiko pematuhan

Dalam persekitaran pengawalseliaan dan audit, anda perlukan:

• Status tugasan yang boleh dikesan
• Log siapa buat apa, bila, dan kenapa
• Konsistensi dokumen

Platform ops yang ada audit trail dan sistem tugasan membantu mengurangkan risiko pematuhan (compliance risk) yang sering timbul bila semua keputusan bertaburan di email.

“AI triggers” yang patut anda cari (bukan sekadar chatbot)

Jawapan terus: cari AI yang menggerakkan kerja—bukan AI yang hanya menjawab soalan.

Berikut contoh AI triggers yang realistik dan relevan untuk underwriting dan servis polisi:

1) Pengelasan submission dan routing automatik

AI membaca dokumen (ACORD, slip, lampiran) dan menghala kes kepada:

• LOB (line of business) yang betul
• Underwriter yang sesuai
• Keutamaan berdasarkan tarikh efektif atau potensi premium

2) Semakan kualiti data sebelum quote

AI menandakan data “tak lengkap” atau meragukan, contohnya:

• Kod klasifikasi tak sepadan dengan deskripsi aktiviti
• Had perlindungan “luar biasa” berbanding profil risiko
• Tarikh efektif terlalu hampir untuk diproses tanpa eskalasi

3) Penciptaan tugasan servis selepas bind secara automatik

Bila polisi dibind, sistem terus mencipta tugasan standard:

• COI
• Invois/pembayaran
• Dokumen polisi
• Audit/pemeriksaan premium (jika berkaitan)

4) Pengesanan bottleneck operasi

Dengan data tugasan, anda boleh nampak:

• Di mana kes tersangkut
• Siapa overload
• Tugasan apa paling kerap buat rework

AI boleh membantu cadangkan penjadualan kerja dan penambahbaikan SOP berdasarkan corak sebenar.

Cara menilai sama ada anda perlukan stack bersatu (checklist 10 minit)

Jawapan terus: jika anda ada simptom “handoff” dan “copy-paste”, stack bersatu biasanya memberi pulangan lebih cepat daripada menambah tool baru.

Semak ini dengan jujur:

1. Berapa kali data yang sama ditaip semula dari submission hingga polisi dikeluarkan?
2. Ada tak satu paparan yang tunjuk status quote, bind, COI, endorsement untuk setiap klien?
3. Bila seseorang cuti, adakah kerja jadi “hilang” sebab hanya dia tahu status dalam inbox?
4. Adakah SLA servis (contoh COI 4 jam) dipantau secara sistematik?
5. Berapa ramai staf anda sebenarnya buat kerja pentadbiran yang boleh dijadikan tugasan automatik?

Jika 3 atau lebih jawapan anda “ya/tinggi”, ini petanda besar.

Pelaksanaan yang realistik: 2–4 minggu vs berbulan-bulan

Jawapan terus: implementasi cepat hanya berlaku bila vendor sediakan templat workflow, onboarding yang tegas, dan integrasi yang jelas.

Salah satu sebab orang trauma dengan transformasi AMS ialah projek terlalu panjang: data migrasi, custom field, latihan, integrasi carrier, dan perubahan SOP. Dalam pendekatan stack bersatu, anda patut menuntut pelan pelaksanaan yang lebih praktikal:

• Minggu 1: pemetaan proses quote→bind→servis (SOP ringkas, bukan dokumen 200 muka)
• Minggu 2: konfigurasi workflow + template dokumen + peranan pengguna
• Minggu 3: integrasi asas + ujian kes sebenar (10–20 submission)
• Minggu 4: go-live bertahap + pemantauan metrik (turnaround, touchpoints, backlog)

Saya tegas dalam hal ini: kalau implementasi tak ukur metrik operasi dari hari pertama, anda hanya “tukar sistem”—bukan baiki operasi.

Apa yang patut dibuat seterusnya (kalau anda mahu hasil, bukan demo)

Jawapan terus: mulakan dengan pilot berfokus pada satu LOB dan satu metrik utama.

Jika organisasi anda sedang menilai AI untuk underwriting dan pengurusan risiko, langkah yang biasanya paling menjadi ialah:

1. Pilih satu segmen yang jelas (contoh: SME komersial, E&S tertentu, atau satu niche MGA)
2. Tetapkan 2 metrik kejayaan yang keras:
   • Masa quote→bind (jam/hari)
   • Masa bind→COI (jam)
3. Audit sentuhan manual: berapa banyak copy-paste, berapa banyak follow-up email
4. Jalankan pilot 30 hari dengan volume sebenar
5. Selepas pilot, buat keputusan berdasarkan data, bukan “rasa selesa”

Hujung tahun 2025 menuju 2026 akan lebih mencabar dari segi kos, pematuhan, dan jangkaan pelanggan. Organisasi yang menang bukan yang ada paling banyak tool—tetapi yang ada aliran kerja underwriting berasaskan AI yang bersatu dan boleh diskalakan.

Kalau stack anda hari ini membuatkan orang hebat anda jadi “operator copy-paste”, itu bukan strategi pertumbuhan. Itu hutang operasi.

Langkah seterusnya: anda nak terus tambah tool baru, atau nak bina mesin operasi insurans yang betul-betul boleh bergerak laju tanpa chaos?