เรื่องนี้มันเริ่มจากความรู้สึกผมเองครับ ผมเคยเป็นคนที่บัตรเด้งโดยไม่ตั้งใจหลายรอบ — บางทีบัตรหมดอายุแล้วยังไม่ได้รับใบใหม่ บางทีธนาคาร flag ว่าเป็น fraud เพราะรูดจ่ายต่างประเทศบ่อย บางทีก็แค่บัญชีไม่พอช่วงปลายเดือน 555 พอจ่ายไม่ผ่าน SaaS หลายๆ เจ้าตัด access ทันที — เซิ่ฟวอ์ฟล์ไม่ขึ้น โดเมนหาย ข้อมูลที่อยู่ในนั้นล็อกตัวเอง

ผมไม่อยากให้ Newton ทำแบบนั้นกับลูกค้าครับ

สถานการณ์จริง

Newton เป็นบริการ AI Agent + เซิร์ฟเวอร์ส่วนตัวรายเดือน ลูกค้าจ่ายผ่าน Stripe ตัดบัตรอัตโนมัติทุกเดือน ระบบเดิมที่ผมและ AI Agent ของผม (ทิม) สร้างไว้ตั้งแต่แรกคือ — ถ้า Stripe ยิง webhook invoice.payment_failed มา ก็ถือว่าหมดสัญญา ลบ server ลบ DNS เคลียร์ออกจากระบบ

ฟังดูเรียบร้อยครับ แต่พอผมจินตนาการตัวเองเป็นลูกค้าปุ๊บ ผมก็คิดเลยว่า "ถ้าเป็นผม ผมจะหัวเสียมากเลยนะ"

เพราะการที่บัตรเด้งหนึ่งครั้ง ไม่ได้แปลว่าลูกค้าตั้งใจเลิกใช้ — บางทีเขาแค่ลืมเปลี่ยนบัตรใหม่ บางทีบัตรโดน fraud lock ชั่วคราว บางทีรู้อยู่แล้วว่ารอบนี้ตัดไม่ผ่านเพราะติดเรื่องโอนเงินเข้าบัญชี

เลยบอกทิมว่า "เคสบัตรเด้งของลูกค้าที่จ่ายอยู่แล้ว ผมอยากให้มี grace period 24 ชั่วโมง — server ยังรันต่อ ส่งอีเมลด่วนเตือน ถ้าใน 24 ชม. บัตรผ่านเองตอน Stripe retry หรือลูกค้าเปลี่ยนบัตร — กลับมาปกติ ถ้าไม่ผ่าน — ค่อยลบ"

ทิมแยก state ของลูกค้าให้ละเอียดขึ้น

เรื่องที่ผมชอบคือ ทิมไม่ได้แค่ patch logic เก่า มันเสนอให้แยก state ของ subscription ออกเป็นหลายแบบให้ชัดก่อน:

  • active — จ่ายผ่าน server รันปกติ
  • past_due — บัตรเด้ง ยังให้ใช้ต่อจนกว่า grace จะหมด
  • cancelling — ลูกค้ากดยกเลิกเอง ใช้ได้จนหมด billing period
  • cancelled — หมดเวลาแล้ว ลบ server

เพิ่มฟิลด์ grace_ends_at ใน DB เก็บ timestamp ที่ grace จะหมด

ตอน Stripe ยิง webhook invoice.payment_failed มา ระบบจะ:

  1. เช็คว่าเป็นลูกค้า trial หรือ paid
  2. ถ้า paid → set status = 'past_due' + grace_ends_at = now + 24h
  3. ส่งอีเมลด่วน (ภาษาไทยหรืออังกฤษตาม locale ลูกค้า) แจ้งว่า "บัตรเด้ง — server กับข้อมูลทั้งหมดจะถูกลบใน 24 ชม. ถ้าไม่อัปเดตบัตร"
  4. ส่ง Telegram ให้ผมรู้ทันที
  5. ไม่ ปิด server

นี่คือจุดสำคัญครับ — server ยังรันต่อ ลูกค้ายังเข้าใช้ได้ตามปกติ ทุกอย่างที่เขาทำไว้ยังอยู่

