ConnectWiz Booking
สมุดนัดหมายที่มีฐานข้อมูลเป็นกระดูกสันหลัง
ไม่ว่าจะจองโดยเจ้าหน้าที่ AI โฟลว์ หรือลูกค้าเอง ทุกนัดหมายไปลงในบัญชีเดียวกัน ที่ห้อง อุปกรณ์ และผู้ให้บริการตัดกันอย่างถูกต้อง การจองซ้อนถูกกันตั้งแต่ชั้นจัดเก็บข้อมูล และปฏิทินจริงของคุณซิงก์ได้ทั้งสองทาง
สี่ประตู
ทุกคนจองจากความจริงชุดเดียวกัน
ทีมงาน ในสมุดนัด
สมุดนัดมุมมองรายวันและการจัดการการจองเต็มรูปแบบ — ประเภท สถานที่ ผู้ให้บริการ รูปแบบย่อยของบริการ ป้ายสถานะที่แต่ละ tenant กำหนดเอง การจัดการเคสไม่มาตามนัด และรายการย่อย
AI ทำสองกริยา
Wiz ยื่นคิวว่างจริงให้ก่อน แล้วค่อยจองอันที่ลูกค้าเลือก — ตั้งใจให้เป็นสองขั้นตอน เพราะการจองคิวว่างแรกให้ใครสักคนอัตโนมัติคือลูกเล่นในเดโม ไม่ใช่การบริการ
โฟลว์ ในฐานะหนึ่งขั้นตอน
ตัวหลักคือ โหนดการจอง ทำให้ระบบอัตโนมัติตัวไหนก็ยื่นคิวว่างให้ลูกค้าเลือกได้ — โฟลว์แจ้งเตือนที่จบลงด้วยการนัดใหม่ โดยไม่ต้องมีคนเข้ามาเกี่ยว
ผู้เข้าชม จองเอง
ตัวหลักคือ วิดเจ็ตบนเว็บไซต์ซึ่งมีมินิแอปจองอยู่ในตัว ให้ลูกค้าเลือกคิวว่างแบบเรียลไทม์ได้ด้วยตัวเอง — และจะโผล่ขึ้นมาก็ต่อเมื่อคุณมีบริการที่จองได้จริง
โมเดลทรัพยากร
ห้อง อุปกรณ์ คน — ตัดกันแบบเดียวกับความเป็นจริง
"ว่าง" เป็นคำถามสามทาง: ผู้ให้บริการ ห้อง และอุปกรณ์ ต้องว่างพร้อมกันทั้งหมด เครื่องมือจองส่วนใหญ่สร้างโมเดลแค่แกนเดียวแล้วภาวนา ส่วนตัวนี้สร้างโมเดลของจุดตัด
บทบาทและตัวบรรจุ
การจองหนึ่งครั้งถือทรัพยากรหลายชิ้นตามบทบาท — ห้อง อุปกรณ์ ผู้ให้บริการ — และการเชื่อมแบบตัวบรรจุทำให้อุปกรณ์ที่อยู่ในห้องซึ่งไม่ว่าง ถูกนับว่าไม่ว่างอย่างถูกต้อง แม้ไม่มีใครจองอุปกรณ์ชิ้นนั้นก็ตาม
ข้อจำกัดของฐานข้อมูล ไม่ใช่กฎในแอป
การกันการทับซ้อนอยู่ในชั้นจัดเก็บข้อมูลในรูปของ exclusion constraint — คำขอสองรายการที่ชิงกันจะชนะทั้งคู่ไม่ได้ เพราะการเขียนครั้งที่สองถูกปฏิเสธในทางกายภาพ กลไกกฎได้แค่สัญญา แต่ข้อจำกัดรับประกัน
ความจุในรูปของหน่วย
คลาสที่มีแปดที่นั่งคือแปดหน่วย ไม่ใช่ตัวนับ — "เหลืออีกหนึ่ง" จึงเป็นข้อเท็จจริงเกี่ยวกับหน่วยหนึ่งโดยเฉพาะ และการคืนเงินก็ไม่ทำให้เลขเพี้ยน
คุณสมบัติที่เข้าเกณฑ์ แยกต่างหาก
"ห้องนี้รองรับบริการนี้ได้ไหม" เป็นเมทริกซ์ของตัวเอง แยกจากเรื่องการถูกใช้งานอยู่ — ทรัพยากรที่ว่างแต่ผิดประเภทจึงไม่ถูกเสนอออกไปเลย และเหตุผลก็ตรวจดูได้
การซิงก์ปฏิทิน
ปฏิทินของคุณ ถูกหักออกจากคิวว่าง
การจองถูกส่งออกไป
นัดหมายไปปรากฏเป็นอีเวนต์ในปฏิทิน Google, Outlook หรือ Apple — และหายไปเมื่อยกเลิก ปฏิทินในมือถือของผู้ให้บริการจึงไม่เคยช้ากว่าสมุดนัดอยู่หนึ่งวัน
เวลาที่ไม่ว่างถูกดึงเข้ามา
อีเวนต์จากภายนอกหักออกจากคิวว่าง — AI จึงไม่เคยเสนอวันพฤหัส 15:00 ตอนที่ Google Calendar ส่วนตัวของคุณมีนัดหมอฟันอยู่แล้ว
บทบาทและทิศทางแยกตามแหล่งข้อมูล
แหล่งข้อมูลที่เชื่อมไว้แต่ละอันมีค่าตั้งของตัวเอง — อ่านจาก เขียนไป ทั้งสองทาง หรือเอาแค่เวลาที่ไม่ว่าง — ปฏิทินคลินิกที่ใช้ร่วมกันกับปฏิทินส่วนตัวจึงเล่นคนละบทได้โดยไม่ตีกัน
การแจ้งเตือนและงานประจำวัน
การติดตามให้จบ แบบอัตโนมัติ
การแจ้งเตือนที่ยิงจริง
คำยืนยันและการเตือนลูกค้าตามเวลาล่วงหน้าที่คุณตั้งไว้ — ทางอีเมล และเลือกเพิ่ม SMS ได้ — พร้อมการแจ้งพนักงานเมื่อมีการจองใหม่ คำว่า "เดี๋ยวกลับมาตามให้" จึงเลิกขึ้นอยู่กับความจำ
การจองตัดสต็อก
นัดหมายงานบริการตัดอะไหล่ออกได้จากที่เดียว นั่นคือ บัญชีสต็อก — การรักษากับวัสดุที่ใช้ไปกระทบยอดกันได้ในจังหวะเดียว
ประวัติย้ายเข้ามาได้
กำลังย้ายมาจาก CRM เจ้าอื่นใช่ไหม กลไกการย้ายระบบนำเข้าประวัตินัดหมายเดิมของคุณเข้าบัญชีเดียวกัน — สมุดนัดจึงไม่ได้เริ่มต้นแบบความจำเสื่อม
เงื่อนไขปลีกย่อยแบบพูดตรง
บอกไว้ก่อนที่คุณจะวางแผนรอบมัน
ยังไม่มีลิงก์จองแบบเดี่ยว
การจองด้วยตัวเองอยู่ในวิดเจ็ตแชทบนเว็บไซต์ — ยังไม่มีหน้าจองสาธารณะแบบ Calendly ที่ส่งทางอีเมลได้ ถ้านั่นคือหัวใจของงานคุณ บอกเรามา เพราะมันมีผลต่อโรดแมป
CRM ภายนอกรับข้อมูลได้น้อยกว่า
เมื่อการจองถูกเขียนออกไปยัง CRM ที่เชื่อมไว้ รายละเอียดเรื่องอุปกรณ์และการตัดจ่ายอาจไม่รอดไปด้วย — API ของผู้ให้บริการไม่ได้เปิดแกนเหล่านั้นไว้ และการซิงก์จะบอกว่าตัดอะไรทิ้ง แทนที่จะตัดทิ้งเงียบ ๆ
บัญชีบันทึกเป็นของเราเสมอ
จะเชื่อมปฏิทินหรือ CRM อะไรเข้ามาก็ตาม บัญชีการจองยังคงเป็นตารางของ ConnectWiz เอง — ระบบภายนอกเป็นแหล่งข้อมูลและกระจกสะท้อน ไม่เคยเป็นตัวหลัก นี่คือจุดยืนด้านการออกแบบ ที่พูดไว้ชัด
ทุกคำถามว่า "ว่างเมื่อไร" จบลงด้วยคิวที่ถูกกันไว้ได้
ตั้งค่าทรัพยากรครั้งเดียว แล้วเจ้าหน้าที่ AI โฟลว์ และลูกค้า ก็จองจากความจริงชุดเดียวกัน