ساعت هشت صبح، مدیر یکی از شعبه‌های یک کافه زنجیره‌ای در واتساپ به فروشنده تجهیزات پیام می‌فرستد: «فشار دستگاه اسپرسو از دیشب افت کرده؛ سرویس‌کار امروز می‌رسد؟» پیام روی گوشی همکاری است که مرخصی دارد. تصویر خطا به همکار پشتیبانی فرستاده می‌شود، اما نام شعبه، مدل دستگاه و قولی که شب قبل داده شده همراه آن نیست. مشتری فقط یک شرکت را می‌بیند و انتظار ندارد با غیبت یک نفر، ماجرای خودش را از اول تعریف کند. مسئله فقط دیر دیدن پیام نیست. ممکن است پاسخ خیلی سریع ارسال شود، اما مسئول سرویس، موعد مراجعه و سابقه خرابی روشن نباشد. اتصال CRM به واتساپ وقتی اثر می‌گذارد که گفت‌وگو را به کار بعدی وصل کند. یک نشان واتساپ کنار صفحه مشتری به‌تنهایی نظم نمی‌سازد. تیم باید بداند چه اطلاعاتی از پیام ارزش ثبت دارد، چه کسی پیگیری را ادامه می‌دهد و مشتری چه زمانی پاسخ کامل می‌گیرد.
CRM یا نرم افزار مدیریت ارتباط با مشتری، سابقه رابطه و پیگیری را برای تیم منظم می‌کند. در نرم افزار CRM کلید می‌توان منبع، مسئول، وضعیت، مکالمات و اقدام بعدی هر سرنخ یا مشتری را ثبت کرد. وظیفه، تماس، جلسه و یادآور نیز برای نظم دادن به پیگیری در دسترس‌اند. این پایه حتی پیش از هر اتصال فنی مفید است: تیم می‌تواند نکته‌های مهم چت را ثبت کند و قول داخل گوشی را به تعهدی قابل دیدن تبدیل کند.
اول روشن کنید اتصال قرار است کدام درد را کم کند
یک تیم می‌خواهد سرنخ‌های تازه را سریع‌تر تحویل بگیرد. تیم دیگر می‌خواهد درخواست خدمات پس از فروش میان فروشنده و تکنسین گم نشود. کسب‌وکاری هم از چند شماره استفاده می‌کند و فقط می‌خواهد هنگام مرخصی یک کارشناس، زمینه مشتری باقی بماند. این نیازها شبیه هم به نظر می‌رسند، اما مسیر فنی و معیار موفقیتشان یکسان نیست. نتیجه مورد انتظار را در یک جمله بنویسید: «هر درخواست سرویس واتساپی باید در ساعات کاری حداکثر ظرف ۳۰ دقیقه یک مسئول و زمان پاسخ بعدی داشته باشد.» هنوز درباره نرم افزار تصمیم نگرفته‌اید؛ فقط معلوم کرده‌اید چه چیزی باید بهتر شود. هدف مبهم «همه‌چیز یکپارچه شود» ممکن است چند صفحه زیبا تحویلتان دهد، بدون اینکه مشکل صبح کافه را حل کند.
سپس پیام‌های یک هفته عادی را مرور کنید. کدام پیام درخواست قیمت است؟ کدام به فرصت فروش باز مربوط می‌شود؟ کدام خرابی پس از فروش است؟ کدام فقط احوال‌پرسی یا گفت‌وگوی شخصی است؟ قرار نیست هر کلمه وارد CRM شود. تاریخ تصمیم، خواسته مشتری، قول تیم، مسئول و اقدام بعدی ارزش عملیاتی دارند. انباشتن همه چت‌ها بدون قاعده، فقط شلوغی گوشی را به جای دیگری منتقل می‌کند.
هر شماره را با یک مشتری یکی نگیرید
شماره تلفن نشانه خوبی برای شناسایی است، اما همیشه هویت کامل مشتری نیست. مدیر شعبه، مسئول خرید و تکنسین یک مجموعه ممکن است از سه شماره درباره یک دستگاه حرف بزنند. برعکس، یک مشاور خرید شاید برای دو شرکت جدا پیام بدهد. اگر اتصال فقط شماره را معیار قرار دهد، احتمال دارد سه پرونده برای یک مسئله ساخته شود یا گفت‌وگوی دو مشتری به هم برسد. پیش از انتقال داده معلوم کنید پیام به کدام شرکت، شعبه، فرد تماس، فرصت فروش یا درخواست خدمت مربوط است. در صحنه کافه، شرکت صاحب قرارداد است، شعبه محل دستگاه و پیام مدیر شعبه آغاز یک درخواست خرابی است. تیم باید این نسبت را تأیید کند. تطبیق خودکار شماره، ادغام رکوردهای تکراری یا تشخیص شرکت از متن پیام را قابلیت آماده فرض نکنید. چند نمونه دشوار واقعی را در آزمون اتصال بگذارید.
اگر مشتری با شماره تازه‌ای پیام داد، نخست نام شرکت، شعبه و موضوع را بپرسید. جمله «برای دستگاه شعبه ونک پیام می‌دهم؛ همان خطای دیروز» هنوز مدل دستگاه یا شماره درخواست را روشن نمی‌کند. یک پاسخ کوتاه و محترمانه برای گرفتن نام شعبه و موضوع، از وصل کردن پیام به پرونده اشتباه بهتر است.
قول داخل چت باید به اقدام بعدی برسد
فرض کنید فروشنده در واتساپ می‌نویسد: «تا ساعت ۱۰ زمان حضور تکنسین را خبر می‌دهم.» این پیام سه جزء دارد: یک تعهد، یک موعد و یک مسئول. اگر فقط متن چت باقی بماند، مدیر نمی‌داند چه کسی باید پاسخ را آماده کند. در پرونده مشتری، خلاصه‌ای روشن بنویسید: «افت فشار دستگاه شعبه ونک؛ فروشنده تا ساعت ۱۰ زمان مراجعه را از سرپرست فنی می‌گیرد؛ پاسخ از واتساپ ارسال می‌شود.» اگر کار به واحد خدمات می‌رسد، درخواست را با اطلاعات فروش قاطی نکنید. در راهکارهای کلید، درخواست‌ها، تیکت‌ها، خدمات پس از فروش و پیگیری مشتری کنار اطلاعات فروش مدیریت می‌شوند. پیام واتساپ به‌خودی‌خود تیکت نمی‌شود. تیم می‌تواند درخواست را ثبت کند، مسئول پیگیری را مشخص کند و برای پاسخ یا تماس بعدی وظیفه و یادآور بگذارد.
تحویل خوب کوتاه است، اما چیزی کم نمی‌گذارد: مشتری چه می‌خواهد، فوریت از کجا آمده، آخرین پاسخ چه بوده، اکنون کار دست چه کسی است و موعد بعدی کدام است. عکس خطای دستگاه شاید برای تکنسین لازم باشد، اما قرارداد، نشانی شعبه و زمان مجاز ورود نیز ممکن است تعیین‌کننده باشند. اگر انتقال فایل یا نمایش آن کنار پرونده برای کار شما حیاتی است، همان مسیر را در آزمون محصول ببینید.
پاسخ سریع یعنی مشتری بداند چه می‌شود
یک تیک آبی یا پیام «در حال بررسی است» همیشه پاسخ مفید نیست. در نخستین جواب، دریافت درخواست را تأیید کنید و قدم بعدی را بگویید: «پیام را دیدم. سرپرست فنی تا ساعت ۱۰ زمان مراجعه را مشخص می‌کند و از همین شماره خبر می‌دهم.» مشتری هنوز راه‌حل نهایی ندارد، اما می‌داند چه کسی پیگیر است و چه زمانی دوباره خبر می‌گیرد.
اگر متخصص به زمان بیشتری نیاز دارد، موعد تازه را پیش از تمام شدن قول قبلی اعلام کنید. سکوت تا ساعت ۱۰ و فرستادن پاسخ مبهم در ظهر، اعتماد را کم می‌کند. کارشناس فروش هم نباید برای سریع به نظر رسیدن، زمان حضور تکنسین را حدس بزند. سرعت واقعی از دسترسی به زمینه و تحویل درست می‌آید، نه از تایپ شتاب‌زده. پیگیری سرنخ نیز وقتی ارزش دارد که هر تماس دلیل تازه داشته باشد. همین اصل در واتساپ صادق است. پیام پشت پیام، جای پاسخ تازه را نمی‌گیرد. اگر نوبت مشتری است، زمان توافق‌شده او را رعایت کنید. اگر نوبت تیم شماست، اقدام بعدی را به دوش مشتری نیندازید.
قواعد واتساپ بخشی از طراحی‌اند
اتصال فنی، قواعد خود کانال را کنار نمی‌زند. سیاست پیام‌رسانی کسب‌وکار واتساپ می‌گوید کسب‌وکار برای تماس بعدی باید شماره فرد و رضایت او را برای دریافت پیام یا تماس داشته باشد و درخواست توقف ارتباط را رعایت کند. اجازه اعلام وضعیت سرویس نیز لزوما مجوز فرستادن هر پیشنهاد تبلیغاتی نیست. در پلتفرم کسب‌وکار واتساپ، شروع گفت‌وگو از طرف کسب‌وکار به الگوی پیام تأییدشده نیاز دارد. تا ۲۴ ساعت پس از آخرین پیام مشتری می‌توان بدون چنین الگویی پاسخ داد و بیرون از این پنجره، الگوی تأییدشده لازم است. اتصال CRM مجوز ارسال بی‌حد پیام یا دور زدن تأیید الگو نیست. این قواعد و قیمت‌گذاری ممکن است تغییر کنند. پیش از راه‌اندازی، نسخه جاری سیاست و مستندات فنی را بررسی کنید.
دسترسی را به اندازه مسئولیت باز کنید
متمرکز شدن اطلاعات به این معنا نیست که همه اعضای شرکت باید همه گفت‌وگوها را ببینند. فروشنده به سابقه فرصت و قول بعدی نیاز دارد، تکنسین باید شرح خرابی و زمان مراجعه را ببیند و مدیر ممکن است فقط وضعیت درخواست و تأخیرها را دنبال کند. پیام شخصی، شماره کارت، مدرک هویتی یا اطلاعات نامرتبط نباید صرفا چون در چت آمده‌اند بی‌هدف تکثیر شوند. در راهکارهای کلید، مدیر می‌تواند سطح دسترسی را تعیین کند و تنظیم دسترسی‌ها و شخصی‌سازی بخش‌ها نیز در راه‌اندازی انجام می‌شوند. پیش از ورود پیام‌ها، مشخص کنید هر نقش چه اطلاعاتی لازم دارد، چه کسی می‌تواند مسئول مشتری را تغییر دهد و چه زمانی دسترسی باید بسته شود.
حساب‌های فنی را نیز زیر کنترل شرکت نگه دارید. شماره کسب‌وکار، حساب مدیریتی، دسترسی‌های فنی و قرارداد ارائه‌دهنده اتصال نباید فقط در اختیار یک همکار یا پیمانکار باشند. همچنین معلوم کنید داده چت در کدام سامانه‌ها می‌ماند، نسخه پشتیبان چگونه نگهداری می‌شود و در پایان همکاری داده چگونه تحویل یا حذف می‌شود. CRM به‌تنهایی پاسخ این پرسش‌ها را تضمین نمی‌کند.
همان مسیر واقعی را پیش از خرید اجرا کنید
در کلید، نیاز اتصال در گفت‌وگوی اولیه بررسی می‌شود تا مسیر متناسب پیشنهاد شود. اگر واتساپ کانال اصلی شماست، به توضیح کلی «قابل اتصال است» اکتفا نکنید. یک پیام از شماره آزمایشی بفرستید، مشتری را شناسایی کنید، نتیجه را در پرونده ببینید و پاسخ را تا رسیدن به گوشی دنبال کنید. قطع اتصال، پیام تکراری و تحویل از فروش به پشتیبانی را هم امتحان کنید.
تا این مسیر را ندیده‌اید، همگام‌سازی خودکار پیام، انتقال تاریخچه قدیمی، کار با چند شماره، دریافت فایل، ارسال الگو یا گرفتن تأیید واتساپ را قابلیت آماده کلید حساب نکنید. محدوده تحویل باید بگوید چه چیزی ثبت می‌شود، از چه زمانی، با چه تأخیری، به دست چه کسانی و هنگام خطا چه اتفاقی می‌افتد. یک آزمایش واقعی، وعده اتصال را به نتیجه‌ای قابل سنجش تبدیل می‌کند.
ثبت دستی، طرح اتصال را محک می‌زند
برای شروع لازم نیست منتظر پروژه فنی بمانید. مثلا یک هفته، تیم پس از هر گفت‌وگوی کاری مهم پنج مورد را دستی ثبت کند: مشتری، موضوع، آخرین قول، مسئول و اقدام بعدی. خیلی زود معلوم می‌شود کدام داده واقعا لازم است و کدام مرحله فقط زحمت اضافه می‌سازد. فرایندی که دستی معنای روشنی ندارد، پس از خودکار شدن فقط سریع‌تر آشفتگی تولید می‌کند. این آزمایش نقاط تحویل را هم نشان می‌دهد. شاید فروشنده درخواست خرابی را خوب ثبت می‌کند، اما سرپرست فنی زمان مراجعه را به فروشنده خبر نمی‌دهد. شاید پاسخ آماده است، اما کسی مسئول ارسال آن به مشتری نیست. در این حالت، مسئله کمبود اتصال نیست. قاعده داخلی ناقص است. نقش‌ها را اصلاح کنید و سپس درباره خودکار کردن بخش‌های تکراری تصمیم بگیرید.
سرعت پاسخ را با واحد درست بسنجید
برای سنجش، «درخواست» را از «پیام» جدا کنید. مشتری ممکن است برای یک خرابی شش پیام و دو عکس بفرستد. همه آنها یک درخواست‌اند. تعریف ساده‌ای بسازید: اگر شیفت پاسخ‌گویی ساعت ۹ تا ۱۷ است، هر درخواست کاری تازه که تا ۱۶:۳۰ رسیده وارد مخرج شود تا همه ۳۰ دقیقه کامل برای پاسخ فرصت داشته باشند. پاسخ به‌موقع یعنی مشتری تا آن مهلت پیامی گرفته باشد که دریافت موضوع را تأیید کند و زمان یا قدم بعدی را بگوید. ایموجی، پیام خودکار یا تیک خوانده‌شدن پاسخ مفید نیست.
فرض کنید در یک هفته ۵۰ درخواست واجد این تعریف رسیده و ۳۸ مورد حداکثر تا ۳۰ دقیقه پاسخ مفید گرفته‌اند. نرخ پاسخ به‌موقع ۳۸ تقسیم بر ۵۰، یعنی ۷۶ درصد است. پیام‌های بعدی همان درخواست مخرج را بزرگ نمی‌کنند. اگر هیچ درخواست واجد شرایطی وجود نداشت، نرخ قابل محاسبه نیست. برای درخواست‌های بیرون ساعات کاری هم قاعده جدا و معلومی داشته باشید تا زمان شب با زمان شیفت کاری مخلوط نشود.
همین تعریف را پیش و پس از تغییر فرایند نگه دارید و کنار نرخ، تعداد درخواست و ترکیب درخواست‌های فروش و خدمات را هم ببینید. اگر هفته دوم ساده‌تر یا خلوت‌تر بوده، بهتر شدن درصد را یکسره به اتصال نسبت ندهید. وقتی داده پیام در گزارش در دسترس نیست، یک نمونه دستی کافی است. اگر در پیاده‌سازی به داده قابل گزارش رسیدید، شکل گزارش و سطح دسترسی آن را هنگام راه‌اندازی مشخص کنید. هر گزارش به ثبت درست داده وابسته است.
ساعت ۹:۴۵ همان روز، مدیر شعبه دوباره درباره دستگاه پیام می‌دهد. این بار همکار پشتیبانی نام شعبه، شرح افت فشار، قول ساعت ۱۰ و مسئول فنی را در پرونده می‌بیند. جواب کوتاه است: «تکنسین بین ۱۱ تا ۱۲ می‌رسد و پیش از حرکت تماس می‌گیرد.» مشتری پاسخ یک شرکت را می‌گیرد، نه تکه‌های پراکنده چند گوشی را.