คู่มือพรอมต์

วิธีใช้ Claude เขียนขั้นตอนการปฏิบัติงานมาตรฐาน

SOP ที่ดีช่วยให้คนที่ไม่เคยทำงานนี้มาก่อนทำได้อย่างถูกต้องในครั้งแรก

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

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

เผยแพร่เมื่อ

บทเรียนฟรี · ไม่ต้องมีบัญชีรู้จักกับ Claudeทำไมต้อง Claude?6 นาทีเริ่มบทเรียนฟรี

สรุปประเด็นสำคัญ

  • อธิบายกระบวนการตามที่คุณทำจริง ไม่ใช่เวอร์ชันสรุปที่สะอาดเรียบร้อย ขั้นตอนที่คุณข้ามเพราะเป็นไปโดยอัตโนมัติสำหรับคุณคือขั้นตอนที่พนักงานใหม่ต้องการเป็นลายลักษณ์อักษรพอดี
  • ให้ Claude รู้ชื่อจริง: เครื่องมือเฉพาะ ฟิลด์ที่แน่นอน ระบบที่ต้องเข้าสู่ระบบ ขั้นตอนที่บอกว่า "อัปเดตระบบ" ไม่มีประโยชน์สำหรับคนที่ยังไม่รู้ว่าระบบไหน
  • ชี้ให้เห็นจุดตัดสินใจอย่างชัดเจน กระบวนการที่มีการแยกแขนง "ถ้าคำขอต่ำกว่า 500 ดอลลาร์ ให้ทำ X ถ้าไม่ ให้ทำ Y" ต้องการให้แยกแขนงนั้นถูกระบุไว้ ไม่ใช่แค่บอกเป็นนัยจากบริบทที่มีแค่คุณคนเดียวที่รู้
  • ขอจุดเริ่มต้นและจุดสิ้นสุดที่ชัดเจน SOP ที่ไม่บอกว่างานเริ่มเมื่อไหร่และเสร็จจริงๆเมื่อไหร่จะทำให้ผู้อ่านต้องเดาว่าตนเองทำเสร็จแล้วหรือยัง
  • ลองทำตามร่างในขณะที่ทำงานนั้นจริงหนึ่งครั้งก่อนที่จะเผยแพร่ SOP ที่ดูดีบนหน้าจอแต่ข้ามขั้นตอนไปจะชัดเจนก็ต่อเมื่อมีคนลองทำตามลำดับจริงๆเท่านั้น
  • แยกเส้นทางปกติออกจากข้อยกเว้น การฝังกรณีข้อยกเว้นไว้กลางขั้นตอนหลักทำให้กรณีทั่วไปตามได้ยากขึ้นในเก้าสิบเปอร์เซ็นต์ของเวลาที่ข้อยกเว้นไม่ได้ใช้

คัดลอกไปใช้ได้เลย

พรอมต์ที่ใช้ได้ทันทีวันนี้

ร่างแรกจากการเดินผ่านกระบวนการ

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

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

เพิ่มจุดตัดสินใจที่ขั้นตอนขึ้นอยู่กับ

นี่คือร่าง SOP ของฉัน: [วางร่างของคุณ] ขั้นตอนที่ 4 แยกแขนงตามเงื่อนไขจริงๆ: ถ้า [เงื่อนไข] ขั้นตอนต่อไปคือ [X] ถ้าไม่ใช่ก็คือ [Y] เขียนขั้นตอนที่ 4 ใหม่เพื่อระบุการแยกแขนงนั้นให้ชัดเจน เพื่อให้คนที่ทำตาม SOP รู้ว่าทางไหนที่ใช้กับพวกเขาก่อนที่จะดำเนินการต่อ

ทำสิ่งนี้สำหรับทุกการแยกแขนงในกระบวนการจริง SOP ที่ซ่อนจุดตัดสินใจไว้ในขั้นตอนเดียวเป็นเหตุผลที่พบบ่อยที่สุดที่ทำให้คนเดินทางผิด

แยกกรณีปกติออกจากข้อยกเว้น

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

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

ทดสอบความเข้มงวดของ SOP เพื่อหาช่องว่าง

อ่านร่าง SOP นี้เหมือนกับว่าคุณไม่เคยทำงานนี้มาก่อนและกำลังทำตามมันเป็นครั้งแรก: [วางร่างของคุณ] ในแต่ละขั้นตอน บอกฉันทุกอย่างที่คุณจำเป็นต้องรู้ที่ไม่ได้ระบุไว้ คำศัพท์ใดๆที่ไม่ได้ให้คำจำกัดความ หรือจุดใดที่คุณจะไม่แน่ใจว่าทำขั้นตอนนั้นถูกต้องก่อนที่จะย้ายไปขั้นตอนต่อไป

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

ปรับ SOP หลังจากกระบวนการเปลี่ยนไป

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

การชี้ให้เห็นว่าอะไรเปลี่ยนไป แทนที่จะแทนที่ขั้นตอนเก่าอย่างเงียบๆ ช่วยให้คนที่จดจำเวอร์ชันก่อนหน้าสังเกตเห็นว่าอะไรแตกต่างไปจริงๆ

โครงสร้าง

สิ่งที่ SOP ที่ทำตามได้ต้องการจริงๆ

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

จุดเริ่มต้นและจุดสิ้นสุดที่ชัดเจน

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

ชื่อจริงสำหรับเครื่องมือจริง

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

จุดตัดสินใจที่ระบุไว้อย่างชัดเจน

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

