ตัวติดตามที่นั่งใบอนุญาตซอฟต์แวร์: ตรวจสอบที่นั่งและการต่อสัญญา

ทำไมที่นั่งใบอนุญาตถึงยุ่งได้เร็วขนาดนี้

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

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

เมื่อระบบพัง คุณจะเห็นมันได้ในสามด้าน:

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

ทีมต่างๆ จะรู้สึกต่างกันไป ฝ่ายการเงินถูกเซอร์ไพรส์ด้วยการต่อสัญญาและคาดการณ์ค่าใช้จ่ายไม่ได้ IT และปฏิบัติการจะได้ตั๋วด่วน “เพิ่มที่นั่งอีกคนวันนี้” แล้วถูกตำหนิเมื่อการเข้าถึงไม่สม่ำเสมอ หัวหน้าทีมไล่ตามการอนุมัติ พนักงานย้ายไปมาระหว่างเครื่องมือโดยไม่มีเจ้าของชัดเจน

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

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

คำศัพท์สำคัญ: ที่นั่ง การต่อสัญญา และการปรับยอด (true-up)

การเข้าใจคำศัพท์ตั้งแต่ต้นช่วยลดการถกเถียง ผู้ขายใช้คำที่คล้ายกันแต่ความหมายอาจต่างกัน

“ที่นั่ง” คือสิทธิ์ของคนหนึ่งคนที่จะใช้ผลิตภัณฑ์ ส่วนใหญ่ขายเป็นที่นั่งแบบระบุชื่อ (named user) ผูกกับคนหนึ่งคน (เช่น [email protected]) ที่นั่งแบบ concurrent ต่างกัน: จำกัดจำนวนคนที่สามารถล็อกอินพร้อมกัน แม้ว่าจะมีบัญชีมากกว่าก็ตาม

คุณมักจะเจอโมเดลสามแบบ:

• ระบุชื่อ (Named user): คนหนึ่งคน หนึ่งที่นั่ง ไม่ว่าจะใช้งานหรือไม่
• ผู้ใช้พร้อมกัน (Concurrent user): ที่นั่งใช้ร่วมกัน จำกัดโดยเซสชันที่ใช้งาน
• ตามบทบาทหรือโมดูล: การเข้าถึงคิดราคาโดยชุดฟีเจอร์หรือระดับ

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

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

ต้องติดตามอะไร (ข้อมูลขั้นต่ำที่สำคัญ)

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

ฟิลด์ขั้นต่ำที่ควรเก็บ

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

• พื้นฐานแอป: ชื่อแอป เจ้าของภายใน ราคาต่อที่นั่ง วันที่เริ่มสัญญา วันที่สิ้นสุดสัญญา
• การมอบที่นั่ง: ผู้ใช้ ทีม บทบาท (หรือระดับไลเซนส์) สถานะที่นั่ง (Active, Pending removal, Unassigned)
• สัญญาณการใช้งาน: วันที่กิจกรรมล่าสุด (หรือการเข้าสู่ระบบล่าสุด) และแหล่งที่มาของตัวเลขนั้น
• การตั้งค่าการเรียกเก็บเงิน: รอบการออกใบแจ้งหนี้ (รายเดือน รายปี) การต่ออัตโนมัติ เปิด/ปิด ระยะเวลาที่ต้องแจ้งล่วงหน้า (วัน)
• หลักฐาน: แหล่งที่เชื่อถือได้สำหรับแต่ละฟิลด์สำคัญ (SSO directory, export จากผู้ดูแล, ใบแจ้งหนี้)

ด้วยเท่านี้ คุณก็สามารถตอบคำถามที่คนมักถามได้: “ทีมไหนถือ 40 ที่นั่ง?” “มีกี่ที่นั่งที่ยังไม่ได้มอบ?” “อะไรต่ออายุเดือนหน้า?”

หลักฐานสำคัญกว่าความสมบูรณ์แบบ

