فرایند پاسخ‌گویی به شکایت باید برای مشتری قابل دسترس و برای تیم قابل پیگیری باشد. شکایت از لحظه دریافت تا بسته شدن یک مالک، مهلت، سابقه اقدام و مسیر ارجاع میخواهد. پاسخ سریع بدون بررسی می‌تواند اعتماد را کمتر کند و بررسی دقیق بدون خبر دادن به مشتری نیز تجربه بدی می‌سازد.
- تعریف واحدی از شکایت و کانال ثبت مرکزی داشته باشید.
- تأیید دریافت باید شماره پیگیری و زمان پاسخ بعدی را اعلام کند.
- سطح خطر و فوریت، مسیر و مسئول رسیدگی را تعیین می‌کند.
- علت‌های تکراری باید به اصلاح محصول یا فرایند برسند.
شکایت را چگونه تعریف کنیم؟
هر بیان نارضایتی که پاسخ یا اصلاح میخواهد باید قابل ثبت باشد. مشتری لازم نیست واژه شکایت را به کار ببرد. تفاوت پرسش، درخواست خدمت و شکایت برای مسیردهی مهم است، اما نباید مانع رسیدگی شود.
تعریف را با مثال در راهنمای کارکنان بنویسید. جمله «سه بار تماس گرفتم و هنوز حل نشده» شکایت است حتی اگر فرم خاصی پر نشده باشد.
مشتری را برای استفاده از عبارت رسمی مجبور نکنید.
کانال‌های دریافت چگونه یکپارچه شوند؟
ایمیل، تلفن، شبکه اجتماعی و حضوری باید به یک پرونده مرکزی برسند. شناسه یکتا از پاسخ تکراری و گم شدن سابقه جلوگیری می‌کند. دسترسی کارکنان باید بر اساس نقش و محرمانگی باشد.
فیلدهای اجباری محدود و کاربردی تعیین کنید. پیام شبکه اجتماعی می‌تواند با رضایت مشتری به پرونده پشتیبانی منتقل شود.
مشتری را وادار نکنید شرح خود را در هر کانال تکرار کند.
توضیح پایه این بخش در ISO 10002:2018، راهنمای رسیدگی به شکایت در سازمان‌ها آمده است. هنگام استفاده از آن، دامنه همان منبع و شرایط مسئله خود را هم در نظر بگیرید.
تأیید دریافت چه بگوید؟
شماره پیگیری، خلاصه موضوع، مسئول و زمان به‌روزرسانی بعدی را اعلام کند. پیام خودکار باید انتظاری واقعی بسازد. قول پاسخ نهایی در زمان غیرممکن اعتماد را کم می‌کند. کانال تماس و دسترسی نیز مشخص باشد.
در همان روز کاری یا بازه تعریف‌شده تأیید بفرستید. پیام می‌تواند بگوید پرونده تا ۲۴ ساعت بررسی اولیه و تا سه روز کاری پاسخ می‌گیرد.
عبارت «در اسرع وقت» را بدون زمان مشخص استفاده نکنید.
اولویت‌بندی چگونه انجام شود؟
شدت آسیب، فوریت، تعداد مشتریان و الزام قانونی معیارهای جدا هستند. خطر ایمنی، نقض داده یا خسارت گسترده باید سریع به سطح تخصصی برسد. ارزش خرید مشتری نباید تنها معیار اولویت باشد.
ماتریس شدت و فوریت با مثال بسازید. گزارش احتمال آلودگی محصول حتی از یک مشتری می‌تواند سطح بحرانی بگیرد.
شکایت پرصداتر را خودکار مهم‌تر ندانید.
توضیح پایه این بخش در GOV.UK، چک‌لیست پاسخ روشن و کامل به شکایت آمده است. هنگام استفاده از آن، دامنه همان منبع و شرایط مسئله خود را هم در نظر بگیرید.
مالک پرونده چه کسی است؟
یک نفر باید پاسخ‌گوی پیشرفت باشد، حتی اگر چند تیم تحقیق کنند. مالک پرونده اطلاعات را جمع، مهلت‌ها را پیگیری و ارتباط با مشتری را حفظ می‌کند. او لزوماً تصمیم‌گیر نهایی جبران نیست.
RACI و سطح اختیار هر نقش را ثبت کنید. پشتیبانی مالک ارتباط است و تیم فنی علت را بررسی می‌کند؛ هر دو مسئولیت روشن دارند.
پرونده را بدون نام میان واحدها پاس ندهید.
برای مطالعه موضوع نزدیک، راهنمای تفاوت NPS و رضایت مشتری را نیز ببینید.
بررسی منصفانه چه مراحلی دارد؟
ادعا، شواهد مشتری، سوابق سیستم و توضیح کارکنان باید جدا جمع شوند. پیش‌داوری بر اساس لحن مشتری یا دفاع فوری از همکار نتیجه را مخدوش می‌کند. حریم خصوصی و حداقل دسترسی رعایت شود.
خط زمانی رخداد و نقاط اختلاف را بنویسید. برای تأخیر سفارش، زمان وعده، اسکن لجستیک و تماس‌ها کنار هم بررسی می‌شوند.
اطلاعات غیرضروری شخصی درخواست نکنید.
پاسخ نهایی چه اجزایی دارد؟
پاسخ باید همه نکات، نتیجه بررسی، دلیل، اقدام و مسیر اعتراض را روشن کند. عذرخواهی باید برای خطای مشخص باشد. زبان ساده، نام مسئول و زمان اقدام بعدی به فهم کمک می‌کند. اگر شکایت رد می‌شود، دلیل قابل بررسی لازم است.
قبل از ارسال با چک‌لیست دقت و کامل بودن بازبینی کنید. به‌جای «مشکل رفع شد» بنویسید مبلغ چه زمانی بازمی‌گردد و چه اصلاحی انجام شده است.
متن حقوقی مبهم و پاسخ قالبی نفرستید.
جبران چگونه تعیین شود؟
جبران باید با نوع زیان، سیاست شرکت و اختیار نقش‌ها متناسب باشد. بازپرداخت، تعویض، انجام دوباره خدمت، اعتبار خرید یا توضیح رسمی گزینه‌های متفاوت‌اند. تصمیم‌ها باید سازگار و قابل استثنا با ثبت دلیل باشند.
جدول اختیار و سقف جبران برای هر سطح بسازید. برای کالای معیوب، تعویض یا بازپرداخت ممکن است مناسب‌تر از تخفیف خرید بعدی باشد.
کوپن را برای هر نوع زیان پاسخ کافی ندانید.
برای مطالعه موضوع نزدیک، راهنمای محاسبه شاخص رضایت مشتری CSAT را نیز ببینید.
چطور از شکایت برای بهبود استفاده کنیم؟
دستهبندی علت ریشهای و روندها باید به اقدام اصلاحی برسد. تعداد شکایت بدون حجم فروش یا شدت کافی نیست. نرخ تکرار، زمان حل، بازگشایی و رضایت پس از رسیدگی تصویر دقیقتری میدهند.
ماهانه سه علت پرتکرار و مالک اصلاح را مرور کنید. افزایش شکایت تحویل همراه داده تأخیر می‌تواند به تغییر قرارداد لجستیک منجر شود.
با بستن تیکت، مشکل فرایندی را بستهشده فرض نکنید.
راهنمای عملی مرحله‌به‌مرحله
ابتدا نقطه شروع را دقیق مشخص کنید. «شکایت را چگونه تعریف کنیم؟» را با وضعیت خود پاسخ دهید و تعریف را با مثال در راهنمای کارکنان بنویسید. سپس «کانال‌های دریافت چگونه یکپارچه شوند؟» را بررسی کنید. فیلدهای اجباری محدود و کاربردی تعیین کنید. اگر اطلاعات این دو مرحله کامل نیست، پیش از خرید، مصرف، اجرا یا پیگیری رسمی، همان اطلاعات را از سند، راهنمای معتبر یا بررسی مستقیم به دست آورید.
در مرحله اجرا، در همان روز کاری یا بازه تعریف‌شده تأیید بفرستید. ماتریس شدت و فوریت با مثال بسازید. این دو اقدام باید به ترتیب انجام شوند، زیرا نتیجه مرحله نخست می‌تواند انتخاب مرحله دوم را تغییر دهد. پیام می‌تواند بگوید پرونده تا ۲۴ ساعت بررسی اولیه و تا سه روز کاری پاسخ می‌گیرد. آنچه دیدید یا اندازه گرفتید را کوتاه و با تاریخ ثبت کنید تا بتوانید نتیجه را بعداً با شرایط مشابه مقایسه کنید.
در بازبینی میانی به پرسش «مالک پرونده چه کسی است؟» برگردید. RACI و سطح اختیار هر نقش را ثبت کنید. سپس «بررسی منصفانه چه مراحلی دارد؟» را جدا بسنجید و خط زمانی رخداد و نقاط اختلاف را بنویسید. پشتیبانی مالک ارتباط است و تیم فنی علت را بررسی می‌کند؛ هر دو مسئولیت روشن دارند. تغییر هم‌زمان چند عامل تشخیص این‌که کدام اقدام مفید بوده را دشوار می‌کند؛ برای هر تصمیم یک دلیل و یک نشانه قابل مشاهده بنویسید.
برای تصمیم پایانی، «پاسخ نهایی چه اجزایی دارد؟» و «جبران چگونه تعیین شود؟» را کنار هم بگذارید. قبل از ارسال با چک‌لیست دقت و کامل بودن بازبینی کنید. جدول اختیار و سقف جبران برای هر سطح بسازید. اگر نتیجه همچنان مبهم است، ماهانه سه علت پرتکرار و مالک اصلاح را مرور کنید. افزایش شکایت تحویل همراه داده تأخیر می‌تواند به تغییر قرارداد لجستیک منجر شود. کار را با معیار آغازین مقایسه کنید و روشن بنویسید ادامه می‌دهید، یک جزء را اصلاح می‌کنید یا برای بررسی تخصصی توقف می‌کنید.
چطور نتیجه را بسنجیم و تصمیم بگیریم؟
پیش از اقدام، یک وضعیت پایه بنویسید: اکنون چه چیزی می‌بینید، چه زمانی رخ می‌دهد و چه محدودیتی دارید. پاسخ پرسش «شکایت را چگونه تعریف کنیم؟» را با یک نمونه واقعی کامل کنید. مشتری لازم نیست واژه شکایت را به کار ببرد. تفاوت پرسش، درخواست خدمت و شکایت برای مسیردهی مهم است، اما نباید مانع رسیدگی شود. سپس معیار موفقیت را مشخص کنید؛ برای نمونه کاهش دفعات، کوتاه شدن زمان، بهتر شدن کیفیت یا روشن شدن یک تصمیم. بدون معیار پایه، تغییر بعدی بیشتر بر حافظه و احساس لحظه‌ای تکیه می‌کند.
در مرحله بعد فقط یک عامل را تغییر دهید. در همان روز کاری یا بازه تعریف‌شده تأیید بفرستید. نتیجه را در شرایط تا حد امکان مشابه بسنجید و کنار آن بنویسید چه چیزهایی ثابت نبوده‌اند. عبارت «در اسرع وقت» را بدون زمان مشخص استفاده نکنید. اگر چند تغییر هم‌زمان انجام شوند، حتی نتیجه خوب هم نشان نمی‌دهد کدام اقدام مؤثر بوده است. این روش برای موضوع‌های روزمره، فنی و آموزشی به یک اندازه از تصمیم عجولانه جلوگیری می‌کند.
برای تفسیر نتیجه، تفاوت میان هم‌زمانی و علت را حفظ کنید. مالک پرونده اطلاعات را جمع، مهلت‌ها را پیگیری و ارتباط با مشتری را حفظ می‌کند. او لزوماً تصمیم‌گیر نهایی جبران نیست. یک بار مشاهده می‌تواند سرنخ بسازد، اما برای نتیجه‌گیری کافی نیست. پشتیبانی مالک ارتباط است و تیم فنی علت را بررسی می‌کند؛ هر دو مسئولیت روشن دارند. اگر نتیجه با انتظار شما فرق داشت، داده را حذف نکنید؛ زمان، محیط، ابزار و شرایط انجام را دوباره بررسی کنید و توضیح محتمل دیگری را کنار فرض نخست بنویسید.
حد توقف را نیز از ابتدا تعیین کنید. متن حقوقی مبهم و پاسخ قالبی نفرستید. اگر نشانه خطر، هزینه پیش‌بینی‌نشده یا افت واضح کیفیت دیده شد، ادامه دادن فقط برای کامل کردن برنامه منطقی نیست. قبل از ارسال با چک‌لیست دقت و کامل بودن بازبینی کنید. توقف به معنی شکست نیست؛ گاهی نشان می‌دهد مسئله به اطلاعات بیشتر، ابزار مناسب‌تر یا نظر متخصص نیاز دارد. تصمیم ایمن باید امکان بازگشت و اصلاح داشته باشد.
در پایان، نتیجه را در سه جمله ثبت کنید: چه کاری انجام شد، چه چیزی تغییر کرد و گام بعدی چیست. تعداد شکایت بدون حجم فروش یا شدت کافی نیست. نرخ تکرار، زمان حل، بازگشایی و رضایت پس از رسیدگی تصویر دقیقتری میدهند. اگر شواهد کافی نیست، با صراحت وضعیت را «نامشخص» بنویسید و مشخص کنید برای روشن شدن چه داده‌ای کم دارید. افزایش شکایت تحویل همراه داده تأخیر می‌تواند به تغییر قرارداد لجستیک منجر شود. این جمع‌بندی کوتاه کمک می‌کند دفعه بعد همان مسیر بی‌نتیجه تکرار نشود و تصمیم تازه بر سابقه قابل بررسی بنا شود.
| مرحله | پرسش | اقدام |
|---|---|---|
| شروع | شکایت را چگونه تعریف کنیم؟ | تعریف را با مثال در راهنمای کارکنان بنویسید. |
| بررسی | مالک پرونده چه کسی است؟ | RACI و سطح اختیار هر نقش را ثبت کنید. |
| تصمیم | چطور از شکایت برای بهبود استفاده کنیم؟ | ماهانه سه علت پرتکرار و مالک اصلاح را مرور کنید. |
فرایند پاسخ‌گویی به شکایت باید برای مشتری قابل دسترس و برای تیم قابل پیگیری باشد. شکایت از لحظه دریافت تا بسته شدن یک مالک، مهلت، سابقه اقدام و مسیر ارجاع میخواهد. پاسخ سریع بدون بررسی می‌تواند اعتماد را کمتر کند و بررسی دقیق بدون خبر دادن به مشتری نیز تجربه بدی می‌سازد. با بستن تیکت، مشکل فرایندی را بستهشده فرض نکنید. معیار، شاهد و فرصت اصلاح را کنار هم ثبت کنید. برداشت شخصی مدیر بدون مثال یا بی‌توجه به ابزار و آموزش لازم، مبنای سنجش منصفانه نیست.
