วงจรคำขอของลูกค้า: ทำแผนผังก่อนออกแบบหน้าจอ

ทำไมหน้าจอจึงล้มเหลวเมื่อไม่มีแผนผังคำขอ

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

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

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

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

การทำแผนผังเวิร์กโฟลว์คำขอช่วยเปิดเผยช่องว่างเหล่านี้ก่อนเริ่มออกแบบอินเทอร์เฟซ ทีมต้องตัดสินใจว่า:

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

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

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

เริ่มจากคำขอหนึ่งรายการและผลลัพธ์ที่ชัดเจน

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

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

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

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

คำจำกัดความสั้นๆ มักช่วยเปิดเผยกฎที่ขาดหายก่อนเริ่มออกแบบ:

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

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

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

ระบุสถานะที่คำขอสามารถเข้าไปอยู่ได้

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

คำขอด้านการสนับสนุนหรือบริการทั่วไปอาจมีสถานะดังนี้:

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

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

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

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

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

วาดการเปลี่ยนผ่านและระบุว่าใครเป็นผู้กระตุ้น

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

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

แผนผังง่ายๆ อาจมีการเปลี่ยนแปลงดังนี้:

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

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

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

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

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

กำหนดผู้รับผิดชอบในการส่งต่องานทุกครั้ง

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

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

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

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

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

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

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

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

กำหนดเวลาที่สอดคล้องกับงาน

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

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

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

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

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

นโยบายง่ายๆ อาจเป็นดังนี้:

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

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

วางแผนการแจ้งเตือนโดยไม่สร้างเสียงรบกวน

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

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

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

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

• ลูกค้า: "เราได้รับคำขออุปกรณ์ของคุณหมายเลข 1842 แล้ว เราจะตรวจสอบภายในวันอังคาร"
• ผู้ตรวจสอบ: "คำขอหมายเลข 1842 รอการอนุมัติจากคุณภายในวันอังคาร เวลา 15.00 น."
• ลูกค้า: "คำขอหมายเลข 1842 ได้รับอนุมัติแล้ว ทีมของเราจะกำหนดเวลาจัดส่งและอัปเดตคุณภายในวันศุกร์"

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

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

ติดตามคำขอของลูกค้าแบบง่ายๆ

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

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

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

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

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

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

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

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

ข้อผิดพลาดทั่วไปที่ทำให้เวิร์กโฟลว์สับสน

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

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

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

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

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

ก่อนออกแบบหน้าจอ ให้ทดสอบแต่ละส่วนของวงจรด้วยคำถามสี่ข้อ:

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

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

ตรวจสอบอย่างรวดเร็วก่อนออกแบบหน้าจอ

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

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

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

ใช้รายการตรวจสอบนี้:

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

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

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

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

เปลี่ยนแผนผังให้เป็นแอปพลิเคชัน

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

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

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

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

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

AppMaster สามารถเปลี่ยนการออกแบบนี้ให้เป็นแอปคำขอแบบ no-code ได้ Data Designer ช่วยสร้างโมเดลคำขอ ผู้ใช้ ทีม กำหนดเวลา และประวัติสถานะ Business Process Editor ช่วยกำหนดการมอบหมาย การเปลี่ยนสถานะ การเตือน และการยกระดับงาน ขณะที่หน้าจอเว็บหรือมือถือแบบเนทีฟรองรับคิวคำขอ หน้ารายละเอียด และรายงานสำหรับผู้จัดการ

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