เลือก PMS โรงแรม อย่าดูแค่ฟีเจอร์ ให้ดูว่าดึงข้อมูลออกมาได้แค่ไหน

เจ้าของโรงแรมเลือก PMS จากสองอย่างเกือบทุกครั้ง คือตารางเปรียบเทียบฟีเจอร์ กับราคาต่อเดือน

สามปีต่อมา คำถามที่เข้ามาคือแขกจากช่องทางไหนพักยาวกว่ากัน คืนไหนของสัปดาห์ที่ราคาเฉลี่ยตกผิดปกติ ห้องประเภทไหนขายได้ก่อนเสมอ แล้วคำตอบคือดึงไม่ได้ ระบบมีข้อมูลครบทุกอย่าง แต่เอาออกมาใช้ในรูปที่ต้องการไม่ได้

เกณฑ์ที่กำหนดเรื่องนี้ไม่เคยอยู่ในโบรชัวร์

คำถามที่แทบไม่มีใครถามตอนเลือก คือเอาข้อมูลออกมาได้แค่ไหน

PMS ทุกตัวเก็บข้อมูลละเอียดใกล้เคียงกัน แต่ให้เอาออกไม่เหมือนกันเลย และมีสามระดับ

ระดับแรก ให้เฉพาะรายงานที่ออกแบบรูปมาไว้แล้ว ต้องการมุมอื่นก็ต้องนั่งคีย์ใหม่จากไฟล์ PDF ระดับที่สอง เปิดให้ดึงข้อมูลดิบเป็นไฟล์ตารางตามช่วงเวลาที่เลือกเองได้ ระดับที่สาม ต่อเข้าระบบอื่นได้อัตโนมัติผ่าน API ซึ่งเป็นระดับเดียวที่ทำแดชบอร์ดที่อัปเดตเองได้จริง

วิธีทดสอบก่อนเซ็นใช้เวลาห้านาที ขอให้เขาดึงข้อมูลย้อนหลังหนึ่งเดือนออกมาเป็นไฟล์ตารางให้ดูตรงหน้า ถ้าทำได้ทันทีคือผ่าน ถ้าตอบว่าต้องเป็นรายงานรูปแบบนี้เท่านั้น ให้รู้ไว้ว่าอีกสามปีจะเจออะไร

เหตุผลที่ข้อนี้สำคัญไม่ใช่เรื่องความสะดวก แต่เพราะการทำ revenue management ต้องอ่านข้อมูลย้อนหลังของโรงแรมคุณเองให้ออกก่อน ถ้าดึงย้อนหลังไม่ได้ การตั้งราคาก็เหลือแค่การเดาให้ดูดี และการตั้งราคาถูกเกินไปเป็นความผิดพลาดที่ไม่มีสัญญาณเตือน และเมื่อรายได้ส่วนใหญ่มาจาก OTAs หลายเจ้าที่มีเงื่อนไขต่างกัน สิ่งที่ต้องดูคือข้อมูลระดับรายการจอง ไม่ใช่ยอดรวมรายเดือน เพราะราคาที่ตั้งในเอ็กซ์ทราเน็ตไม่ใช่ราคาที่ได้รับจริงและแต่ละช่องทางต่างกัน

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

ตัวแปรไม่ใช่จำนวนห้อง แต่คือจำนวนคนที่แตะระบบพร้อมกัน

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

แต่เส้นนี้เป็นแค่ตัวประมาณ ที่พัก 45 ห้องที่มีสามกะและมีแม่บ้านห้าคนเปลี่ยนโจทย์แล้ว ขณะที่ 60 ห้องที่เจ้าของคุมคนเดียวยังไม่เปลี่ยน สิ่งที่กำหนดจริงคือมีคนหลายคนทำงานบนระบบเดียวกันพร้อมกันหรือยัง

พอถึงจุดนั้น สิ่งที่ต้องมีคือโมดูลแม่บ้านที่อัปเดตสถานะห้องจากมือถือได้ ระบบปิดยอดสิ้นวันที่รัดกุมพอสำหรับส่งงานข้ามกะ การแยกสิทธิ์ผู้ใช้ที่ตรวจย้อนได้ว่าใครแก้อะไรเมื่อไหร่ การรองรับกรุ๊ปและ allotment และการเชื่อม POS ของห้องอาหารหรือมินิบาร์เข้าโฟลิโอห้องโดยตรง

ระบบที่ออกแบบมาสำหรับที่พักไม่กี่ห้องมีเพดานใช้งานจริง ไม่ใช่เพราะจำนวนห้องที่ใส่ได้ แต่เพราะเวิร์กโฟลว์ไม่ได้ออกแบบให้หลายคนทำงานคู่ขนาน

ถามให้ชัดว่าเอกสารภาษีทำจบในระบบได้ไหม

ข้อนี้ต้องถามเป็นคำถาม ไม่ใช่เชื่อตามชื่อผู้พัฒนา คำถามคือระบบออกใบกำกับภาษีเต็มรูปได้จากในระบบเลยหรือไม่ และให้เขาแสดงตัวอย่างที่ออกจริง

ถ้าออกได้แต่ใบเสร็จหรือ invoice ตามมาตรฐานสากล โรงแรมต้องไปทำเอกสารภาษีนอกระบบอีกรอบ กลายเป็นงานซ้ำทุกเดือนและเป็นจุดที่ผิดพลาดง่ายที่สุดตอนปิดงบ ถ้าลูกค้าองค์กรหรือบริษัททัวร์เป็นสัดส่วนสำคัญของรายได้ ข้อนี้มีน้ำหนักมากกว่าฟีเจอร์หน้าบ้านทุกอย่างรวมกัน

ต้นทุนที่ต้องเทียบคือห้าปี ไม่ใช่ต่อเดือน

ราคาต่อห้องต่อเดือนฟังดูเล็กเสมอตอนดูใบเสนอราคา แต่คูณจำนวนห้องแล้วคูณหกสิบเดือน จะได้ตัวเลขที่เทียบกับการซื้อขาดได้จริง และต้องบวกค่าติดตั้ง ค่าอบรมพนักงาน ค่าเชื่อม POS ค่าย้ายข้อมูลเข้าระบบใหม่ รวมถึงค่าเชื่อม OTAs ถ้าไม่ได้มาในตัว

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

อีกข้อที่ควรทำก่อนเซ็นคือโทรทดสอบซัพพอร์ตตอนสองทุ่มวันเสาร์ เพราะระบบล่มไม่เคยเลือกเวลาทำการ และคืนที่โรงแรมเต็มคือคืนที่ระบบทำงานหนักที่สุด

สรุปให้เหลือประโยคเดียว

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