เพิ่ม wallet เข้า stack เดิม หรือย้ายแพลตฟอร์ม?

ถ้าแพลตฟอร์ม customer engagement ของคุณไม่มี wallet pass แบบ native คุณมี 2 ทาง ทางแรกคือเชื่อมเครื่องมือออกบัตรแยกแล้วคอยซิงก์ 2 ระบบให้ตรงกัน ทางที่สองคือย้ายไปแพลตฟอร์มที่ออกบัตร Apple Wallet และ Google Wallet บนโปรไฟล์ลูกค้าเดียวกัน ทางแรกเริ่มได้เร็วกว่า ทางที่สองดูแลง่ายกว่าเมื่อ wallet กลายเป็นส่วนหนึ่งของ journey แล้ว

บทความนี้เขียนให้ทีมที่ใช้แพลตฟอร์มอย่าง Braze, OneSignal หรือ CleverTap และอยากได้ wallet pass โดยไม่ต้องรื้อทุกอย่างทิ้ง ถ้าอยากดูภาพรวมระดับผู้ให้บริการ ดูได้ที่ หน้าเปรียบเทียบ Wallet passes ครับ

คุณเริ่มจากจุดไหน

การรองรับ wallet ต่างกันมากในแต่ละแพลตฟอร์ม engagement Braze เพิ่ม wallet ผ่านพาร์ตเนอร์อย่าง PassKit ส่วน OneSignal ไม่มี wallet pass แบบ native ก่อนวางแผน ให้ตรวจเอกสารปัจจุบันของแพลตฟอร์มที่คุณใช้ เพราะเรื่องนี้เปลี่ยนได้เสมอ

เมื่อไม่มีการรองรับแบบ native บัตรจะอยู่ในระบบหนึ่ง ส่วนลูกค้าอยู่อีกระบบหนึ่ง บัตรทุกใบที่คุณออก อัปเดต หรือใช้กำหนดกลุ่มเป้าหมาย ต้องดึงข้อมูลจากทั้งสองฝั่ง

สำหรับแบรนด์ไทย ภาพนี้มักซับซ้อนกว่านั้นอีกชั้น หลายทีมใช้ LINE Official Account เป็นช่องทางหลักคุยกับลูกค้าอยู่แล้ว เพราะคนไทยใช้ LINE มากกว่า 50 ล้านคน ถ้าเพิ่มเครื่องมือออกบัตรเข้าไปอีกตัว ข้อมูลลูกค้าจะกระจายอยู่ 3 ที่ คือแพลตฟอร์ม engagement, LINE OA และเครื่องมือ wallet

ทาง A: ใช้ CEP เดิม แล้วเพิ่มเครื่องมือออกบัตร

คุณใช้แพลตฟอร์มเดิมส่ง push, อีเมล และจัดการ segment ต่อไป แล้วเชื่อมเครื่องมือออกบัตรแยกสำหรับ Apple Wallet และ Google Wallet

ปกติจะทำงานแบบนี้ CEP หรือระบบหลังบ้านของคุณเรียก API ของเครื่องมือออกบัตรเพื่อออกบัตร ส่วนใหญ่ผ่าน webhook ถ้าเครื่องมือออกบัตรส่ง event ออกมาได้ event เหล่านั้นจะไหลกลับเข้า CEP ให้คุณแบ่งกลุ่มผู้ถือบัตรได้

ข้อดีมีจริง ไม่ต้องย้ายอะไรเลย ทีมใช้เครื่องมือและ journey เดิมต่อได้ และเริ่มจาก use case เดียวก่อนได้ เช่น บัตรสะสมแต้ม

ข้อเสียจะค่อย ๆ สะสม มี 2 ฐานข้อมูลที่ต้องซิงก์ ค่าบริการ 2 ราย และการตรวจด้านความปลอดภัยกับ GDPR 2 รอบ ทุกสถานการณ์ที่ต้องใช้การอัปเดตบัตรคู่กับข้อความ เช่น “แต้มของคุณใกล้หมดอายุแล้ว” ต้องสร้างข้ามเครื่องมือ 2 ตัว

ทาง B: ย้ายไปแพลตฟอร์มที่มี wallet แบบ native

คุณย้ายงานส่งข้อความไปยังแพลตฟอร์มที่ออก wallet pass ได้ในตัว บนโปรไฟล์เดียวกับ push, in-app, อีเมล และ SMS

บัตรถูกออกตาม User ID ภายในแพลตฟอร์ม ทั้ง segment, journey และทุกช่องทางมองผู้ถือบัตรเป็นลูกค้าคนเดียวกัน ขั้นตอนหนึ่งใน journey ออกบัตร และขั้นตอนถัดไปส่งลิงก์

คุณได้โปรไฟล์เดียว journey เดียว และสัญญาฉบับเดียว การอัปเดตบัตรกับข้อความมาจาก trigger เดียวกัน และไม่มีชั้นซิงก์ข้อมูลที่ต้องคอยเฝ้า

ต้นทุนคือการย้ายระบบเอง ได้แก่ การเปลี่ยน SDK การนำเข้าข้อมูล และการสร้าง journey กับเทมเพลตใหม่ การลงทุนนี้คุ้มเมื่อ wallet เป็นช่องทางระยะยาว ไม่ใช่แคมเปญครั้งเดียว

กรอบการตัดสินใจ

