top of page

Crisis Communication in Crowd Management: เมื่อการสื่อสารกลายเป็นส่วนหนึ่งของระบบความปลอดภัย

จักรพันธ์ ภวังคะรัตน์

Head of Property Management, JLL Thailand

เลขาธิการ สมาคมบริหารทรัพย์สินแห่งประเทศไทย

3 September 2026



เหตุการณ์ในคอนเสิร์ต FAREWELL CONCERT อัสนี–วสันต์ เมื่อวันที่ 2 กันยายน 2569 ที่ IMPACT Arena เป็นกรณีศึกษาที่น่าสนใจของการบริหารสถานการณ์ฉุกเฉินในพื้นที่ที่มีคนจำนวนมาก จากข้อมูลที่เปิดเผยในช่วงเช้าวันที่ 3 กันยายน พบว่าพื้นที่นั่งยกระดับชั่วคราวบางส่วนเกิดการทรุดตัว ส่งผลให้มีการตรวจสอบและเคลื่อนย้ายผู้ชมบางส่วน การแสดงเริ่มล่าช้า มีการหยุดการแสดงและทยอยนำผู้ชมออกจากบางพื้นที่ ก่อนตัดสินใจยุติการแสดง โดย IMPACT ชี้แจงว่าเหตุการณ์เกิดกับโครงสร้างที่นั่งยกระดับชั่วคราวที่ติดตั้งเพิ่มเติม และไม่ได้กระทบต่อโครงสร้างพื้นถาวรของอาคาร ขณะที่ผู้จัดประกาศเลื่อนรอบดังกล่าวไปเป็นวันที่ 9 กันยายน 2569


เหตุการณ์นี้ยังไม่ควรถูกใช้เพื่อตัดสินว่าใครทำถูกหรือผิด เพราะรายละเอียดด้านวิศวกรรม กระบวนการตัดสินใจ และข้อมูลที่ Control Room ได้รับในแต่ละช่วงเวลายังไม่ได้เปิดเผยทั้งหมด แต่หากมองผ่านหลัก Crowd Management และ Crisis Communication กรณีนี้ให้บทเรียนสำคัญว่า ในสถานการณ์ที่มีคนหลายพันคนรวมตัวกัน ความปลอดภัยไม่ได้ขึ้นอยู่กับโครงสร้าง ระบบดับเพลิง ทางหนีไฟ เจ้าหน้าที่รักษาความปลอดภัย หรือแผนอพยพเพียงอย่างเดียว การทำให้คนจำนวนมาก “รู้ว่าเกิดอะไรขึ้น รู้ว่าต้องทำอะไร และเชื่อมั่นพอที่จะทำตามคำแนะนำ” คือส่วนหนึ่งของระบบความปลอดภัยเช่นกัน


แนวคิดจากหนังสือ Applied Crowd Science ของ G. Keith Still ทำให้เราเห็นว่า Crowd Safety ต้องมองคนเป็นระบบที่มีการเคลื่อนที่ มี Density มี Flow และมีพฤติกรรมตอบสนองต่อสิ่งแวดล้อม เมื่อเกิดความผิดปกติขึ้น ปัญหาทางกายภาพเพียงจุดเดียวสามารถสร้างผลต่อเนื่องได้ หากคนจำนวนมากเริ่มเคลื่อนที่พร้อมกันไปยังพื้นที่เดียวกัน ดังนั้น Crowd Management จึงเกี่ยวข้องกับทั้งการออกแบบพื้นที่ การบริหารคน และการให้ข้อมูล เพราะข้อมูลที่ประชาชนได้รับสามารถเปลี่ยนทิศทางและความเร็วของการเคลื่อนที่ของ Crowd ได้


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


