ماتریس ارجاع پشتیبانی مشتری باید نشان دهد کارشناس چه چیزی را میتواند انجام دهد، برای چه تصمیمی به تأیید نیاز دارد و پس از ارجاع چه کسی پاسخ مشتری را میدهد. فهرست شماره داخلی افراد به تنهایی ماتریس ارجاع نیست. اگر اختیار مبهم باشد، پرونده بین واحدها میچرخد یا کارشناس برای پایان تماس وعده خارج از اختیار میدهد. این الگو باید با ساختار واقعی سازمان تکمیل شود.
تصمیمها را از موضوعات عمومی جدا کنید
عنوانهایی مانند «موضوع فنی» یا «موضوع مالی» بیش از حد کلیاند. بنویسید چه تصمیمی لازم است: تأیید اجرای راهکار، تغییر اطلاعات سفارش، بررسی استثنا یا پاسخ به شکایت درباره تعهد قبلی. حدود اختیار را با فعل روشن تعریف کنید؛ میتواند اطلاع دهد، میتواند درخواست ثبت کند یا میتواند اجرا را تأیید کند؟ ثبت درخواست و تأیید نتیجه دو سطح متفاوتاند و نباید در یک خانه مبهم قرار بگیرند.
مسئول تصمیم و مالک پرونده را مشخص کنید
ممکن است تصمیم نزد مدیر عملیات باشد اما ارتباط با مشتری در پشتیبانی بماند. در جدول، مرجع تصمیم و مسئول پیگیری پاسخ را جدا بنویسید. برای نبودن مسئول اصلی، جانشین مصوب لازم است. زمان پاسخ داخلی باید قابل پیگیری باشد، ولی کارشناس نباید آن را بدون بررسی به وعده حل مشتری تبدیل کند. اگر واحد دریافتکننده ارجاع را نمیپذیرد، مسیر رفع اختلاف باید به سرپرست معلوم باشد و پرونده معلق نماند.
جدول نمونه حدود اختیار و تحویل
عنوانهای زیر نمونهاند و تصمیم مجاز واقعی ایجاد نمیکنند. مسئول شرکت باید نام نقشها، سطح دسترسی و استثناهای مجاز را تأیید کند. برای هر پرونده نیز نام فرد مسئول ثبت شود تا ارجاع فقط به یک واحد کلی نباشد.
- نوع تصمیم نمونه: اجرای راهکار فنی حساس؛ کار مجاز دریافت اولیه: ثبت نشانه و اقدام قبلی؛ مرجع تصمیم در الگوی داخلی: مسئول فنی دارای اختیار؛ اطلاعات لازم برای ارجاع: اثر، زمان و نتیجه راهکارهای مصوب؛ مالک خبر به مشتری: کارشناس پرونده
- نوع تصمیم نمونه: تغییر مشخصات سفارش؛ کار مجاز دریافت اولیه: دریافت درخواست و بازخوانی؛ مرجع تصمیم در الگوی داخلی: مسئول عملیات سفارش؛ اطلاعات لازم برای ارجاع: مرحله ارسال و تغییر دقیق؛ مالک خبر به مشتری: مالک پرونده سفارش
- نوع تصمیم نمونه: درخواست استثنا در سیاست؛ کار مجاز دریافت اولیه: ثبت خواسته بدون وعده پذیرش؛ مرجع تصمیم در الگوی داخلی: مدیر تعیین شده در سیاست؛ اطلاعات لازم برای ارجاع: خواسته، دلیل و مرجع سیاست؛ مالک خبر به مشتری: مسئول رسیدگی
- نوع تصمیم نمونه: شکایت از تعهد قبلی؛ کار مجاز دریافت اولیه: ثبت موعد و خروجی وعده داده شده؛ مرجع تصمیم در الگوی داخلی: سرپرست مسئول تعهد؛ اطلاعات لازم برای ارجاع: سابقه وعده و اقدام انجام شده؛ مالک خبر به مشتری: مالک شکایت
دانلود همین جدول با قالب CSV سازگار با اکسل
متن تحویل را به یک سؤال مشخص ختم کنید
نمونه ارجاع: «مشتری درباره این مرحله درخواست تغییر دارد. وضعیت فعلی، خواسته دقیق و اقدام قبلی ثبت شده است. لطفاً امکان اجرای درخواست و محدودیت قابل اعلام را تأیید کنید.» سپس پذیرش مسئول دریافتکننده و موعد پاسخ داخلی را بگیرید. پروندهای که فقط به گروهی فرستاده شده اما کسی آن را نپذیرفته، تحویل کامل ندارد. اطلاعات مورد نیاز را یکجا بفرستید تا مشتری برای پاسخ به سؤال تکراری دوباره تماس نگیرد.
ماتریس را از پروندههای سرگردان اصلاح کنید
در مرور هفته، موارد ارجاع برگشتی و تصمیمهای بدون صاحب را بررسی کنید. اگر یک نوع درخواست همیشه بین دو واحد جابهجا میشود، مسئولیت و حدود اختیار را شفافتر کنید. تغییر نقش یا خروج همکار باید در جدول و مسیرهای وابسته منعکس شود. معیار کاربردی این است که کارشناس بداند قدم بعدی چیست و مشتری بداند چه کسی خبر میدهد؛ کوتاهشدن مسیر همراه با تصمیم درست اهمیت دارد، نه صرفاً کمشدن تعداد ارجاع روی گزارش.
ادامه مطالعه و بررسی فرایند تماس
برای مرتبطکردن این الگو با جریان کار تیم، راهنمای طراحی فرایند پشتیبانی تلفنی را بخوانید. برای بررسی تناسب اپراگپ با نیاز کسبوکارتان، معرفی و دموی اپراگپ را ببینید و سناریوی خود را مبنای ارزیابی قرار دهید.
موضوع مرتبط: راهنمای قابلیت مرتبط با این فرایند.