ถ้าจะเปรียบเทียบแพลตฟอร์ม wallet pass ให้เริ่มจากการแบ่งเป็น 3 กลุ่ม คือเครื่องมือออกบัตรแบบแยก (standalone) แพลตฟอร์มสะสมแต้มที่มี wallet ในตัว และแพลตฟอร์ม customer engagement ที่ออกบัตรแบบ native ได้ ถ้าบัตรคือทั้งโปรแกรม เครื่องมือแบบแยกก็เพียงพอ แต่เมื่อบัตรต้องทำงานร่วมกับ push, อีเมล, segment และ journey แพลตฟอร์มที่ถือโปรไฟล์ลูกค้าอยู่แล้วมักเป็นผู้ชนะ
ก่อนอื่นต้องเคลียร์เรื่องชื่อ Apple PassKit คือ framework ของ Apple สำหรับบัตรใน Wallet และผู้ให้บริการบัตรทุกรายสร้างบนนั้น ส่วน PassKit Inc. คือบริษัทที่ขายแพลตฟอร์มออกบัตร เวลาคนค้นหา “ทางเลือกแทน PassKit” หมายถึงบริษัท และบทความนี้เปรียบเทียบในมุมนั้น พร้อมบอกว่า Wallet passes ของ Pushwoosh อยู่ตรงไหน สำหรับแบรนด์ไทยที่ใช้ LINE Official Account อยู่แล้ว คำถามสำคัญจึงเป็นว่าบัตรจะอยู่บนโปรไฟล์ลูกค้าเดียวกับช่องทางที่ใช้อยู่ได้หรือไม่ครับ
เครื่องมือ wallet pass 3 กลุ่ม
เครื่องมือออกบัตรแบบแยก PassKit, Passcreator, PassSlot และ Pass2U เน้นที่ตัวบัตร PassKit มี builder แบบไม่ต้องเขียนโค้ดคู่กับ API สำหรับ Apple Wallet และ Google Wallet ส่วน PassSlot เป็น builder เฉพาะทางสำหรับ Apple Wallet ใช้กับค้าปลีกและอีเวนต์เป็นหลัก และ Pass2U เป็น builder แบบไม่ต้องเขียนโค้ดสำหรับทั้ง 2 แพลตฟอร์มที่เจาะกลุ่มธุรกิจขนาดเล็ก ในไทยที่ผู้ใช้ Android ราว 60% และ iOS ราว 40% เครื่องมือที่รองรับแค่ Apple จะเข้าไม่ถึงลูกค้ากว่าครึ่ง
แพลตฟอร์มสะสมแต้มที่มี wallet ผู้ให้บริการด้าน loyalty อย่าง Antavo และ Yotpo ดูแลตรรกะของโปรแกรม (แต้ม ระดับสมาชิก ของรางวัล) และเสนอ wallet เป็นอีก 1 วิธีแสดงบัตร
แพลตฟอร์ม engagement ที่มี wallet แบบ native แพลตฟอร์ม customer engagement อย่าง Pushwoosh และ Airship ออกบัตรได้เองบนโปรไฟล์เดียวกับ push, in-app, อีเมล และ SMS แพลตฟอร์ม engagement อื่นเพิ่ม wallet ผ่านพาร์ตเนอร์ ตัวอย่างเช่น Braze ทำงานร่วมกับผู้ให้บริการบัตรอย่าง PassKit
ตารางเปรียบเทียบ
| เกณฑ์ | เครื่องมือออกบัตรแบบแยก | แพลตฟอร์มสะสมแต้มที่มี wallet | CEP ที่มี wallet ผ่านพาร์ตเนอร์ | CEP ที่มี wallet แบบ native |
|---|---|---|---|---|
| บัตร Apple และ Google | Native บางเครื่องมือรองรับแค่ Apple | แตกต่างกันไป | ผ่านเครื่องมือของพาร์ตเนอร์ | Native |
| Visual builder | มี | แตกต่างกันไป | อยู่ในเครื่องมือของพาร์ตเนอร์ | มี |
| API | แตกต่างกันไป | มี | 2 API | มี |
| อัปเดตแบบเรียลไทม์ | มี | มี | มี ผ่านการซิงก์ | มี |
| Segment จากข้อมูลลูกค้า | จำกัดอยู่ที่ข้อมูลบัตร | ข้อมูล loyalty | ผ่านการซิงก์ | โปรไฟล์เดียวกัน |
| Journey ข้ามช่องทาง | ไม่มี | จำกัด | 2 เครื่องมือ | 1 journey |
| Push, อีเมล, SMS ในเครื่องมือเดียว | ไม่มี | แตกต่างกันไป | มี แต่ wallet แยก | มี |
อ่านตารางตามแถว ไม่ใช่ตามคอลัมน์ แถวที่สำคัญที่สุดสำหรับทีม retention คือ segment, journey และช่องทาง นั่นคือจุดที่แต่ละกลุ่มต่างกันจริง ส่วนเรื่องการออกบัตร ทุกกลุ่มใกล้เคียงกัน
เครื่องมือแบบแยกคิดราคาอย่างไร
ราคาเปลี่ยนได้เสมอ ก่อนตัดสินใจให้ตรวจหน้าราคาปัจจุบันของแต่ละรายและจดวันที่ที่ตรวจไว้ และถามให้ชัดว่าผู้ให้บริการนับจากบัตรที่ออก หรือบัตรที่ยังอยู่บนโทรศัพท์ (active) โปรแกรมเดียวกันอาจมีค่าใช้จ่ายต่างกันมากภายใต้ 2 รูปแบบนี้ หลักเดียวกับที่แบรนด์ไทยใช้ประเมินต้นทุนต่อข้อความของ LINE Official Account
รูปแบบราคาทั้งหมดและต้นทุนแฝง ดูได้ในคู่มือเรื่องราคา
เมื่อไรที่เครื่องมือแบบแยกเพียงพอ
เครื่องมือออกบัตรแบบแยกเหมาะเมื่อ wallet คือตัวโปรแกรม ไม่ใช่ 1 ช่องทางในโปรแกรม กรณีทั่วไป:
- ผู้จัดงานคอนเสิร์ตหรืออีเวนต์ที่ออกบัตรเข้างาน โดยไม่มีแอปและไม่มีการส่งข้อความต่อเนื่อง
- ธุรกิจขนาดเล็ก เช่น ร้านกาแฟที่ทำบัตรสะสมแสตมป์โดยไม่มี CRM อื่น
- แคมเปญครั้งเดียว: คูปอง บัตรผู้เข้าร่วมงานสัมมนา หรือบัตรตามฤดูกาลช่วงสงกรานต์
ในกรณีนี้ designer และ API ของผู้ให้บริการก็ทำงานได้ครบ การเพิ่มแพลตฟอร์ม engagement เต็มรูปแบบจะเป็นเครื่องมือที่เกินความจำเป็น และเราก็จะบอกแบบนี้กับทุกคนที่ถาม
เมื่อไรที่คุณต้องใช้แพลตฟอร์ม engagement
ภาพจะเปลี่ยนเมื่อบัตรต้องตอบสนองต่อข้อมูลลูกค้าและทำงานร่วมกับช่องทางอื่น คุณโตเกินเครื่องมือแบบแยกแล้วเมื่อ:
- คุณต้องการออกบัตรจาก event ในแอปหรือเว็บไซต์ เช่น การสมัครสมาชิกหรือคำสั่งซื้อแรก
- คุณแบ่งกลุ่มผู้ถือบัตรตามพฤติกรรมที่อยู่ใน CDP หรือแพลตฟอร์ม engagement ของคุณ
- ช่วงเวลาเดียว เช่น แต้มที่ใกล้หมดอายุ ต้องมีทั้งการอัปเดตบัตร push และอีเมล
- คุณกำลังซิงก์ 2 ฐานข้อมูลและสร้าง journey เดียวกัน 2 รอบ
ถึงจุดนี้คำถามจะกลายเป็นว่าจะเชื่อมเครื่องมือออกบัตรเข้ากับแพลตฟอร์มปัจจุบัน หรือย้ายไปแพลตฟอร์มที่มี wallet แบบ native
Pushwoosh อยู่ตรงไหน
Pushwoosh คือแพลตฟอร์ม customer engagement หลายช่องทางที่ออกบัตร Apple Wallet และ Google Wallet แบบ native โดยไม่มีพาร์ตเนอร์คั่นกลาง บัตรออกตาม User ID และอยู่ใน CDP, segment และ Customer Journey เดียวกับ push, in-app, อีเมล, SMS และ WhatsApp ใน journey มีขั้นตอน Issue Wallet Pass โดยเฉพาะ ร้านค้าปลีก โรงแรม หรือแอปธนาคารจึงออกบัตรจากเหตุการณ์เดียวกับที่ใช้ส่ง push ได้
คุณได้ visual builder สำหรับทั้ง 2 แพลตฟอร์ม REST API และการอัปเดตแบบเรียลไทม์ บน Apple การอัปเดตจะเงียบ เว้นแต่ฟิลด์จะมี change message ซึ่งลูกค้าจะเห็นการแจ้งเตือนบนหน้าจอล็อก บน Google การเปลี่ยนแปลงจะซิงก์ไปยังทุกเครื่องที่บันทึกบัตรไว้ ข้อมูลโฮสต์บนโครงสร้างพื้นฐานของ Pushwoosh เองในเยอรมนีและสหรัฐอเมริกา สอดคล้องกับ GDPR และได้รับการรับรอง SOC 2 Type 2
พูดให้ชัดเรื่องข้อจำกัด: Pushwoosh ไม่มีบัตรแบบ NFC เช่น บัตรแตะขึ้นรถสาธารณะหรือคีย์การ์ดห้องโรงแรม และไม่ว่าแพลตฟอร์มไหน Apple และ Google อนุญาตเฉพาะการแจ้งเตือนที่เกี่ยวกับบัตรเท่านั้น
ลดจำนวนเครื่องมือด้วย Pushwoosh
ถ้า wallet เป็น 1 ช่องทางในโปรแกรม retention ที่ใหญ่กว่า Pushwoosh วางมันไว้ข้าง push, in-app, อีเมล, SMS และ WhatsApp บนโปรไฟล์ลูกค้าเดียว 1 builder, 1 API และ 1 journey สำหรับทุกช่องทาง
แพลตฟอร์ม wallet ที่ใช่ไม่ใช่แพลตฟอร์มที่มีเทมเพลตบัตรมากที่สุด แต่เป็นแพลตฟอร์มที่อยู่ใกล้ข้อมูลลูกค้าของคุณที่สุด
