รายสัปดาห์ ส.ค. 2025 – ส.ค. 2026 · เฉพาะข้อมูลจริงจาก DB

ทำไมยอดไม่พอ — คำตอบจากเส้นแนวโน้ม 12 เดือน

หน้านี้สร้างขึ้นเพื่อตัดสิน 2 สมมติฐานที่ทีมถกกัน: (H1) "เรารั้งคนไม่เก่ง แต่ใครอยู่แล้วอยู่เลย" และ (H2) "ระบบฝากรองรับไม่พอ"

คำตัดสิน

H1 จริง — และเป็นจุดแข็ง ไม่ใช่จุดอ่อน

เดือนแรกเหลือ ~31% (รั้งไม่เก่ง = จริง) แต่หลังเดือน 3 เส้น retention แบนสนิท คนที่รอดอยู่เป็นปี ระบบจึงเป็น "ratchet": คลื่นคนใหม่แต่ละรอบยกฐานลูกค้าประจำขึ้นถาวร — ยอดสัปดาห์โตเท่าตัวใน 1 ปี (~30M → ~65–75M) ด้วยกลไกนี้

H2 แบบ "รับโหลดไม่ไหว" — ไม่จริง

อัตรา reject รายชั่วโมงแบน ~10–12% ทั้งวัน และชั่วโมงพีค 19:00 (โหลดหนักสุด x2) reject แค่ 10.8% ต่ำกว่าค่าเฉลี่ย — ถ้าระบบรองรับไม่พอ ตัวเลขต้องพุ่งตอนพีค แต่มันไม่พุ่ง

H2 แบบ "friction" — จริงกว่าที่เคยรายงาน

เมื่อนับด้วย created_at (แถว reject ส่วนใหญ่ไม่มี transaction_time ทำให้ตัวเลขเดิมต่ำเกินจริง): 8 สัปดาห์ล่าสุด 11.6% ของความพยายามฝากถูก reject — SLIP 70.7%, GATEWAY 14.8%, PROMPTPAY 10.1%, SMS 2.2% — เป็นเงินที่หล่นระหว่างทางจริง แต่ไม่ใช่ตัวอธิบายหลักว่าทำไมยอดโตช้า

ตัวการจริง: เครื่องยนต์คนใหม่แผ่ว

ยอดโตทุกครั้งที่มีคลื่นคนใหม่ (ก.ย.–ต.ค. 2025 และ เม.ย.–พ.ค. 2026) — ตั้งแต่ มิ.ย. คนใหม่เหลือ 2.3–5k/สัปดาห์ จากพีค 8–10k ยอดวันนี้ยืนด้วยฐานคนเก่า ถ้าไม่มีคลื่นถัดไป การโตจะแบน — งบและแรงควรไปที่การหาคนใหม่ + activation ก่อน friction

ยอดฝากรายสัปดาห์ (ล้านบาท)

เส้นทึบ = ยอดรวม · พื้นที่ล่าง = เงินจากคนที่เพิ่งฝากครั้งแรกสัปดาห์นั้น (สังเกตว่าเป็นสัดส่วนเล็กมาก — ยอดยืนด้วยคนเก่า)

คนฝากรายสัปดาห์: ทั้งหมด vs หน้าใหม่

เห็นคลื่นหาลูกค้า 2 รอบชัดเจน และการแผ่วตัวหลัง มิ.ย. 2026

อัตรา reject รายชั่วโมง (90 วัน) — ทดสอบ capacity

ถ้าระบบรองรับไม่พอ อัตราต้องพุ่งช่วงพีค — ความจริง: แบนทั้งวัน ยกเว้นหลังเที่ยงคืนที่พุ่ง 20–26% (น่าจะเกี่ยวรอบ limit รายวัน/หน้าต่างธนาคาร ควรไล่ต่อ)

อัตรา reject จริงต่อช่องทาง (8 สัปดาห์ล่าสุด นับด้วย created_at)

ช่องทาง	สำเร็จ	reject	อัตรา reject	หมายเหตุ
SMS	966,183	21,453	2.2%	เสถียรสุด
PROMPTPAY	236,226	26,606	10.1%
GATEWAY	412,155	71,861	14.8%	สูงกว่าที่ตาราง 90 วันเดิมรายงาน (0.2%) มาก — ตัวเดิมนับเฉพาะแถวที่มี transaction_time
SLIP	40,973	98,729	70.7%	รวมการอัปซ้ำ/retry — ผู้ใช้พยายามหลายครั้งกว่าจะผ่าน

แก้ความเข้าใจจากหน้า "ช่องทาง & Whale": ตารางในหน้านั้นกรองด้วย transaction_time ซึ่งแถว reject ส่วนใหญ่ไม่มีค่า อัตรา reject จึงต่ำกว่าจริงมาก — ใช้ตัวเลขหน้านี้เป็นหลัก
QR ที่สร้างแล้วถูกทิ้งค้าง (pending เกินอายุ) = 0 ทุกสัปดาห์ — ระบบเคลียร์สถานะได้ครบ ไม่มีรายการจม
โอกาสถัดไป: ประเมิน "เงินที่กู้คืนได้" จากการลด reject (ต้อง query ยอดเงินของแถว reject เพิ่ม) และไล่สาเหตุ reject พุ่งช่วง 00:00–01:00