นี่คือเหตุผลที่ Communication in Times of Trouble ของ Matthew Seeger และ Timothy Sellnow ให้ความสำคัญอย่างมากกับการสื่อสารในภาวะที่ข้อมูลยังไม่สมบูรณ์ หลักสำคัญคือองค์กรไม่จำเป็นต้องรอจนรู้ทุกอย่างจึงเริ่มสื่อสาร เพราะใน Crisis ความเงียบเองก็เป็นข้อมูลรูปแบบหนึ่ง และช่องว่างของข้อมูลมักถูกเติมด้วยข่าวลือ การคาดเดา และข้อมูลจากแหล่งอื่น



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


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


หลักจาก Crisis & Emergency Risk Communication หรือ CERC ของ CDC ยิ่งอธิบายเรื่องนี้ชัดขึ้น เพราะคนประมวลผลข้อมูลต่างจากภาวะปกติเมื่ออยู่ภายใต้ความกังวลหรือความกลัว ความสามารถในการรับข้อมูลซับซ้อนจะลดลง ดังนั้น Emergency Message ควรสั้น ชัดเจน มี Action ที่ทำตามได้ และควรถูกย้ำผ่านหลายช่องทางที่สอดคล้องกัน


สำหรับคอนเสิร์ตขนาดใหญ่ ช่องทางเหล่านั้นอาจประกอบด้วย PA Announcement, LED Screen, เจ้าหน้าที่ประจำโซน, Security, Event Staff, Social Media และข้อความจากผู้จัด แต่สิ่งสำคัญกว่าจำนวนช่องทางคือทุกช่องทางต้องสื่อสารจากสถานการณ์เดียวกัน ถ้าเจ้าหน้าที่หน้าพื้นที่พูดอย่างหนึ่ง จอภาพแสดงอีกอย่าง Social Media บอกอีกอย่าง และผู้ชมได้ยินข่าวจากคนรอบข้างอีกอย่าง ความเชื่อมั่นต่อระบบจะลดลงอย่างรวดเร็ว


ตรงนี้เป็นสิ่งที่ Ongoing Crisis Communication ของ W. Timothy Coombs ช่วยเติมเต็ม เพราะ Crisis Communication ต้องถูกเตรียมก่อนเกิด Crisis ตั้งแต่ใครเป็นผู้มีอำนาจตัดสินใจ ใครเป็น Incident Commander ใครสามารถอนุมัติข้อความ ใครเป็น Spokesperson และอะไรคือช่องทางหลักในการสื่อสาร หากต้องเริ่มค้นหาคำตอบเหล่านี้หลังเกิดเหตุแล้ว เวลาที่ควรใช้บริหาร Crowd จะถูกใช้ไปกับการประสานงานภายในองค์กรแทน


สำหรับ Mass Gathering สิ่งที่น่าสนใจอีกประการคือ Operational Communication กับ Corporate Communication มีหน้าที่ต่างกัน


Corporate Communication ต้องอธิบายว่าเกิดอะไรขึ้น สาเหตุคืออะไร ใครรับผิดชอบ จะเยียวยาอย่างไร และจะป้องกันการเกิดซ้ำอย่างไร ซึ่งมีความสำคัญต่อ Reputation และ Trust หลังเหตุการณ์ แต่ Operational Communication ระหว่างเกิดเหตุมีภารกิจเร่งด่วนกว่านั้น คือทำให้คนจำนวนมากมีพฤติกรรมที่ช่วยลดความเสี่ยง


คำถามของ Operational Communication จึงเป็น


ตอนนี้เราต้องการให้ Crowd ทำอะไร?

  • ให้อยู่กับที่

  • ให้หลีกเลี่ยงพื้นที่หนึ่ง

  • ให้ย้ายไปอีกโซน

  • ให้ทยอยออก

  • ให้ใช้ประตูบางประตู

  • หรือให้อพยพทั้งหมด


เมื่อมองในมุมนี้ Communication จะกลายเป็นส่วนหนึ่งของ Crowd Control Loop


Observe → Assess → Decide → Communicate → Crowd Responds → Observe Again