ข้อยกเว้นที่แยกออกจากขั้นตอนหลัก

ให้เส้นทางปกติสั้นและเรียบร้อย และย้ายกรณีข้อยกเว้นไปยังส่วนของตัวเอง SOP ที่ฝังข้อยกเว้นไว้ในขั้นตอนหลักทำให้กรณีทั่วไปตามได้ยากขึ้น

ขั้นตอนที่คุณข้าม

เหตุใดกระบวนการที่คุณจะอธิบายในหนึ่งประโยคไม่ใช่กระบวนการที่จะให้ Claude

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

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

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

ข้อผิดพลาดที่พบบ่อย

สิ่งที่ทำให้ SOP ล้มเหลวในครั้งแรกที่มีคนใช้จริง

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

การอ้างอิงเครื่องมือที่คลุมเครือแทนชื่อจริง

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

การตัดสินใจที่ซ่อนไว้ถูกฝังในขั้นตอนเดียว

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

ไม่มีจุดสิ้นสุดที่ระบุไว้สำหรับงาน

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

ข้อยกเว้นผสมกับขั้นตอนหลัก

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

เก็บเนื้อหาที่เกี่ยวข้องไว้ด้วยกัน

เหตุใด SOP จึงได้ประโยชน์จากการอยู่ร่วมกับเอกสารที่เกี่ยวข้อง

ขั้นตอนการปฏิบัติงานมาตรฐานไม่ค่อยอยู่โดดเดี่ยว โดยปกติแล้วมันจะอ้างถึงนโยบายที่ต้องปฏิบัติตาม เวอร์ชันก่อนหน้าที่มันแทนที่ หรือขั้นตอนที่เกี่ยวข้องสำหรับงานที่แตกต่างแต่เชื่อมโยงกัน และการเก็บเอกสารเหล่านั้นไว้ใกล้กันระหว่างการร่างทำให้ผลลัพธ์มีความสอดคล้องกันมากกว่าการเขียน SOP แบบโดดเดี่ยวและหวังว่ามันจะสอดคล้องกับทุกอย่างอื่น ฟีเจอร์โปรเจกต์ของ Claude ให้คุณเก็บไฟล์ที่เกี่ยวข้องชุดหนึ่งไว้ในที่เดียว เพื่อให้การสนทนาแต่ละครั้งเกี่ยวกับ SOP สามารถอ้างอิงเนื้อหาพื้นฐานเดียวกันได้โดยไม่ต้องวางซ้ำทุกครั้ง ซึ่งมีการบันทึกไว้ในหน้าช่วยเหลือเรื่องโปรเจกต์ที่ support.claude.com

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

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

ก่อนที่จะเผยแพร่

สิ่งที่ต้องตรวจสอบก่อนที่ SOP จะกลายเป็นเวอร์ชันทางการ

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

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

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

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

SOP ที่ดีอยู่รอดจากผู้ใช้จริงคนแรกของมัน

การอธิบายกระบวนการอย่างละเอียดเพียงพอให้คนอื่นสามารถทำตามได้จริงเป็นทักษะการเขียนที่เฉพาะเจาะจง บทเรียนฟรีของ Nightschool AI ครอบคลุมงานเขียนในที่ทำงานจริงด้วย Claude รวมถึงการตัดสินใจเกี่ยวกับสิ่งที่ควรระบุและสิ่งที่ควรทิ้งไว้ในส่วนข้อยกเว้นแยกต่างหาก

คำถามที่พบบ่อย

สิ่งที่สำคัญที่สุดที่ต้องบอก Claude ก่อนที่มันจะร่าง SOP คืออะไร?

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

ฉันควรจัดการขั้นตอนที่ขึ้นอยู่กับเงื่อนไขอย่างไร?

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

ข้อยกเว้นควรผสมกับขั้นตอนหลักที่มีลำดับเลขหรือไม่?

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

ฉันจะรู้ได้อย่างไรว่าร่าง SOP ของฉันมีช่องว่างจริงๆ?

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

Claude สามารถช่วยให้ SOP สอดคล้องกับเอกสารนโยบายที่เกี่ยวข้องได้หรือไม่?

การเก็บทั้งสองไว้ในโปรเจกต์ Claude เดียวกัน ตามที่อธิบายไว้ในหน้าช่วยเหลือเรื่องโปรเจกต์ที่ support.claude.com ทำให้ง่ายขึ้นที่จะอ้างอิงนโยบายระหว่างการร่างและตรวจสอบความเบี่ยงเบนระหว่างสองอย่างในภายหลัง

SOP ควรบอกอะไรเกี่ยวกับเวลาที่งานเสร็จสิ้น?

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

ฉันควรอัปเดต SOP อย่างไรหลังจากกระบวนการจริงเปลี่ยนไป?

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

ใครควรตรวจสอบร่าง SOP ก่อนที่จะเผยแพร่?

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

SOP ทำงานได้ก็ต่อเมื่อคนใหม่สามารถทำตามได้จริง

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

Nightschool AI เป็นแพลตฟอร์มการเรียนรู้อิสระ ไม่มีส่วนเกี่ยวข้อง ได้รับการรับรอง หรือได้รับการสนับสนุนจาก Anthropic แต่อย่างใด Claude เป็นเครื่องหมายการค้าของ Anthropic, PBC กำลังมองหา Claude Academy อย่างเป็นทางการของ Anthropic อยู่ใช่ไหม ไปที่ academy.claude.com