วิธีอัปเดตเอกสารให้เป็นปัจจุบันอยู่เสมอเมื่อ UI ของคุณเปลี่ยนแปลง

อัปเดตเมื่อ 3 พฤศจิกายน 2026

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

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

ทำไมเอกสารที่ล้าสมัยถึงสะสมเร็วขนาดนี้?#

เนื้อหาช่วยเหลืออธิบายถึงอินเทอร์เฟซ และอินเทอร์เฟซก็เปลี่ยนแปลงทุกรอบสปรินต์ สิ่งที่ทำให้สถานการณ์แย่ลงมี 3 ประการ:

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

นี่เป็นปัญหาที่วัดผลได้ เมื่อ Tella ตรวจสอบศูนย์ช่วยเหลือของตนเองในเดือนตุลาคม 2026 พบว่า วิดีโอในบทความช่วยเหลือ 32 จาก 76 รายการ (42%) ล้าสมัย (เป็นการตรวจสอบเนื้อหาของตนเองโดยผู้ให้บริการ) และผู้อ่านก็สังเกตเห็นได้: ในการสำรวจลูกค้า 5,728 รายของ Gartner พบว่ามีเพียง 14% ของปัญหาการบริการที่ได้รับการแก้ไขอย่างสมบูรณ์ผ่านบริการตนเอง และเหตุผลที่พบบ่อยที่สุดของความล้มเหลว (43%) คือการไม่พบเนื้อหาที่เกี่ยวข้องกับปัญหา บทความที่ล้าสมัยยิ่งเพิ่มปัญหานี้: เนื้อหาที่ไม่ตรงกับหน้าจออีกต่อไปก็ไม่ต่างอะไรกับการไม่มีเนื้อหาเลย

ต้นทุนตกอยู่ที่ทีมสนับสนุน เพราะลูกค้ามักจะลองอ่านเอกสารก่อน Harvard Business Review รายงานในปี 2017 ว่า 81% ของลูกค้าพยายามแก้ไขปัญหาด้วยตนเองก่อนที่จะติดต่อเจ้าหน้าที่ ขั้นตอนที่ล้าสมัยมักกลายเป็นตั๋วแจ้งปัญหา ดูตัวเลขเพิ่มเติมได้ใน สถิติการบริการตนเองของลูกค้า ของเรา

พื้นฐานอะไรบ้างที่ช่วยให้เอกสารเป็นปัจจุบันอยู่เสมอ?#

ไม่ว่าคุณจะใช้เครื่องมือใด นิสัย 4 ประการนี้จะช่วยจัดการงานส่วนใหญ่ได้:

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

ส่วนที่เหลือของคู่มือนี้คือกิจวัตรการอัปเดตตามรอบการปล่อยฟีเจอร์ที่อยู่เหนือพื้นฐานเหล่านั้น

คุณจะทราบได้อย่างไรว่าบทความและวิดีโอใดบ้างที่ล้าสมัยจากการปล่อยฟีเจอร์?#

รายการชื่อบทความไม่สามารถบอกคุณได้ว่าการปล่อยฟีเจอร์ทำให้ส่วนใดเสียหาย แต่รายการหน้าจอทำได้ ให้สร้างรายการสินค้าคงคลังโดยแบ่งตามบทความหรือวิดีโอ และแท็กด้วยหน้าจอ หน้าเว็บ หรือส่วนประกอบที่แสดงในนั้น โดยใช้ชื่อเดียวกับที่ทีมผลิตภัณฑ์ของคุณใช้ในตั๋วและบันทึกการปล่อยฟีเจอร์ ("การตั้งค่าการเรียกเก็บเงิน", "หน้าต่างเชิญ", "แถบนำทางด้านซ้าย")

