SmeDNA สร้างเสร็จและได้ 4.14 จาก AI 3 ตัว — สิ่งที่ยังเป็นศูนย์คือลูกค้า
คำตอบสั้น: SmeDNA คือ Business DNA platform สำหรับธุรกิจไทย ครอบคลุม 132 ประเภทธุรกิจใน 20 หมวด บน core เดียวที่ปรับตามประเภทร้าน รันอยู่บน production server จริงตั้งแต่ 21 มิ.ย. 2026 และเป็น แอปเดียวในระบบนิเวศที่มี agentic execution ระดับ L3 อยู่ใน production code จริง แต่ ยังไม่มีผู้ใช้ภายนอกแม้แต่รายเดียว — และนั่นคือเหตุผลเดียวที่หน้านี้มีอยู่
code-truth จำนวนประเภทธุรกิจและสถานะ deploy = หลักฐานจากโค้ดและ runbook จริง · คะแนนแข่งขันใด ๆ บนเว็บนี้เป็น self-assessment เชิง directional ไม่ใช่ audit และไม่ได้ผ่าน user research · วิธีที่เราวัดตัวเอง และข้อจำกัดของมัน →
Evidence
อะไรที่ตรวจสอบได้แล้ว
โครงสร้าง 132 ประเภทธุรกิจ
จุดต่างเชิงโครงสร้างคือ เลือกประเภทธุรกิจแล้ว capability, AI agent และ package ประกอบขึ้นเองจาก core เดียว ไม่ใช่แยก build ทีละร้าน หมวดที่ใหญ่ที่สุดคือค้าปลีก 21 ประเภท ตามด้วยบริการ 13 และอาหาร/เครื่องดื่ม 11 ตัวเลข 132 นับได้จากไฟล์ taxonomy ในโค้ดโดยตรง
รันบน production จริง ไม่ใช่ demo
SmeDNA ย้ายขึ้น production VPS ตั้งแต่ 21 มิ.ย. 2026 มี runbook การ deploy และ deploy lock ที่ใช้จริง และมีชุด regression ที่ถือเป็น ratchet ขนาด 137 test files นอกจากนี้ event wire ข้ามแอปไป OperDNA ถูกตรวจสอบสดเมื่อ 11 ก.ค. (HMAC, ครบทั้ง 5 event types พร้อม negative control)
Agentic L3 — สิ่งที่ SmeDNA มีอยู่แอปเดียวในระบบนิเวศ
ทั้ง 16 แอปมี "สมอง" แต่ SmeDNA เป็นแอปเดียวที่ agentic execution รันอยู่ใน production code จริง (ระดับ L3 = ระบบเสนอและลงมือได้ภายใต้การกำกับ ไม่ใช่ auto-execute) และความปลอดภัยถูกบังคับที่ระดับโค้ด ไม่ใช่แค่นโยบายบนกระดาษ:
Guardrail ที่บังคับในโค้ด
- ค่าเริ่มต้นของระบบคือ ปิด (
enabled = False) - Kill switch เปิดไว้เป็นค่าเริ่มต้น
auto_executeถูกปฏิเสธที่ API layer — เพดานคือ L3- เปลี่ยนบัญชีธนาคารของ supplier = การกระทำต้องห้ามถาวร
- 11 reason code จริงสำหรับอธิบายทุกการตัดสินใจ
ราคาทองยังให้คนกรอก — โดยตั้งใจ
ระบบรับราคาทอง 4 quote ต่อรอบ (แท่ง/รูปพรรณ × ซื้อ/ขาย) โดย ร้านเป็นคนกรอกเอง ไม่ใช่ feed อัตโนมัติ และหมวดทองถูก บล็อกออกจากขอบเขต agent autonomy อย่างจงใจ นี่คือ ratchet ด้านความปลอดภัยที่เอกสารภายในระบุว่า "ห้ามหย่อน" — เงินก้อนใหญ่และราคาผันผวนไม่ใช่ที่ที่ควรให้ AI ตัดสินใจแทนคน
Vertical ร้านทอง — ตัวอย่างว่า "เฉพาะทาง" หมายถึงอะไร
ร้านทองเป็น vertical ที่ลึกที่สุดในตอนนี้ เพราะโจทย์บังคับให้ระบบทั่วไปใช้ไม่ได้: ราคาขยับทั้งวัน คิดราคาตามน้ำหนักบวกค่ากำเหน็จ ภาษีทองรูปพรรณคิดเฉพาะส่วนต่าง จำนำกับขายฝากเป็นสัญญาคนละแบบตามกฎหมาย และสต๊อกมีมูลค่าลอยตามตลาด
Capability ที่มีในระบบ
- ราคาทอง 4 quote ต่อรอบ
- POS คิดตามน้ำหนัก + ค่ากำเหน็จ
- VAT ทองรูปพรรณเฉพาะส่วนต่าง · รับซื้อทองเก่า
- แยกจำนำ / ขายฝาก + พิมพ์ใบสัญญา
- สต๊อก mark-to-market · KYC/AML/ทะเบียน
- Gold Price & Pawn Risk Agent
สิ่งที่ Partner ต้องเติม
- ตรวจ workflow กับหน้าร้านจริงที่มีของหมุนทุกวัน
- ยืนยันการตีความภาษี/กฎหมายกับกรณีของร้านเอง
- ออกแบบ onboarding ที่พนักงานหน้าร้านใช้ได้จริง
- รับ L1 support ในภาษาและเวลาทำการของร้าน
boundary รายการซ้ายคือ capability ที่ build แล้วในระบบ ไม่ใช่คำรับรองทางกฎหมายหรือบัญชี — การนำไปใช้จริงต้องผ่านการตรวจของผู้เชี่ยวชาญที่รับผิดชอบร้านนั้น
Business Health Score — สูตรเต็ม ไม่ใช่กล่องดำ
หน้าผลิตภัณฑ์ของเราโฆษณา "Business Health Score" มานาน แต่ไม่เคยบอกว่ามันคิดยังไง ซึ่งไม่ควรเป็นแบบนั้น — ตัวเลขที่ร้านจะใช้ตัดสินใจต้องตรวจสอบได้ นี่คือสูตรจริงที่อ่านจากโค้ด:
| องค์ประกอบ | น้ำหนัก | คิดอย่างไร |
|---|---|---|
| Revenue trend | 25% | ยอดขายเดือนนี้เทียบเดือนก่อน · 50 = ทรงตัว · โต 1% = +1 คะแนน · ตก 1% = −1 · ตัดที่ 0–100 |
| Gross margin | 25% | (ยอดขาย − ต้นทุนขาย) ÷ ยอดขาย × 100 · ต้นทุนคิดจาก cost_price × จำนวน · ไม่มียอดขาย = 50 (เป็นกลาง) |
| Inventory health | 20% | % ของสินค้าที่ ไม่ ต่ำกว่าจุดสั่งซื้อหรือหมดสต๊อก · ไม่มีสินค้า = 100 |
| Cash position | 15% | เงินสดในลิ้นชักวันนี้ ÷ 10,000 บาท × 100 · เกิน baseline = 100 · ลิ้นชักว่าง = 0 |
| Reconciliation rate | 15% | % ของรายการธนาคารที่กระทบยอดแล้ว · ไม่มีรายการธนาคาร = 100 |
คะแนนรวมคือค่าเฉลี่ยถ่วงน้ำหนักของทั้ง 5 (น้ำหนักรวมเป็น 1.00 พอดี) แต่ละองค์ประกอบให้ 0–100 · แถบสถานะ: ≥ 70 = healthy · 40–69 = warning · < 40 = critical · คำนวณด้วย SQL aggregate ต่อร้านเดียวเท่านั้น ไม่ข้ามร้าน และเป็น deterministic คือข้อมูลเดิมให้ผลเดิมเสมอ ไม่ใช่ LLM เดา
ข้อจำกัดที่ต้องรู้ Reconciliation rate (15%) ตอนนี้ให้ 100 เกือบตลอด เพราะยังไม่มี bank integration ป้อนรายการเข้ามา (ดูหัวข้อถัดไป) แปลว่า 15% ของคะแนนยังเป็นแต้มคงที่จนกว่าจะเชื่อมธนาคารได้จริง · CASH_BASELINE ที่ 10,000 บาทเป็นค่าตั้งต้นเดียวกันทุกร้าน ซึ่งอาจไม่เหมาะกับร้านทองหรือร้านที่หมุนเงินสดสูง — เป็นโจทย์ที่ Domain Partner ช่วยปรับได้
Boundary
สิ่งที่ยังไม่พร้อม (อ่านก่อนตัดสินใจ)
ส่วนนี้คือเหตุผลที่ควรอ่านหน้านี้ให้จบก่อนคุยกับเรา ถ้าข้อใดข้อหนึ่งเป็น dealbreaker ของคุณ การรู้ตอนนี้ดีกว่ารู้หลังเซ็น
ไม่มี traction
การประเมิน 16 ก.ค. ให้ Traction = 1 จาก 5 กับ ทุกแอปทั้ง 16 ตัว ทั้ง 3 โมเดล เพดานเดียวกันหมด — เป็นข้อที่ผู้ประเมินเห็นตรงกันมากที่สุดข้อหนึ่ง คำของ Codex ในรายงานคือ "HTTP 200 ไม่ใช่ traction"
Marketplace ยังไม่เชื่อมจริง
connector ของ Shopee / Lazada / Facebook / Omise ตอนนี้มีแค่ credential store และ signed test-connection — ยังไม่มี order sync จริง เช่นเดียวกับ bank reconciliation ที่ยังเป็น roadmap ไม่ใช่ของที่ส่งมอบได้วันนี้ ถ้าดีลของคุณต้องพึ่งสิ่งเหล่านี้ ต้องคุย scope และเวลาให้ชัดก่อนเริ่ม
132 ประเภท ≠ 132 vertical ที่พิสูจน์แล้ว
taxonomy ครอบคลุม 132 ประเภท และ core ใช้ร่วมกัน แต่หน้าเจาะลึกที่ผ่านการออกแบบ workflow เฉพาะทางมี 9 ประเภท ประเภทอื่นยังไม่มีผู้เชี่ยวชาญตรวจ — นี่คือช่องที่ Domain Partner เข้ามาเป็นเจ้าของได้
ยังไม่มี pricing และ SLA
ตามกฎ No Partner, No Launch เราไม่เปิดขายเชิงพาณิชย์ให้ vertical ที่ยังไม่มีคนรับผิดชอบลูกค้า pricing, SLA และ revenue share เกิดหลัง opportunity brief และ pilot ไม่ใช่ก่อน
ทำไมถึงเขียนแบบนี้ รัฐธรรมนูญของเราข้อ 16 ห้าม "โฆษณาเกินจริง" และ "อ้างผลลัพธ์แน่นอน" ส่วนข้อ 18 กำหนดให้ "แยก Fact, Inference และ Suggestion" ออกจากกัน หน้านี้จึงเขียนตามนั้น — ถ้าเราไม่ซื่อสัตย์กับคุณตอนนี้ คุณจะเชื่อรายงานผลจากเราตอน pilot ได้อย่างไร
Operating Boundary
ใครดูแลอะไร — L1 คืองานของคุณ
ขอบอกตรง ๆ ตั้งแต่ต้น: Partner เป็นเจ้าของ L1 support นี่ไม่ใช่ข้อต่อรอง แต่เป็นการออกแบบตามรัฐธรรมนูญของบริษัท (ข้อ 27 และมติ DEC-0004 "Founder ไม่ทำ L1") และเป็นเหตุผลโดยตรงที่ SmeDNA ถูกเลือกเป็น commercial focus รอบแรก — มติ DEC-0005 ระบุเหตุผลไว้ว่า "มีช่องทางตลาด, มีโอกาสเกิดรายได้เร็ว, Partner-led ได้, และ Support สามารถส่งต่อได้"
Partner / L1
- Customer discovery และโจทย์เฉพาะร้าน
- Onboarding, ตั้งค่า, อบรมพนักงาน
- Support การใช้งานประจำวัน
- หลักฐานผลลัพธ์จากหน้าร้านจริง
Product Owner / L2
- บั๊กและการตั้งค่าขั้นสูง
- Integration และ data migration
- Implementation playbook
- Acceptance criteria ของ pilot
DNAfinity / L3
- สถาปัตยกรรมและ shared core
- Identity, consent, security guardrails
- เหตุวิกฤตและ major design decisions
- Release governance
อ่านต่อ โมเดลการทำงานร่วมกันฉบับเต็ม — L0 ถึง L3, pilot gate และสิ่งที่ทำให้เราปฏิเสธ →
Partner FAQ
คำถามที่ควรถามเราก่อน
SmeDNA มีลูกค้าใช้งานจริงกี่ราย
ยังไม่มีผู้ใช้ภายนอก การประเมิน 16 ก.ค. 2026 ด้วย AI models อิสระ 3 ตัวให้คะแนน Traction ของ SmeDNA และของทุกแอปในระบบนิเวศเท่ากับ 1 จาก 5 ซึ่งเป็นเพดานเดียวกันทั้ง portfolio ระบบรันบน production server จริงตั้งแต่ 21 มิ.ย. 2026 แต่ยังไม่เปิดขายเชิงพาณิชย์เพราะยังไม่มี Partner Owner ตามกฎ No Partner, No Launch
SmeDNA รองรับธุรกิจประเภทใดบ้าง
Business DNA taxonomy ครอบคลุม 132 ประเภทธุรกิจใน 20 หมวด ตั้งแต่ค้าปลีก อาหารและเครื่องดื่ม บริการ สุขภาพ การศึกษา ผลิต ก่อสร้าง อสังหาริมทรัพย์ ยานยนต์ การเงิน โลจิสติกส์ ไปจนถึงแฟรนไชส์ ปัจจุบันมีหน้าเจาะลึกเปิดแล้ว 9 vertical ส่วนที่เหลือใช้ core เดียวกันแต่ยังไม่มี workflow เฉพาะทางที่ผ่านการตรวจของผู้เชี่ยวชาญ
SmeDNA จัดการภาษีและกฎหมายร้านทองอย่างไร
vertical ร้านทองรองรับราคาทอง 4 quote ต่อรอบที่ร้านกรอกเอง, POS คิดตามน้ำหนักบวกค่ากำเหน็จ, VAT ทองรูปพรรณคิดเฉพาะส่วนต่าง, แยกจำนำกับขายฝากตามกฎหมายพร้อมพิมพ์ใบสัญญา, สต๊อก mark-to-market และการแจ้งเตือน KYC/AML สิ่งเหล่านี้เป็น capability ในระบบ ไม่ใช่คำรับรองทางกฎหมายหรือบัญชี ร้านต้องยืนยันอัตราและการยื่นกับบัญชีหรือทนายของตัวเองอีกครั้ง
ทำไมราคาทองไม่ดึงอัตโนมัติ
เป็นการตัดสินใจด้านความปลอดภัยโดยตั้งใจ ร้านเป็นคนกรอกราคาเอง และหมวดทองถูกบล็อกออกจากขอบเขตการทำงานอัตโนมัติของ AI agent เอกสารภายในระบุว่าเป็น ratchet ที่ "ห้ามหย่อน" เพราะทองเป็นสินทรัพย์มูลค่าสูงที่ราคาผันผวนระหว่างวัน ความรับผิดชอบจึงควรอยู่กับคน
Partner ของ SmeDNA ต้องรับผิดชอบอะไร
Partner ดูแล L1 คือ customer discovery, onboarding, ตั้งค่า อบรม และ support การใช้งานหน้าร้าน Product Owner ดูแล L2 คือบั๊ก การตั้งค่าขั้นสูงและ integration ส่วน Founder ดูแลเฉพาะ L3 คือสถาปัตยกรรมและเหตุวิกฤต Partner ไม่ต้องเขียนโปรแกรมเอง ยกเว้นบทบาท Implementation Partner
SmeDNA เชื่อมกับ Shopee หรือธนาคารได้แล้วหรือยัง
ยัง connector ของ marketplace มีแค่ credential store และ signed test-connection ยังไม่มี order sync จริง ส่วน bank reconciliation ยังอยู่ใน roadmap ถ้าดีลของคุณต้องพึ่ง integration เหล่านี้ ต้องกำหนด scope และเวลาร่วมกันก่อนเริ่ม pilot
Next
ถ้าคุณมีร้านหรือเครือข่ายร้านอยู่แล้ว
สิ่งที่มีค่าที่สุดสำหรับเราตอนนี้ไม่ใช่คำชม แต่คือ ร้านจริง 1 ร้านที่ยอมให้ทดลอง พร้อมคนที่รับผิดชอบผลลัพธ์ได้ ขั้นแรกคือคุย 30 นาทีเพื่อดูว่าตรงกันไหม ไม่เริ่มจากสัญญา
เสนอตัวดูแล SmeDNA vertical ดูรายละเอียดผลิตภัณฑ์
อัปเดต หน้านี้อัปเดต 17 ก.ค. 2026 · หลักฐานคะแนนและ traction อ้างอิงรอบประเมิน 16 ก.ค. 2026 · วิธีที่เราวัดตัวเลขของตัวเอง →