Contact
Line : comsiam
Contact
Line : comsiam

Prompt Microsoft Copilot สำหรับเขียนรายงานที่ดี ควรระบุให้ชัดว่า รายงานเรื่องอะไร ใช้ข้อมูลจากไหน เขียนให้ใครอ่าน ต้องการโครงสร้างแบบไหน และต้องการผลลัพธ์ในระดับรายละเอียดเท่าไร
ถ้าสั่งเพียงว่า “ช่วยเขียนรายงานให้หน่อย” Copilot อาจสร้างข้อความกว้าง ๆ ที่ดูเหมือนรายงาน แต่ยังไม่ตรงกับงานจริง หรืออาจเติมข้อมูลที่ไม่มีอยู่ใน Source
สูตรพื้นฐานที่ใช้ได้ดีคือ:
หัวข้อ + วัตถุประสงค์ + Audience + Source + Structure + Tone + Length + Constraints
ตัวอย่าง:
“เขียนรายงานสรุปผลโครงการสำหรับผู้บริหาร โดยใช้เฉพาะข้อมูลจากเอกสารที่ให้ แบ่งเป็น Executive Summary, Results, Problems, Risks และ Next Steps ความยาวไม่เกิน 1,500 คำ และห้ามสร้างตัวเลขใหม่”
รายงานมีหลายแบบ เช่น
Prompt ควรบอกประเภทของรายงานตั้งแต่ต้น
ตัวอย่าง:
“เขียนรายงานผลการดำเนินงานโครงการติดตั้งระบบเครือข่ายประจำเดือนกันยายน”
ชัดกว่า:
“เขียนรายงานโครงการ”
หัวข้อที่ชัดช่วยควบคุมขอบเขต
รายงานอาจมีวัตถุประสงค์ต่างกัน เช่น
Prompt:
“วัตถุประสงค์คือให้ผู้บริหารเข้าใจผลลัพธ์ ปัญหา และสิ่งที่ต้องตัดสินใจ”
ช่วยให้รายงานไม่กลายเป็นเพียงการเล่าเหตุการณ์
ตัวอย่าง:
Audience มีผลต่อระดับรายละเอียด
รายงานสำหรับผู้บริหารอาจเน้น
มากกว่ารายละเอียดทางเทคนิคทุกขั้นตอน
Source อาจเป็น
Prompt:
“ใช้เฉพาะข้อมูลจาก Source ที่ให้ และห้ามสร้างข้อมูลเพิ่ม”
นี่สำคัญมากสำหรับรายงานที่ต้องใช้จริง
เพิ่มคำสั่ง:
“ถ้าหัวข้อใดไม่มีข้อมูล ให้ระบุว่า ‘ไม่มีข้อมูลเพียงพอ’ แทนการคาดเดา”
ช่วยลดการสร้างรายละเอียดปลอม
ตัวอย่างโครงสร้าง:
Prompt ที่มี Structure ชัด มักใช้งานได้ง่ายกว่า
ตัวอย่าง:
“เขียน Daily Report จากข้อมูลนี้ โดยแบ่งเป็น งานที่เสร็จ งานที่กำลังทำ ปัญหา และแผนพรุ่งนี้”
เหมาะกับทีมปฏิบัติการ
ตัวอย่าง:
“เขียน Weekly Report โดยสรุป Completed, In Progress, Blockers, KPI และ Priorities สัปดาห์หน้า”
ช่วยให้ผู้รับเห็นความคืบหน้าได้เร็ว
ตัวอย่าง:
“เขียน Monthly Report จากข้อมูลนี้ โดยเปรียบเทียบผลกับเดือนก่อน และระบุ Trend ที่สำคัญ”
ควรใช้ตัวเลขจริงจาก Source
ตัวอย่าง:
“เขียน Project Report โดยแบ่งเป็น Objective, Progress, Milestones, Risks, Issues และ Next Actions”
เหมาะกับ Project Management
ตัวอย่าง:
“สร้าง Project Status Report แบบกระชับสำหรับผู้บริหาร โดยเน้นสถานะปัจจุบัน ปัญหา ความเสี่ยง และสิ่งที่ต้องตัดสินใจ”
ช่วยลดรายงานที่ยาวเกินไป
ตัวอย่าง:
“เขียน Sales Report จากตารางนี้ โดยสรุปยอดขายรวม สินค้าที่ขายดี พื้นที่ที่เติบโต และรายการที่ควรตรวจเพิ่มเติม”
ต้องใช้ข้อมูลจากตารางจริง
ตัวอย่าง:
“สรุปรายงานการเงินจากข้อมูลนี้ โดยแยกรายรับ รายจ่าย กระแสเงินสด และรายการผิดปกติ”
ตัวเลขทางการเงินควรตรวจซ้ำทุกครั้ง
ตัวอย่าง:
“เขียน Incident Report เรื่อง [ปัญหา] โดยแบ่งเป็น Timeline, Impact, Root Cause ที่ทราบ, Action Taken และ Prevention”
เหมาะกับงาน IT และ Operations
โครงสร้างที่ดี:
ช่วยให้รายงานอ่านเข้าใจง่าย
ตัวอย่าง:
“เปลี่ยน Meeting Notes นี้เป็นรายงานการประชุม โดยแยก Discussion, Decisions, Action Items, Owners และ Deadlines”
ช่วยเปลี่ยน Notes ที่กระจัดกระจายให้เป็นระบบ
ตัวอย่าง:
“เขียน Executive Report ไม่เกิน 1 หน้า โดยเน้นผลลัพธ์ 5 ข้อ ความเสี่ยง 3 ข้อ และ Decision Required”
เหมาะกับผู้บริหารที่ต้องอ่านเร็ว
Executive Summary ควรตอบว่า:
Prompt:
“เขียน Executive Summary ไม่เกิน 200 คำ”
ช่วยให้ผู้อ่านเห็นภาพรวมก่อน
ตัวอย่างที่ไม่ช่วย:
“ในปัจจุบันธุรกิจมีการแข่งขันสูง…”
ควรเข้าเรื่องจริง เช่น:
“เดือนนี้ยอดขายเพิ่มขึ้น 8% จากเดือนก่อน แต่กำไรขั้นต้นลดลงจากต้นทุนขนส่งที่สูงขึ้น”
ถ้าข้อมูล Source รองรับ
ใช้:
“ดึง KPI และตัวเลขสำคัญทั้งหมดจากข้อมูลนี้ แล้วจัดเป็นตารางก่อนเขียนรายงาน”
ช่วยลดการตกหล่น
ตัวอย่าง:
“ตรวจว่าตัวเลขใน Draft รายงานตรงกับ Source หรือไม่ และระบุจุดที่ไม่ตรง”
เหมาะก่อนส่งรายงานจริง
ตัวอย่าง:
“จากข้อมูลนี้ ระบุ Trend ที่เห็นได้ชัด พร้อมอ้างอิงตัวเลขจาก Source”
ไม่ควรให้ AI สรุป Trend โดยไม่มีข้อมูลรองรับ
ตัวอย่าง:
“หาค่าหรือเหตุการณ์ที่ผิดปกติจากข้อมูลนี้ และอธิบายว่าควรตรวจอะไรเพิ่มเติม”
เหมาะกับยอดขาย ค่าใช้จ่าย หรือ Performance
ตัวอย่าง:
“เปรียบเทียบเดือนนี้กับเดือนก่อน โดยแสดง Absolute Change และ Percentage Change จากตัวเลขที่ให้”
ช่วยให้รายงานมี Context มากขึ้น
ตัวอย่าง:
“เปรียบเทียบ Actual กับ Target และสรุปว่ารายการใดสูงหรือต่ำกว่าเป้าหมาย”
เหมาะกับ KPI Report
ตัวอย่าง:
“เขียนส่วน Results โดยใช้เฉพาะผลที่วัดได้จากข้อมูล และหลีกเลี่ยงคำชมเชิงความรู้สึก”
ช่วยให้รายงานดูเป็นกลาง
ใช้:
“สรุปปัญหาที่เกิดขึ้น โดยระบุ Impact และสถานะการแก้ไข”
ช่วยให้ Problem Section ใช้งานต่อได้
ตัวอย่าง:
“ระบุความเสี่ยงจากข้อมูลที่มี พร้อม Impact และ Mitigation ที่มีอยู่”
หากเป็นการคาดการณ์ ควรแยกออกจากข้อเท็จจริงชัดเจน
ตัวอย่าง:
“จาก Findings เหล่านี้ สร้าง Recommendation ที่เชื่อมกับข้อมูลโดยตรง และแยกเป็น Quick Win กับ Long-term”
ช่วยให้ข้อเสนอแนะไม่ลอย
ไม่ควรเขียน:
“ควรเพิ่มงบโฆษณา”
ถ้าข้อมูลยังไม่แสดงว่าปัญหาอยู่ที่งบโฆษณา
ควรเชื่อม Recommendation กับ Finding
ตัวอย่าง:
“เปลี่ยน Recommendation เป็น Next Steps ที่มี Task, Owner และ Deadline”
ช่วยให้รายงานต่อยอดไปสู่ Action ได้
ตัวอย่าง:
“สรุปสถานะโครงการเป็นตารางที่มี Workstream, Status, Owner, Risk และ Next Action”
เหมาะกับรายงานที่ต้อง Scan เร็ว
ตัวอย่าง:
“สรุปรายงานให้เหลือ Bullet Point สำหรับผู้บริหาร โดยไม่เกิน 10 ข้อ”
เหมาะกับ Management Update
ตัวอย่าง:
“เขียนรายงานฉบับเต็มประมาณ 1,500–2,000 คำ โดยมี H1, H2 และ H3 ชัดเจน”
เหมาะกับเอกสารที่ต้องเก็บเป็นหลักฐาน
ใช้:
“ย่อรายงานนี้ให้เหลือ 1 หน้า โดยรักษาตัวเลข Findings และ Decision Required”
ช่วยสร้าง Executive Version
ตัวอย่าง:
“ขยายหัวข้อ Risks โดยอธิบาย Impact และ Mitigation เพิ่ม แต่ห้ามสร้างข้อมูลใหม่”
ช่วยเพิ่มรายละเอียดเฉพาะส่วน
ตัวอย่าง:
“Rewrite รายงานนี้ให้มืออาชีพ กระชับ และลดข้อความซ้ำ โดยรักษาข้อมูลและตัวเลขเดิมทั้งหมด”
เหมาะกับ Draft ที่เขียนจากหลายคน
ใช้:
“ปรับรายงานให้คนที่ไม่ใช่ผู้เชี่ยวชาญเข้าใจได้ โดยอธิบายศัพท์เทคนิคเมื่อจำเป็น”
ช่วยให้รายงานเข้าถึง Audience กว้างขึ้น
ตัวอย่าง:
“ปรับรายงานนี้ให้เป็นภาษาธุรกิจแบบเป็นทางการ แต่ไม่ใช้คำซับซ้อนเกินจำเป็น”
เหมาะกับเอกสารองค์กร
ใช้:
“หาส่วนที่พูดข้อมูลเดียวกันซ้ำหลายครั้ง และเสนอเวอร์ชันที่กระชับขึ้น”
ช่วยลดรายงานยืดเยื้อ
ตัวอย่าง:
“ตรวจรายงานนี้ว่าขาด Objective, Result, Risk, Action หรือ Conclusion ส่วนใดหรือไม่”
เหมาะกับ Final Review
ใช้:
“ตรวจว่ามีตัวเลข วันที่ หรือข้อความใดในรายงานที่ขัดแย้งกันเอง”
มีประโยชน์มากกับเอกสารยาว
ตัวอย่าง:
“ทำเครื่องหมายทุกข้อความที่เป็นข้อสรุปหรือ Claim และระบุว่ามีข้อมูลรองรับจาก Source หรือไม่”
ช่วยป้องกันการสรุปเกินข้อมูล
ใช้:
“ตรวจชื่อบุคคล ชื่อบริษัท วันที่ และตัวเลขทั้งหมดกับ Source”
รายละเอียดเล็ก ๆ เหล่านี้ผิดแล้วกระทบความน่าเชื่อถือมาก
ตัวอย่าง:
“จาก Notes และข้อมูลดิบนี้ จัดกลุ่มข้อมูลก่อน แล้วเขียนเป็นรายงานที่มีโครงสร้าง”
เหมาะเมื่อ Source ยังไม่เป็นระเบียบ
ใช้:
“จัดข้อมูลเหล่านี้เป็น Theme ก่อน ได้แก่ Results, Problems, Risks, Feedback และ Actions”
จากนั้นค่อย Generate Report
ช่วยลดการปะติดปะต่อแบบสุ่ม
ตัวอย่าง:
“จากตารางนี้ สรุป KPI สำคัญ ความเปลี่ยนแปลง และรายการผิดปกติ แล้วเขียนเป็น Management Report”
ต้องตรวจ Formula และตัวเลขต้นทางด้วย
ตัวอย่าง:
“สรุปผลแบบสอบถาม โดยแบ่งเป็น Quantitative Findings, Common Feedback และ Recommendations”
ถ้ามี Open-ended Response สามารถจัด Theme เพิ่มได้
ใช้:
“จัด Feedback ลูกค้าเป็น Theme นับความถี่แต่ละประเด็นจากข้อมูลที่มี และสรุป Top Issues โดยไม่สร้างจำนวนเพิ่มเอง”
เหมาะกับ Customer Experience Report
ตัวอย่าง:
“เขียนรายงาน Support ประจำเดือน โดยสรุปจำนวนเคส ประเภทปัญหา เคสค้าง และปัญหาที่เกิดซ้ำ”
ช่วยหา Pattern ของงาน Support
ใช้:
“รวม Update จากหลายทีมเป็นรายงานเดียว โดยรักษาเจ้าของงานและสถานะของแต่ละ Workstream”
ช่วยลดเวลารวมรายงาน
ตัวอย่าง:
“เขียนรายงานโดยแบ่งเป็น Problem, Evidence, Root Cause, Solution และ Expected Result”
เหมาะกับ Improvement Project
ตัวอย่าง:
“เปรียบเทียบสถานะก่อนและหลังโครงการ โดยใช้ตัวเลขเดียวกันทั้งสองช่วง”
ช่วยให้เห็นผลลัพธ์ชัดขึ้น
ตัวอย่าง:
“เขียน Conclusion ไม่เกิน 150 คำ โดยสรุปผลหลัก ความเสี่ยง และสิ่งที่ควรทำต่อ”
ไม่ควรเพิ่มข้อมูลใหม่ใน Conclusion
“ช่วยเขียนรายงานเรื่อง [หัวข้อ]
วัตถุประสงค์:
[Objective]
Audience:
[ผู้รับ]
Source:
[ข้อมูลต้นทาง]
ช่วงเวลา:
[Period]
โครงสร้าง:
Tone:
มืออาชีพ ชัดเจน และเป็นกลาง
Length:
ประมาณ [จำนวน] คำ
ข้อกำหนด:
Template นี้เหมาะกับรายงานธุรกิจหลายประเภท
“สร้าง Executive Report จากข้อมูลนี้
ตอบไม่เกิน 1 หน้า
แบ่งเป็น:
เน้นเฉพาะข้อมูลที่มีผลต่อการตัดสินใจ”
“จากข้อมูลต่อไปนี้ เขียน Weekly Report
แบ่งเป็น:
ใช้ Bullet Point และตอบกระชับ”
“เขียน Project Report สำหรับ [โครงการ]
ข้อมูล:
[Source]
แบ่งเป็น:
ห้ามสร้างสถานะหรือเปอร์เซ็นต์ความคืบหน้าที่ไม่มีข้อมูล”
“เขียน Incident Report จากข้อมูลนี้
แบ่งเป็น:
หาก Root Cause ยังไม่ยืนยัน ให้ระบุว่าอยู่ระหว่างตรวจสอบ”
หลังได้ Draft แล้วสามารถสั่ง:
“ทำ Executive Summary ให้สั้นลง”
“เปลี่ยน Results เป็นตาราง”
“เพิ่ม Action Owner”
“ลด Technical Detail”
“ขยาย Risk Section”
วิธีนี้ดีกว่าเริ่ม Generate ใหม่ทุกครั้ง
Microsoft Copilot ช่วยจัดรูปแบบ สรุป และร่างรายงานได้ดี แต่รายงานที่ใช้ตัดสินใจยังควรตรวจข้อมูลต้นทาง
โดยเฉพาะ
ตรวจอย่างน้อย:
ใช้ลำดับ:
ช่วยให้รายงานเป็นระบบมากกว่าการ Generate ครั้งเดียว
สูตรคือ:
Topic + Objective + Audience + Source + Structure + Analysis + Constraint
ตัวอย่าง:
“เขียนรายงานยอดขายเดือนกันยายนสำหรับผู้บริหาร โดยใช้ข้อมูลจากตารางที่ให้ แบ่งเป็น Executive Summary, KPI, Trend, Problems และ Next Actions และห้ามสร้างตัวเลขที่ไม่มีในตาราง”
Microsoft Copilot มีประโยชน์มากกับการเปลี่ยนข้อมูลจำนวนมากให้กลายเป็นรายงานที่มีโครงสร้าง แต่คุณภาพของรายงานขึ้นอยู่กับ Source, Objective และ Prompt ที่ให้ไปตั้งแต่ต้น
สำหรับผู้อ่าน comsiam สูตรที่ใช้ได้ง่ายคือ “Objective → Source → Findings → Analysis → Recommendation → Next Step” และควรแยกให้ชัดว่าอะไรคือข้อเท็จจริง อะไรคือการวิเคราะห์ และอะไรคือข้อเสนอแนะ
comsiam แนะนำให้ใช้ Copilot ช่วยทำ Outline, Draft, Summary และ Final Rewrite แต่ก่อนส่งรายงานจริงควรตรวจตัวเลข วันที่ ชื่อ และข้อสรุปกับ Source อีกครั้งเสมอ เพื่อให้รายงานทั้งอ่านง่ายและน่าเชื่อถือ