LINE LIFF ในงานแต่งของผม เริ่มจากคำถามว่าแขกต้องทำอะไร
ผมไม่ได้เริ่มจากการเลือก LINE API, LIFF หรือ Mini App ตอนออกแบบระบบสำหรับงานแต่งของตัวเอง
ผมเริ่มจากคำถามที่ง่ายกว่านั้นมาก
ถ้าผมเป็นแขกที่ได้รับการเชิญมางานแต่ง ผมต้องทำอะไรบ้าง ตั้งแต่วันที่ได้รับการ์ดเชิญ วันที่ต้องยืนยันว่าจะมาหรือไม่ วันที่เดินทางมาถึงงาน ไปจนถึงช่วงที่งานจบแล้ว
และในแต่ละช่วง มีอะไรที่ทำให้แขกรู้สึกว่ายุ่งยาก สับสน หรือต้องเดินไปถามทีมงานโดยไม่จำเป็นหรือเปล่า
คำถามนี้เปลี่ยนวิธีที่ผมมองการใช้เทคโนโลยีในการทำงานไปพอสมควร
เพราะถ้าเราเริ่มต้นด้วยคำถามว่าอยากใช้ API ตัวไหน เราก็มีแนวโน้มจะออกแบบระบบตามความสามารถของเครื่องมือ แต่ถ้าเริ่มจาก Customer Journey เราจะเห็นว่าปัญหาของลูกค้าไม่ได้เกิดขึ้นเฉพาะตอนซื้อสินค้า และไม่ได้จบลงทันทีที่ธุรกรรมเสร็จสิ้น
สำหรับผม นี่คือความแตกต่างระหว่างการเอาเทคโนโลยีมาใช้ กับการออกแบบระบบที่ทำให้ประสบการณ์ของลูกค้าดีขึ้นจริง
บทความนี้จะพาไปดูวิธีคิดจากกรณีงานแต่งของผม ตั้งแต่การทำความเข้าใจ Journey การแยก Pain Point การเลือกเทคโนโลยี หน้าจอจริงของระบบเช็กอินที่ทำงานบน LINE LIFF ไปจนถึงการนำหลักคิดเดียวกันไปประยุกต์ใช้กับธุรกิจ Retail, Banking, Insurance และธุรกิจบริการอื่น ๆ
1. ทำไมผมถึงเอางานแต่งมาคิดแบบ Marketing Systems Designer
เวลาพูดถึง Digital Transformation หลายคนมักเริ่มจากสิ่งที่องค์กรอยากมี เช่น Chatbot, CRM, Application, Marketing Automation หรือระบบเก็บข้อมูลลูกค้า
ผมไม่ได้คิดว่าสิ่งเหล่านี้ผิด แต่ผมคิดว่ามีคำถามหนึ่งที่ควรถามก่อนเสมอ
เรากำลังสร้างเทคโนโลยีเพื่อแก้ปัญหาอะไรในประสบการณ์ของลูกค้า?
งานแต่งเป็นกรณีศึกษาที่ดีสำหรับการตั้งคำถามนี้ เพราะแม้จะเป็นงานที่เกิดขึ้นเพียงช่วงเวลาหนึ่ง แต่ประสบการณ์ของแขกกลับมีหลายช่วงต่อเนื่องกัน
ก่อนวันงาน แขกต้องรับรู้ข้อมูลและตอบรับคำเชิญ
เมื่อใกล้ถึงวันงาน แขกอาจต้องตรวจสอบรายละเอียดและเตรียมตัวเดินทาง
เมื่อมาถึงสถานที่ แขกต้องรู้ว่าจะเช็กอินตรงไหน นั่งโต๊ะไหน และต้องทำอะไรต่อ
ระหว่างงาน อาจมีกิจกรรมที่ต้องการให้แขกมีส่วนร่วม
หลังงานจบ ความสัมพันธ์ระหว่างเจ้าภาพกับแขกก็ยังดำเนินต่อไปได้ ไม่ว่าจะเป็นการขอบคุณ การแบ่งปันภาพถ่าย หรือการติดต่อกันในโอกาสถัดไป
ลองสังเกตว่าแต่ละช่วงมีเป้าหมายไม่เหมือนกันเลย
ช่วงก่อนงานคือการช่วยให้แขกตัดสินใจและเตรียมตัวได้ง่ายขึ้น
ช่วงหน้างานคือการลดความสับสนและทำให้ทุกอย่างดำเนินไปอย่างราบรื่น
ช่วงหลังงานคือการรักษาความรู้สึกดี ๆ ที่เกิดขึ้นระหว่างกัน
ถ้าเรามองทั้งหมดเป็นเพียงงานอีเวนต์หนึ่งวัน เราอาจสนใจแค่การจัดสถานที่ อาหาร และกำหนดการ แต่ถ้ามองเป็น Customer Journey เราจะเริ่มเห็นโอกาสในการออกแบบประสบการณ์ตั้งแต่ต้นจนจบ
ผมมองว่านี่เป็นจุดเริ่มต้นของการทำงานแบบ Marketing Systems Designer คือไม่ได้มองเฉพาะเครื่องมือหรือช่องทางสื่อสาร แต่พิจารณาว่าแต่ละองค์ประกอบควรทำหน้าที่อะไร เพื่อให้ประสบการณ์โดยรวมมีความต่อเนื่องกัน
และที่สำคัญ วิธีคิดแบบนี้ไม่ได้จำกัดอยู่แค่การจัดงานแต่ง
ธุรกิจที่มีลูกค้าเดินทางผ่านหลายขั้นตอน ไม่ว่าจะเป็นการสมัครสมาชิก การจองบริการ การซื้อสินค้า การใช้บริการ หรือการกลับมาซื้อซ้ำ ล้วนมีโจทย์ลักษณะเดียวกัน
2. เริ่มจาก Customer Journey ก่อนเลือก LINE API
ผมอยากให้ลองนึกถึงประสบการณ์ของแขกที่มางานแต่งสักคนหนึ่ง
เขาได้รับคำเชิญ แต่ยังไม่แน่ใจว่าจะมาได้หรือไม่
หลังจากตัดสินใจว่าจะมา เขาต้องยืนยันการเข้าร่วม
เมื่อถึงวันงาน เขาเดินทางมาถึงสถานที่ แต่ยังต้องหาว่าตัวเองอยู่โต๊ะไหน
ระหว่างงาน เขาอาจได้รับเชิญให้ร่วมกิจกรรม
หลังจากกลับบ้าน เขาอาจอยากดูภาพถ่ายจากงาน หรือได้รับข้อความขอบคุณจากเจ้าภาพ
ทั้งหมดนี้เป็นคนคนเดียวกัน แต่สิ่งที่เขาต้องการในแต่ละช่วงต่างกัน
ถ้าเราออกแบบระบบโดยไม่แยก Journey เราอาจสร้างหน้าจอหรือช่องทางเดียว แล้วพยายามยัดทุกอย่างเข้าไปในนั้น แต่ถ้าเราแยก Journey ก่อน เราจะเห็นว่าบางช่วงต้องการการสื่อสาร บางช่วงต้องการการลงมือทำ และบางช่วงต้องการเหตุผลให้คนกลับมามีปฏิสัมพันธ์อีกครั้ง (ถ้ายังไม่คุ้นกับการทำ Journey ผมสรุปพื้นฐานไว้ในบทความ Customer Journey คืออะไร)
ผมสรุปวิธีคิดนี้เป็นสามคำได้ว่า
Talk → Do → Stay
Talk คือช่วงที่เราสื่อสารเพื่อให้ลูกค้ารู้ เข้าใจ หรือสนใจ
Do คือช่วงที่ลูกค้าต้องลงมือทำบางอย่าง เช่น ยืนยันข้อมูล ลงทะเบียน เช็กอิน จอง หรือซื้อสินค้า
Stay คือช่วงที่เราสร้างเหตุผลให้ลูกค้ายังคงมีความสัมพันธ์กับแบรนด์ และกลับมาใช้งานอีกเมื่อมีความต้องการ
นี่ไม่ใช่ Funnel มาตรฐานที่ทุกธุรกิจต้องใช้ตามลำดับตายตัว แต่เป็นกรอบช่วยคิดว่าในแต่ละช่วง เราต้องออกแบบประสบการณ์แบบไหน
ตัวอย่างเช่น การส่งข้อความเตือนให้ลูกค้ามาทำรายการให้เสร็จ เป็นโจทย์ด้าน Talk แต่การทำหน้าจอให้ลูกค้ากดดำเนินการได้ทันทีเป็นโจทย์ด้าน Do ส่วนการออกแบบสิทธิประโยชน์หรือบริการที่ทำให้ลูกค้ากลับมาใช้งานในอนาคตเป็นโจทย์ด้าน Stay
ถ้าเราทำ Talk ได้ดี แต่ Do ยุ่งยาก ลูกค้าก็อาจไม่ทำสิ่งที่เราต้องการ
ถ้าเราทำ Do ได้ดี แต่ไม่มีเหตุผลให้กลับมา ความสัมพันธ์ก็อาจจบลงหลังธุรกรรมแรก
และถ้าเราสร้างระบบ Stay โดยไม่ได้ทำให้ประสบการณ์พื้นฐานดีขึ้น เราก็อาจกำลังพยายามรักษาลูกค้าไว้ทั้งที่ยังแก้ปัญหาที่เกิดขึ้นระหว่างทางไม่สำเร็จ
นี่คือเหตุผลที่ผมอยากเริ่มจาก Journey ก่อนเทคโนโลยี
3. เปลี่ยน Journey ให้เป็น Pain Point ที่แก้ได้จริง
เมื่อเราเห็น Journey แล้ว ขั้นต่อไปไม่ใช่การรีบสร้างระบบ แต่เป็นการระบุว่าลูกค้าต้องเจอปัญหาอะไรในแต่ละช่วง
สำหรับกรณีงานแต่ง เราสามารถแยกโจทย์ออกมาได้ดังนี้
| ช่วงของ Journey | สิ่งที่แขกต้องทำ | Pain Point ที่ควรตรวจสอบ | เป้าหมายการออกแบบ |
|---|---|---|---|
| ก่อนงาน | ตอบรับคำเชิญ | ข้อมูลกระจัดกระจาย หรือยืนยันไม่สะดวก | ทำให้ตอบรับได้ง่าย |
| ก่อนเดินทาง | ตรวจสอบรายละเอียดงาน | ต้องค้นหาข้อมูลเดิมซ้ำ | เข้าถึงข้อมูลที่จำเป็นได้สะดวก |
| เมื่อมาถึงงาน | เช็กอิน | ไม่รู้ว่าต้องเริ่มตรงไหน หรือเกิดคิว | ลดขั้นตอนและความสับสน |
| ระหว่างอยู่ในงาน | หาที่นั่ง | ต้องถามทีมงานหรือค้นหาป้าย | ช่วยให้หาข้อมูลของตัวเองได้เร็ว |
| ระหว่างงาน | เข้าร่วมกิจกรรม | ไม่รู้ว่าจะร่วมอย่างไร หรือขั้นตอนมากเกินไป | ลดแรงเสียดทานในการมีส่วนร่วม |
| หลังงาน | รับข่าวสารหรือภาพถ่าย | การติดต่อสิ้นสุดทันทีหลังงาน | เปิดโอกาสให้ความสัมพันธ์ดำเนินต่อ |
ตารางนี้เป็นการวิเคราะห์ Pain Point ที่ควรใช้ตั้งต้น ไม่ใช่การยืนยันว่าทุกปัญหาเกิดขึ้นกับแขกทุกคนจริงในงานของผม
ความแตกต่างนี้สำคัญ เพราะถ้าเราไม่แยกข้อเท็จจริงออกจากสมมติฐาน เราอาจสร้างระบบแก้ปัญหาที่ไม่มีใครมีปัญหานั้นจริง ๆ (เรื่องการแยก Pain Point ที่สำคัญจริงออกจากปัญหาที่เราคิดไปเอง ผมเขียนแยกไว้อีกบทความ)
ตัวอย่างเช่น การทำระบบค้นหาโต๊ะอาจดูมีประโยชน์ แต่ก่อนลงทุนพัฒนา เราควรตรวจสอบก่อนว่าแขกสับสนเรื่องที่นั่งมากน้อยแค่ไหน ข้อมูลที่ใช้ค้นหามีความพร้อมหรือไม่ และวิธีเดิมสร้างภาระให้แขกหรือทีมงานมากเพียงใด
เมื่อเข้าใจปัญหาชัดขึ้น เราจึงค่อยตัดสินใจว่าควรแก้ด้วยการปรับการสื่อสาร การปรับขั้นตอน การใช้ระบบดิจิทัล หรือการเปลี่ยนวิธีทำงานของทีม
บางปัญหาไม่จำเป็นต้องใช้เทคโนโลยีเลยก็ได้
ถ้าปัญหาเกิดจากป้ายบอกทางไม่ชัด การปรับป้ายอาจมีประสิทธิภาพกว่าการสร้างแอปพลิเคชันใหม่
ถ้าปัญหาเกิดจากข้อมูลที่ทีมงานไม่ตรงกัน การจัดการข้อมูลและกระบวนการทำงานอาจสำคัญกว่าการเพิ่มช่องทางสื่อสาร
แต่ถ้าปัญหาเกิดจากการต้องค้นหาข้อมูลเฉพาะบุคคลจำนวนมาก การออกแบบระบบให้ลูกค้าเข้าถึงข้อมูลของตัวเองได้โดยตรงก็อาจเป็นทางเลือกที่เหมาะสม
สิ่งที่ผมต้องการคือให้เทคโนโลยีเข้ามาแก้ Pain Point ที่ชัดเจน ไม่ใช่สร้าง Pain Point ใหม่เพื่อให้เทคโนโลยีที่เราเลือกดูมีความจำเป็น
4. เมื่อรู้ปัญหาแล้ว ค่อยเลือกเครื่องมือให้ตรงหน้าที่
เมื่อโจทย์ชัดขึ้น เราจึงเริ่มพิจารณาว่าเทคโนโลยีแต่ละประเภทช่วยแก้ปัญหาส่วนไหนได้บ้าง
ในระบบที่ทำงานร่วมกับ LINE มีองค์ประกอบที่เกี่ยวข้องหลายประเภท ได้แก่ LINE Official Account, LINE Messaging API, LIFF และ LINE MINI App
สิ่งสำคัญคือองค์ประกอบเหล่านี้ไม่ได้ทำหน้าที่เหมือนกันทั้งหมด และไม่ควรถูกเลือกเพียงเพราะเป็นเครื่องมือที่กำลังได้รับความนิยม (ถ้าอยากเห็นความต่างของแต่ละตัวแบบละเอียด อ่านต่อได้ที่ LINE API เลือกใช้อย่างไรให้เหมาะกับ Campaign)
4.1 LINE Official Account: ช่องทางที่ลูกค้ารู้จักและเข้าถึงได้
LINE Official Account หรือ LINE OA เป็นช่องทางสื่อสารที่ธุรกิจใช้ติดต่อกับผู้ใช้ผ่าน LINE
ในบริบทของงานแต่ง ช่องทางลักษณะนี้สามารถใช้สื่อสารรายละเอียด แจ้งข้อมูลที่จำเป็น หรือพาแขกไปยังหน้าสำหรับดำเนินการบางอย่างได้
แต่การมี LINE OA ไม่ได้แปลว่าประสบการณ์ทั้งหมดจะถูกออกแบบเรียบร้อยแล้ว
เรายังต้องตอบให้ได้ว่า ข้อความแต่ละชิ้นควรส่งเมื่อไร ใครควรได้รับข้อความนั้น และเมื่อผู้ใช้กดเข้าไปแล้ว เขาควรทำอะไรต่อ
ถ้าส่งข้อความครบทุกอย่างแต่ปลายทางยังยุ่งยาก เราก็แก้ได้เพียงส่วนหนึ่งของ Journey เท่านั้น
4.2 LINE Messaging API: เมื่อการสื่อสารต้องเชื่อมกับระบบ
ตามเอกสารของ LINE Developers, LINE Messaging API ช่วยให้ระบบหรือ Bot Server ส่งและรับข้อมูลผ่าน LINE Platform รวมถึงตอบกลับหรือส่งข้อความให้ผู้ใช้ตามรูปแบบที่ API รองรับได้
สิ่งที่ทำให้ API มีความสำคัญในเชิงระบบ ไม่ใช่เพียงความสามารถในการส่งข้อความ แต่เป็นการเปิดทางให้การสื่อสารเชื่อมโยงกับข้อมูลและกระบวนการทำงานของบริการได้
ตัวอย่างเชิงแนวคิดคือ หากแขกยืนยันเข้าร่วมงานแล้ว ระบบอาจใช้ข้อมูลนั้นประกอบการสื่อสารในขั้นต่อไป หรือหลังจากแขกดำเนินการบางอย่างสำเร็จ ระบบอาจแจ้งข้อมูลที่เกี่ยวข้องกับสถานะของรายการนั้น
อย่างไรก็ตาม การทำงานเหล่านี้ต้องมีการออกแบบระบบหลังบ้าน การจัดการข้อมูล และการกำหนดเงื่อนไขที่เหมาะสม ไม่ได้เกิดขึ้นโดยอัตโนมัติเพียงเพราะเปิดใช้ API
ในธุรกิจจริง หลักการเดียวกันนี้สามารถใช้กับการยืนยันการจอง การแจ้งสถานะคำสั่งซื้อ การแจ้งเตือนลูกค้า หรือการติดตามขั้นตอนการใช้บริการ
4.3 LIFF: เมื่อผู้ใช้ต้องทำงานบนหน้าจอที่ออกแบบเอง
LIFF หรือ LINE Front-end Framework เป็นแพลตฟอร์มสำหรับเว็บแอปพลิเคชันที่ทำงานร่วมกับ LINE Platform โดยแอปสามารถใช้ความสามารถของ LIFF เพื่อเข้าถึงข้อมูลที่ได้รับอนุญาต และสร้างประสบการณ์การใช้งานตามโจทย์ของบริการได้
ถ้า Messaging API ช่วยเรื่องการสื่อสาร LIFF ก็เกี่ยวข้องกับประสบการณ์บนหน้าจอที่ผู้ใช้เข้าไปดำเนินการ
ในบริบทของงานแต่ง เราอาจใช้แนวคิดนี้ในการออกแบบหน้าตอบรับคำเชิญ หน้าสำหรับกรอกข้อมูล หรือหน้าที่ให้แขกตรวจสอบรายละเอียดที่เกี่ยวข้องกับตัวเอง ทั้งนี้ต้องพัฒนาฟังก์ชันและระบบข้อมูลให้รองรับจริง
ข้อดีของการคิดจาก Journey คือเราไม่จำเป็นต้องถามก่อนว่าจะใช้ LIFF หรือไม่ แต่ถามว่าขั้นตอนที่ผู้ใช้ต้องทำจำเป็นต้องมีหน้าจอเฉพาะหรือเปล่า
ถ้าเป็นเพียงการรับข้อมูลสั้น ๆ และช่องทางเดิมทำได้ดีอยู่แล้ว การเพิ่มหน้าจอใหม่อาจไม่คุ้มค่า
แต่ถ้าผู้ใช้ต้องกรอกข้อมูลหลายรายการ ตรวจสอบสถานะ หรือทำธุรกรรมที่มีเงื่อนไข หน้าจอที่ออกแบบเฉพาะอาจช่วยให้ประสบการณ์ชัดเจนขึ้น
4.4 LINE MINI App: เมื่อบริการต้องมีประสบการณ์ที่ครบขึ้น
LINE MINI App เป็นเว็บแอปพลิเคชันที่ให้ผู้ใช้เข้าถึงบริการผ่าน LINE ได้โดยไม่จำเป็นต้องติดตั้ง Native App แยกต่างหาก
ตัวอย่างประเภทบริการที่เหมาะกับแนวคิดนี้ ได้แก่ การจอง การจัดการสมาชิก หรือการใช้บริการที่มีหลายขั้นตอน
อย่างไรก็ตาม ไม่ใช่ทุกงานที่ต้องใช้ LINE MINI App และไม่ใช่ว่าทุกฟังก์ชันจะเกิดขึ้นได้เพียงแค่เลือกแพลตฟอร์มนี้ การพัฒนาจริงยังขึ้นอยู่กับข้อกำหนดของบริการ การเชื่อมต่อข้อมูล และเงื่อนไขของ LINE Platform
สำหรับผม การเลือกระหว่าง LIFF, LINE MINI App และวิธีอื่นจึงควรพิจารณาจากความต้องการของบริการ ข้อกำหนดทางเทคนิค และประสบการณ์ที่ต้องการให้ลูกค้าได้รับ (ถ้ามี LIFF อยู่แล้วและกำลังชั่งใจเรื่องการย้าย ดูเมื่อไหร่ควรย้ายจาก LIFF ไป LINE MINI App)
รายละเอียดด้านสถานะการให้บริการ การตรวจสอบหรือรับรองแอป และความสามารถที่ใช้งานได้ควรตรวจสอบจากเอกสารทางการในช่วงเวลาที่พัฒนาเสมอ
4.5 เครื่องมือแต่ละตัวไม่จำเป็นต้องถูกใช้ทุกตัว
ถ้าเราวางเครื่องมือก่อน Journey เราอาจเริ่มจากการพยายามหาหน้าที่ให้ทุกเทคโนโลยีที่มีอยู่
แต่ถ้าเราเริ่มจาก Journey เราจะมีอิสระที่จะเลือกเฉพาะองค์ประกอบที่จำเป็น
| ความต้องการ | สิ่งที่ควรพิจารณา |
|---|---|
| สื่อสารข้อมูลทั่วไป | LINE OA และรูปแบบข้อความที่เหมาะสม |
| ส่งหรือรับข้อมูลผ่านระบบ | LINE Messaging API |
| ให้ผู้ใช้กรอกข้อมูลหรือทำรายการบนเว็บ | LIFF หรือเว็บแอปที่เหมาะสม |
| สร้างบริการหลายขั้นตอนภายใน LINE | พิจารณา LINE MINI App ตามความเหมาะสม |
| ลดความสับสนจากกระบวนการเดิม | อาจเริ่มจากการปรับ Workflow โดยไม่ต้องเพิ่มเทคโนโลยี |
ตารางนี้เป็นแนวทางเบื้องต้นสำหรับการเลือกองค์ประกอบ ไม่ใช่การจับคู่แบบตายตัว เพราะเครื่องมือบางประเภททำงานร่วมกันได้ และรายละเอียดของแต่ละระบบอาจแตกต่างกันตามข้อกำหนดทางเทคนิค
สิ่งที่ผมอยากเน้นคือ เทคโนโลยีเป็นองค์ประกอบของระบบ ไม่ใช่เป้าหมายสุดท้ายของการออกแบบ
5. หน้าจอจริงของระบบเช็กอินงานแต่งบน LINE LIFF
ทั้งหมดข้างบนคือวิธีคิด ส่วนนี้คือสิ่งที่ระบบในงานแต่งของผมทำได้จริง ดูจากหน้าเช็กอินที่แขกเปิดผ่าน LINE ในวันงาน
ภาพหน้าจอเหล่านี้มาจากระบบจริงในโหมดทดสอบ ชื่อแขกและเลขโต๊ะในภาพเป็นข้อมูลตัวอย่าง
1. เช็กอินด้วยบัญชี LINE ของแขกเอง หน้าเช็กอินเป็นเว็บแอปที่ทำงานบน LIFF เมื่อแขกเปิดลิงก์ใน LINE ระบบจะขอเข้าสู่ระบบด้วย LINE แล้วนำบัญชีนั้นไปหาคำตอบ RSVP ที่แขกเคยส่งไว้ ถ้าเจอ ระบบจะเช็กอินให้ทันที แล้วแสดงชื่อ โต๊ะ และจำนวนแขกที่มาด้วย แขกไม่ต้องพิมพ์ชื่อ และไม่ต้องรอทีมงานเปิดรายชื่อหา
2. หาที่นั่งได้เองจากการ์ดโต๊ะ เมื่อกดการ์ดโต๊ะ ระบบจะเปิดแผนผังที่นั่งที่อัปโหลดไว้ในระบบหลังบ้าน พร้อมบอกว่าโต๊ะของแขกคนนั้นคือโต๊ะไหน นี่คือการแก้ Pain Point เรื่อง “ต้องถามทีมงานหรือค้นหาป้าย” ในตารางข้อ 3 ด้วยการให้แขกเข้าถึงข้อมูลของตัวเองโดยตรง
3. ไม่มีชื่อใน RSVP ก็ไม่ติด แขกที่ไม่ได้ตอบรับล่วงหน้าจะเห็นช่องให้ใส่ชื่อเล่นเพื่อเช็กอินด้วยตัวเอง แล้วแจ้งทีมงานเรื่องโต๊ะ ส่วนทีมงานยังเช็กอินแขกแบบ manual จากหน้า Admin ได้ ระบบจึงไม่ได้บังคับให้ทุกคนต้องเดินตามเส้นทางเดียว
หลังเช็กอินเสร็จ หน้าจอเดียวกันจะพาแขกไปต่อได้อีกหลายทาง ได้แก่ แก้ไขโปรไฟล์ Dating Zone สำหรับแขกที่เปิดสถานะโสด การโอนเงินของขวัญผ่าน QR พร้อมแจ้งสลิปให้ทีมงานยืนยัน และกิจกรรมระหว่างงานอย่างเกม Wedding Run กับการชิงโชค
เกม Wedding Run แขกบังคับตัวละครเดินไปตามทางในงาน เก็บหัวใจเพื่อเพิ่มคะแนน และระวังชน BM เพราะชนแล้วจะถูกหักคะแนน เลือกได้ทั้งโหมด Normal และ Hard ที่ได้คะแนนคูณ 1.8 เล่นได้หลายครั้ง และคะแนนสูงสุดของแต่ละคนจะขึ้น Leaderboard
ถูบัตรชิงโชค ก่อนเริ่ม หน้านี้จะขึ้นว่าเกมยังไม่เริ่มและให้รอประกาศจากพิธีกร เมื่อเปิดเกมจากระบบหลังบ้าน บัตรจะขึ้นบนมือถือของแขก ให้ถูเพื่อดูผลว่าเป็นผู้โชคดีหรือไม่
Dating Zone แขกที่ติ๊ก “ฉันโสด” ในหน้าโปรไฟล์จะปัดการ์ดของแขกโสดคนอื่นได้ ถ้าถูกใจกันทั้งคู่ ระบบจะขึ้น It’s a Match และเก็บไว้ในหน้า Matches เมื่อ Match กันแล้ว หน้า Matches จะแสดงรูปและ Instagram ของอีกฝ่าย แขกที่ไม่ได้เปิดสถานะโสดจะเข้าส่วนนี้ไม่ได้ โปรไฟล์ AN-AN ในภาพใช้โดยได้รับอนุญาตจากเจ้าของ
ถ้ามองด้วยกรอบ Talk → Do → Stay การเช็กอิน การหาที่นั่ง และการแจ้งสลิปคือส่วน Do ที่ต้องทำให้จบเร็ว ส่วน Dating Zone และกิจกรรมระหว่างงานคือการให้เหตุผลแขกอยู่กับระบบต่อหลังจากทำสิ่งที่จำเป็นเสร็จแล้ว
ระบบนี้ทำงานบน LIFF ทั้งหมด ไม่ได้ทำเป็น LINE MINI App ซึ่งสอดคล้องกับหลักในข้อ 4.4 ว่าไม่ใช่ทุกงานต้องใช้ MINI App
สิ่งที่ผมแสดงในส่วนนี้คือความสามารถของระบบ ไม่ใช่ตัวเลขว่ามีแขกใช้งานกี่คน หรือช่วยลดเวลาหน้างานได้เท่าไร เพราะผมไม่มีข้อมูลที่ตรวจสอบได้ในเรื่องนั้น
6. ออกแบบ Flow ให้ประสบการณ์ต่อเนื่อง ไม่ใช่แค่ทำแต่ละฟังก์ชันให้เสร็จ
หลังจากกำหนด Journey และเลือกแนวทางเทคโนโลยีแล้ว ขั้นต่อไปคือการเชื่อมแต่ละกิจกรรมให้กลายเป็น Flow ที่ทำงานต่อเนื่องกัน
ลองพิจารณา Flow เชิงแนวคิดของงานแต่ง
ขั้นที่ 1: แขกได้รับคำเชิญ
แขกได้รับข้อมูลที่จำเป็นและรู้ว่าต้องดำเนินการอย่างไรต่อ
ขั้นที่ 2: แขกตอบรับ
ระบบรับข้อมูลการตอบรับ และนำข้อมูลไปใช้ในการเตรียมงานตามกระบวนการที่กำหนดไว้
ขั้นที่ 3: แขกเตรียมตัวมาร่วมงาน
ข้อมูลที่จำเป็น เช่น รายละเอียดสถานที่และกำหนดการ ควรเข้าถึงได้สะดวกโดยไม่ต้องให้แขกค้นหาข้อมูลจากหลายแหล่ง
ขั้นที่ 4: แขกมาถึงสถานที่
ระบบหรือกระบวนการหน้างานควรช่วยให้แขกเข้าใจว่าต้องเริ่มตรงไหน และลดความสับสนที่ไม่จำเป็น
ขั้นที่ 5: แขกมีส่วนร่วมในงาน
หากมีกิจกรรมดิจิทัล ระบบควรช่วยให้แขกเข้าร่วมได้ง่าย และไม่เพิ่มขั้นตอนที่ขัดจังหวะประสบการณ์หลักของงาน
ขั้นที่ 6: งานจบ แต่ความสัมพันธ์ไม่จำเป็นต้องจบ
การขอบคุณ การแบ่งปันภาพถ่าย หรือการติดต่อในโอกาสที่เหมาะสมสามารถเป็นส่วนหนึ่งของประสบการณ์หลังงานได้
สิ่งที่น่าสนใจคือแต่ละขั้นไม่ได้ทำหน้าที่แยกขาดจากกัน
ข้อมูลจากการตอบรับอาจเกี่ยวข้องกับการเตรียมงาน ข้อมูลที่จัดเตรียมไว้ล่วงหน้าอาจช่วยให้ขั้นตอนหน้างานชัดเจนขึ้น และประสบการณ์หลังงานอาจต่อยอดความสัมพันธ์ที่เกิดขึ้นก่อนหน้านั้น
ระบบเช็กอินในข้อ 5 เป็นตัวอย่างของเรื่องนี้ แขกเช็กอินได้ทันทีก็เพราะคำตอบ RSVP ในขั้นที่ 2 ถูกผูกไว้กับบัญชี LINE ของแขกตั้งแต่แรก
นี่คือเหตุผลที่ผมให้ความสำคัญกับ Flow มากกว่าการนับจำนวนฟังก์ชัน
ระบบหนึ่งอาจมีฟังก์ชันมากมาย แต่ถ้าผู้ใช้ต้องเริ่มใหม่ทุกครั้ง ต้องกรอกข้อมูลเดิมซ้ำ หรือไม่รู้ว่าขั้นตอนถัดไปคืออะไร ประสบการณ์โดยรวมก็อาจยังไม่ดี
ในทางกลับกัน ระบบที่มีฟังก์ชันไม่มาก แต่เชื่อมข้อมูลและขั้นตอนสำคัญได้ดี อาจสร้างประสบการณ์ที่ราบรื่นกว่า
สำหรับธุรกิจที่กำลังวางแผนพัฒนาระบบ ผมแนะนำให้ทำ Customer Journey Map และ Service Blueprint ควบคู่กัน โดยแยกให้ชัดว่าลูกค้าทำอะไร สิ่งที่ลูกค้าเห็นคืออะไร ทีมงานต้องทำอะไร และระบบหลังบ้านต้องรองรับข้อมูลหรือเงื่อนไขใด
วิธีนี้ช่วยให้ทีมการตลาด ทีมปฏิบัติการ และทีมเทคโนโลยีคุยกันบนโจทย์เดียวกันได้มากขึ้น
7. ถอดจากงานแต่งไปสู่ธุรกิจ: หลักคิดเดียวกันใช้ได้อย่างไร
ผมไม่คิดว่าธุรกิจอื่นควรนำ Flow ของงานแต่งไปใช้ตามตรง เพราะแต่ละอุตสาหกรรมมีข้อจำกัด ความเสี่ยง และพฤติกรรมของลูกค้าที่ต่างกัน
สิ่งที่สามารถนำไปใช้ต่อได้คือวิธีตั้งคำถามและวิธีออกแบบระบบจาก Journey
Retail / E-Commerce: ลูกค้าซื้อแล้วหายไป
ในธุรกิจค้าปลีก ปัญหาอาจไม่ได้อยู่ที่การหาลูกค้าใหม่เพียงอย่างเดียว แต่รวมถึงการทำให้ลูกค้ากลับมาซื้อซ้ำด้วย
หากลูกค้าซื้อสินค้าแล้ว ธุรกิจควรพิจารณาว่าข้อมูลใดจำเป็นต่อการให้บริการหลังการขาย และมีช่วงเวลาใดที่ลูกค้าอาจต้องการข้อมูลเพิ่มเติม
ตัวอย่างเช่น การแจ้งสถานะคำสั่งซื้อ การให้ข้อมูลการใช้งาน หรือการสื่อสารข้อเสนอที่สัมพันธ์กับความต้องการจริง
แต่การส่งข้อความถี่ขึ้นไม่ได้แปลว่าลูกค้าจะกลับมาซื้อซ้ำมากขึ้นเสมอไป ธุรกิจต้องตรวจสอบว่าข้อความช่วยให้ลูกค้าได้รับประโยชน์หรือทำให้เกิดการรบกวน
กรอบ Talk → Do → Stay ช่วยแยกได้ว่าเรากำลังแก้ปัญหาการรับรู้ การทำธุรกรรม หรือการรักษาความสัมพันธ์
Banking: ลูกค้าต้องผ่านหลายขั้นตอนเพื่อใช้บริการ
ในธุรกิจธนาคาร ลูกค้าอาจต้องค้นหาข้อมูล เปรียบเทียบบริการ ตรวจสอบคุณสมบัติ และดำเนินการตามขั้นตอนที่กำหนด
โจทย์จึงไม่ใช่เพียงการส่งข้อความให้ลูกค้ารู้ว่ามีบริการ แต่เป็นการช่วยให้ลูกค้าเข้าใจขั้นตอนและดำเนินการได้ถูกต้อง
หากมีขั้นตอนที่ลูกค้ามักหยุดกลางทาง ธุรกิจควรตรวจสอบว่าปัญหาเกิดจากข้อมูลไม่ชัด ขั้นตอนซับซ้อน หรือข้อกำหนดที่ลูกค้ายังไม่เข้าใจ
สำหรับบริการทางการเงิน การออกแบบยังต้องคำนึงถึงความปลอดภัย การยืนยันตัวตน ความเป็นส่วนตัว และข้อกำหนดของบริการด้วย ไม่ควรลดขั้นตอนจนทำให้การควบคุมความเสี่ยงเสียไป
Insurance: ความสัมพันธ์ไม่ได้เกิดเฉพาะวันที่ซื้อกรมธรรม์
ธุรกิจประกันภัยมี Journey ที่ยาวกว่าธุรกรรมแรก ลูกค้าอาจต้องทำความเข้าใจความคุ้มครอง ติดต่อสอบถามเมื่อเกิดเหตุ ยื่นเคลม และต่ออายุกรมธรรม์
แต่ละช่วงมีความต้องการข้อมูลไม่เหมือนกัน
ในช่วงก่อนซื้อ ลูกค้าต้องการความเข้าใจและความมั่นใจ
ในช่วงใช้บริการ ลูกค้าต้องการข้อมูลที่ถูกต้องและการดำเนินการที่ชัดเจน
ในช่วงต่ออายุ ลูกค้าต้องการเข้าใจเงื่อนไขและตัดสินใจได้อย่างเหมาะสม
หากองค์กรออกแบบการสื่อสารโดยคำนึงถึง Journey ก็มีโอกาสช่วยลดความสับสนและทำให้ลูกค้าเข้าถึงข้อมูลที่เกี่ยวข้องได้ดีขึ้น ทั้งนี้ผลลัพธ์จริงต้องวัดจากข้อมูลการให้บริการ ไม่ใช่สรุปจากการมีระบบเพียงอย่างเดียว
ธุรกิจบริการ: อย่าหยุดออกแบบที่วันที่ลูกค้าจ่ายเงิน
หลักคิดนี้ยังใช้ได้กับธุรกิจบริการที่มีการจอง การนัดหมาย หรือการให้บริการต่อเนื่อง
ตัวอย่างเช่น คลินิกที่ต้องนัดหมายและแจ้งเตือนลูกค้า สถาบันการศึกษาที่มีขั้นตอนสมัครและติดตามการเรียน หรือธุรกิจที่ต้องให้ลูกค้ากลับมาใช้บริการตามรอบ
คำถามสำคัญไม่ใช่ว่าจะเพิ่มข้อความหรือระบบอัตโนมัติตรงไหน แต่คือช่วงใดที่ลูกค้าต้องการความช่วยเหลือ และเราจะทำให้การดำเนินการขั้นถัดไปง่ายขึ้นอย่างไร
ทั้งหมดนี้เป็นการนำหลักคิดจากกรณีงานแต่งไปประยุกต์ใช้ ไม่ใช่หลักฐานว่าการใช้เทคโนโลยี LINE จะเพิ่มยอดขายหรืออัตราการกลับมาใช้บริการได้โดยอัตโนมัติ
8. สิ่งที่นักการตลาดควรวัด หลังจากออกแบบระบบแล้ว
เมื่อเราออกแบบระบบจาก Customer Journey แล้ว การวัดผลก็ต้องสะท้อนเป้าหมายของแต่ละช่วงด้วย
ถ้าเราต้องการให้ลูกค้าตอบรับคำเชิญได้ง่ายขึ้น เราควรวัดการตอบรับและเวลาที่ใช้ในขั้นตอนนั้น
ถ้าเราต้องการลดความสับสนหน้างาน เราควรตรวจสอบจำนวนคำถามที่ทีมงานต้องตอบ เวลาที่ใช้ดำเนินการ และปัญหาที่เกิดขึ้นจริง
ถ้าเราต้องการให้ลูกค้ากลับมาใช้บริการ เราต้องวัดพฤติกรรมการกลับมาใช้บริการในช่วงเวลาที่เหมาะสม ไม่ใช่ใช้จำนวนข้อความที่ส่งเป็นตัวแทนของความสำเร็จ
ตัวอย่าง KPI ที่สามารถพิจารณาได้มีดังนี้
| เป้าหมาย | ตัวชี้วัดที่ควรพิจารณา |
|---|---|
| ทำให้การตอบรับง่ายขึ้น | อัตราการตอบรับ และอัตราการทำรายการสำเร็จ |
| ลดความยุ่งยากในการทำรายการ | อัตราการทำรายการสำเร็จ เวลาที่ใช้ และอัตราการหลุดออกจากขั้นตอน |
| ลดภาระทีมงาน | จำนวนคำถามซ้ำและเวลาที่ใช้ให้บริการ |
| ทำให้ลูกค้ากลับมาใช้บริการ | Repeat Rate หรืออัตราการกลับมาใช้บริการ |
| พัฒนาความสัมพันธ์ระยะยาว | พฤติกรรมการกลับมาใช้บริการและตัวชี้วัดความพึงพอใจที่เหมาะสม |
ตัวชี้วัดเหล่านี้เป็นข้อเสนอสำหรับการออกแบบการวัดผล ไม่ใช่ผลลัพธ์ที่เกิดขึ้นแล้วจากงานแต่งของผม
อีกเรื่องที่ผมคิดว่านักการตลาดควรระวังคือ การวัดผลของระบบจากจำนวนข้อความที่ส่งหรือจำนวนคนที่เปิดใช้งานเพียงอย่างเดียว
ตัวเลขเหล่านี้ช่วยบอกได้ว่าระบบทำงานบางส่วนหรือไม่ แต่ยังไม่ตอบว่าประสบการณ์ของลูกค้าดีขึ้นหรือเปล่า
หากเราต้องการพิสูจน์ว่าระบบใหม่ช่วยลดความยุ่งยากจริง เราควรกำหนดวิธีวัดก่อนเริ่มใช้งาน เก็บข้อมูลก่อนและหลังการเปลี่ยนแปลง และควบคุมปัจจัยอื่นที่อาจมีผลต่อผลลัพธ์
ในกรณีที่เป็นไปได้ การทดสอบกับกลุ่มผู้ใช้หรือเปรียบเทียบกระบวนการเดิมกับกระบวนการใหม่จะช่วยให้เข้าใจผลของการเปลี่ยนแปลงได้ดีขึ้น
สำหรับงานแต่งของผม ผมจะไม่อ้างว่า Repeat Rate, Conversion Rate หรือความพึงพอใจเพิ่มขึ้น หากไม่มีข้อมูลที่ตรวจสอบได้รองรับ
สิ่งที่ผมนำเสนอในบทความนี้คือแนวทางคิดและแนวทางออกแบบระบบ ไม่ใช่รายงานผลลัพธ์เชิงตัวเลขของโครงการ
9. บทเรียนสำคัญ: Marketing ไม่ควรจบที่การสื่อสาร
เมื่อมองย้อนกลับไป สิ่งที่ผมสนใจจากกรณีงานแต่งไม่ใช่เพียงว่าเราสามารถนำเทคโนโลยีอะไรมาประกอบกันได้บ้าง
แต่เป็นการเปลี่ยนจุดเริ่มต้นของการทำงาน
แทนที่จะเริ่มจากคำถามว่าเราจะใช้เครื่องมืออะไร เราเริ่มจากการทำความเข้าใจว่าลูกค้าต้องทำอะไร เจอปัญหาตรงไหน และต้องการความช่วยเหลือแบบใดในแต่ละช่วง
จากนั้นจึงออกแบบกระบวนการ เลือกเทคโนโลยี และกำหนดตัวชี้วัดที่สัมพันธ์กับเป้าหมาย
ถ้าจะสรุปวิธีคิดนี้ให้เป็นลำดับ ผมจะใช้ 5 ขั้นตอน
- Map the Journey — ทำความเข้าใจเส้นทางของลูกค้าตั้งแต่ต้นจนจบ
- Identify the Friction — ระบุขั้นตอนที่สร้างความยุ่งยากหรือทำให้ลูกค้าไม่สามารถเดินหน้าต่อได้
- Design the Experience — กำหนดว่าประสบการณ์ที่ดีขึ้นควรมีหน้าตาอย่างไร
- Select the Technology — เลือกเทคโนโลยีตามความจำเป็นของประสบการณ์และข้อกำหนดของระบบ
- Measure the Outcome — วัดว่าการเปลี่ยนแปลงช่วยแก้ปัญหาที่ตั้งไว้จริงหรือไม่
ลำดับนี้เป็นหลักคิดที่ผมสังเคราะห์จากการออกแบบประสบการณ์และการวางระบบ ไม่ใช่ Framework มาตรฐานที่ผ่านการรับรองผลในทุกอุตสาหกรรม
สิ่งที่ต้องระวังคืออย่าปล่อยให้ขั้นตอนเลือกเทคโนโลยีกลายเป็นจุดเริ่มต้นโดยปริยาย เพราะเมื่อทีมตัดสินใจเลือกเครื่องมือไปแล้ว การตั้งคำถามใหม่ว่าจำเป็นต้องใช้เครื่องมือนั้นหรือไม่จะทำได้ยากขึ้น
ผมคิดว่านี่เป็นเรื่องที่นักการตลาดและทีมเทคโนโลยีควรคุยกันให้ชัดตั้งแต่ต้น
นักการตลาดไม่จำเป็นต้องเป็นคนเขียนโค้ดทุกคน แต่ควรอธิบายได้ว่าลูกค้าต้องทำอะไร ระบบควรช่วยตรงไหน และความสำเร็จหน้าตาเป็นอย่างไร
ในทางกลับกัน ทีมเทคโนโลยีก็ไม่ควรได้รับเพียงรายการฟังก์ชัน แต่ควรเข้าใจว่าฟังก์ชันเหล่านั้นกำลังแก้ปัญหาอะไรในประสบการณ์ของลูกค้า
เมื่อทั้งสองทีมเข้าใจโจทย์เดียวกัน การเลือกเทคโนโลยีจะมีเหตุผลมากขึ้น และโอกาสที่ระบบจะถูกสร้างขึ้นมาแล้วไม่มีคนใช้ก็อาจลดลงได้
10. สรุป: อย่าเริ่มจาก API ถ้ายังไม่รู้ว่าลูกค้าต้องเดินทางอย่างไร
การออกแบบระบบสำหรับงานแต่งทำให้ผมกลับมาตั้งคำถามกับวิธีคิดที่พบได้บ่อยในการทำ Digital Project
เรามักเริ่มจากสิ่งที่เทคโนโลยีทำได้ แล้วค่อยหาวิธีนำไปใช้กับธุรกิจ
แต่ผมอยากให้ลองกลับลำดับใหม่
เริ่มจากลูกค้า ทำความเข้าใจ Journey ระบุ Pain Point ออกแบบประสบการณ์ แล้วจึงเลือกเทคโนโลยีที่เหมาะสม
หากต้องใช้ LINE API ก็เลือกตามหน้าที่ที่ระบบต้องการ หากต้องมีหน้าจอสำหรับให้ลูกค้าดำเนินการ ก็พิจารณา LIFF หรือ LINE MINI App ตามความเหมาะสม และหากปัญหาแก้ได้ด้วยการปรับกระบวนการโดยไม่ต้องสร้างระบบใหม่ นั่นก็เป็นทางเลือกที่ควรพิจารณาเช่นกัน
ผมไม่ได้มองว่าเทคโนโลยีเป็นสิ่งสำคัญน้อยลง แต่คิดว่าเทคโนโลยีจะมีคุณค่ามากขึ้นเมื่อเรารู้ว่ากำลังใช้มันเพื่อแก้ปัญหาอะไร
สำหรับผม นี่คือหัวใจของการคิดแบบ Marketing Systems Designer
ไม่ใช่การรู้จักเครื่องมือให้มากที่สุด แต่เป็นการออกแบบให้ทุกเครื่องมือและทุกขั้นตอนทำงานร่วมกัน เพื่อให้ลูกค้าได้รับประสบการณ์ที่ดีขึ้นตั้งแต่เริ่มต้นจนจบ
และบางครั้ง การเริ่มจากคำถามง่าย ๆ ว่า “ลูกค้าต้องทำอะไรต่อ?” ก็มีประโยชน์กว่าการเริ่มจากคำถามว่า “เราจะใช้ API ตัวไหนดี?”
ถ้าทีมของคุณมีงานอีเวนต์ ระบบสมาชิก หรือบริการที่ลูกค้าต้องลงทะเบียนและทำรายการผ่าน LINE ทีม Spark Factor ช่วยวาง Journey และออกแบบระบบ LINE API ตั้งแต่ Messaging API, LIFF ไปจนถึง MINI App ได้ ทักมาคุยโจทย์ของทีมคุณได้
References
Primary
Supporting
หมายเหตุด้านหลักฐาน: บทความนี้อธิบายหลักคิดและตัวอย่างการประยุกต์ใช้จากกรณีงานแต่ง โดยไม่ได้อ้างตัวเลขผลลัพธ์ของโครงการที่ยังไม่มีข้อมูลยืนยัน ภาพหน้าจอในข้อ 5 มาจากระบบจริง โดยหน้าเช็กอินใช้โหมดทดสอบ และโปรไฟล์ที่ปรากฏในหน้า Dating Zone ใช้โดยได้รับอนุญาตจากเจ้าของ การนำ LINE Messaging API, LIFF หรือ LINE MINI App ไปใช้จริงต้องตรวจสอบข้อกำหนดทางเทคนิคและความสามารถที่เปิดให้ใช้ ณ วันที่พัฒนาอีกครั้ง
