صبح دوشنبه، سرپرست یکی از شعب یک زنجیره رستوران با فروشنده تماس می‌گیرد: ماشین ظرف‌شویی صنعتی وسط شیفت متوقف شده است. فروشنده قول می‌دهد متخصص تا ظهر تماس بگیرد و عکس خطا را در پیام شخصی برای متخصص می‌فرستد. متخصص تصور می‌کند همکار خدمات پرونده را گرفته است. ساعت دو مشتری دوباره زنگ می‌زند و همه سؤال‌های صبح را از نو جواب می‌دهد. مشکل فنی هنوز همان است. آشفتگی داخل شرکت یک مشکل تازه هم ساخته است. پشتیبانی یکجا یعنی هر درخواست، یک سابقه مشترک و یک مسئول روشن داشته باشد. تیم باید بداند مشتری چه گفته، اثر مشکل چیست، اکنون کار دست چه کسی است و پاسخ بعدی چه زمانی می‌رسد. «یکجا» لزوما به معنی جمع شدن خودکار ایمیل، تلفن، پیام‌رسان و چت در یک صندوق نیست. حتی اگر درخواست‌ها دستی وارد شوند، یک پرونده مشترک می‌تواند جلوی پاسخ‌های موازی و قول‌های گمشده را بگیرد.
CRM کوتاه‌شده Customer Relationship Management و به معنای مدیریت ارتباط با مشتری است. تیکت هم نام پرونده قابل پیگیری یک درخواست است؛ موضوع، مسئول، وضعیت و قدم بعدی آن تا رسیدن به نتیجه روشن می‌ماند. در این مقاله «درخواست» حرف یا نیاز مشتری است و «تیکت» روشی برای دنبال کردن آن درخواست.
هر درخواست فقط یک پرونده اصلی داشته باشد
مشتری ممکن است صبح به فروشنده زنگ بزند و بعد عکس را برای متخصص بفرستد. اگر هر پیام به یک کار جدا تبدیل شود، دو نفر پاسخ می‌دهند یا هر دو منتظر دیگری می‌مانند. همان ابتدا مشخص کنید کدام پرونده مرجع است. پیام‌ها و کارهای مرتبط باید به همان موضوع برگردند، حتی اگر چند همکار در حل آن نقش دارند. برای درخواست ماشین ظرف‌شویی، یک خلاصه مفید چنین چیزهایی دارد: نام شرکت و شعبه، شخص رابط، زمان شروع مشکل، نشانه یا کد خطا، اثر روی کار رستوران، کاری که تا این لحظه امتحان شده، وعده‌ای که به مشتری داده‌اید و اقدام بعدی. این فهرست روش تیم است. لازم نیست همه موارد را بدون فکر به فرم بلند تبدیل کنید. فقط چیزی را بگیرید که در تشخیص، پاسخ یا تحویل لازم است.
یک شرکت می‌تواند هم‌زمان چند درخواست داشته باشد. خرابی دستگاه شعبه ونک با پرسش واحد مالی درباره صورت‌حساب یک موضوع نیست. آنها را زیر یک تیکت مبهم «مشکلات مشتری» جمع نکنید. پرونده مشتری رابطه کلی را نگه می‌دارد و هر درخواست مسیر و نتیجه خودش را دارد.
دریافت درخواست با پاسخ واقعی فرق دارد
ثبت تیکت به مشتری نشان نمی‌دهد چه کسی مسئله را فهمیده است. نخستین پاسخ معنادار باید بگوید درخواست دیده شده، برداشت تیم از مشکل چیست و قدم بعدی چه زمانی انجام می‌شود. پیام خودکار «درخواست شما ثبت شد» اگر فقط رسید باشد، جای پاسخ کارشناس را نمی‌گیرد. در سناریوی ما، پاسخ روشن می‌تواند این باشد: «خرابی مربوط به توقف دستگاه هنگام شست‌وشوست و عکس خطا رسید. متخصص خدمات تا ساعت سه برای بررسی اولیه تماس می‌گیرد. اگر بازدید لازم باشد، زمان پیشنهادی را در همان تماس می‌گوییم.» مشتری اکنون می‌داند شرکت چه فهمیده و چه چیزی هنوز قطعی نیست.
پیش از قول زمان، ساعات کاری، دسترسی به متخصص و شرایط قرارداد خدمت خودتان را ببینید. یک عدد یکسان برای همه نوع درخواست نسازید. پرسش ساده کاربری با توقف دستگاه در شیفت کاری اثر یکسانی ندارد. قولی بدهید که تیم توان انجامش را دارد و همان موعد را در اقدام بعدی بنویسید.
فوریت را از اثر مسئله بفهمید
بلندترین صدا همیشه فوری‌ترین درخواست نیست. اثر مشکل بر کار مشتری را بپرسید. آیا فعالیت اصلی متوقف شده است؟ آیا راه موقت امن و قابل قبول وجود دارد؟ چند شعبه درگیرند؟ آیا موعد بیرونی مانند بازرسی یا مراسم نزدیک است؟ پاسخ این سؤال‌ها اولویت را روشن‌تر از نام مشتری یا تعداد تماس‌های او می‌کند.
| وضعیت اثر | نمونه در رستوران | تصمیم نخست تیم |
|---|---|---|
| توقف جدی | دستگاه اصلی از کار افتاده و جایگزین عملی وجود ندارد | مسئول پاسخ را فوری روشن کنید و زمان بررسی متخصص را اعلام کنید |
| اختلال با راه موقت | ظرفیت کم شده اما شعبه با روش دیگری ادامه می‌دهد | اثر و محدودیت راه موقت را ثبت و موعد بررسی را هماهنگ کنید |
| درخواست عادی | پرسش درباره نگهداری یا آموزش کاربر | پاسخ را در صف عادی با موعد روشن قرار دهید |
این جدول قانون خودکار نرم افزار نیست. هر کسب‌وکار باید سطح‌ها، ساعت خدمت و اختیار تصمیم را با قراردادها و ظرفیت خودش تنظیم کند. اگر خطری برای افراد یا تجهیزات مطرح است، مسیر ایمنی سازمان مقدم بر صف معمول پشتیبانی است.
مسئول تیکت با انجام‌دهنده همه کارها یکی نیست
مسئول درخواست مراقب ادامه ارتباط است، اما ممکن است تعمیر را متخصص انجام دهد یا پاسخ مالی را حسابداری آماده کند. مشتری نباید برای فهمیدن وضعیت میان واحدها بچرخد. مسئول اصلی می‌داند اکنون چه کاری در جریان است، نتیجه چه زمانی می‌رسد و چه چیزی باید به مشتری گفته شود. برای تحویل به متخصص، فقط عکس خطا را نفرستید. خلاصه باید مدل دستگاه، شعبه، نشانه مشکل، اثر روی کار، کارهای امتحان‌شده، زمان دسترسی به محل و قول داده‌شده به مشتری را داشته باشد. اگر اطلاعاتی هنوز نرسیده، نام مسئول دریافت و موعدش را اضافه کنید. متخصص از مسئله شروع می‌کند، نه از جست‌وجوی پیام‌های پراکنده.
در نرم افزار CRM کلید، منبع، مسئول، وضعیت، مکالمات و اقدام بعدی مشتری در پرونده ثبت می‌شوند. وظیفه، تماس، جلسه و یادآور نیز برای نظم دادن به کارهای بعدی در دسترس‌اند. بخش پشتیبانی کلید، درخواست‌ها، تیکت‌ها، خدمات پس از فروش و پیگیری مشتری را کنار اطلاعات فروش نگه می‌دارد. این پایه مشترک، تحویل را کوتاه و پاسخ را منسجم‌تر می‌کند.
راهنمای هماهنگی وظایف پروژه فرق مسئول رابطه تجاری و انجام‌دهنده کار فنی را با نمونه‌های بیشتری توضیح می‌دهد. همین فرق در پشتیبانی مهم است: مسئولیت ارتباط نباید با تخصص تعمیر اشتباه شود.
«منتظر» باید بگوید منتظر چه کسی هستیم
وضعیت کلی «منتظر پاسخ» چیزی را روشن نمی‌کند. درخواست ممکن است منتظر عکس مشتری، تایید قطعه از انبار، نظر متخصص یا هماهنگی ورود به شعبه باشد. در یادداشت و اقدام بعدی بنویسید چه ورودی‌ای لازم است، چه کسی آن را می‌گیرد و چه زمانی دوباره بررسی می‌شود.
اگر کار دست مشتری است، پرونده را رها نکنید. بگویید چه اطلاعاتی لازم است و چرا. مثلا «برای تشخیص اولیه، عکس پلاک دستگاه و کد خطا لازم است. اگر تا چهارشنبه رسید، متخصص همان روز نتیجه بررسی را اعلام می‌کند.» اگر مشتری زمان بیشتری خواست، انتخاب او را ثبت کنید و موعد بعدی را با خودش هماهنگ کنید.
اگر کار داخل شرکت مانده است، مشتری نباید تاخیر را با سکوت تجربه کند. وقتی موعد قبلی قابل انجام نیست، پیش از گذشتن آن خبر بدهید، دلیل لازم را کوتاه بگویید و زمان تازه‌ای پیشنهاد کنید. پاسخ صادقانه شاید مسئله را حل نکند، اما اعتماد را از بین نمی‌برد.
حل فنی با بستن درخواست یکی نیست
متخصص ممکن است قطعه را عوض کند و کار خودش را تمام‌شده بداند. تیکت زمانی آماده بستن است که نتیجه مورد انتظار روشن باشد. آیا دستگاه یک چرخه کامل را بدون خطا انجام داده است؟ آیا سرپرست شعبه نتیجه را دیده؟ آیا اقدام دیگری مانند ارسال قطعه یا آموزش کوتاه باقی مانده است؟
برای هر نوع درخواست، معیار پایان ساده تعریف کنید. پرسش اطلاعاتی با پاسخ فهمیده‌شده تمام می‌شود. خرابی فنی ممکن است به آزمون دستگاه و تایید مشتری نیاز داشته باشد. درخواست مالی زمانی بسته می‌شود که پاسخ یا سند مورد توافق تحویل شده باشد. «متخصص رفت» نتیجه نیست. اگر همان مشکل کمی بعد برگشت، تیکت تازه را بی‌ارتباط با سابقه قبلی نسازید. پرونده پیشین را ببینید و مشخص کنید آیا مسئله دوباره باز شده یا خرابی دیگری رخ داده است. تعداد بازشدن دوباره می‌تواند نشانه کیفیت حل باشد، اما فقط وقتی تعریف «همان مشکل» میان کارشناسان یکسان باشد.
عددهایی که واقعا به شیفت بعد کمک می‌کنند
زمان نخستین پاسخ را از لحظه دریافت درخواست تا نخستین پاسخ معنادار بسنجید. رسید خودکار یا عبارت «بررسی می‌کنیم» را پاسخ معنادار ندانید. اگر خارج ساعات کاری زمان را متوقف می‌کنید، این قاعده باید برای همه درخواست‌ها یکسان باشد و در گزارش نوشته شود.
واجد شرایط یعنی درخواست واقعی و در دامنه خدمت که پیام آزمایشی یا نسخه تکراری همان مسئله نیست. فرض کنید در یک هفته ۴۰ درخواست واجد شرایط دریافت شده است و برای هرکدام یک روز کاری کامل فرصت پاسخ در نظر گرفته‌اید. ۳۲ درخواست در زمان هدف پاسخ معنادار گرفته‌اند. نرخ پاسخ به‌موقع برابر است با:
۳۲ ÷ ۴۰ = ۸۰ درصد
هشت درخواست دیرپاسخ یا بی‌پاسخ در صورت کسر نمی‌آیند. درخواست آخر هفته باید همان یک روز کاری کامل را بگیرد. گزارش را پیش از پایان مهلت آخرین مورد نبندید. اگر هیچ درخواست واجد شرایطی ندارید، نرخ قابل محاسبه نیست و نباید صفر نوشته شود.
زمان حل را جدا نگه دارید. پاسخ سریع می‌تواند شروع خوبی باشد، اما حل خرابی قطعه شاید چند روز طول بکشد. برای مقایسه، نوع درخواست و نقطه پایان را ثابت کنید. مخلوط کردن پرسش رمز ورود با تعمیر دستگاه، میانگینی می‌سازد که درباره هیچ‌کدام حرف درستی نمی‌زند.
عدد دیگر، درخواست‌های باز در یک ساعت ثابت است. مثلا دوشنبه ساعت نه چند تیکت باز دارید و چند مورد اقدام بعدی یا مسئول روشن ندارند؟ این عدد عکس لحظه‌ای صف است، نه نرخ حل. برای دیدن تغییر، هر هفته همان ساعت و همان تعریف را به کار ببرید.
گزارش را به یک تصمیم کوچک وصل کنید
گزارش موضوع درخواست‌ها می‌تواند نشان دهد چه چیزی بیشتر تکرار شده است، به شرط آنکه دسته‌ها روشن و ثبت منظم باشد. اگر «سایر» بزرگ‌ترین گروه شد، توضیح‌هایش را بخوانید. شاید یک مشکل تازه پدید آمده یا دسته‌بندی برای کارشناسان قابل فهم نیست.
تکرار یک موضوع به تنهایی ثابت نمی‌کند محصول ایراد دارد. شاید راهنمای استفاده مبهم باشد، آموزش اولیه کافی نباشد یا نام یک قطعه مشتری را گیج کند. چند تیکت واقعی را باز کنید، گفته مشتری و اقدام انجام‌شده را بخوانید و بعد یک تغییر محدود انتخاب کنید. ماه بعد همان تعریف را بسنجید.
داشبورد راهکارهای کلید اطلاعات فروش، بازاریابی و پشتیبانی را نمایش می‌دهد و مدیر می‌تواند گزارش دریافت کند و سطح دسترسی تعیین کند. تعریف هر شاخص، منبع داده و دسترسی لازم را هنگام راه‌اندازی با درخواست‌های واقعی خودتان بررسی کنید.
پشتیبانی و فروش یک پرونده مشترک دارند، نه یک هدف
درخواست تعمیر با فرصت فروش یکی نیست. اگر مشتری درباره تعویض دستگاه یا خرید برای شعبه تازه علاقه نشان داد، تیم می‌تواند یک فرصت فروش جدا با مبلغ، مرحله، احتمال موفقیت و اقدام بعدی روشن بسازد. تیکت تعمیر تا حل مسئله خودش ادامه پیدا می‌کند. تبدیل هر شکایت به پیشنهاد فروش، اعتماد را خیلی سریع می‌سوزاند. همکار فروش باید بداند مشتری درگیر یک مشکل باز است تا زمان و لحن تماسش را درست انتخاب کند. کارشناس پشتیبانی هم باید قول مرتبطی را که فروش داده ببیند. دسترسی هر نقش را به اندازه کارش تنظیم کنید. دید مشترک به معنی باز بودن همه اطلاعات برای همه افراد نیست.
مرز «پشتیبانی یکجا» را پیش از خرید روشن کنید
اگر کار شما به ورود خودکار ایمیل، چت یا پیام‌رسان، تبدیل تماس به تیکت، مسیردهی خودکار، شمارنده تعهد زمان خدمت، پاسخ آماده، پایگاه دانش، ربات پاسخ‌گو یا اتصال به انبار و مالی وابسته است، آنها را از عبارت عمومی تیکت و اتوماسیون نتیجه نگیرید. همان درخواست خرابی را در درخواست دمو اجرا کنید و مسیر ورود، ارجاع، هشدار، گزارش و پلن لازم را روشن بنویسید.
راه‌اندازی کلید شامل بررسی نیاز، تنظیم دسترسی‌ها، شخصی‌سازی بخش‌ها و آموزش تیم است. سه درخواست واقعی و بدون اطلاعات محرمانه به جلسه ببرید: یک خرابی فوری، یک سؤال عادی و یک درخواست منتظر مشتری. اگر تیم برای هر سه بتواند مسئول، وضعیت، اقدام بعدی و معیار پایان را یکسان بفهمد، فرایند آماده اجراست.
شیفت فردا را با سه پرونده شروع کنید
سه درخواست باز را انتخاب کنید. از کارشناس بخواهید در کمتر از یک دقیقه بگوید مشتری چه می‌خواهد، اثر مسئله چیست، کار دست چه کسی است و چه زمانی پاسخ بعدی می‌رسد. هرجا پاسخ مبهم شد، همان بخش پرونده را اصلاح کنید. این تمرین کوچک خیلی زود نشان می‌دهد مشکل از کمبود اطلاعات است، از مسئول نامعلوم یا از قول بدون موعد. بعد یکی از درخواست‌ها را تا پایان دنبال کنید. هنگام تحویل، مشتری را وادار به تکرار داستان نکنید. هنگام بستن، نتیجه را با معیار روشن بسنجید. پشتیبانی یکجا از خرید یک صندوق پیام شروع نمی‌شود. از لحظه‌ای شروع می‌شود که همه همکاران یک پاسخ واحد برای این سؤال دارند: «قدم بعدی برای این مشتری چیست؟»