ตัวติดตามจะเสียความเชื่อถือเมื่อไม่มีใครบอกได้ว่าตัวเลขมาจากไหน เพิ่มบันทึกแหล่งที่มาง่ายๆ แม้แค่ “Okta export จาก 12 ม.ค.” หรือ “PDF ใบแจ้งหนี้ รายการที่ 3” เมื่อต่อมาฝ่ายการเงินกับ IT ขัดแย้งกัน คุณจะคลี่คลายได้เร็ว

ตัวอย่าง: คุณเห็น 15 ที่นั่ง Active สำหรับเครื่องมือออกแบบ แต่กิจกรรมล่าสุดว่างสำหรับครึ่งหนึ่ง ถ้าหลักฐานบอกว่า “คอนโซลแอดมินไม่แสดงการเข้าสู่ระบบล่าสุด” คุณจะรู้ว่าช่องว่างมาจากแหล่งข้อมูล ไม่ใช่ตัวติดตาม นั่นทำให้การตัดสินใจชัดเจน: ดึงสัญญาณจากล็อก SSO หรือเก็บขั้นตอนการตรวจด้วยตนเอง

ถ้าคุณสร้างสิ่งนี้ใน AppMaster เริ่มจากการจำลองฟิลด์เหล่านี้ในตารางง่ายๆ แล้วเพิ่มการทำงานอัตโนมัติหลังจากพื้นฐานถูกต้อง

แหล่งข้อมูลมาจากที่ไหนและทำอย่างไรให้เชื่อถือได้

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

แหล่งข้อมูลทั่วไปคือ HR (รายชื่อพนักงานและวันที่เข้า/ออก), SSO/IdP (ใครล็อกอินได้), คอนโซลแอดมินของผู้ขาย (การมอบที่นั่งและบทบาท) และใบแจ้งหนี้หรือสัญญา (วันที่ต่อสัญญา จำนวน ราคา) กุญแจคือความสม่ำเสมอ: อย่าใช้แหล่งข้อมูลผสมกันสำหรับฟิลด์เดียว

ฐานข้อมูลที่สะอาดมีลักษณะดังนี้:

• คนและสถานะการจ้าง: รายชื่อ HR
• อีเมล/ตัวตนการเข้าสู่ระบบ: SSO/IdP
• การมอบที่นั่งและระดับแผน: คอนโซลแอดมินผู้ขาย
• ต้นทุน ระยะสัญญา วันที่ต่อสัญญา: ใบแจ้งหนี้หรือสัญญา
• ความเป็นเจ้าของทีม: กฎองค์กรที่เลือก (แผนก ศูนย์ต้นทุน หรือผู้จัดการ)

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

การแมปทีมเป็นจุดที่ตัวติดตามมักเน่า เลือกกฎที่อยู่รอดจากการปรับโครงสร้าง (ตัวอย่าง “ทีม = ศูนย์ต้นทุน” หรือ “ทีม = ผู้จัดการโดยตรง”) จดไว้ และใช้ทุกที่

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

ทีละขั้นตอน: สร้างรากฐานตัวติดตามที่นั่งของคุณ

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

1) สร้างสองตารางง่ายๆ

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

เก็บข้อมูลใน Apps ให้เป็นข้อเท็จจริงที่ไม่อยากให้คัดลอก: ผู้ขาย แผน รอบการเรียกเก็บ วันที่ต่อสัญญา และบันทึกต้นทุน เก็บ Seats ให้เน้นการมอบ: ผู้ใช้ ทีม บทบาท/ระดับ วันที่มอบ และสัญญาณการใช้งาน (แม้จะเป็นแบบแมนนวลก่อน)

2) มาตรฐานสถานะตั้งแต่วันแรก

สถานะป้องกันการถกเถียงทีหลัง ใช้ชุดเล็กๆ ที่มีความหมายชัดเจน:

• Active: ที่นั่งที่จ่ายแล้ว คนต้องการมัน
• Inactive: ไม่ถูกใช้งานเมื่อเร็วๆ นี้ ต้องการตรวจสอบ
• Pending removal: เจ้าของอนุมัติการลบ รอกำหนดการ
• Removed: ที่นั่งถูกเรียกคืน บันทึกวันที่

3) เพิ่มฟิลด์การต่อสัญญาและการปรับยอดที่ขับเคลื่อนการดำเนินการ