ในวันปล่อยฟีเจอร์ ให้อ่านบันทึกการปล่อยฟีเจอร์ (หรือ Pull Request ที่รวมเข้าด้วยกันและระบุว่าเป็นส่วนที่ผู้ใช้เห็น) เทียบกับคอลัมน์ "หน้าจอที่แสดง" จากนั้นเพิ่มสัญญาณราคาประหยัดสองประการที่บันทึกการปล่อยฟีเจอร์อาจมองข้ามไป:

1. ค้นหาป้ายกำกับที่ถูกเปลี่ยนชื่อในศูนย์ช่วยเหลือของคุณ หาก "Workspace" เปลี่ยนเป็น "Team" ให้ค้นหาคำว่า "Workspace" ในบทความและสคริปต์วิดีโอทั้งหมด
2. ติดตามตั๋วแจ้งปัญหาเป็นเวลา 14 วันหลังการปล่อยฟีเจอร์ วลีเช่น "ในวิดีโอแสดงว่า", "ฉันหาปุ่มไม่เจอ" หรือ "บทความบอกว่า" เป็นตัวชี้เป้าเนื้อหาที่การคัดกรองพลาดไป

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

การเปลี่ยนแปลงประเภทไหน? คัดกรองเป็น 4 ระดับ#

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

กฎสองข้อจะช่วยให้การคัดกรองมีความซื่อตรง ประการแรก ตัดสินระดับตามสิ่งที่ผู้อ่านเห็น ไม่ใช่สิ่งที่นักออกแบบเปลี่ยน: หากป้ายกำกับเดิมยังมองเห็นได้ชัดเจนในวิดีโอ ให้ถือว่าเป็นระดับ 2 เพราะการแก้ไขคำบรรยายเพียงอย่างเดียวจะทำให้วิดีโอแสดงคำหนึ่งแต่พูดอีกคำหนึ่ง ประการที่สอง ตรวจสอบ Feature Flags หากเลย์เอาต์ใหม่กำลังถูกปล่อยให้ผู้ใช้ 20% เนื้อหาเดิมยังคงถูกต้องสำหรับผู้อ่านอีก 80% ให้รออัปเดตเมื่อการปล่อยฟีเจอร์ถึงทุกคน หรือเผยแพร่ทั้งสองเวอร์ชันและระบุว่าเวอร์ชันใดใช้กับใคร

คุณจะอัปเดตบทความช่วยเหลือเมื่อ UI เปลี่ยนแปลงได้อย่างไร?#

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

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

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

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

ตรวจสอบว่าโฮสต์ของคุณสามารถแก้ไขไฟล์เดิมได้หรือไม่ YouTube Studio ช่วยให้คุณ ตัดต่อวิดีโอที่เผยแพร่ไปแล้วได้โดยที่ URL ยอดวิว และความคิดเห็นยังคงเดิม แต่การใช้ฟุตเทจใหม่หมายถึงการอัปโหลดใหม่และ URL ใหม่ ส่วน Vimeo ระบุว่า การแทนที่ไฟล์วิดีโอจะยังคงลิงก์และโค้ดฝังตัวเดิมไว้ และ การแทนที่สื่อ ของ Wistia จะคงโค้ดฝังตัวไว้เช่นกัน แม้ว่าจะมีการสร้างคำบรรยายใหม่ก็ตาม

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

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

ค่าใช้จ่ายในการบันทึกวิดีโอเว็บแอปใหม่ของเรา: ประมาณ 2 นาทีและ 9 เครดิต#

เพื่อให้เห็นภาพค่าใช้จ่ายในการบันทึกใหม่ เราได้ใช้เครื่องมือบันทึก AI ของ Clevera กับแอปเดโมสาธารณะ (TodoMVC) ในเดือนตุลาคม 2026 คำสั่งประกอบด้วยสามประโยค: เพิ่มรายการสิ่งที่ต้องทำสามรายการ, ทำเครื่องหมายว่าเสร็จสิ้นหนึ่งรายการ, จากนั้นคลิกตัวกรอง Active ข้อความนั้นคือการบันทึกใหม่ทั้งหมด บันทึกไว้ในคลังของคุณ และในวันปล่อยอัปเดต คุณเพียงแค่วางข้อความนั้นอีกครั้ง แก้ไขเฉพาะขั้นตอนที่เปลี่ยนไปแล้วเริ่มการทำงาน การตั้งค่าบัญชีเดโมและคำสั่งครอบคลุมอยู่ใน วิธีบันทึกเดโมเว็บแอปโดยอัตโนมัติ

