แอปรับคำขอสำหรับบริษัทบริการวิชาชีพ: แผนปฏิบัติที่ใช้ได้จริง

ทำไมการรับข้อมูลที่กระจัดกระจายจึงทำให้งานล่าช้าโดยไม่จำเป็น

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

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

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

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

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

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

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

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

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

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

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

แยกคำถามสำหรับลูกค้าออกจากบันทึกภายใน

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

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

กำหนดสิทธิ์การมองเห็นก่อนสร้างเวิร์กโฟลว์:

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

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

กำหนดผู้รับผิดชอบให้ทุกขั้นตอน

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

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

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

เลือกบริบทของโครงการที่ควรเก็บ

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

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

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

เก็บข้อมูลเวลาและขอบเขตตั้งแต่ต้น

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

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

แบบฟอร์มรับข้อมูลโครงการที่ใช้งานได้จริงมักประกอบด้วย:

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

ลดช่องข้อมูลที่บังคับกรอกให้เหลือเท่าที่จำเป็น

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

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

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

เชื่อมโยงผู้ติดต่อของลูกค้ากับคำขอ

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

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

บันทึกบทบาทของแต่ละคน

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

ป้ายกำกับที่มีประโยชน์ ได้แก่:

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

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

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

ตรวจสอบองค์กรก่อนสร้างระเบียนใหม่

ให้พนักงานค้นหาองค์กรก่อนสร้างระเบียนใหม่ จับคู่จากชื่อบริษัท โดเมนอีเมล และหมายเลขโทรศัพท์เมื่อมีข้อมูล วิธีนี้ช่วยตรวจพบความแตกต่างเล็กๆ เช่น «Acme Ltd» กับ «Acme Limited» ซึ่งอาจทำให้ลูกค้ารายเดียวกันถูกแยกเป็นสองระเบียน

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

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

สร้างกระบวนการตรวจสอบความขัดแย้งที่ทำตามได้

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

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

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

ทำให้สถานะการตรวจสอบเห็นได้ชัด

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

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

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

บันทึกผลการตัดสินใจสั้นๆ

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

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

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

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

ถามเรื่องงบประมาณโดยไม่ทำให้การรับข้อมูลกลายเป็นการเสนอราคา

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

ใช้ช่วงงบประมาณที่สอดคล้องกับงานที่บริษัทรับ บริษัทที่ปรึกษาอาจเสนอ «ต่ำกว่า $10,000» «$10,000 ถึง $25,000» «$25,000 ถึง $75,000» และ «มากกว่า $75,000» ตัวเลือกควรกว้างพอให้ลูกค้าตอบได้อย่างรวดเร็ว

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

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

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

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

ตั้งค่าเวิร์กโฟลว์รับคำขอทีละขั้นตอน

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

เริ่มจากระเบียนคำขอ

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

ใช้สถานะที่บอกจุดตัดสินใจจริง:

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

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

ส่งต่อ มอบหมาย และแจ้งเตือน

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

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

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

ส่งต่องานที่อนุมัติแล้วไปยังกระบวนการถัดไป

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

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

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

ตัวอย่าง: จากการติดต่อครั้งแรกไปจนถึงการส่งต่องาน

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

เจ้าหน้าที่เพิ่ม Maya เป็นผู้ติดต่อหลัก จากนั้นเพิ่มผู้จัดการฝ่ายการเงินของ Northline ซึ่งจะอนุมัติการใช้จ่าย และผู้จัดการโครงการที่จะดูแลคำถามในแต่ละวัน แบบฟอร์มรับข้อมูลโครงการเก็บภูมิภาคที่จะขยาย เป้าหมายทางธุรกิจ กำหนดเปิดตัว และข้อจำกัดเบื้องต้น Maya ระบุวันที่ 30 กันยายนเป็นเป้าหมาย ให้ช่วงงบประมาณเบื้องต้น $75,000 ถึง $100,000 และแจ้งว่าบริษัทต้องนำเสนอคำแนะนำเบื้องต้นภายในสี่สัปดาห์

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

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

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

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

ข้อผิดพลาดที่พบบ่อยในการรับคำขอ

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

ขอข้อมูลมากเกินไปตั้งแต่ต้น

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

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

ปล่อยให้การตัดสินใจไม่มีเจ้าของ

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

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

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

เก็บคำถามเก่าไว้ตลอดไป

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

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

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

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

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

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

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

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

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