หมายเหตุ
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลอง ลงชื่อเข้าใช้หรือเปลี่ยนไดเรกทอรีได้
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลองเปลี่ยนไดเรกทอรีได้
บทความนี้แนะนำวิธีการอย่างเป็นทางการและไม่เป็นทางการในการสนับสนุนผู้ใช้โซลูชันต่างๆ รวมถึงแอป โฟลว์ และแชทบอท Power Platform
แผนภาพนี้แสดงกรอบการสนับสนุนและการสำเร็จการศึกษาทั่วไปสำหรับองค์กรต่างๆ
| Type | รายละเอียด |
|---|---|
|
การสนับสนุนตนเอง (ภายใน) เกิดขึ้นเมื่อผู้สร้างสนับสนุนโซลูชันของตนเอง ผู้ใช้โซลูชันรู้ว่าต้องติดต่อผู้สร้างเพื่อขอรับการสนับสนุน และมักจะไม่เห็นฝ่ายไอทีหรือทีมในระดับหรือชนิดของการสนับสนุนที่ผู้สร้างมีให้ |
|
การสนับสนุนโดยทีม (ภายใน) เกิดขึ้นเมื่อสมาชิกในทีมเรียนรู้จากกันและกันขณะที่พวกเขาพัฒนา Power Platform โซลูชัน สมาชิกในกลุ่มคนกลายเป็นเจ้าของร่วมของแอป โฟลว์ และแชทบอทของกลุ่มคน เจ้าของร่วมสามารถสนับสนุนการสอบถามของผู้ใช้และสามารถแก้ไขจุดบกพร่องและเปลี่ยนแปลงเล็กน้อยได้ แม้ว่าบางครั้งการสนับสนุนที่ช่วยเหลือทีมจะเกิดขึ้นอย่างไม่เป็นทางการ คุณควรทำให้กระบวนการนี้เป็นแบบแผนเมื่อการรับมาใช้และการเติบโตของคุณเติบโตเต็มที่ |
|
ฝ่ายสนับสนุนด้านบริการช่วยเหลือ (ภายใน) จัดการปัญหาและคำขอด้านการสนับสนุนอย่างเป็นทางการ ฝ่ายช่วยเหลือสามารถช่วยเหลือเกี่ยวกับคำถามต่างๆ เช่น วิธีการเข้าถึงแอปบนอุปกรณ์เคลื่อนที่ หรือวิธีขอเข้าถึงแหล่งข้อมูลแบ็กเอนด์ พวกเขาจะเปลี่ยนเส้นทางคำถามที่เกี่ยวข้องกับโซลูชันไปยังช่องทางที่สนับสนุนโซลูชัน |
|
การสนับสนุนเฉพาะ Power Platform (ภายใน) เกี่ยวข้องกับการจัดการปัญหาที่ซับซ้อนซึ่งส่งผลกระทบโดยฝ่ายช่วยเหลือ แอปพลิเคชันที่สำคัญจะถูกส่งไปยังกลุ่มคนนี้ และพวกเขาสามารถปรับใช้การแก้ไขจุดบกพร่องได้ |
|
การสนับสนุนจากพันธมิตร (ภายนอก) สามารถเสริมข้อเสนอการสนับสนุนภายในของคุณ และสนับสนุนแอปพลิเคชันที่สำคัญหรือทำงานร่วมกับแผนกเฉพาะเพื่อสนับสนุนแอปของพวกเขา เรียนรู้เพิ่มเติมใน รับความช่วยเหลือจากผู้เชี่ยวชาญ Power Apps พันธมิตร |
|
การสนับสนุนของ Microsoft (ภายนอก) สามารถใช้เพื่อยื่นปัญหาทางเทคนิคที่เกี่ยวข้องกับแพลตฟอร์มได้ ตามแผนการสนับสนุนของคุณ การสนับสนุนทางเทคนิคและบริการให้คำปรึกษาต่างๆ พร้อมให้บริการแก่คุณ เรียนรู้เพิ่มเติมใน การสนับสนุนสำหรับ Microsoft Power Platform |
ทำให้กรอบการสนับสนุนของคุณเป็นทางการ
ขึ้นอยู่กับขนาดขององค์กรของคุณและวิธีการจัดส่งที่มีอยู่สำหรับเทคโนโลยีแบบเขียนโค้ดเล็กน้อยและโค้ดระดับสูง คุณอาจเลือกวิธีต่างๆ ในการทำให้การสนับสนุนของคุณเป็นทางการ
กระจายอำนาจ: หาก Power Platform แนวทางการนำไปใช้ของคุณเป็นแบบ กระจายอำนาจเป็นส่วนใหญ่ คุณจะมีทีมงานอิสระทั่วทั้งองค์กรที่ทำหน้าที่ส่งมอบและควบคุม Power Platform โซลูชัน ด้วยโมเดลนี้ การสนับสนุนอาจได้รับการมอบหมาย และการสนับสนุนที่ช่วยเหลือโดยทีมอาจเป็นบริการที่เกี่ยวข้องที่สุดสำหรับผู้ใช้และผู้สร้าง
รวมศูนย์: หาก Power Platform แนวทางการนำไปใช้ของคุณเป็นแบบ รวมศูนย์เป็นส่วนใหญ่ คุณจะมีทีมงานส่วนกลางที่ประกอบด้วยเจ้าของผลิตภัณฑ์ซึ่งเป็นเจ้าของการส่งมอบโซลูชันแผนกต่างๆ ด้วยโค้ดต่ำจากหน่วยธุรกิจต่างๆ ทั่วทั้งองค์กร ด้วยแบบจำลองนี้ การสนับสนุนจะถูกรวมศูนย์และทีมสนับสนุนจากส่วนกลางจะตอบคำถามและข้อสงสัย
ในองค์กรส่วนใหญ่ การผสมผสานรูปแบบการส่งมอบให้ได้ผลดีที่สุด แม้ว่าทีมงานแบบกระจายอำนาจจะสนับสนุนโซลูชันให้กับผู้สร้าง แต่แผนกบริการช่วยเหลือและทีมสนับสนุนส่วนกลางอาจยังคงมีความจำเป็นสำหรับปัญหาทางเทคนิค คำถามของผู้ใช้ และการสนับสนุนระดับแรก
กำหนดระดับของแอปพลิเคชัน
เมื่อคุณกำหนดกระบวนการสนับสนุนและเส้นทางการยกระดับ สิ่งสำคัญคือการแบ่งประเภทโซลูชันตามความสำคัญ แนวทางนี้ช่วยให้คุณสามารถสร้างกระบวนการที่รับประกันว่าแอปพลิเคชันที่สำคัญมีการป้องกันที่จำเป็นในขณะที่หลีกเลี่ยงการขัดขวางนวัตกรรมในสถานการณ์ด้านประสิทธิภาพการผลิต
| ลักษณะและกระบวนการ | ประสิทธิภาพการทำงาน | สำคัญ | วิกฤต |
|---|---|---|---|
| กรณีการใช้งาน | ประสิทธิภาพการทำงานส่วนบุคคลและกรณีการใช้งานของทีมขนาดเล็กที่อาจใช้ข้อมูลที่มีอยู่ | แอปพลิเคชันทางธุรกิจที่เรียบง่ายหรือความคิดริเริ่มของทีม กระบวนการทำงานร่วมกันแบบสแตนด์อโลนขนาดเล็ก | แอปพลิเคชันทางธุรกิจที่ซับซ้อน ความคิดริเริ่มในระดับองค์กร หรือปริมาณงานที่สำคัญต่อภารกิจซึ่งอาจส่งผลกระทบอย่างมากต่อธุรกิจในช่วงเวลาหยุดทำงาน |
| ความซับซ้อน | กระบวนการอย่างง่าย | ความซับซ้อนปานกลาง | ความซับซ้อนสูง |
| ฐานผู้ใช้ | ฐานผู้ใช้ขนาดเล็ก: ผู้ใช้รายบุคคล เพื่อนร่วมงานโดยตรง หรือทีมงานขนาดเล็ก | กำหนดขอบเขตเป็นหน่วยธุรกิจ | ฐานผู้ใช้ขนาดใหญ่หรือการใช้งานทั่วทั้งองค์กร |
| วงจรชีวิตการพัฒนา | การวนซ้ำในระดับสูง | โดยปกติน้อยกว่าสามเดือนในการพัฒนา | วงจรการพัฒนาที่ยาวนานขึ้น |
| ผลกระทบ | ผลกระทบต่อธุรกิจต่ำ | สำคัญแต่ไม่มีความสำคัญทางธุรกิจ (ผลกระทบปานกลาง) | ผลกระทบทางธุรกิจสูง |
| เอแอลเอ็ม | ไม่จำเป็นต้องมีการจัดการวงจรชีวิตแอปพลิเคชัน | จำเป็นต้องมี ALM และอาจทำได้โดยการนำเข้า/ส่งออกโซลูชันด้วยตนเอง | จำเป็นต้องมีกระบวนการ ALM ที่แข็งแกร่ง ALM สำเร็จได้โดยใช้ Azure DevOps หรือ GitHub pipeline |
| กลยุทธ์ด้านสิ่งแวดล้อม | โซลูชันสร้างขึ้นในค่าเริ่มต้นหรือสภาพแวดล้อมการทำงานที่ใช้ร่วมกัน | สภาพแวดล้อมการพัฒนาเฉพาะ และสภาพแวดล้อมการทดสอบและการผลิตที่ใช้ร่วมกัน (แชร์กับโซลูชันอื่น เช่น เฉพาะหน่วยธุรกิจ) สภาพแวดล้อมได้รับการจัดการโดยหน่วยธุรกิจ (แบบกระจายอำนาจ) หรือโดยไอทีส่วนกลาง (แบบรวมศูนย์) | สภาพแวดล้อมการพัฒนา/การทดสอบ/การทำงานโดยเฉพาะ สภาพแวดล้อมได้รับการจัดการโดยไอทีส่วนกลาง |
| การอนุญาตของผู้สร้าง | ผู้สร้างมีบทบาทความปลอดภัยผู้สร้างสภาพแวดล้อมในสภาพแวดล้อม | ผู้สร้างมีบทบาทความปลอดภัยผู้สร้างสภาพแวดล้อมหรือเครื่องมือปรับแต่งระบบในสภาพแวดล้อมการพัฒนา แต่มีเฉพาะบทบาทความปลอดภัยผู้ใช้เท่านั้นในสภาพแวดล้อมการทดสอบและการใช้งานจริง โซลูชันอาจเป็นของลูกค้าองค์กรบริการหรือผู้ดูแลระบบสภาพแวดล้อมในการทดสอบและการใช้งานจริง | ผู้สร้างมีบทบาทความปลอดภัยผู้สร้างสภาพแวดล้อมหรือเครื่องมือปรับแต่งระบบในสภาพแวดล้อมการพัฒนา แต่มีเฉพาะบทบาทความปลอดภัยผู้ใช้เท่านั้นในสภาพแวดล้อมการทดสอบและการใช้งานจริง การปรับใช้โซลูชันเกิดขึ้นโดยอัตโนมัติและโซลูชันเป็นของผู้ให้บริการหลักในการทดสอบและการใช้งานจริง |
| การมีส่วนร่วมด้านไอที | ธรรมาภิบาลเชิงรับ ฝ่ายไอทีสามารถมองเห็นโซลูชันที่กำลังสร้างขึ้นและติดตามการใช้งาน | การทำงานของไอทีในระดับโซลูชันหรือผู้ใช้ ผู้สร้างให้รายละเอียดโซลูชัน เช่น วิธีแก้ปัญหาที่อาจเกิดขึ้นและแหล่งข้อมูลที่ใช้ | สภาพแวดล้อมการทำงานจริงจัดการโดยฝ่ายไอที |
| โมเดลสนับสนุน | สนับสนุนตนเอง | การช่วยเหลือทีมที่สนับสนุน | การสนับสนุนทางการ |
เมื่อกำหนดโมเดลการสนับสนุน โปรดพิจารณาเส้นทางการสำเร็จการศึกษา โซลูชันอาจเริ่มต้นด้วยการสนับสนุนในระดับผลิตภาพ แต่เติบโตในด้านฟังก์ชันการทำงานหรือฐานผู้ใช้จนต้องมีการสนับสนุนในระดับที่สำคัญ กำหนดวิธีที่ผู้สร้างสามารถขอการสนับสนุนที่เป็นทางการมากขึ้นและเปลี่ยนโซลูชันไปสู่สภาพแวดล้อมที่สนับสนุนได้
การสนับสนุนผู้สร้าง (การสนับสนุนตนเอง)
การสนับสนุนผู้สร้างหมายถึงผู้สร้างที่สนับสนุนแอปและโฟลว์ของตนเองที่สร้างขึ้นสำหรับตนเอง ทีมของตน หรือเพื่อนร่วมงานของตน การสนับสนุนได้แก่การตอบคำถามของผู้ใช้ การแก้ไขจุดบกพร่อง และการจัดการคำขอเปลี่ยนแปลง การสนับสนุนประเภทนี้เป็นแบบไม่เป็นทางการ โดยผู้ใช้มักรู้จักผู้ผลิตและติดต่อกับพวกเขาโดยตรง
สำคัญ
ในฐานะส่วนหนึ่งของการรับผู้ผลิตรายใหม่ ให้แน่ใจว่าผู้ผลิตทราบถึงเส้นทางการสนับสนุน การสำเร็จการศึกษา และการยกระดับ ผู้ผลิตที่เหนื่อยล้าจากการสนับสนุนโซลูชันระดับธุรกิจที่สำคัญของตนไม่สามารถสร้างสรรค์หรือสร้างสิ่งใหม่ๆ ได้ กำหนดวิธีที่ผู้ผลิตจัดระดับโซลูชันของตนไปสู่ระดับการสนับสนุนถัดไป และกระบวนการนั้นเกี่ยวข้องกับอะไร
นอกเหนือจากการสื่อสารกระบวนการเชิงรุกไปยังผู้ผลิตแล้ว ให้แน่ใจว่าคุณมีการกำกับดูแลเชิงรับเพื่อระบุโซลูชันที่มีการแชร์และใช้กันอย่างแพร่หลาย ซึ่งอาจมีความสำคัญต่อธุรกิจของคุณ ติดต่อผู้จัดทำเพื่อยืนยันว่าโซลูชันเหล่านั้นมีราวรองรับที่จำเป็น ใช้ การวิเคราะห์ระดับผู้เช่า เพื่อเรียนรู้เพิ่มเติมเกี่ยวกับการใช้งานแอปพลิเคชันของคุณ ส่งออกข้อมูลระยะไกลไปยังบัญชีที่จัดเก็บข้อมูลของคุณ เพื่อสร้างรายงานที่ได้รับการปรับปรุง หรือใช้ ชุดเริ่มต้น CoE เป็นจุดเริ่มต้น
การสนับสนุนที่ช่วยเหลือทีม
การสนับสนุนโดยความช่วยเหลือของทีมหมายถึงสมาชิกในทีมเป็นเจ้าของแอปและโฟลว์ร่วมกันที่สร้างขึ้นหรือใช้โดยทีมของพวกเขา และช่วยสนับสนุนโซลูชันเหล่านี้ในระหว่างการทำงานประจำวัน การสนับสนุนได้แก่การตอบคำถามจากผู้ใช้ การแก้ไขจุดบกพร่อง และการส่งคำขอเปลี่ยนแปลง ผู้สร้างที่กลายเป็น ผู้ชนะของคุณ มีแนวโน้มที่จะรับบทบาทสนับสนุนที่ไม่เป็นทางการชนิดนี้ด้วยความสมัครใจ เพราะพวกเขามีความต้องการที่จะช่วยเหลือโดยแท้จริง
แม้ว่าสิ่งนี้มักจะเริ่มต้นอย่างไม่เป็นทางการ แต่หลายองค์กรก็ทำให้การสนับสนุนที่ช่วยเหลือโดยทีมเป็นทางการเพื่อขยายความพยายาม Power Platform กระบวนการนี้เกี่ยวข้องกับหน่วยธุรกิจที่เป็นเจ้าของสภาพแวดล้อมเฉพาะของตนเอง การรับบทบาทผู้ดูแลสภาพแวดล้อม และการสนับสนุนโซลูชันในสภาพแวดล้อมเหล่านั้น ในองค์กรขนาดใหญ่ ทีมงานเฉพาะภายในแต่ละหน่วยธุรกิจจะรับบทบาทนี้ Power Platform
การสนับสนุนบริการความช่วยเหลือ
แผนกช่วยเหลือดำเนินการเป็นบริการร่วมกันโดยแผนกไอที
บริการความช่วยเหลือสามารถ:
- สนับสนุนปัญหาทางเทคนิคที่ไม่สามารถแก้ไขได้หากขาดการมีส่วนร่วมของฝ่ายไอที เช่น Power Platform ปัญหาด้านบริการที่จำเป็นต้องให้ผู้ดูแลระบบ ยื่นตั๋วการสนับสนุน ใน Power Platform ศูนย์ผู้ดูแลระบบ
- ตอบคำถามเกี่ยวกับผู้ใช้และการกำกับดูแล เช่น วิธีการขอเข้าถึงแอปพลิเคชัน หรือค้นหาแอปพลิเคชันได้จากที่ใด
- ส่งปัญหาเกี่ยวกับแอปที่สำคัญไปยังทีมสนับสนุนที่ถูกต้อง
ทีมสนับสนุน Power Platform เฉพาะ
เมื่อการนำไปใช้ของคุณเพิ่มมากขึ้นและผู้ผลิตพัฒนาโซลูชันที่สำคัญต่อธุรกิจมากขึ้น คุณอาจต้องมีทีมสนับสนุนเฉพาะ Power Platform
ทีมนี้ควรประกอบด้วยผู้เชี่ยวชาญ Power Platform ทางเทคนิคที่สามารถสนับสนุนปัญหาที่ซับซ้อนได้ ให้ทีมนี้มีส่วนร่วมในกระบวนการสนับสนุนผ่านเส้นทางที่กำหนดโดยใช้ตั๋วสนับสนุน
ทีมนี้จะสนับสนุนโซลูชัน Power Platform ภารกิจที่สำคัญที่เปิดตัวในสภาพแวดล้อมที่ได้รับการสนับสนุนโดยเฉพาะจากส่วนกลาง
หากโครงสร้างขององค์กรของคุณเป็นแบบกระจายอํานาจ ให้พิจารณาการสนับสนุนจากทีมช่วยเหลืออย่างเป็นทางการเพื่อให้สอดคล้องกับภูมิภาคหรือหน่วยธุรกิจของท้องถิ่น กับทีมสนับสนุน Power Platform ส่วนกลางที่ช่วยเหลือเฉพาะกับคิวรีที่ซับซ้อนหรือการกําหนดค่าส่วนกลางเช่น นโยบายข้อมูล ลูกค้าบางรายเลือกที่จะจ้างบุคคลภายนอกเพื่อให้บริการสนับสนุนระดับนี้แก่พันธมิตร
การจัดการคำขอโดยเป็นเพียงเส้นทางการยกระดับจากแผนกช่วยเหลือเป็นเรื่องยากที่จะบังคับใช้ เนื่องจากผู้เชี่ยวชาญด้านเทคนิคเหล่านี้มักเป็นที่รู้จักดีในหมู่ผู้ใช้ทางธุรกิจ Power Platform เพื่อเป็นการส่งเสริมลักษณะในการผ่านช่องทางที่เหมาะสม ทีมนี้ควรเปลี่ยนเส้นทางผู้ใช้ให้ส่งตั๋วบริการความช่วยเหลือ นอกจากนี้ยังจะปรับปรุงคุณภาพข้อมูลสำหรับการวิเคราะห์คำขอของบริการความช่วยเหลือ
การสนับสนุนคู่ค้า
ลูกค้าจำนวนมากเลือกที่จะทำงานร่วมกับคู่ค้าในการรับมาใช้ของ Power Platform ของพวกเขา รวมถึงการสนับสนุน ความร่วมมือนี้อาจรวมถึงความช่วยเหลือด้านการพัฒนาสำหรับผู้สร้าง ความช่วยเหลือในการจัดตั้ง CoE และขั้นตอนการสนับสนุนทางเทคนิค และการสนับสนุนทางเทคนิคตลอด 24 ชั่วโมงทุกวันสำหรับแอปที่สำคัญ
ฝ่ายสนับสนุนของ Microsoft
ฝ่ายสนับสนุนของ Microsoft ใช้เพื่อแจ้งปัญหาทางเทคนิคเกี่ยวกับแพลตฟอร์ม ตาม แผนการสนับสนุน ของคุณ การสนับสนุนทางเทคนิคและบริการให้คำปรึกษาต่างๆ พร้อมให้บริการแก่คุณ
เคล็ดลับ
ก่อนที่จะสร้างตั๋วการสนับสนุน โปรดตรวจสอบ Power Apps การสนับสนุน, Power Automate การสนับสนุน และ Microsoft Copilot Studio การสนับสนุน สำหรับปัญหาที่มีความสำคัญสูงซึ่งส่งผลกระทบต่อลูกค้าทุกคนเป็นวงกว้าง
ข้อควรพิจารณาและการดำเนินการหลัก
พิจารณาการดำเนินการที่สำคัญเหล่านี้เพื่อปรับปรุงโซลูชันที่รองรับโดยตนเองและโดยทีม:
- ให้การยอมรับและให้กำลังใจแก่ผู้สร้างของคุณ
- ให้แน่ใจว่าผู้ผลิตทราบถึงกระบวนการในการขยายโซลูชันของตนไปยังช่องทางการสนับสนุนที่เป็นทางการมากขึ้น
- จัดให้มีเวลาทำการ โอกาสในการให้คำปรึกษา และการฝึกอบรมสำหรับผู้สร้างเพื่อเพิ่มทักษะของตนอย่างต่อเนื่อง
- จัดทำเส้นทางการยกระดับเพื่อให้ผู้สร้างสามารถเชื่อมต่อกับ Power Platform ผู้เชี่ยวชาญด้านเทคนิค
- สร้าง ส่วนประกอบเทมเพลต สำหรับผู้สร้างเพื่อรวมไว้ในแอปของตน เช่น แบบฟอร์มสำหรับให้ผู้ใช้ติดต่อฝ่ายช่วยเหลือ
- ประเมินการจัดทำการสนับสนุนโดยทีมอย่างเป็นทางการตามปริมาณงานและจำนวนโซลูชันที่ต้องการการสนับสนุนในพื้นที่ทางธุรกิจที่เจาะจง
พิจารณาการดำเนินการที่สำคัญเหล่านี้เพื่อปรับปรุงการสนับสนุนแผนกบริการช่วยเหลือภายในของคุณ:
- กำหนดขอบเขตเริ่มต้นของหัวข้อ Power Platform ที่บริการความช่วยเหลือจะจัดการ
- ประเมินระดับความพร้อมของบริการความช่วยเหลือในการจัดการการสนับสนุน
- จัดให้มีการฝึกอบรมเพิ่มเติมแก่เจ้าหน้าที่ฝ่ายช่วยเหลือเพื่อแก้ไขช่องว่างความพร้อม
- กำหนดเส้นทางการยกระดับสำหรับคำขอที่แผนกช่วยเหลือไม่สามารถจัดการได้โดยตรง
- อัปเดตฐานความรู้ของบริการความช่วยเหลือสำหรับหัวข้อ Power Platform ที่เป็นที่รู้จัก ให้แน่ใจว่ามีคนรับผิดชอบในการอัปเดตฐานความรู้เป็นประจำเพื่อสะท้อนถึงคุณลักษณะใหม่และคุณลักษณะที่ได้รับการปรับปรุง ติดตามข้อมูลอัปเดตโดยสมัครรับฟีด RSS ของ Power Apps บล็อก, Power Automate บล็อกและ Microsoft Copilot Studio บล็อก
- ตรวจสอบให้แน่ใจว่ามีระบบการติดตามปัญหาที่ดี มักเป็นระบบจำหน่ายตั๋วที่สามารถจัดการระดับความสำคัญได้
- ตัดสินใจว่าจะมีใครรับสายเพื่อแก้ไขปัญหาใดๆ ที่เกี่ยวข้องกับ Power Platform หรือไม่ หากเหมาะสม ตรวจสอบให้แน่ใจว่าความคาดหวังสำหรับการสนับสนุนตลอด 24/7 นั้นชัดเจน
- กำหนด SLA ที่มีอยู่และให้แน่ใจว่ามีการแจ้งความคาดหวังสำหรับการตอบสนองและการแก้ไขปัญหาอย่างชัดเจน
- เตรียมพร้อมที่จะแก้ไขปัญหาทั่วไปที่เฉพาะเจาะจงอย่างรวดเร็ว ตัวอย่างเช่น คำขอใช้ตัวเชื่อมต่อใหม่ควรได้รับการจัดการอย่างรวดเร็ว การตอบสนองการสนับสนุนช้าอาจส่งผลให้ผู้ใช้ค้นหาวิธีแก้ปัญหา
- ตรวจสอบให้แน่ใจว่าบริการความช่วยเหลือของคุณมีบทบาทความปลอดภัยที่อนุญาตให้พวกเขา เพิ่มตั๋วสนับสนุนกับ Microsoft ตัดสินใจว่าบริการความช่วยเหลือหรือทีมสนับสนุนเฉพาะจะพิจารณาปัญหาเหล่านั้นหรือไม่
พิจารณาการดำเนินการที่สำคัญเหล่านี้เพื่อปรับปรุงการสนับสนุนเฉพาะภายในของคุณ: Power Platform
- กำหนดให้ชัดเจนว่าความรับผิดชอบของบริการความช่วยเหลือสิ้นสุดที่ใด และความรับผิดชอบในการสนับสนุนโดยเฉพาะเริ่มต้นที่ใด
- รับรองว่าทีมสนับสนุน Power Platform เฉพาะมีพาธการส่งต่อโดยตรงเพื่อเข้าถึงผู้ดูแลระบบส่วนกลางสำหรับ Microsoft 365 และ Azure ถือเป็นวิกฤตเมื่อเกิดปัญหาแพร่หลายที่เกินขอบเขต Power Platform ปัญหาต่างๆ ดังกล่าวอาจเกี่ยวข้องกับบัญชีผู้ใช้และการอนุญาต การกำหนดค่าเครือข่าย หรือแหล่งข้อมูลที่ใช้ในโซลูชัน Power Platform
- สร้างลูปข้อคิดเห็นจากทีมการสนับสนุนเฉพาะกลับไปที่บริการความช่วยเหลือเพื่อให้สามารถอัปเดตฐานข้อมูลองค์ความรู้ด้านไอทีได้ เป้าหมายคือเพื่อให้แผนกช่วยเหลือหลักมีอุปกรณ์ที่ดีขึ้นในการจัดการกับปัญหาต่างๆ มากขึ้นในอนาคต
- สร้างลูปข้อคิดเห็นจากบริการความช่วยเหลือไปยังทีมการสนับสนุนเฉพาะ เมื่อเจ้าหน้าที่ฝ่ายสนับสนุนสังเกตเห็นความซ้ำซ้อนหรือความไร้ประสิทธิภาพ พวกเขาสามารถสื่อสารข้อมูลนั้นไปยังทีมการสนับสนุนเฉพาะ ซึ่งอาจเลือกที่จะเปลี่ยนแปลงและปรับปรุงกระบวนการภายใน ตัวอย่างเช่น หากฝ่ายช่วยเหลือมีงานล้นมือในการสร้างและกำหนดค่าสภาพแวดล้อมใหม่สำหรับผู้สร้าง ทีมงานเฉพาะทางอาจพิจารณาการทำให้กระบวนการนี้เป็นแบบอัตโนมัติโดยใช้ส่วนประกอบการจัดการคำขอสภาพแวดล้อม Power Platform ใน CoE Starter Kit
- สร้างเส้นทางการยกระดับปัญหาสำหรับแต่ละบุคคลและทีมงานที่สนับสนุนโซลูชันของตนไปยังทีมสนับสนุนเฉพาะเพื่อปลดบล็อกปัญหาเมื่อพวกเขาเผชิญกับปัญหาที่ไม่สามารถแก้ไขได้ด้วยตนเอง
- สร้างเส้นทางการส่งมอบจากบุคคลและทีมงานที่สนับสนุนโซลูชันของตนไปยังทีมสนับสนุนเฉพาะเพื่อให้แอปพลิเคชันที่สำคัญสามารถเปลี่ยนผ่านได้
- ตัดสินใจเกี่ยวกับกลยุทธ์โดยรวมของคุณในการเปลี่ยนโซลูชันให้กับทีมงานเฉพาะ ตัวอย่างเช่น เมื่อจำนวนโซลูชันที่สำคัญและสำคัญของคุณเพิ่มขึ้น คุณจะเพิ่มพนักงานในทีมสนับสนุนเฉพาะหรือไม่ หรือคุณจะพึ่งพาหน่วยธุรกิจในการจัดหาพนักงานทีมสนับสนุนสำหรับพื้นที่ของตน