วิดีโอแนะนำความยาว 0:40 ที่ Clevera สร้างจากการบันทึกด้วย AI นั้น โดยไม่มีการตัดต่อ

เอเจนต์ทำตามคำสั่งโดยไม่มีการลองใหม่หรือคลิกผิดที่เราพบ การบันทึกใช้เวลาประมาณ 78 วินาที และการสร้างวิดีโอความยาว 0:40 ใช้เวลาอีกประมาณ 50 วินาที โดยมีค่าใช้จ่าย 9 เครดิต: 5 เครดิตสำหรับการวิเคราะห์การบันทึก และ 4 เครดิตสำหรับวิดีโอแนะนำ มีข้อควรระวังสองประการ: ราคานี้เป็นสำหรับการบันทึกใหม่ ไม่ใช่การเขียนใหม่หลังจากเปลี่ยนขั้นตอน และเอเจนต์จะหยุดพักระหว่างขั้นตอน (ฟุตเทจ 58 วินาทีสำหรับงานที่คนทำในเวลาประมาณ 20 วินาที) ดังนั้นควรตรวจสอบการบันทึกใหม่แต่ละครั้งก่อนนำไปใช้งานจริง

แล้วเรื่องการแปลและฟีเจอร์ที่ยกเลิกไปล่ะ?#

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

ยกเลิกการใช้งาน อย่าเพียงแค่ลบ เมื่อฟีเจอร์ถูกลบออก ให้เก็บถาวรบทความนั้น เปลี่ยนเส้นทาง URL เก่าไปยังหน้าที่ใกล้เคียงที่สุดในปัจจุบัน และลบวิดีโอออกจากทุกที่ใน "Where it lives" หน้าที่ถูกลบไปแล้วแต่ลูกค้ายังบุ๊กมาร์กไว้อยู่จะกลายเป็น 404 และกลายเป็นตั๋วแจ้งปัญหา

ใครควรเป็นเจ้าของอัปเดตเอกสาร และบ่อยแค่ไหน?#

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

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

คุณจะวัดผลได้อย่างไรว่าเอกสารของคุณเป็นปัจจุบัน?#

เลือกตัวเลขสองหรือสามตัวแล้วตรวจสอบหลังจากปล่อยอัปเดตแต่ละครั้ง:

• ตรวจสอบแล้วตั้งแต่รุ่นล่าสุด: รายการที่มีวันที่ "ตรวจสอบล่าสุด" หลังจากรุ่นล่าสุด หารด้วยรายการที่มีหน้าจอที่รุ่นนั้นเกี่ยวข้อง ตั้งเป้าหมายที่ 100% สำหรับรายการระดับ 2 และ 3 ภายในหนึ่งสัปดาห์
• จำนวนวันในการแก้ไข: ค่ามัธยฐานของจำนวนวันตั้งแต่ปล่อยอัปเดตจนถึงการแก้ไขที่ใช้งานจริง ตามระดับ
• ตั๋วที่ระบุว่าเอกสารผิด: ตั๋วที่แท็กว่า "บทความผิด" หรือ "วิดีโอไม่อัปเดต" ในช่วง 14 วันหลังจากปล่อยอัปเดต หากต้องการเชื่อมโยงสิ่งนี้กับการลดจำนวนตั๋ว โปรดดู วิธีวัดอัตราการลดตั๋วสนับสนุน
• การค้นหาที่ล้มเหลวและการให้คะแนนต่ำ: การค้นหาที่ไม่พบผลลัพธ์และการโหวต "ไม่เป็นประโยชน์" ในหน้าที่เปลี่ยนไป คู่มือของเราเรื่อง การค้นหาช่องว่างของเนื้อหาในศูนย์ช่วยเหลือ จะแสดงวิธีจัดการกับปัญหาเหล่านี้

