สร้างแอปคำขอเดินทางพร้อมวงเงินอนุมัติ

ทำไมคำขอเดินทางของทีมจึงติดขัด

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

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

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

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

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

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

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

กำหนดหน้าที่ของแต่ละคนก่อนสร้างแอป

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

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

กำหนดสิ่งที่เปลี่ยนแปลงได้หลังส่งคำขอ

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

ตัวอย่างเช่น พนักงานส่งคำขอทริปไป Chicago มูลค่า $900 และผู้จัดการอนุมัติแล้ว หากยอดประมาณการเพิ่มเป็น $1,450 เพราะค่าโดยสารสูงขึ้น แอปควรแจ้งผู้จัดการและเก็บยอดเดิมไว้พร้อมเหตุผลของการเปลี่ยนแปลง

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

กำหนดขอบเขตการอนุมัติให้ชัดเจน

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

นโยบายง่ายๆ อาจกำหนดดังนี้:

• ผู้จัดการอนุมัติทริปของแผนกตนเองได้สูงสุด $1,000
• หัวหน้าแผนกอนุมัติคำขอระหว่าง $1,001 ถึง $3,000
• ฝ่ายการเงินตรวจสอบคำขอที่เกิน $3,000 ทริปต่างประเทศ และข้อยกเว้นของนโยบาย
• ผู้บริหารอนุมัติการเดินทางที่เกินงบประมาณของแผนก

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

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

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

เลือกฟิลด์สำหรับคำขอเดินทางแต่ละรายการ

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

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

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

แยกค่าใช้จ่ายโดยประมาณ

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

คำนวณยอดรวมโดยประมาณโดยอัตโนมัติ นักเดินทางที่ไป Berlin สองคืนอาจกรอกค่าเที่ยวบิน $320 ค่าโรงแรม $440 ค่าอาหาร $120 และการเดินทางในพื้นที่ $60 คำขอจะแสดงยอดประมาณการ $940 ขณะเดียวกันยังเห็นค่าใช้จ่ายทุกส่วน

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

เพิ่มหลักฐานและบริบทเมื่อจำเป็น

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

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

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

จัดการข้อยกเว้นของนโยบายอย่างโปร่งใส

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

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

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

ใช้ตัวเลือกเหตุผลจำนวนไม่มาก และเปิดพื้นที่ให้เพิ่มรายละเอียด:

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

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

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

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

สร้างวงเงินอนุมัติที่ทุกคนทำตามได้

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

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

• คำขอไม่เกิน $750 ส่งให้ผู้จัดการโดยตรง
• คำขอระหว่าง $751 ถึง $2,500 ส่งให้ผู้จัดการและหัวหน้าแผนก
• คำขอเกิน $2,500 ส่งให้ผู้จัดการ หัวหน้าแผนก และฝ่ายการเงิน
• คำขอที่อยู่นอกนโยบายส่งให้ฝ่ายการเงินไม่ว่าจะมีค่าใช้จ่ายเท่าใด

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

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

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

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

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

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

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

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

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

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

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

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

ระเบียนเดียวกันจึงติดตามทริปตั้งแต่ประมาณการครั้งแรกจนถึงรายงานค่าใช้จ่ายสุดท้าย

ตัวอย่าง: การไปพบลูกค้าที่มีข้อยกเว้น

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

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

Maya เลือกโรงแรมใกล้สำนักงานลูกค้า ราคาต่อคืนสูงกว่าเพดานนโยบาย $25 แต่โรงแรมที่ถูกกว่าจะทำให้ต้องเดินทางเพิ่มเที่ยวละ 45 นาทีและไม่รองรับการเช็กอินล่าช้า แอปจึงกำหนดให้เพิ่มหมายเหตุข้อยกเว้นก่อนส่งคำขอ เธอเขียนว่า «เวิร์กช็อปลูกค้าเริ่มเวลา 8:00 น. ทั้งสองวัน โรงแรมนี้อยู่ในระยะเดินถึงและรองรับการมาถึงล่าช้าหลังเที่ยวบินช่วงเย็น»

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

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

หลังจบทริป Maya เพิ่มลิงก์ใบเสร็จเที่ยวบิน ใบแจ้งหนี้โรงแรม และรายงานค่าใช้จ่าย เธอกรอกยอดจริงเป็น $1,792 ทีมจึงเปรียบเทียบยอดประมาณการกับค่าใช้จ่ายจริงได้ และเห็นว่าข้อยกเว้นค่าโรงแรมที่อนุมัติเพิ่มค่าใช้จ่าย $50 ขณะที่เที่ยวบินมีราคาต่ำกว่าที่คาดไว้

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

ข้อผิดพลาดที่ทำให้การอนุมัติมีปัญหา

กฎการอนุมัติจะล้มเหลวเมื่อไม่สอดคล้องกับวิธีเดินทางจริงของทีม ผู้จัดการฝ่ายขายอาจต้องอนุมัติการไปพบลูกค้ามูลค่า $1,800 ขณะที่หัวหน้าทีมสนับสนุนดูแลทริปภายในประเทศระยะสั้นที่ต่ำกว่า $500 วงเงินเดียวสำหรับทุกแผนกทำให้คำขอทั่วไปต้องรอนาน หรือส่งคำขอราคาแพงไปยังผู้ที่ไม่มีอำนาจด้านงบประมาณเพียงพอ

กำหนดวงเงินตามแผนก บทบาท ประเภททริป หรือใช้หลายปัจจัยร่วมกันเมื่อจำเป็น ให้เวอร์ชันแรกเรียบง่าย หัวหน้าทีมอาจอนุมัติทริปได้สูงสุด $750 หัวหน้าแผนกสูงสุด $2,500 และฝ่ายการเงินตรวจสอบรายการที่เกินกว่านั้น

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

ให้ตรวจสอบใหม่เมื่อ:

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

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

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

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

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

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

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

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

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

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

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

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

เริ่มจากเล็กๆ แล้วปรับปรุงกระบวนการ

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

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

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

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

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

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

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