สำหรับแต่ละแอป ติดตาม วันที่ต่อสัญญา ระยะเวลาที่ต้องแจ้งล่วงหน้า (เช่น 30 วัน) และ เจ้าของการต่อสัญญา ที่ระบุชื่อบุคคล (ไม่ใช่ “IT”) ถ้าใช้ true-up ให้เพิ่ม วันที่ true-up และบันทึกว่าอะไรถือเป็นที่นั่งที่ต้องเรียกเก็บ

4) สร้างสามวิวที่คุณจะใช้จริง

สร้างวิวที่ตรงกับงานจริง: แยกตามทีม (สำหรับผู้จัดการ), แยกตามแอป (สำหรับ IT/การเงิน), และการต่อสัญญาที่กำลังจะมาถึง (เรียงตามหน้าต่างการแจ้ง)

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

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

วิธีหาที่นั่งที่ไม่ได้ใช้โดยไม่ทำให้เวิร์กโฟลว์พัง

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

นิยาม “ไม่ได้ใช้” ให้เหมาะกับเครื่องมือ

เริ่มจาก 1-2 สัญญาณที่วัดได้เชื่อถือได้: วันที่เข้าสู่ระบบล่าสุด กิจกรรมสำคัญล่าสุด (สร้างตั๋ว รันรายงาน ผลักโค้ด) หรือว่าผู้ใช้ยังเข้าถึงโปรเจกต์ที่ใช้งานอยู่หรือไม่

คำนิยามเริ่มต้นภาคปฏิบัติคือ “ไม่ล็อกอินใน 60 วัน และไม่มีกิจกรรมใน 90 วัน” ทำให้เรียบง่าย แล้วปรับถ้ามีผลบวกเท็จ

ถ้าต้องการค่าธรณีประตูเริ่มต้น ให้ใช้:

• 30 วัน: เครื่องมือใช้งานทุกวัน (แชท กล่องจดหมายสนับสนุน)
• 60 วัน: เครื่องมือใช้งานเป็นสัปดาห์ (ออกแบบ วิเคราะห์)
• 90 วัน: เครื่องมือใช้งานเป็นครั้งคราว (การเงิน การปฏิบัติตาม)
• ยาวกว่า: ระบบตามฤดูกาลหรือสิ้นไตรมาส

ลบการเข้าถึงอย่างปลอดภัยด้วยคิวการตรวจสอบ

แทนที่จะลบอัตโนมัติ ให้สร้างคิวการตรวจสอบและให้ผู้จัดการยืนยัน นั่นปกป้องเวิร์กโฟลว์และหลีกเลี่ยงคำถาม “ใครล็อกฉันออก?”

กระบวนการน้ำหนักเบามักเพียงพอ:

• ทำเครื่องหมายผู้สมัครตามเกณฑ์
• แจ้งผู้จัดการพร้อมเหตุผลสั้นๆ (เช่น ไม่ล็อกอินใน 90 วัน)
• เสนอสามทางเลือก: เก็บ ลดระดับ หรือเรียกคืน
• กำหนดเส้นตาย (5-10 วันทำการ)
• บันทึกการตัดสินใจสุดท้ายและวันที่

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

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

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

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

ตั้งบันไดการเตือนที่สอดคล้องกับระยะเวลาในการทำงานจริง:

• 90 วัน: ยืนยันเจ้าของ เงื่อนไขสัญญา และระยะเวลาที่ต้องแจ้ง
• 60 วัน: ทบทวนการใช้งานและเลือกแผน (ลด เก็บ หรือขยาย)
• 30 วัน: ล็อกจำนวนที่นั่งเป้าหมายและเริ่มเอกสารจัดซื้อ
• 14 วัน: ยืนยันการเปลี่ยนแปลงและเตรียมการต่อสัญญา

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

True-up ต้องมีจุดตรวจของตัวเอง เพิ่มจุดกลางเทอม (ครึ่งทางของสัญญา) เพื่อจับการเพิ่มที่นั่งช้าๆ และอีกครั้ง 30 วันก่อนการต่อสัญญาเพื่อให้จำนวนสุดท้ายอิงจากความเป็นจริง