คุณสามารถอัปเดตเอกสารโดยอัตโนมัติได้หรือไม่?#

ได้บางส่วน สิ่งที่คุณสามารถทำให้อัตโนมัติได้ในปัจจุบัน:

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

Clevera ช่วยให้เอกสารและวิดีโอเป็นปัจจุบันได้อย่างไร#

Clevera เป็นแพลตฟอร์ม AI ที่เปลี่ยนการบันทึกหน้าจอให้เป็นวิดีโอแนะนำพร้อมคำบรรยาย บทความช่วยเหลือทีละขั้นตอน และหน้าในศูนย์ช่วยเหลือที่คุณโฮสต์ไว้ ใน 74 ภาษา โดยมีสี่ส่วนที่สอดคล้องกับกระบวนการข้างต้น:

• LiveSync (ทุกแผน). แก้ไขคำบรรยายวิดีโอที่เผยแพร่แล้ว ข้อความบนหน้าจอ ไฮไลท์ หรือการเบลอ และทุกลิงก์แชร์ของ Clevera โค้ดฝังตัว และหน้าศูนย์ช่วยเหลือที่แสดงวิดีโอนั้นจะเล่นเวอร์ชันใหม่ ส่วนไฟล์ MP4 ที่ดาวน์โหลดไปแล้วจะยังคงเป็นเวอร์ชันเดิม
• การบันทึกใหม่. บันทึกขั้นตอนที่เปลี่ยนไปด้วยแอปเดสก์ท็อปบน Mac, Windows หรือ Linux หรือปล่อยให้ เครื่องบันทึกหน้าจอ AI คลิกผ่านเว็บแอปสาธารณะจากคำสั่งที่คุณบันทึกไว้ในคลัง Clevera จะเขียนสคริปต์ เสียงพากย์ และบทความที่ตรงกันจากการบันทึกใหม่ จากนั้นคุณค่อยแปลเวอร์ชันภาษาอังกฤษที่เสร็จสมบูรณ์อีกครั้ง ในราคา 3 ถึง 10 เครดิตต่อภาษา (องค์ประกอบข้อความที่คุณเพิ่มเองจะไม่ถูกแปล; ดู วิธีแปลวิดีโอสอนการใช้งาน สำหรับเคล็ดลับการตรวจสอบในแต่ละภาษา)
• Autopilot (Pro และ Custom). Autopilot จะคอยตรวจสอบรุ่นอัปเดตหรือ Pull Request ที่รวมเข้าแล้วใน GitHub repository หรือหน้าบันทึกการเปลี่ยนแปลงของคุณ และตรวจสอบวิดีโอและบทความในศูนย์ช่วยเหลือเทียบกับการเปลี่ยนแปลงแต่ละอย่าง สำหรับทุกรายการที่อ่านจนจบ ระบบจะเสนอ "ยังถูกต้องอยู่", การแก้ไขข้อความ หรือการบันทึกหน้าจอที่เปลี่ยนไปใหม่ (เมื่อคุณอนุญาตให้เข้าถึงแอปของคุณ) วิดีโอที่บันทึกใหม่จะแทนที่วิดีโอเก่าที่ลิงก์เดิม
• ผู้ช่วย AI (Pro ขึ้นไป). หากทีมของคุณทำงานใน Claude Code, Cursor หรือ ChatGPT พวกเขาสามารถอัปเดตบทความ Clevera และสร้างวิดีโอผ่าน MCP server ของ Clevera ได้

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

