# Crisis Management แบรนด์ CrowdStrike แถลงอะไรบ้างหลังระบบล่ม

> ที่มา: https://phygital.co.th/insights/brand-crisis-management · เผยแพร่ 9 มกราคม 2568 · อ่าน 13 นาที · โดย PARANATH PANARATANA

อัปเดตของ CrowdStrike ทำเครื่อง Windows ล่มราว 8.5 ล้านเครื่องเมื่อ 19 ก.ค. 2567 ไล่ดูคำแถลงแต่ละรอบว่าใส่อะไร ใครลงชื่อ และแบรนด์ไทยใช้ต่อได้แค่ไหน

## Key Takeaways

- **CrowdStrike ปล่อยอัปเดตที่ทำให้เครื่อง Windows ล่มเมื่อวันที่ 19 กรกฎาคม 2567** — Microsoft ประเมินว่ากระทบราว 8.5 ล้านเครื่อง และบริษัทใช้หน้าเว็บหน้าเดียวเป็นช่องทางแถลงทุกรอบ ตั้งแต่วันแรกจนถึงเดือนตุลาคม
- **จดหมายรอบแรกของ CEO ออกในวันเดียวกับที่ระบบล่ม** — มีทั้งคำขอโทษ ขอบเขตของปัญหา คำยืนยันว่าไม่ใช่การโจมตีทางไซเบอร์ และช่องทางที่จะแจ้งข่าวต่อ แม้ในวันนั้นบริษัทยังไม่ได้อธิบายสาเหตุเชิงเทคนิคทั้งหมด
- **รอบถัดมาแต่ละรอบเพิ่มข้อมูลคนละชนิด** — รายงานเบื้องต้น ตัวเลขเครื่องที่กลับมาใช้ได้ รายงานวิเคราะห์สาเหตุฉบับเต็ม และคำตอบเรื่องข่าวลือกับฐานะการเงิน ทำให้ผู้อ่านเห็นว่าเรื่องเดินไปถึงไหนโดยไม่ต้องรอข่าวจากที่อื่น

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

