เปลี่ยนอีเมลแอดเดรร่วมเป็นแอปจัดการเคส

ทำไมอีเมลแอดเดรร่วมจึงสร้างความสับสน

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

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

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

อีเมลซ่อนความรับผิดชอบ

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

ทีมมักพยายามใช้แท็กในหัวข้อ เช่น "[Assigned: Mia]" หรือโฟลเดอร์ชื่อ "In progress" วิธีเหล่านี้ใช้ได้ก็ต่อเมื่อทุกคนทำตามขั้นตอนเดียวกันทุกครั้ง และจะเริ่มมีปัญหาเมื่อย้ายงานให้คนอื่นหรือมีหลายทีมเข้ามาช่วย

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

คำตอบซ้ำทำให้เสียทั้งเวลาและความไว้วางใจ

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

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

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

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

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

การจัดการเคสเปลี่ยนอะไรบ้าง

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

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

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

ระเบียนเดียวแทนหลายเธรด

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

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

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

บันทึกและประวัติอยู่กับคำขอ

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

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

สำรวจคำขอที่คุณได้รับในวันนี้

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

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

เปลี่ยนรูปแบบอีเมลให้เป็นประเภทเคส

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

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

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

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

ให้แต่ละคำขอมีที่อยู่

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

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

เลือกอีเมลแอดเดรสแรกที่จะเปลี่ยนจากปริมาณงานและความสับสน เริ่มจากกล่องจดหมายที่ได้รับคำขอซ้ำๆ และมีหลายคนตอบ เช่น it-support@ หรือ access@ ส่วนคำขอที่ไม่ปกติหรือมีความละเอียดอ่อนควรรอไว้ก่อน หากทีมยังตกลงกระบวนการไม่ได้

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

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

ตั้งค่าแอปทีละขั้นตอน

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

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

สร้างลำดับสถานะที่ทุกคนเข้าใจ

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

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

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

เพิ่มกฎการส่งต่อและเปลี่ยนผู้รับผิดชอบ

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

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

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

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

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

ส่งต่องานโดยไม่เกิดคำตอบซ้ำ

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

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

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

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

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

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

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

ตัวอย่าง: คำขอสิทธิ์ IT ภายใน

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

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

เคสจะเดินตามเส้นทางที่ชัดเจน

1. แอปส่งเคสให้ผู้จัดการของ Maya อนุมัติ
2. หลังได้รับอนุมัติ กฎการส่งต่อจะส่งเคสไปยังคิวสิทธิ์ IT
3. สมาชิกทีม IT รับเคสและกลายเป็นผู้รับผิดชอบ
4. ผู้รับผิดชอบให้สิทธิ์ บันทึกการดำเนินการ และปิดเคส

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

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

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

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

ข้อผิดพลาดที่พบบ่อยระหว่างเปลี่ยนระบบ

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

ทำให้ผู้รับผิดชอบมองเห็นได้เสมอ

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

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

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

ใช้ป้ายสถานะให้สม่ำเสมอ

เมนูสถานะที่ยาวทำให้สับสน ใช้ป้ายที่เข้าใจง่ายและกำหนดความหมายของแต่ละป้ายให้ชัดเจน

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

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

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

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

ตรวจสอบสั้นๆ ก่อนเปิดใช้งาน

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

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

ตรวจสอบกฎการมอบหมายกับคำขอทั่วไป การรีเซ็ตรหัสผ่านอาจส่งตรงไปยังฝ่ายสนับสนุน IT ส่วนใบอนุญาตซอฟต์แวร์ใหม่อาจต้องอนุมัติก่อน กำหนดกฎสำรองที่เข้าใจง่ายสำหรับเคสที่เข้าคิวผิด

ทดสอบมุมมองของแต่ละคน

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

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

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

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

ใช้รายการตรวจสอบนี้ก่อนเปิดใช้งาน

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

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

เลือกขั้นตอนถัดไป

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

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

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

สำหรับเวิร์กโฟลว์แรก ให้ใส่ฟิลด์ที่จำเป็นต่อการทำงาน

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

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

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

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