ให้คะแนนตัวเองจาก 4 คำถาม

ถ้าคำตอบของคุณตั้งแต่ 2 ข้อขึ้นไปคือ “ระยะยาว” “หลายสถานการณ์” “ไม่มีนักพัฒนา” หรือ “ลดผู้ประมวลผลข้อมูล” ให้พิจารณาทาง B อย่างจริงจัง ถ้าไม่มีเลย ทาง A ก็เป็นตัวเลือกที่ดีมาก และคุณกลับมาทบทวนได้ในอีก 1 ปี

ในตลาดไทย ข้อ “ช่องทาง” มักได้คะแนนสูงกว่าที่คิด แคมเปญตามฤดูกาลอย่างสงกรานต์ (13-15 เมษายน), 11.11 และ 12.12 ต้องใช้บัตรคู่กับ push และอีเมลในเวลาเดียวกัน และนี่คือช่วงที่การซิงก์ข้าม 2 เครื่องมือมักพลาดมากที่สุด

คำนวณต้นทุนของการใช้ 2 เครื่องมือ

ทาง A ดูถูกกว่าในวันแรก เพราะไม่มีอะไรต้องย้าย แต่ถ้ามองทั้งปี ให้บวกส่วนที่ไม่เคยโผล่ในใบแจ้งหนี้ของผู้ให้บริการบัตร ได้แก่ การสร้าง integration การดูแลการซิงก์ งาน journey ที่ทำซ้ำ และการประเมินผู้ให้บริการรายที่ 2

ทาง B จ่ายต้นทุนก้อนใหญ่ตอนต้น คืองานย้ายระบบ แล้วตามด้วยค่าแพลตฟอร์มเดียว ให้เปรียบเทียบทั้งสองทางในช่วง 12 ถึง 24 เดือน ไม่ใช่แค่เดือนเดียว

ถ้าคุณจ่ายค่าข้อความ LINE OA อยู่แล้ว ให้ใส่บรรทัดนั้นในการคำนวณด้วย ค่าใช้จ่ายต่อข้อความของ LINE OA ค่อนข้างสูง และ push notification ต้นทุนต่ำกว่า หลายทีมจึงใช้ push ส่งการเตือนที่เกี่ยวกับบัตร แล้วเก็บ LINE ไว้สำหรับบทสนทนาที่ต้องการช่องทางนั้นจริง ๆ ใช้ร่วมกันเพื่อเพิ่มช่องทาง ไม่ใช่ทดแทนกัน

เช็กลิสต์การย้ายระบบ

ถ้าคุณเลือกทาง B ให้วางแผนการย้ายโดยยึดลูกค้าเป็นหลัก ไม่ใช่เครื่องมือ

• ตรวจสิ่งที่คุณส่งอยู่ ทำรายการแคมเปญ push, อีเมล, SMS และ in-app รวมถึง journey และ segment ที่ต้องย้าย
• จับคู่ข้อมูล User ID, tag, event และบันทึกความยินยอม (consent) User ID คือสิ่งที่ผูกบัตรเข้ากับลูกค้า
• ตั้งค่า wallet ครั้งเดียว ใบรับรอง Apple Pass Type ID (บัญชี Apple Developer $99 ต่อปี) และ Google Issuer ID ที่เชิญ service account ของ Pushwoosh เข้า issuer ของคุณแล้ว
• ติดตั้ง SDK แทนที่ SDK เดิมในแอป และทดสอบ push ก่อนย้าย traffic
• สร้าง journey หลักใหม่ก่อน welcome, abandoned cart, win-back แล้วค่อยต่อด้วยสถานการณ์ wallet ใหม่
• วางแผนการเปิดตัวบัตร ออกบัตรจากขั้นตอนใน journey แล้วส่งลิงก์ทางอีเมล, SMS หรือ push
• รันคู่ขนานช่วงสั้น ๆ เปิดแพลตฟอร์มเดิมไว้ช่วงสั้น ๆ แล้วค่อยปิด

ระหว่างย้ายระบบ ให้ใช้ API ออกบัตรจากระบบหลังบ้านของคุณเอง

ข้อควรระวังสำหรับไทย คือ Android กับ iOS ใกล้เคียงกัน (ราว 60/40) ตอนทดสอบ SDK และการออกบัตร จึงต้องทดสอบทั้ง Apple Wallet และ Google Wallet ด้วยน้ำหนักเท่ากัน และอย่าเลือกช่วงก่อนสงกรานต์หรือ 11.11 เป็นช่วงรันคู่ขนาน

ทำให้ stack ของคุณเรียบง่ายขึ้นด้วย Pushwoosh

Pushwoosh ออกบัตร Apple Wallet และ Google Wallet แบบ native บน User ID, segment และ journey เดียวกับ push, in-app, อีเมล, SMS และ WhatsApp เป็นแพลตฟอร์มเดียว โฮสต์บนโครงสร้างพื้นฐานของตัวเองในเยอรมนีและสหรัฐอเมริกา สอดคล้องกับ GDPR และได้รับ SOC 2 Type 2 ดู ตำแหน่งของ Pushwoosh ในบรรดาตัวเลือก wallet

การเพิ่ม wallet ไม่ควรหมายถึงการต่อเครื่องมืออีกตัว แต่ควรหมายถึงโปรไฟล์ลูกค้าเดียวที่ทุกช่องทางใช้งานได้

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