ข้อความทุกรอบคัดจากหน้า [Falcon Content Update Remediation and Guidance Hub](https://www.crowdstrike.com/falcon-content-update-remediation-and-guidance-hub/) ที่ CrowdStrike ใช้เป็นช่องทางทางการ หน้านี้ระบุวันเวลาที่อัปเดตแต่ละส่วนเป็นเวลา UTC บทนี้แปลงเป็นเวลาไทยเมื่อจำเป็น ส่วนจำนวนเครื่องที่ได้รับผลกระทบมาจาก[บล็อกของ Microsoft วันที่ 20 กรกฎาคม 2567](https://blogs.microsoft.com/blog/2024/07/20/helping-our-customers-through-the-crowdstrike-outage/)

## วันที่ 19 กรกฎาคม 2567 เกิดอะไรขึ้น

CrowdStrike เป็นบริษัทความปลอดภัยไซเบอร์ที่ติดตั้งโปรแกรมตรวจจับภัยชื่อ Falcon ไว้ในเครื่องของลูกค้าองค์กร เวลา 04:09 น. UTC ของวันที่ 19 กรกฎาคม 2567 หรือ 11:09 น. ตามเวลาไทย บริษัทส่งอัปเดตการตั้งค่าให้เครื่อง Windows ตามรอบงานปกติ อัปเดตชุดนั้นทำให้เครื่องที่ได้รับค้างและขึ้นหน้าจอสีฟ้า บริษัทถอนอัปเดตออกเวลา 05:27 น. UTC หรือ 78 นาทีหลังปล่อย เครื่อง Mac และ Linux ไม่ได้รับผลกระทบ

Microsoft เขียนในบล็อกวันรุ่งขึ้นว่าประเมินจำนวนเครื่องที่ได้รับผลกระทบไว้ราว 8.5 ล้านเครื่อง หรือไม่ถึงร้อยละหนึ่งของเครื่อง Windows ทั้งหมด

### ทำไมกระทบไม่ถึงร้อยละหนึ่ง แต่เป็นข่าวไปทั่วโลก

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

## แถลงรอบแรกในวันเดียวกับที่ระบบล่ม

หน้าแถลงบันทึกว่าจดหมายฉบับแรกของ George Kurtz ผู้ก่อตั้งและ CEO ส่งออกเวลา 19:30 น. UTC ของวันที่ 19 กรกฎาคม หรือราวตีสองครึ่งของวันที่ 20 ตามเวลาไทย จดหมายขึ้นต้นถึงลูกค้าและพันธมิตร และลงชื่อ CEO คนเดียว ข้อความในจดหมายแยกได้เป็นเจ็ดส่วน

| ส่วนของจดหมาย           | ข้อความที่ใช้ (ถอดความ)                                                                                | ตอบคำถามของผู้อ่านว่า                 |
| ------------------------- | --------------------------------------------------------------------------------------------------------- | ------------------------------------------ |
| คำขอโทษ                  | ขอโทษทุกคนโดยตรงสำหรับเหตุระบบล่ม และเข้าใจว่าเรื่องนี้ร้ายแรงแค่ไหน                       | บริษัทรู้หรือยังว่าตัวเองทำให้เกิด |
| สิ่งที่ทำไปแล้ว       | ระบุปัญหาได้เร็วและส่งการแก้ไขแล้ว ตอนนี้เน้นกู้ระบบของลูกค้า                               | ปัญหายังลามอยู่ไหม                     |
| สาเหตุระดับที่รู้แล้ว | เกิดจากข้อบกพร่องในอัปเดตเนื้อหาสำหรับเครื่อง Windows                                             | เกิดจากอะไร                              |
| ขอบเขต                    | Mac และ Linux ไม่ได้รับผลกระทบ ระบบป้องกันของลูกค้ายังทำงาน                                     | ฉันโดนด้วยไหม                           |
| สิ่งที่ไม่ใช่           | เหตุนี้ไม่ใช่การโจมตีทางไซเบอร์                                                                     | ข้อมูลของฉันรั่วไหม                    |
| ช่องทางแจ้งข่าวต่อ    | จะอัปเดตผ่าน Support Portal บล็อกและฝ่ายเทคนิคคือช่องทางทางการ                                   | จะติดตามจากที่ไหน                       |
| คำเตือนและคำมั่น       | ระวังผู้ไม่หวังดีที่แอบอ้างเป็นบริษัท และสัญญาว่าจะเปิดเผยว่าเรื่องเกิดขึ้นได้อย่างไร | ต่อจากนี้จะได้รู้อะไรอีก            |

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

### ทำไมต้องบอกตั้งแต่รอบแรกว่า "ไม่ใช่การโจมตีทางไซเบอร์"

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

## รายงานเบื้องต้น ตัวเลข และรายงานฉบับเต็ม

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

| วันที่ (2567) | สิ่งที่เพิ่ม                                                                                                                     | ลงชื่อหรือออกในนามใคร |
| -------------- | ---------------------------------------------------------------------------------------------------------------------------------- | -------------------------- |
| 19 ก.ค.        | จดหมายรอบแรก                                                                                                                     | CEO                        |
| 22 ก.ค.        | เริ่มใช้วิธีกู้เครื่องแบบอัตโนมัติ (ระบุในคำถามที่พบบ่อยภายหลัง)                                                      | บริษัท                     |
| 24 ก.ค.        | รายงานเบื้องต้นหลังเหตุการณ์ (Preliminary Post Incident Review) บอกว่าอัปเดตเป็นแบบไหน ทดสอบอย่างไร และจะทำอะไรเพิ่ม | บริษัท                     |
| 25 ก.ค.        | ตัวเลขเครื่องที่กลับมาออนไลน์ มากกว่าร้อยละ 97 เมื่อเทียบกับสัปดาห์ก่อนเกิดเหตุ                                       | บริษัท                     |
| 31 ก.ค.        | ตัวเลขชุดสุดท้าย ราวร้อยละ 99 ณ วันที่ 29 ก.ค. พร้อมหมายเหตุว่าปกติตัวเลขนี้แกว่งราวร้อยละ 1 ต่อสัปดาห์             | บริษัท                     |
| 6 ส.ค.         | รายงานวิเคราะห์สาเหตุฉบับเต็ม (Root Cause Analysis) บทสรุปผู้บริหาร และจดหมายฉบับที่สองของ CEO                         | บริษัทและ CEO             |

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

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

### ทำไมต้องออกรายงานเบื้องต้นก่อนรู้สาเหตุทั้งหมด

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

## รอบปิดในเดือนตุลาคม

วันที่ 28 ตุลาคม 2567 บริษัทปรับส่วนคำถามที่พบบ่อยบนหน้าเดิม คำถามชุดนี้ตอบเรื่องที่คนยังพูดถึงหลังเหตุการณ์ผ่านไปสามเดือน มีสามเรื่องที่ควรสังเกต

1. **ข่าวลือเชิงเทคนิค** บริษัทตอบตรง ๆ ว่ารายงานข่าวที่บอกว่ามีการข้ามขั้นตอนทดสอบส่วนที่ทำงานระดับเคอร์เนลของ Windows ไม่เป็นความจริง และตอบว่าไบต์ว่าง (null bytes) ในไฟล์อัปเดตไม่ใช่สาเหตุ โดยลิงก์ไปบทวิเคราะห์ที่อธิบายเรื่องนี้
2. **ฐานะการเงิน** บริษัทระบุว่า ณ 31 กรกฎาคม 2567 ถือเงินสดรวมรายการที่เทียบเท่า 4.0 พันล้านดอลลาร์สหรัฐ มีวงเงินสินเชื่อหมุนเวียน 750 ล้านดอลลาร์สหรัฐ และเขียนว่าเชื่อว่ากระแสเงินสดเพียงพอสำหรับภาระทางกฎหมายที่อาจเกิดขึ้น พร้อมบอกว่ามีกรมธรรม์ประกันภัยรองรับ
3. **เงื่อนไขสัญญา** บริษัทชี้ไปที่ข้อกำหนดมาตรฐานบนเว็บไซต์ รวมถึงข้อจำกัดความรับผิด

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

### บริษัทเล็กต้องพูดเรื่องเงินในคำชี้แจงด้วยไหม

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

## สิ่งที่หน้าแถลงของบริษัทไม่ได้เล่า

หน้าแถลงเป็นเอกสารที่บริษัทเขียนเอง เก็บไว้ให้คนอ่านย้อนหลัง จึงมีขอบเขตห้าข้อที่ควรรู้ก่อนเอาไปเป็นต้นแบบ

1. **ไม่มีข้อความที่ถูกแก้หรือถอดออก** หน้านี้แสดงฉบับล่าสุดของแต่ละส่วน เราไม่เห็นว่าระหว่างทางเคยเขียนอะไรแล้วเปลี่ยน
2. **ไม่มีโพสต์บนโซเชียลของผู้บริหาร** บทนี้ไม่ได้เปิดอ่านโพสต์บน X หรือบทสัมภาษณ์ทางโทรทัศน์ที่ออกในวันเดียวกัน
3. **ไม่มีเสียงของฝั่งที่ได้รับผลกระทบ** ความเห็นของลูกค้า สายการบิน โรงพยาบาล หรือหน่วยงานกำกับดูแล อยู่นอกหน้าแถลงนี้
4. **บริษัทนี้ขายให้องค์กร** คนอ่านหลักคือฝ่ายไอทีของลูกค้า ภาษาและรายละเอียดเทคนิคจึงลึกกว่าที่ร้านค้าหรือแบรนด์สินค้าอุปโภคบริโภคต้องใช้
5. **หน้าแถลงไม่ได้บอกว่าได้ผลแค่ไหน** ไม่มีตัวเลขลูกค้าที่ยกเลิกหรือยอดขายหลังเหตุการณ์ บทนี้จึงเล่าได้แค่ว่าบริษัทพูดอะไร ยังบอกไม่ได้ว่าลูกค้าองค์กรตัดสินใจต่อสัญญากับ CrowdStrike กันกี่ราย

## แม่แบบแถลงรอบแรกเจ็ดช่อง

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

| ช่อง                                  | ตัวอย่างสำหรับร้านที่ส่งสินค้าเสียทั้งล็อต                                                       |
| ------------------------------------- | -------------------------------------------------------------------------------------------------------- |
| 1\. ขอโทษและบอกว่ารู้เรื่องแล้ว | ขอโทษลูกค้าที่ได้รับสินค้าล็อตวันที่ 3-5 และเรารู้แล้วว่าสินค้าบางส่วนเสียก่อนถึงมือ |
| 2\. สิ่งที่ทำไปแล้ว               | หยุดส่งล็อตนี้ตั้งแต่เช้าวันนี้ และเก็บสินค้าที่เหลือในคลังแยกไว้                         |
| 3\. สาเหตุเท่าที่รู้               | เบื้องต้นพบว่าตู้เย็นในรถขนส่งเสีย กำลังตรวจว่ามีสาเหตุอื่นไหม                            |
| 4\. ใครได้รับผลกระทบ             | เฉพาะคำสั่งซื้อที่ส่งวันที่ 3-5 ในเขตกรุงเทพฯ                                                   |
| 5\. สิ่งที่ไม่ใช่                   | สินค้าล็อตอื่นและหน้าร้านไม่เกี่ยวข้อง                                                           |
| 6\. ติดตามจากที่ไหน                 | ข้อมูลใหม่จะอยู่ที่โพสต์ปักหมุดนี้โพสต์เดียว แอดมินจะตอบในแชตของเพจเท่านั้น            |
| 7\. รอบถัดไปและคำมั่น             | จะแจ้งวิธีคืนเงินภายในเวลา 18:00 น. พรุ่งนี้ และจะเล่าผลตรวจสาเหตุเมื่อได้ผล               |

เมื่อข่าวลบเริ่มจากลูกค้ารายเดียวที่ร้องเรียนเข้ามา ลำดับการตอบก่อนเรื่องขยายอยู่ใน[Reactive Marketing ตอบคำร้องเรียนลูกค้าก่อนเรื่องไปถึง สคบ.](https://phygital.co.th/insights/reactive-marketing) ถ้าเรื่องอยู่ในรีวิวบน Google หรือเพจ วิธีตอบรีวิวทีละข้อความอยู่ใน[บริหารรีวิวออนไลน์ รีวิวลบแบบไหนขอลบได้บน Shopee กับ Google](https://phygital.co.th/insights/online-review-reputation-management-thailand) ส่วนการตัดสินใจภายในองค์กรช่วงแรก เช่น ใครสั่งหยุดขายและใครคุมข้อมูล อ่านต่อได้ใน[Crisis Management 24 ชั่วโมงแรก ผู้บริหารต้องตัดสินอะไรก่อน](https://phygital.co.th/insights/crisis-management-ceo-first-24-hours) และถ้านักข่าวติดต่อขอความเห็น ดู[Newsjacking นักข่าวอยากได้อะไรจากแบรนด์ตอนข่าวกำลังร้อน](https://phygital.co.th/insights/newsjacking-marketing) ประกอบ ขอบเขตงานประชาสัมพันธ์ช่วงวิกฤตดูได้ที่หน้า[บริการ Digital PR](https://phygital.co.th/solutions/digital-pr)

### ถ้ารอบถัดไปยังไม่มีอะไรใหม่ ต้องแถลงไหม

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

## สรุป

หลังอัปเดตของ CrowdStrike ทำให้เครื่อง Windows ล่มราว 8.5 ล้านเครื่องในวันที่ 19 กรกฎาคม 2567 บริษัทแถลงผ่านหน้าเว็บหน้าเดียวหลายรอบ จดหมายรอบแรกของ CEO ออกในวันเดียวกัน มีคำขอโทษ สิ่งที่แก้แล้ว สาเหตุเท่าที่ยืนยันได้ ขอบเขต การยืนยันว่าไม่ใช่การโจมตี ช่องทางทางการ และคำมั่นว่าจะเล่าสาเหตุทั้งหมด จากนั้นมีรายงานเบื้องต้นวันที่ 24 กรกฎาคม ตัวเลขเครื่องที่กลับมาออนไลน์ รายงานสาเหตุฉบับเต็มพร้อมจดหมายฉบับที่สองวันที่ 6 สิงหาคม และคำตอบเรื่องข่าวลือกับฐานะการเงินในเดือนตุลาคม ข้อความแต่ละรอบพูดเฉพาะสิ่งที่ยืนยันได้ในวันนั้น และบอกว่าจะมีอะไรตามมา

## คำถามที่พบบ่อย (FAQ)

### ควรลบโพสต์เดิมที่ถูกวิจารณ์ไหม

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

### ใครควรเป็นคนลงชื่อในคำชี้แจง

รอบแรกและรอบที่ขอโทษ ควรเป็นคนที่มีอำนาจสูงสุดของธุรกิจ ในกรณีนี้ CEO ลงชื่อจดหมายสองฉบับ ส่วนรายงานเทคนิคและตัวเลขความคืบหน้าออกในนามบริษัท ร้านเล็กที่เจ้าของเป็นหน้าร้านเอง ให้เจ้าของลงชื่อ

### แถลงรอบแรกช้าไปกี่ชั่วโมงถึงจะสาย

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

### ถ้าความผิดเกิดจากคู่ค้าหรือผู้ส่งวัตถุดิบ ควรบอกไหม

บอกได้เมื่อยืนยันแล้ว และต้องไม่ใช้เป็นเหตุผลเพื่อพ้นความรับผิด ลูกค้าซื้อจากแบรนด์ คนที่ต้องขอโทษและชดเชยก่อนคือแบรนด์ ถ้าการร่วมงานกับพาร์ทเนอร์คือจุดที่มีปัญหา เรื่องนี้มีรายละเอียดอยู่ใน[ความเสี่ยง Co-Branding เลิกกลางทางแล้วสต๊อกร่วมแบรนด์ไปไหน](https://phygital.co.th/insights/co-branding-risk-management)

### ต้องแปลคำชี้แจงเป็นภาษาอื่นด้วยไหม

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

### เรื่องจบเมื่อไร และกลับมาโพสต์ขายของได้เมื่อไร

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

## ถ้าวันนี้ต้องแถลง ทีมของคุณรู้ไหมว่าจะโพสต์ที่ไหนและใครลงชื่อ

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

- [นัดประชุมผ่าน Google Meet](https://calendar.app.google/DotQdE7Ca8LZG6Us5)
- [เพิ่มเพื่อนใน LINE](https://lin.ee/J8Qq8Do)