Faberic
§ Case 04 · Product · Totoloop

ระบบร้านอาหาร
ที่ไม่ต้องซื้อฮาร์ดแวร์

ร้านอาหารเล็ก ๆ ไม่ควรต้องซื้อ POS หรือ tablet เพื่อจะมีระบบ — Totoloop คือ operating system ของร้านอาหารบนมือถือที่ทุกคนมีอยู่แล้ว

01 · Problem

ร้านที่ขายดี แต่ระบบคือ Google Form กับความจำ

ร้านอาหารจริงในเชียงใหม่ที่รับออเดอร์ปิ่นโตรายสัปดาห์เจอปัญหาคลาสสิกของ SME:

  • ลูกค้าไม่รู้ว่าอาหารจะถึงกี่โมง → ทักถามเข้ามาตลอด และอาหารเสี่ยงเสียระหว่างรอ
  • ออเดอร์อยู่ใน Google Form → ข้อมูลกระจัดกระจาย ไม่เชื่อมกับครัว ไม่มีโปรไฟล์ลูกค้า
  • อาหารเสร็จทีละจาน → ต้องไล่แจ้งลูกค้าเป็นราย ๆ ด้วยมือ

ทางเลือกในตลาดคือระบบ POS ที่ต้องซื้อ hardware — ต้นทุนที่ร้านเล็กไม่ควรต้องแบก

02 · Design Decision

ออกแบบ workflow ก่อน — แล้ว software ค่อยตามมา

  • Zero hardware — ทั้งระบบเป็น PWA เปิดจากลิงก์ / QR / LINE ได้ทันที ไม่ต้องติดตั้ง app ไม่ต้องซื้ออุปกรณ์
  • สามบทบาท ระบบเดียว — ลูกค้า (สั่ง + ติดตาม) · พนักงานครัว (kitchen board) · เจ้าของ (จัดการเมนู/ออเดอร์) ใช้มือถือของตัวเอง
  • Real-time kitchen board — ครัวแตะปุ่มเลื่อนสถานะ → ลูกค้าได้รับแจ้งเตือนทันทีผ่าน LINE
  • แจ้งเตือนรายจาน — จานหนึ่งเสร็จ ระบบแจ้งเฉพาะลูกค้าที่สั่งจานนั้น — ไม่มีใครต้องไล่ส่งข้อความเอง
  • Subscription รายสัปดาห์ — ลูกค้าตั้งแบบแผน (วัน + มื้อ + จาน) ระบบสร้างออเดอร์ให้อัตโนมัติทุกสัปดาห์
  • Multi-tenant ตั้งแต่วันแรก — สถาปัตยกรรมพร้อมขยายเป็น SaaS ให้ร้านอื่นโดยไม่ต้องรื้อ
Software ไม่ได้สร้างระบบ — ระบบต่างหากที่กำหนดว่า software ควรเป็นอะไร
03 · System

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

11 modules ครบวงจร — ตั้งแต่รับลูกค้า · จัดการอาหารที่แพ้ · เมนูรายสัปดาห์ · subscription อัตโนมัติ · kitchen display แบบ real-time · การจัดส่งพร้อมแจ้ง ETA · notification engine · ไปจนถึง admin panel ของเจ้าของร้าน

ทุก module ผ่านการทดสอบ end-to-end และ deploy บน production แล้ว

04 · Result

Live ใน production — ใช้กับร้านจริง

ระบบขึ้น production ตั้งแต่ ส.ค. 2026 และเป็น testbed ของ pattern ฝั่ง SME ที่ Faberic ใช้ต่อยอดกับลูกค้ารายอื่น — บทเรียนจากร้านอาหารจริง กลายเป็นความรู้ที่ถ่ายทอดได้

05 · What we learned

SME ไม่ได้ขาดเทคโนโลยี — ขาดระบบที่ออกแบบจากงานจริง

ปัญหาของร้านไม่เคยเป็น "ไม่มี AI" หรือ "ไม่มี POS" — แต่เป็น workflow ที่ไม่เคยถูกออกแบบ เมื่อ workflow ชัด (ใครสั่ง → ใครทำ → ใครรู้เมื่อไหร่) software ที่ตามมาจะเรียบง่ายและถูกกว่าที่ทุกคนคิด

และบทเรียนเชิงวิศวกรรม: เลือกจุดที่ต้องยืดหยุ่นให้แม่น — เราทำ ports & adapters เฉพาะ 3 จุดที่ต้องเปลี่ยนได้จริง (auth · notification · payment) ที่เหลือใช้โครงสร้างมาตรฐาน — ความเรียบง่ายคือสิ่งที่ต้องออกแบบ

Next case
05 · การตัดสินใจระดับบริหาร ที่ตรวจสอบย้อนหลังได้ →
มีปัญหาคล้ายกัน? คุยกับเรา