ทำให้การแจ้งเตือนทุกฉบับสามารถดำเนินการได้ ข้อความเตือนที่มีประโยชน์รวมเจ้าของ แผน จำนวน (ซื้อ เทียบกับมอบหมาย เทียบกับใช้งาน) เส้นตายการแจ้ง และขั้นตอนถัดไปชัดเจน เช่น “เรียกคืน 12 ที่นั่ง” หรือ “ขอใบเสนอราคา”

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

ความผิดพลาดและกับดักที่พบบ่อย

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

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

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

การออกจากงานยังอาจย้อนกลับได้เมื่อที่นั่งถูกลบโดยไม่ได้ตรวจสอบบัญชีร่วมหรือบัญชีบริการ: support@ กล่องเมล API user บอท คีออสก์ การลบสิ่งเหล่านี้อาจทำให้เวิร์กโฟลว์พังและต้องรีแอคทีฟเร่งด่วน

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

กับดักความสะอาดของข้อมูล

การเปลี่ยนชื่อทีมฟังดูเล็กแต่ทำให้การรายงานใช้ไม่ได้ “Sales” “Sales Ops” และ “Revenue” อาจเป็นทีมเดียวกันหรือสามทีมต่างกัน เลือกกฎการตั้งชื่อแล้วยึดติด

เพื่อลดการเบี้ยว ให้มาตรฐานฟิลด์ไม่กี่อย่างและจำกัดข้อความอิสระ:

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

ตัวอย่าง: บริษัทตัดที่นั่งไม่ได้ใช้งาน 15 ที่ก่อนการต่อสัญญ แล้วพบว่า 5 ในนั้นเป็นบัญชีบริการผูกกับระบบอัตโนมัติ ถ้าสร้างตัวติดตามใน AppMaster การมีช่องเช็กบ็อกซ์ “บัญชีบริการ” และฟิลด์เหตุผลสั้นๆ จะบังคับให้ตรวจสอบก่อนจะทำอะไรพัง

เช็คลิสต์รายเดือนอย่างรวดเร็ว

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

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

การตรวจสอบรายเดือน 15 นาที

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

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

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

ตัวอย่าง: ทำความสะอาดที่นั่งก่อนการต่อสัญญาไตรมาส

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

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

สำหรับเครื่องมือระบบสนับสนุน วงจรเป็นดังนี้:

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

ระหว่างการตรวจสอบ พวกเขาพบรายละเอียดสัญญาที่เปลี่ยนแผน: มีขั้นต่ำรายปี แต่เรียกเก็บรายไตรมาส ขณะนี้เกินขั้นต่ำ 10 ที่ และมีคน 18 คนที่จะเข้าร่วมทีมสนับสนุนเดือนหน้า นั่นคือความเสี่ยง true-up

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

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

ขั้นตอนถัดไป: เริ่มเล็กแล้วค่อยอัตโนมัติ

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

กิจวัตรที่คุณทำได้จริง:

• ระบุที่นั่งทุกที่สำหรับห้าเครื่องมือชั้นนำตามผู้ใช้ (หรือแยกตามทีมถ้านั่นคือข้อมูลที่มี)
• กำหนดเจ้าของหนึ่งคนต่อเครื่องมือ (คนที่สามารถอนุมัติการเปลี่ยนแปลง)
• ตั้งหน้าต่างเตือนแรกเป็น 90 วันก่อนการต่อสัญญาหรือ true-up
• นิยาม “ไม่ได้ใช้งาน” (เช่น ไม่ล็อกอินใน 30-60 วัน)
• ตรวจทานและดำเนินการสัปดาห์ละครั้ง (10-15 นาที)

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

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

เมื่อพร้อมก้าวเกินสเปรดชีต AppMaster (appmaster.io) เป็นหนึ่งในตัวเลือกสำหรับเปลี่ยนสิ่งนี้เป็นแอปภายในที่พร้อมใช้งานจริง มีฐานข้อมูลจริง การเข้าถึงตามบทบาท และการเตือนและการอนุมัติอัตโนมัติ