Cron เช็ครายชั่วโมง

ทีนี้ระบบต้องรู้ว่า "เมื่อ 24 ชั่วโมงผ่านไป" — ตรงนี้ทิมใช้ cron job ที่มีอยู่แล้วชื่อ trial_grace_check.py (เดิมไว้เช็คลูกค้า trial ที่หมดอายุ) แล้วขยายให้ครอบคลุม paid ด้วย

Cron นี้รันทุกชั่วโมง ดู subscription ที่ status = 'past_due' และ grace_ends_at < now:

  • ถ้าเป็น trial → ส่งอีเมล "trial หมดเวลา" + ลบ server
  • ถ้าเป็น paid → ส่งอีเมล "บัตรเด้ง — server ถูกลบแล้ว" + ย้ายอีเมลลูกค้าจาก paid list ไป newsletter list + cancel sub บน Stripe + ลบ server + ลบ DNS

แล้วถ้าลูกค้าเปลี่ยนบัตรหรือ Stripe retry สำเร็จ Stripe จะยิง webhook invoice.paid มา — ระบบ clear past_due กลับเป็น active + ล้าง grace_ends_at ลูกค้าไม่ต้องมาแจ้งอะไรกับเรา server ก็ไม่ขึ้น flag อะไรให้เขาเห็น

คือสำหรับลูกค้าที่บัตรเด้งแล้วแก้ทันใน 24 ชม. — เขาไม่รู้ตัวด้วยซ้ำว่าระบบสะดุด

ทำไม "managed" ถึงคิดเรื่องนี้ได้

เรื่องนี้เป็นตัวอย่างชัดๆ ของสิ่งที่ การเช่า server กับการมี server ส่วนตัวต่างกันยังไง — และทำไมโมเดล managed ถึงให้ value ที่ self-host ทำเองยาก

ถ้าคุณ self-host AI Agent เอง พอบัตรเด้งกับ Anthropic, Hetzner, หรือ provider ไหนก็ตาม คุณต้องนั่งจัดการเองทุกที่ ไม่มีใครมา monitor ให้ ไม่มี grace period อัตโนมัติ ลูกค้าหลายคนของผมไม่ใช่ dev — เขาไม่อยากต้องมานั่งเช็คว่า server ตัวไหนค้างค่ารายเดือน

Newton คือ โมเดล managed ที่ทีมเรา monitor ให้ — ทีมเราเห็น webhook ก่อน ทีมเราส่งอีเมลแจ้งก่อน ทีมเราให้เวลาก่อน และถ้าจำเป็นจริงๆ ค่อยตัด server

เหมือนเช่าคอนโด ถ้าคุณค้างค่าเช่าวันเดียว เจ้าของคอนโดที่ดี ๆ จะไม่ฟ้องไล่คุณออกทันที เขาจะส่ง SMS ก่อน ถามก่อนว่าเป็นไรไหม ให้เวลาแก้ก่อน — Newton ก็เลยทำแบบนั้นกับ server ลูกค้า

เรื่องเล็กๆ ที่บอกเยอะ

เรื่อง grace period 24 ชั่วโมงนี่อาจดูเล็กมากเทียบกับฟีเจอร์อื่นของ Newton แต่ผมว่ามันเป็นเรื่องที่บอกเยอะมาก — มันบอกว่าเราคิดยังไงกับลูกค้า

SaaS ส่วนใหญ่ "เน้นรายได้" — บัตรเด้ง = ตัด access ให้เร็วที่สุด ไม่อย่างนั้นเสีย margin

Newton ผมอยากให้ "เน้นลูกค้า" — บัตรเด้ง = ให้เวลา 24 ชม. แก้ก่อน เสีย margin วันเดียวก็ไม่เป็นไร ดีกว่าทำให้ลูกค้าหัวเสีย

