Faberic
§ Case 01 · Sales System

ระบบ AI ที่ดีขึ้น
เพราะเราเอา AI ออก

เราออกแบบ AI 14 features ให้ระบบขายของกลุ่มธุรกิจตัวแทนจำหน่ายรถยนต์ — แล้วพบว่า 12 ตัวไม่จำเป็นต้องใช้ AI เลย

01 · Problem

ต้องการระบบขายที่ "มี AI" — เหมือนที่ทุกคนต้องการ

กลุ่มธุรกิจตัวแทนจำหน่ายรถยนต์ต้องการระบบบริหาร sales pipeline โดย requirement ตั้งต้นระบุให้ใช้ cloud AI ขับเคลื่อน 14 features — ตั้งแต่ lead scoring · customer insights · ไปจนถึง sales coaching

แต่มีเงื่อนไขหนึ่งที่สำคัญกว่าตัวเทคโนโลยี: ผู้จัดการฝ่ายขายต้องอธิบายได้ว่าระบบตัดสินใจอย่างไร — ทำไม lead รายนี้ถึง Hot ทำไมรายนั้นถึงไม่ใช่

02 · What we found

Audit ทั้ง 14 features — 12 ตัวแก้ได้ด้วย logic ล้วน

เมื่อไล่ดูทีละ feature เราพบว่า lead scoring ทำได้ด้วย rule ที่มีน้ำหนักชัดเจน · การร่างข้อความหาลูกค้าทำได้ด้วย template · โปรไฟล์ลูกค้า 360° ประกอบได้จากข้อเท็จจริงในระบบ · sales coaching ตอบได้จาก knowledge base

เหลือเพียง 2 features ที่ต้องใช้ความเข้าใจภาษาจริง ๆ — และทั้งคู่ให้ผลตอบแทนต่ำ

"AI" ในเอกสาร requirement กลายเป็นป้ายชื่อของทางแก้ ไม่ใช่ความจำเป็นของปัญหา

03 · Tension

ความยืดหยุ่นของ LLM vs ความรับผิดชอบต่อการตัดสินใจ

LLM เข้าใจภาษาได้ดี แต่มาพร้อมต้นทุนที่มองไม่เห็น: การตัดสินใจแบบ black box ที่อธิบายไม่ได้ · ค่าใช้จ่ายต่อ request · ข้อมูลลูกค้าที่ต้องออกไปนอก server · และ vendor lock-in

ส่วน rule-based logic อธิบายได้และทำซ้ำได้เป๊ะ — แต่ยืดหยุ่นน้อยกว่า และธุรกิจต้องดูแล rule เอง

คำถามที่แท้จริงไม่ใช่ "AI เก่งพอไหม" แต่คือ "ใครควรเป็นเจ้าของ logic การตัดสินใจของธุรกิจนี้"

04 · Design Decision

Glass-box Decision Engine

เราตัดสินใจให้ทุกการตัดสินใจในระบบ — lead scoring · customer profile · insights — คำนวณจาก rule ที่เขียนไว้ชัดเจน มี version และตรวจสอบย้อนหลังได้ ไม่ใช่จากการ inference ของ LLM

  • Intentional — ทีมเป็นเจ้าของสูตร อธิบายได้ว่าทำไมน้ำหนักแต่ละตัวเป็นเท่านี้
  • Versioned — ruleset ทุกชุดมี policy version กำกับ
  • Traceable — ทุกผลลัพธ์บันทึกพร้อม version + input + breakdown ของคะแนน — replay ได้ทุกการตัดสินใจ
LLM observes. Code decides. — ให้ AI ทำสิ่งที่มันเก่ง (อ่าน เข้าใจ สังเกต) · แต่การตัดสินใจ เป็นของ code ที่ธุรกิจเป็นเจ้าของ
05 · System

สิ่งที่สร้างจริง

ระบบ multi-tenant พร้อม Row-Level Security ที่ชั้น database · decision logic ทั้งหมดเป็น pure function ที่มี versioned ruleset · ทุกการให้คะแนนถูกบันทึกเป็น decision log ที่ audit ได้ · รันบน infrastructure ที่ธุรกิจควบคุมเอง — ข้อมูลลูกค้าไม่ออกไปไหน

06 · Result

ขึ้น production — และอธิบายตัวเองได้ทุกการตัดสินใจ

ระบบผ่านการทดสอบ multi-role end-to-end (sales coordinator ติดตามลูกค้า Hot · manager ดู pipeline analytics) โดยไม่พบ critical bug และ core decision pipeline ผ่านการ validate บน production จริงแล้ว

ที่สำคัญกว่า: เมื่อผู้จัดการถามว่า "ทำไม lead นี้ Hot" — ระบบตอบได้เป็น breakdown ของคะแนน ไม่ใช่ "AI บอกมา"

07 · What we learned

ถ้า logic ทำได้ อย่าใช้ AI

Generative AI เก่งเรื่องเข้าใจสิ่งที่ไม่มีโครงสร้าง — แต่ไม่ควรเป็นเจ้าของการตัดสินใจสำคัญ การแลกความยืดหยุ่นทางภาษา กับความอธิบายได้ + ทำซ้ำได้ + ความเป็นเจ้าของ logic เป็นการแลกที่คุ้มเสมอสำหรับธุรกิจ SME และตลาดที่ต้องการความรับผิดชอบ

และภาระการดูแล rule ไม่ใช่ต้นทุน — มันคือ feature: ธุรกิจเป็นเจ้าของ logic ของตัวเอง

Next case
02 · สร้างสมองให้บริษัท →
มีปัญหาคล้ายกัน? คุยกับเรา