เกณฑ์ทั้ง 6
- มี access ถึงลูกค้าจริง
- มีเวลา
- มี domain expertise
- มีแรงจูงใจด้านรายได้
- มีทีม support
- มี commitment ที่วัดได้
ใครดูแลอะไร และเมื่อไรที่เราจะปฏิเสธคุณ
คำตอบสั้น: DNAfinity มี 16 แอปแต่มี Founder คนเดียว โมเดลนี้จะพังทันทีถ้าเราหลอกตัวเองเรื่องขอบเขต เราจึงเขียนกติกาไว้ล่วงหน้า: Partner เป็นเจ้าของ L1 support · Founder แตะเฉพาะ L3 · ไม่มี Partner ก็ไม่เปิดขาย · และ สิทธิ์ทุกอย่างเกิดหลัง pilot ไม่ใช่ก่อน บทความนี้อธิบายว่าทำไม และบอกตรง ๆ ว่าเมื่อไรเราจะบอกว่าไม่
ที่มา ทุกข้อในหน้านี้อ้างอิงรัฐธรรมนูญบริษัท (DKOS-001) ข้อ 15 Partner Constitution, ข้อ 16 Customer Constitution, ข้อ 27 Support Constitution และมติ DEC-0004 / DEC-0005 ที่มีสถานะ Accepted
1
ปัญหาที่โมเดลนี้แก้
เรามีแอปที่ใช้งานได้ 16 ตัวบนฐานร่วมเดียวกัน สร้างโดยคนคนเดียวทำงานร่วมกับ AI สิ่งที่เราไม่มีคือ ผู้ใช้ภายนอก — ศูนย์ราย การประเมินอิสระด้วย AI 3 ตัวเมื่อ 16 ก.ค. 2026 ให้คะแนน Traction เท่ากับ 1 จาก 5 กับทุกแอปทั้ง 16 ตัว ทุกโมเดลเห็นตรงกันหมด — ผู้ประเมินรายหนึ่งสรุปสั้น ๆ ว่า "HTTP 200 ไม่ใช่ traction"
ข้อสรุปที่ตามมาไม่ใช่ "ต้องการเงิน" แต่คือ ต้องการคนที่มีตลาดอยู่แล้วและรับผิดชอบลูกค้าได้จริง — และถ้าเรารับพาร์ทเนอร์เข้ามาโดยยังคิดว่า Founder จะตอบแชตลูกค้าเองได้ ระบบจะพังทันทีที่มีลูกค้ารายที่สอง กติกาด้านล่างจึงไม่ใช่ระเบียบราชการ แต่เป็นเงื่อนไขให้โมเดลนี้อยู่รอด
2
ชั้น support: L0 ถึง L3
| ชั้น | ใครรับ | ครอบคลุมอะไร |
|---|---|---|
| L0 | ระบบ (self-service) | FAQ · Knowledge Base · Guided Onboarding · AI Assistant · Tutorial |
| L1 | Partner | การใช้งาน · ตั้งค่า · อบรม · แก้ปัญหาพื้นฐาน |
| L2 | Product Owner | บั๊ก · configuration ขั้นสูง · integration |
| L3 | Founder | เหตุวิกฤต · Strategic Escalation · Major Design Decision |
ประโยคที่เขียนไว้ในรัฐธรรมนูญตรง ๆ คือ "Founder ต้องไม่เป็น L1" และมติ DEC-0004 ที่มีสถานะ Accepted ระบุว่า "Founder รับเฉพาะ L3 และ Strategic Escalation"
นี่คือเหตุผลโดยตรงที่ SmeDNA และ AppForge ถูกเลือกเป็น commercial focus รอบแรก — มติ DEC-0005 ให้เหตุผลไว้ว่า "มีช่องทางตลาด, มีโอกาสเกิดรายได้เร็ว, Partner-led ได้, และ Support สามารถส่งต่อได้" ไม่ใช่เพราะสองแอปนี้เจ๋งที่สุด แต่เพราะมันเป็นสองแอปที่ ส่งต่อ support ให้พาร์ทเนอร์ได้จริง
3
เกณฑ์ 4 ใน 6 ข้อ
ผู้สมัครควรมีอย่างน้อย 4 ใน 6 ข้อนี้ ไม่ต้องครบทุกข้อ:
ข้อที่หนักที่สุดคือข้อแรก
เราสร้างของเป็น เราขาดตลาด ผู้สมัครที่มีทุกข้อยกเว้น "access ถึงลูกค้า" คือกรณีที่ยากที่สุดสำหรับเรา เพราะมันแปลว่าเราสองฝ่ายเก่งเรื่องเดียวกันและขาดเรื่องเดียวกัน
กติกาที่ตามมา No Partner, No Launch — vertical ใดที่ยังไม่มี Partner Owner รับผิดชอบ ห้ามเปิดขายเชิงพาณิชย์ นี่คือเหตุผลที่หลายแอปยังอยู่สถานะ Showcase ทั้งที่สาธิตได้แล้ว เราเลือกไม่ขายมากกว่าจะขายแล้วไม่มีคนดูแล
4
เส้นทาง 4 ขั้น และประตูที่ต้องผ่าน
- 1
Fit call — 30 นาที
จับคู่ความเชี่ยวชาญ ตลาด และแอป ไม่เริ่มจากสัญญาระยะยาว ถ้าไม่ตรงกัน จบตรงนี้แบบไม่เสียเวลาใคร
- 2
Opportunity brief
เขียนให้ชัดว่าลูกค้าเป้าหมายคือใคร ปัญหาคืออะไร ขอบเขตแค่ไหน ใครรับบทบาทไหน วัดด้วย KPI อะไร และใช้ข้อมูลอะไรร่วมกัน — ประตูนี้ผ่านเมื่อทั้งสองฝ่ายเซ็นชื่อบนกระดาษแผ่นเดียวกันได้
- 3
Controlled pilot
ทดลองกับลูกค้าหรือ use case จำกัด พร้อม acceptance criteria, support owner ที่ระบุชื่อได้ และ paid conversion path — ประตูนี้ผ่านเมื่อมีหลักฐานจากผู้ใช้จริง ไม่ใช่ความเห็น
- 4
Review and scale
ตัดสินจาก outcome, ต้นทุน support จริง และผลงานของ Partner ก่อนขยาย commercial scope — ประตูนี้ผ่านเมื่อต้นทุนต่อรายลดลง ไม่ใช่แค่ยอดเพิ่ม
สิ่งที่ Partner Agreement ระบุเมื่อถึงขั้นลงนาม: role, territory, target, revenue share, support responsibility, data responsibility, IP, confidentiality, exit terms และ non-compete ตามความเหมาะสม ทั้งหมดตกลงบนหลักฐานจาก pilot ไม่ใช่บนคำสัญญา
5
เมื่อไรที่เราจะบอกว่าไม่
การรู้ตอนนี้ประหยัดเวลาทั้งสองฝ่ายมากกว่ารู้ตอนเดือนที่สาม เราจะปฏิเสธเมื่อ:
ขอสิทธิ์ก่อนมีหลักฐาน
ต้องการ exclusivity หรือ revenue share ตั้งแต่ก่อน pilot — ไม่มีสิทธิ์ใดเป็นอัตโนมัติ ทุกอย่างมาจาก opportunity brief, หลักฐานจาก pilot และข้อตกลงที่ลงนามแยกต่างหาก
คาดหวังให้ Founder ทำ L1
ถ้าโมเดลของคุณคือส่งลูกค้ามาแล้วให้เราดูแลต่อทั้งหมด นั่นคือโมเดล reseller ที่ต้องมีทีม support ของเรารองรับ ซึ่งเรายังไม่มี และรัฐธรรมนูญห้ามไว้
ขายเกินกว่าที่ของทำได้
รัฐธรรมนูญข้อ 16 ห้าม "โฆษณาเกินจริง" และ "อ้างผลลัพธ์แน่นอน" ถ้าแผนการขายต้องพึ่งการบอกลูกค้าว่ามี integration ที่ยังไม่มี เราไม่ร่วม
ต้องการข้อมูลผู้ใช้
การเข้าร่วม Partner Program ไม่ให้สิทธิ์เข้าถึงระบบหรือข้อมูลผู้ใช้ การเชื่อมข้อมูลทุกกรณีต้องผ่าน identity, consent, purpose และ audit controls
สรุป
ทำไมประกาศกติกาไว้ก่อน
เพราะกติกาที่บอกทีหลังคือกับดัก และเพราะรัฐธรรมนูญของเราเขียนไว้ว่าลูกค้าต้องได้รับ "ความคาดหวังที่ถูกต้อง" — ถ้าเราติดหนี้ความซื่อสัตย์นั้นกับลูกค้า เราก็ติดหนี้มันกับพาร์ทเนอร์ที่จะไปดูแลลูกค้าแทนเราด้วย
ถ้าอ่านจบแล้วยังคิดว่าตรงกัน นั่นคือสัญญาณที่ดีที่สุดที่เราจะได้รับ
ดูบทบาทและสมัคร ดูหลักฐานฝั่ง SmeDNA
อัปเดต เผยแพร่ 16 ก.ค. 2026 · อัปเดต 17 ก.ค. 2026 · อ้างอิง DKOS-001 Constitution v1.1 · ข้อมูล traction อ้างอิงรอบประเมิน 16 ก.ค. 2026
FAQ
คำถามที่พบบ่อยเรื่องขอบเขต
ทำไม Partner ต้องรับงาน L1 support
เพราะเป็นการออกแบบตามรัฐธรรมนูญของบริษัท ข้อ 27 กำหนดชั้น support เป็น L0 ถึง L3 และระบุว่า Founder ต้องไม่เป็น L1 ส่วนมติ DEC-0004 ยืนยันว่า Founder รับเฉพาะ L3 และ Strategic Escalation เหตุผลเชิงโครงสร้างคือระบบนิเวศมี 16 แอปแต่มี Founder คนเดียว ถ้า Founder รับ L1 ของทุกแอป ระบบจะพังทันทีที่มีลูกค้ารายที่สอง
DNAfinity ปฏิเสธ Partner เมื่อไร
เมื่อไม่ผ่านเกณฑ์อย่างน้อย 4 ใน 6 ข้อ หรือเมื่อผู้สมัครต้องการสิทธิ์ผูกขาดและส่วนแบ่งรายได้ก่อนมีหลักฐานจาก pilot หรือเมื่อคาดหวังให้ Founder รับงาน L1 หรือเมื่อโมเดลธุรกิจขัดกับขอบเขตของผลิตภัณฑ์ เช่นต้องการขาย AppForge แข่งกับเครื่องมือ generate แอปในตลาด ซึ่งไม่ใช่สิ่งที่ AppForge วางไว้
เส้นทางจากคุยครั้งแรกถึงเป็น Partner เต็มตัวเป็นอย่างไร
สี่ขั้น เริ่มจาก fit call 30 นาทีเพื่อจับคู่ความเชี่ยวชาญกับแอป ตามด้วย opportunity brief ที่กำหนดลูกค้าเป้าหมาย ปัญหา ขอบเขต บทบาท KPI และข้อมูลที่ใช้ร่วมกัน จากนั้นเป็น controlled pilot กับลูกค้าจำกัดพร้อม acceptance criteria และ paid conversion path และสุดท้ายคือ review and scale ที่ตัดสินจาก outcome ต้นทุน support และผลงานจริง ไม่ใช่จากความตั้งใจ
Partner ได้สิทธิ์เข้าถึงข้อมูลผู้ใช้หรือไม่
ไม่โดยอัตโนมัติ การเชื่อมข้อมูลใด ๆ ต้องอยู่ภายใต้ identity, consent, purpose และ audit controls ของระบบ การเข้าร่วม Partner Program ไม่ได้ให้สิทธิ์เข้าถึงระบบหรือข้อมูลผู้ใช้ และรัฐธรรมนูญข้อ 16 ห้ามใช้ข้อมูลเกินขอบเขต consent ที่ผู้ใช้ให้ไว้