ที่เจ๋งคือ ผมไม่ต้องมานั่งเขียนโค้ดเอง ทิมคุยกับผมเรื่องสเปก แล้วลงมือทำหมดเองตั้งแต่ database migration, webhook handler, cron job, อีเมล template ภาษาไทย+อังกฤษ, Telegram noti, ไปจนถึง deploy บน production

ทั้งหมดใน session เดียว ไม่ถึงครึ่งวัน — และตอนที่ผมเขียนบล็อกนี้ ระบบนี้ก็ใช้งานจริงอยู่แล้วบน Newton ทั้ง ฝั่งไทย และฝั่ง global (อีก feature ที่ใช้แนวคิด state-driven แบบเดียวกันคือ การ sync ลิสต์ email Brevo ครับ)

ถ้าอยากมี AI ที่คิดถึง user experience แบบนี้ได้

ผมเขียนเรื่องนี้เพราะผมว่ามันเป็นตัวอย่างที่ดีของสิ่งที่ AI Agent ทำได้แต่ AI Chatbot ทำไม่ได้ — ChatGPT ตอบได้ว่า "grace period คืออะไร" แต่ AI Agent ของผมลงมือออกแบบ + เขียน + deploy ระบบ grace period จริงในธุรกิจจริง ของลูกค้าจริง

คำถามที่พบบ่อย

ถ้าบัตรเครดิตเด้ง SaaS จะตัด access ทันทีเลยไหม?

ส่วนใหญ่ SaaS ทั่วไปจะตัด access ค่อนข้างเร็วครับ เพราะเน้นปกป้อง margin บริการที่ดีกว่าจะมี grace period ให้ลูกค้าแก้บัตรก่อน เช่น 24-72 ชั่วโมง เพราะการที่บัตรเด้งหนึ่งครั้งไม่ได้แปลว่าลูกค้าตั้งใจเลิกใช้

ระบบ payment grace period ทำงานยังไง?

เมื่อบัตรเด้ง ระบบจะ set status เป็น past_due และบันทึกเวลาสิ้นสุด grace ไว้ใน DB จากนั้นส่งอีเมลแจ้งลูกค้าทันที server ยังรันต่อปกติ cron job เช็ครายชั่วโมง ถ้าลูกค้าแก้บัตรและ Stripe retry สำเร็จภายใน grace ก็กลับมา active โดยอัตโนมัติครับ

ทำไมถึงเลือก 24 ชั่วโมง ไม่ใช่ระยะเวลาอื่น?

24 ชั่วโมงสั้นพอที่จะไม่กระทบรายได้มาก แต่ยาวพอที่ลูกค้าจะตื่นนอน เช็ค email รู้ว่าบัตรมีปัญหา และจัดการแก้ได้ครับ บัตรหมดอายุ บัญชีไม่พอช่วงสิ้นเดือน หรือธนาคาร lock ชั่วคราว ส่วนใหญ่แก้ได้ใน 24 ชั่วโมง

ถ้า Stripe retry สำเร็จเอง ลูกค้าต้องทำอะไรไหม?

ไม่ต้องทำอะไรเลยครับ Stripe จะส่ง webhook กลับมาว่า invoice paid ระบบจะ clear สถานะกลับเป็น active อัตโนมัติ ลูกค้าไม่รู้ด้วยซ้ำว่าระบบสะดุดไป ทุกอย่างเหมือนเดิมโดยที่เขาไม่ต้องกดอะไร

ถ้าคุณเป็นเจ้าของธุรกิจที่อยากมี AI ส่วนตัวแบบนี้ — ที่ไม่ใช่แค่ตอบคำถาม แต่ลงมือสร้างระบบที่คิดถึงลูกค้าของคุณได้ ลอง Newton ได้ครับ เซิร์ฟเวอร์ส่วนตัว + AI Agent พร้อมใช้ใน 10 นาที แล้วทีมเราดูแลให้เอง รวมถึงสอน AI ของคุณให้พูดถูกโทน กับลูกค้าของคุณด้วย

และถ้าวันหนึ่งบัตรของคุณเองเด้ง — เราก็มี grace period 24 ชั่วโมงให้คุณเหมือนกันครับ 555

— ปอนด์