Control Room ตรวจพบความผิดปกติ ทีมประเมินความเสี่ยง ผู้มีอำนาจตัดสินใจเลือกมาตรการ จากนั้นสื่อสารเพื่อให้ Crowd เปลี่ยนพฤติกรรม แล้ว Control Room ต้องกลับไปดูว่าคำสั่งนั้นได้ผลหรือไม่ หากคนไม่เคลื่อนที่ตามที่ต้องการ หรือเกิด Density สูงขึ้นในอีกพื้นที่หนึ่ง ต้องปรับมาตรการและสื่อสารใหม่


นี่คือเหตุผลที่การประกาศเพียงว่า “ขอให้ทุกท่านออกจากพื้นที่เพื่อความปลอดภัย” อาจยังไม่เพียงพอสำหรับ Crowd Management เพราะคนยังต้องตัดสินใจเองว่าจะออกทางไหน ไปที่ไหน ต้องรีบหรือไม่ และจะเกิดอะไรต่อไป


Emergency Communication ที่ดีจึงควรตอบอย่างน้อย 5 เรื่อง

  • What happened? — เกิดอะไรขึ้นเท่าที่สามารถยืนยันได้

  • What should I do? — ต้องการให้ผู้ชมทำอะไร

  • Where should I go? — ต้องไปที่ไหนหรือใช้เส้นทางใด

  • What should I avoid? — พื้นที่หรือพฤติกรรมใดควรหลีกเลี่ยง

  • When is the next update? — จะได้รับข้อมูลครั้งต่อไปเมื่อใด


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


กรณีคอนเสิร์ตอัสนี–วสันต์จึงมีบทเรียนที่ใหญ่กว่าคำถามว่าพื้นยกระดับเกิดปัญหาเพราะอะไร สิ่งที่ทุก Venue, Organizer, Property Manager และ Facility Manager ควรกลับไปถามคือ ถ้าเหตุการณ์แบบนี้เกิดขึ้นกับเราในคืนนี้ เรามีระบบตัดสินใจและสื่อสารพร้อมหรือยัง


Control Room รู้หรือไม่ว่าใครเป็นผู้ตัดสินใจหยุดงาน ใครสามารถสั่ง Partial Evacuation ใครอนุมัติข้อความต่อผู้ชม PA Operator มี Prepared Message หรือไม่ LED Screen สามารถเปลี่ยนจาก Content ปกติเป็น Emergency Message ได้ภายในกี่นาที เจ้าหน้าที่แต่ละโซนได้รับข้อมูลเดียวกันหรือไม่ และหากโทรศัพท์หรืออินเทอร์เน็ตใช้งานไม่ได้ เรายังสามารถสื่อสารกับคนหลายหมื่นคนได้อย่างไร


คำถามเหล่านี้ควรถูกทดสอบผ่าน Tabletop Exercise และ Simulation ก่อนวันจัดงาน เพราะ Emergency Plan ที่มีอยู่ในแฟ้มไม่ได้รับประกันว่าจะทำงานได้เมื่อสถานการณ์จริงเกิดขึ้น การซ้อมควรรวม Communication Inject เข้าไปด้วย เช่น เมื่อพบความผิดปกติเวลา 19.05 น. ใครต้องรู้ภายในหนึ่งนาที ข้อความแรกต้องออกภายในกี่นาที ใครเป็นผู้อนุมัติ และหากข้อมูลใหม่ขัดกับข้อความเดิมจะ Update อย่างไร


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


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


ดังนั้นสำหรับ Concert, Stadium, Convention Centre, Shopping Mall หรือ Mixed-use Development เราอาจต้องเริ่มมอง Communication ใหม่


Communication is not only about telling people what happened. It is part of the safety system that tells people what to do next.


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

Chakrapan Pawangkarat

  • TikTok
  • Facebook
  • LinkedIn
  • Instagram
  • Youtube
bottom of page