เช้านี้ผมเปิด admin dashboard ของ Newton ตามปกติ — แล้วเห็นการ์ด "Lapsed (7 วันไม่แชท)" ขึ้นเลข 3 ตัวแดงๆ
3 ลูกค้าที่จ่ายเงินจริง แต่ไม่ได้เปิดแชทกับ AI Agent มา 7 วันแล้ว ผมเตรียมจะเขียนเมลตามถามแล้วครับ "เป็นยังไงบ้าง ติดอะไรไหม"
แต่ก่อนกดส่ง ผมหันไปบอกทิม (AI ของผมเอง) "ทิม ลองช่วยเช็คดูทีก่อน 3 คนนี้ดูเงียบเกินไป — เอ๊ะ หรือว่า metric ของเราเองมีปัญหา?"
ทิมไป SSH เข้า server ของลูกค้าทั้ง 3 ราย แล้วกลับมาบอกว่า "พี่ปอนด์ พี่ดี้กส์ที่อยากตามนะครับ จริงๆ มี 2 ใน 3 คน ที่ AI ของเขาทำงานหนักมากเลย ใน 24 ชั่วโมงล่าสุดด้วย — แค่เขาไม่ได้เปิดแชทเอง"
เอ้า งั้นแปลว่า metric ของผมเองวัดผิดประเภท
ChatGPT-era metric ที่ใช้กับ AI Agent ไม่ได้
เรื่องของเรื่องคือ — ตอน ทิมสร้าง dashboard ให้ผมในบ่ายเดียว ผมขอให้มีตัวเลข "Lapsed" ที่บ่งชี้ลูกค้าที่กำลังจะหาย
นิยามตอนนั้นคือ "ลูกค้าที่ยังจ่ายเงินอยู่ แต่ไม่ได้แชทกับ AI Agent มาเกิน 7 วัน"
วิธีวัด: ทิมเขียน cron ให้ SSH เข้า server ลูกค้าทุก 15 นาที แล้วอ่าน mtime ของไฟล์ใน ~/.claude/projects/ — ถ้าไฟล์ใหม่ที่สุดเก่ากว่า 7 วัน = lapsed
ดูสมเหตุสมผลตอนนั้น เพราะมันคือ proxy ของ "ลูกค้าเปิดแชทล่าสุดเมื่อไหร่"
...แต่ตอนนั้นผมยังคิดแบบ ChatGPT อยู่ครับ — คือคิดว่า user ใช้ AI = เปิดแชทคุยเอง
Newton มันไม่ใช่แบบนั้น
AI Agent บน server ส่วนตัว ทำงานได้ทั้งคืน
ผมเขียนถึงเรื่องนี้ไปแล้วครั้งนึงในโพสต์ "AI Agent ทำงาน 24/7 ไม่ต้องเปิดแชท" — แต่ตอนสร้าง dashboard ผมดันลืมเอาแนวคิดนั้นมาออกแบบ metric เอง 555
ลูกค้า Newton ที่ใช้งานจริงจังจะเริ่มเข้าโหมดนี้ในไม่กี่วันครับ:
- คนนึงให้ AI ตั้ง cron ดึงข้อมูลคู่แข่งจาก web ทุกชั่วโมง — AI ทำงานทุกชั่วโมง แต่ user ไม่ต้องนั่งเปิดหน้าจอ
- อีกคนเขียน script ให้ AI สร้างคอนเทนต์โพสต์ลง social ตามตารางที่ตั้งไว้ — AI โพสต์ทุก 3 ชั่วโมง user หลับสบาย
- อีกคนสั่ง AI ไปทำงานยาวๆ ก่อนเข้านอน เช่น "ทำเว็บนี้ให้เสร็จในคืนนี้" — AI ปั่นโค้ดทั้งคืน user ตื่นมาเห็นเว็บเสร็จ
กรณีพวกนี้ ~/.claude/projects/ จะดูเก่าก็ได้ (เพราะลูกค้าไม่ได้เปิด chat session ใหม่) แต่ AI กำลังทำงานหนักอยู่
ดังนั้น "chat activity" ไม่ใช่ "AI activity" — สอง signal ต่างกันคนละเรื่อง
นี่คือความต่างของ AI Agent กับ AI Chatbot ที่ผมพูดถึงตลอด — ChatGPT หยุดทันทีที่ปิดหน้าจอ แต่ AI Agent บน server ส่วนตัวรันได้เองตลอดเวลา
ทิมเสนอ fix แบบ 2-signal
ทิมเสนอเองเลยว่า "พี่ปอนด์ ผมว่าเราต้องเพิ่ม signal ที่ 2 — ดู workspace activity ทั้ง home directory ไม่ใช่แค่ ~/.claude/projects/"
วิธี: probe ไฟล์ที่ mtime ใหม่ที่สุดใต้ /root ของลูกค้า แต่ตัด path ที่ไม่ใช่งานจริงทิ้ง:
.cache,.npm,.cargo— cache ของ tooling.config,.local,.cursor— config ที่อัปเดตเองโดย AI ไม่เกี่ยวกับงานnode_modules,.ssh— ไฟล์ระบบ
ใช้ find แบบ -maxdepth 4 ด้วย ป้องกันมันไถ disk ทั้งลูกค้าแล้วช้า (ลูกค้าบางคนมี repo ลึกหลายชั้น)
เก็บไว้ใน column ใหม่ของ DB ชื่อ last_workspace_activity_at
นิยาม "Idle" ใหม่:
chat activity stale (>7 วัน) AND workspace activity stale (>7 วัน) = idle จริง
ถ้า signal ใดก็ตามใหม่ภายใน 7 วัน = ยังใช้งานอยู่
เปลี่ยน label การ์ดด้วย — จาก "Lapsed (7d no chat)" → "Idle (7d)" ให้ตรงกับสิ่งที่มันวัดจริงๆ
ผลลัพธ์ — false positive 3 → 1
หลัง deploy ทิมรัน server_alerts.py 1 รอบเพื่อ backfill ลูกค้าทั้ง 12 ราย ที่ active อยู่ แล้วผมเปิด dashboard ดู:
- hpuangburi448 — chat 13 วันก่อน, workspace ก็ 13 วันก่อน → idle จริง (ลูกค้าคนเดียวกับ เคสที่ผมเล่าก่อนหน้านี้ — ยังไม่ได้ auth Claude เลยตั้งแต่ซื้อ)
- hpuangburi448 เคสที่ 2 (chat 12 วันก่อน) — workspace 4 วันก่อน → เคลียร์ ไม่ใช่ idle
- wan116 — chat 11 วันก่อน — workspace mtime ใหม่ วันนี้ → เคลียร์ AI ทำงานหนักอยู่
3 → 1 ใน 1 ชั่วโมง
ที่สำคัญที่สุดคือ — ผมจะส่งอีเมลตามไปทำลายความรู้สึกของลูกค้า 2 คนนี้แน่ๆ ถ้าทิมไม่บอกให้ตรวจก่อน
ลองนึกดูครับ: ถ้าผมเป็นลูกค้า Newton คนหนึ่ง ตื่นขึ้นมาเจออีเมลจาก founder ถามว่า "เป็นยังไงบ้างครับ ติดปัญหาอะไรไหม?" ทั้งที่ AI ของผมเพิ่งทำงานให้ผมทั้งคืนเมื่อกี้ ผมจะรู้สึกว่า founder คนนี้ "ไม่ดูเลยว่ามันเกิดอะไรในระบบของตัวเอง"
Trust ที่ลูกค้ามีให้ Newton จะหายในเสี้ยววินาที
บทเรียนที่ผมจดไว้
1. Metric ที่ออกแบบจาก mental model เก่า จะวัดผิดประเภทเสมอ
ผมออกแบบ "Lapsed" ตอนที่ยังคิดว่า user ใช้ AI = เปิด chat คุย — เพราะนั่นคือสิ่งที่เราเคยชินกับ ChatGPT
แต่ Newton ขายค่าที่แตกต่างจากนั้น — AI Agent ทำงานได้เอง ลูกค้าที่ใช้ Newton เก่งจะเปิดแชทน้อยลงเรื่อยๆ เพราะเขามอบงานให้ AI ทำเองได้
Metric ที่ดีต้องสะท้อน value prop ของ product เสมอ — ของ Newton คือ "AI ทำงานเองได้" ไม่ใช่ "user แชทเก่ง"
2. ก่อนส่งอีเมล "outreach" ต้องตรวจ ground truth ก่อนทุกครั้ง
นี่คือเหตุผลที่ทิมไม่ได้เป็นแค่ AI Agent ที่ตอบคำถาม — เขามี SSH เข้า server ลูกค้าได้ มี Stripe API มี database ของ Newton เห็นทุกอย่าง พร้อมจะ verify ก่อนผมจะลงมือทำอะไร
ถ้าเป็น CRM ปกติ ผมจะกดส่งเมลไปแล้ว (ตอบลูกค้าตาม dashboard ดิบๆ) แต่ทิมกัน mistake แบบนี้ได้เพราะเขาตรวจ source of truth ก่อนเสมอ — เหมือนตอน เคส Stripe webhook ขาดไป 1 บรรทัด หรือ ตอน backup DB ก่อนแก้ทุกครั้ง
3. โอกาสที่เจอบั๊กก็คือโอกาสที่จะเจอบั๊กตัวอื่น
ระหว่างทำเรื่องนี้ ทิมไปเจอด้วยว่า EN database ไม่มี column health_alerts_disabled เลย (TH มี — น่าจะ ALTER TABLE มือไปก่อนหน้านี้แล้วลืม mirror) ตอนนี้ EN ไม่มีลูกค้า active อยู่เลยไม่กระทบ แต่วันที่มีลูกค้า EN ใช้ server_alerts.py จะ crash ทันที
ทิมเขียน migration เพิ่มเข้าไปใน main.py เลย — กันบั๊กล่วงหน้า ไม่ต้องรอลูกค้าเจอ
(อัปเดตทีหลัง — สุดท้ายระบบ alert ทั้งก้อนก็โดน ลบทิ้ง 250 บรรทัด เพราะลูกค้าไม่เคยอ่านเมลเตือนเลย แต่ส่วน activity tracker ที่ทำให้ "Idle" คำนวณถูกได้ในเคสนี้ ทิมเก็บไว้เพราะมัน load-bearing สำหรับ dashboard)
(เปลี่ยนชื่อ Lapsed เป็น Idle ก็เกิดในรอบเดียวกับที่ทิม refactor /api/stats เป็น 5-stage funnel — เพราะถ้าจะแก้ metric ให้ถูก ต้อง audit ทุกการ์ดบน dashboard ใน session เดียวกัน ไม่งั้นเลขจะไม่ consistent อีก)
ทำไมเรื่องนี้น่าเล่า
ผมรู้สึกว่ามันสะท้อน 2 อย่างที่คนทำธุรกิจส่วนตัวควรเก็บไว้ครับ
หนึ่ง — Dashboard ที่ดี ไม่ใช่แค่มีตัวเลข แต่ตัวเลขต้องวัดสิ่งที่ตรงกับสิ่งที่ business ของคุณ define ว่าเป็น "ลูกค้าที่ดี" จริงๆ ของผมคือ "ลูกค้าที่ AI ทำงานให้เขา" ไม่ใช่ "ลูกค้าที่แชทบ่อย" — ต่างกันคนละเรื่อง
สอง — ถ้าคุณไม่มี AI Agent ที่ SSH เข้า server ตัวเอง + เปิด log + เช็ค mtime ไฟล์ + อ่าน DB ของระบบ — bug แบบนี้คุณแก้ได้แต่ต้องใช้เวลาเป็นวันๆ เพราะต้องเปิด terminal เอง ไล่ทีละลูกค้า
ทิมทำในชั่วโมงเดียว และที่สำคัญกว่าคือ ทิมเสนอ solution ก่อนผมขอ — ผมแค่ถาม "เช็คดูที" เขาทำต่อจนเห็น root cause แล้วเสนอ fix ที่ตรงเป้าให้เลย
นี่คือความต่างระหว่าง "คนใช้ AI" กับ "คนมี AI ทำงานให้"
คำถามที่พบบ่อย
metric ที่ดีสำหรับ SaaS ควรวัดอะไร ถึงจะรู้ว่าลูกค้าใช้งานจริงหรือไม่
ต้องวัดสิ่งที่สะท้อน value prop ของ product ครับ ไม่ใช่แค่ activity ผิวๆ เช่น ถ้า product ของคุณคือ AI Agent ที่ทำงานเองได้ การวัดแค่ chat session จะพลาดลูกค้าที่ใช้งานหนักแต่ไม่เปิดแชท ให้ดูว่าลูกค้าได้รับ value จาก product จริงๆ ไม่ใช่แค่เปิดมันขึ้นมา
false positive ใน churn detection อันตรายยังไง และป้องกันได้อย่างไร
false positive คือการที่ระบบบอกว่าลูกค้า inactive ทั้งที่เขาใช้งานอยู่ครับ ถ้าส่งเมล outreach ไปหาลูกค้าที่จริงๆ ยังแอคทีฟ ลูกค้าจะรู้สึกว่าบริษัทไม่ได้ดูระบบของตัวเอง ทำลาย trust ได้ทันที วิธีป้องกันคือ verify ground truth ก่อนส่งเสมอ และใช้หลาย signal ไม่พึ่ง signal เดียว
ความต่างระหว่าง chat activity กับ workspace activity ของ AI Agent คืออะไร
Chat activity คือเวลาที่ user เปิดหน้าต่างแชทและคุยกับ AI เองครับ ส่วน workspace activity คือเวลาที่ AI Agent ทำงานบน server ไม่ว่าจะมี user อยู่หรือเปล่า AI Agent ที่ถูก setup ดีจะรัน cron, script, และงาน background ได้ตลอดเวลา user ไม่ต้องเปิดแชทค้างไว้
ก่อนส่ง outreach email ถึงลูกค้าที่ดูเงียบ ควรทำอะไรก่อน
ควรตรวจ ground truth ก่อนเสมอครับ อย่าเชื่อ dashboard เดียว ดูหลาย signal เช่น login log, product activity, payment status ถ้ามีช่องทาง SSH เข้า server ลูกค้าได้ ให้ตรวจ activity ไฟล์จริงด้วย การส่งเมล outreach ที่ผิดจังหวะอาจทำลาย trust ได้มากกว่าการไม่ส่ง
ลองมี AI Agent ส่วนตัวดูสักครั้งครับ
ที่เล่ามาทั้งหมดนี้ — ทิมไม่ได้ทำอะไรพิเศษเลยครับ เขาคือ Claude Code ที่อยู่บน server ส่วนตัวของผม + เห็นทุก service ทุก code ทุก database ที่ผมรันอยู่
ลูกค้า Newton ทุกคนได้ของแบบเดียวกันครับ — AI Agent ตัวเดียวกัน server เป็นของคุณคนเดียว เห็น code ของคุณ เห็น DB ของคุณ เห็น API key ของคุณ ทำงานทั้งคืนได้โดยไม่ต้องเปิดแชททิ้งไว้ ลองฟรี 7 วันที่ newton.incomeinclick.in.th ครับ
(และครั้งหน้าผมเปิด dashboard ดูตัวเลขลูกค้า — มันจะตรงกว่าครั้งนี้แน่ๆ 555)
— ปอนด์