ส่วนที่ Clevera อาจไม่ตอบโจทย์: หากเอกสารของคุณเป็น API reference ที่สร้างจากโค้ดโดยตรง แนวทาง docs-as-code จะเป็นเครื่องมือที่เหมาะสมกว่า และหากเนื้อหาช่วยเหลือของคุณอยู่ในแพลตฟอร์มอื่นที่คุณไม่คิดจะย้ายออก การสร้างวิดีโอและบทความของ Clevera ก็ยังช่วยได้ แต่ฟีเจอร์ Autopilot จะทำงานร่วมกับศูนย์ช่วยเหลือและวิดีโอที่โฮสต์บน Clevera เท่านั้น

เริ่มใช้งานฟรี: แผน Free มาพร้อมศูนย์ช่วยเหลือแบบโฮสต์และวิดีโอความยาวสูงสุด 3 นาที สำหรับภาพรวมในการสร้างศูนย์ช่วยเหลือด้วยตัวเอง โปรดดู วิธีสร้างฐานความรู้ด้วย AI และ ซอฟต์แวร์ศูนย์ช่วยเหลือของ Clevera หากคุณมี AI ผู้ช่วยตอบคำถามเกี่ยวกับผลิตภัณฑ์อยู่แล้ว การเตรียมเอกสารให้พร้อมสำหรับ AI คือก้าวถัดไปที่คุณควรทำ

รายการตรวจสอบวันปล่อยฟีเจอร์#

คัดลอกรายการนี้ไปใส่ในเทมเพลตการปล่อยฟีเจอร์ของคุณ

• บันทึกการปล่อยฟีเจอร์ระบุหน้าจอที่เปลี่ยนแปลงทั้งหมด โดยใช้ชื่อตามรายการสินค้า
• ตรวจสอบฟีเจอร์แฟล็ก: ระบุเปอร์เซ็นต์การเปิดใช้งาน; อัปเดตเมื่อครบ 100% (หรือเผยแพร่ทั้งสองเวอร์ชัน)
• ค้นหาชื่อเรียกเก่าที่อาจหลงเหลืออยู่ในบทความและสคริปต์วิดีโอ
• แท็กรายการที่ได้รับผลกระทบแต่ละรายการว่าเป็น L0 (ความสวยงาม), L1 (ชื่อเรียก), L2 (เลย์เอาต์) หรือ L3 (ขั้นตอนการทำงาน)
• L1: เปลี่ยนชื่อเรียก, ถ่ายภาพหน้าจอใหม่, แก้ไขเสียงบรรยายและข้อความบนหน้าจอ
• L2/L3: บันทึกขั้นตอนการทำงานใหม่; เขียนใหม่หรือสร้างขั้นตอนในบทความขึ้นใหม่
• แทนที่วิดีโอใหม่ในทุกลิงก์, การฝัง (embed) และวิดเจ็ต
• ค้นหาและแทนที่ไฟล์ที่ดาวน์โหลดไปแล้ว (LMS, สไลด์นำเสนอ, อีเมล)
• อนุมัติเนื้อหาภาษาอังกฤษ จากนั้นจึงดำเนินการแปลใหม่
• อัปเดตรายการสินค้า: วันที่ตรวจสอบล่าสุด, เจ้าของ, คำแนะนำในการบันทึก
• ตรวจสอบตั๋วที่ระบุปัญหาเกี่ยวกับเอกสารภายใน 14 วันหลังการปล่อยฟีเจอร์

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

ควรปรับปรุงเอกสารบ่อยแค่ไหน?#

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

ใครควรเป็นผู้รับผิดชอบในการทำให้เอกสารเป็นปัจจุบัน?#

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

ฉันต้องบันทึกวิดีโอสอนการใช้งานใหม่ทุกครั้งที่ UI เปลี่ยนแปลงหรือไม่?#

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

ฉันจะค้นหาบทความช่วยเหลือที่ล้าสมัยได้อย่างไร?#

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