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

مشکل را با رفتار بنویسید، نه با برچسب
«فروشنده مقاومت دارد» یافته خوبی نیست.
حدس، یافته نیست. شاید او برای ثبت یک تماس مجبور است همان اطلاعات را دوباره بنویسد، معنی دو وضعیت را نمیفهمد یا نمیداند ذخیره انجام شده است. رفتار دیدهشده را ثبت کنید: «در سه پرونده تمرینی، کاربر پس از نوشتن یادداشت نتوانست اقدام بعدی را پیدا کند.»
هر مشاهده سه بخش داشته باشد: کار موردنظر، مانع دیدهشده و اثر مانع. مثلا کاربر برای یافتن پرونده از همکارش کمک خواست، دو رکورد همنام را اشتباه گرفت و تماس را روی پرونده دیگری نوشت. حالا مسئله روشنتر از جمله «جستوجو ضعیف است» شده است.
اول سراغ مانعی بروید که کار پرتکرار یا حساس را خراب میکند. یک اصطلاح گیجکننده در تماس روزانه از رنگ نامناسب نموداری که ماهی یک بار دیده میشود مهمتر است. شدت، تکرار و اثر را کنار هم ببینید.
کاربر مقصر پیشفرض نیست.
ثبت را به اندازه تصمیم کوتاه کنید
هر دادهای که میگیرید باید مصرفکننده داشته باشد. اگر فیلدی ماهها پُر نمیشود، بپرسید چه تصمیمی به آن وابسته است. شاید فیلد لازم نیست، شاید نامش نامفهوم است یا شاید در مرحله اشتباه نمایش داده میشود. حذف یا تغییر آن را بدون بررسی نیاز گزارش و فرایند دیگری انجام ندهید. برای تماس نخست، اطلاعات لازم میتواند نام مشتری، موضوع درخواست، راه ارتباطی، مسئول پرونده و اقدام بعدی باشد. اطلاعات فنی عمیقتر زمانی معنا دارد که نیاز روشن شده باشد. مجبور کردن کارشناس به حدس درباره بودجه یا زمان خرید، فرم را کامل نشان میدهد اما داده قابل اعتماد نمیسازد.
در نرم افزار CRM کلید، منبع، مالک، وضعیت، مکالمات و اقدام بعدی هر سرنخ و مشتری قابل ثبتاند. برای تجربه روزانه، همین پنج مورد را روی چند پرونده آزمایش کنید. در راهاندازی کلید، بخشها متناسب با فرایند تیم شخصیسازی میشوند. مخفی کردن شرطی هر فیلد یا ساخت هر فرم دلخواه را بدون دیدن نسخه موردنظر قطعی ندانید.
واژههای سیستم باید واژههای تیم باشند
اگر مدیر میگوید «پیشنهاد ارسال شد» ولی فروشنده آن را «قیمت دادیم» مینامد، شاید هر دو یک مرحله را منظور داشته باشند. نام مرحله باید برای کسی که هر روز کار را انجام میدهد روشن باشد. عبارتهای رسمی و بلند، گزارش را دقیقتر نمیکنند. اصول شناختهشده کاربردپذیری بر هماهنگی زبان سیستم با زبان آشنای کاربر، یکدستی واژهها و پیشگیری از خطا تأکید میکنند. برای تیم فروش، تعریف مرحله را با یک رویداد قابل دیدن بنویسید. «پیشنهاد ارسال شد» یعنی فایل واقعا از کانال تاییدشده برای مشتری رفته است، نه اینکه پیشنویس روی رایانه آماده باشد.
سه پرونده قدیمی را باز کنید و از دو کاربر بخواهید وضعیتشان را جداگانه بگویند. اگر پاسخها فرق دارد، پیش از ساخت گزارش، تعریف را اصلاح کنید. داده یکدست از واژه یکدست شروع میشود.
اقدام بعدی باید همان لحظه روشن شود
ثبت مکالمه بدون قدم بعدی، تاریخچه میسازد اما کار را جلو نمیبرد. مشتری گفته مسئول فنی سهشنبه حاضر است. اقدام روشن این است: «هماهنگی جلسه مشخصات با مسئول فنی تا دوشنبه ساعت ۱۲.» عبارت «پیگیری شود» مسئول، زمان و نتیجه مورد انتظار ندارد.
کلید برای نظم دادن به وظیفه، تماس، جلسه و یادآور ساخته شده است. این ابزارها وقتی تجربه را بهتر میکنند که کاربر بداند کدام را برای چه کاری انتخاب کند. تماس برای گفتوگوی تلفنی است، جلسه زمان حضور چند نفر را نگه میدارد و وظیفه نتیجهای را میخواهد که باید تحویل شود. تیم میتواند همین تعریفها را با کار خودش هماهنگ کند.
بعد از ثبت، از کاربر بپرسید: «اگر فردا صبح این پرونده را باز کنی، میفهمی چه کاری مانده است؟» اگر جواب نه است، یادداشت بلندتر لزوما راهحل نیست. یک جمله دقیق درباره اقدام بعدی بیشتر به کار میآید.

هر نقش آزمون خودش را لازم دارد
مدیر فروش، کارشناس فروش و پشتیبانی یک کار یکسان ندارند. مدیر میخواهد بداند فرصتها کجا ماندهاند و کدام پرونده اقدام بعدی ندارد. فروشنده باید به پرونده درست برسد و تماس را ثبت کند. پشتیبانی میخواهد درخواست باز و قول قبلی را ببیند. برای هر نقش دو یا سه کار پرتکرار انتخاب کنید. مسیر مدیر را با ثبت تماس فروشنده نسنجید. مسیر فروشنده را هم با نمودار مدیریتی قضاوت نکنید. کسی که فقط ماهی یک گزارش میبیند با فردی که روزی سی پرونده باز میکند اصطکاک یکسانی ندارد.
هر نقش، کار روزانه خودش را دارد.
سطح دسترسی نیز بخشی از تجربه است. کاربر باید اطلاعات لازم برای کارش را ببیند و با داده نامرتبط شلوغ نشود. در راهاندازی کلید، دسترسیها تنظیم و بخشها متناسب با فرایند تیم شخصیسازی میشوند. تعداد نقشها، ریز مجوزها و نمای دقیق هر کاربر را با ساختار واقعی تیم در دمو امتحان کنید.
آموزش را از پرونده واقعی شروع کنید
نمایش همه منوها، آموزش نیست.
یک سناریوی آشنا بردارید: مشتری از نمایشگاه آمده، قیمت دستگاه را خواسته و سهشنبه جلسه فنی دارد. فروشنده پرونده را میسازد، منبع و مسئول را ثبت میکند، نتیجه گفتوگو را مینویسد و جلسه بعدی را میگذارد. مدیر همان پرونده را جدا باز میکند و مسئول پرونده و کار مانده را میبیند.
آموزش کلید پس از آمادهسازی تنظیمات و دسترسیها با نقش کاربران هماهنگ میشود. اگر کاربر هنوز معنی مرحلهها را نمیداند، میانبر بیشتر مشکل را حل نمیکند.
برای اجرای محدود میتوانید از پایلوت سیروزه کلید ایده بگیرید. دامنه را کوچک نگه دارید، روی چند پرونده فعال کار کنید و مسئلهها را پیش از گسترش به کل تیم برطرف کنید. تقویم را با آمادگی خودتان تنظیم کنید؛ سی روز وعده استقرار یا نتیجه مالی نیست.
نسخه موبایل را در محل واقعی امتحان کنید
کلید اپلیکیشن موبایل دارد. برای تصمیم خرید، وجود برنامه کافی نیست؛ کیفیت هر کار را روی گوشی و شبکه واقعی تیم بسنجید. اگر فروشنده بیرون دفتر کار میکند، از او بخواهید پس از یک بازدید تمرینی، به پرونده مشتری برسد، نتیجه را بنویسد و تماس بعدی را بگذارد. آزمون را با گوشی و شرایط واقعی انجام دهید. نور محیط، اندازه صفحه، اینترنت ضعیف و تماس ورودی روی تجربه اثر دارند. اگر کار شما به GPS، ثبت مسیر، حالت آفلاین، همگامسازی پس از اتصال، عکس مستقیم یا تبدیل صدا به متن وابسته است، هر مورد را جدا ببینید. وجود اپلیکیشن هیچکدام را بهتنهایی ثابت نمیکند.
کار میدانی باید پیش از خرید روی همان دستگاهی امتحان شود که تیم استفاده خواهد کرد.
پیشرفت را با یک کار ثابت بسنجید
پس از هر تغییر، همان کار را دوباره با کاربران مشابه اجرا کنید. روش سنجش کاربردپذیری سه چیز را پیشنهاد میکند: موفقیت در انجام کار، زمان انجام و رها کردن کار یا تصور اشتباه درباره کامل شدن آن. ثابت ماندن کار و سؤالها، مقایسه دورهای مختلف را معتبرتر میکند.
فرض کنید دوازده فروشنده، هرکدام یک بار سناریوی ثبت تماس و اقدام بعدی را انجام میدهند. ده نفر بدون کمک به نتیجه درست میرسند. نرخ موفقیت ۱۰ تقسیم بر ۱۲ یا حدود ۸۳ درصد است. اگر یک نفر سه بار تلاش کند، آن را سه کاربر نشمارید. زمان را فقط میان تلاشهایی مقایسه کنید که تعریف شروع و پایان یکسان دارند.
اگر هیچ کاربر واجد شرایطی در آزمون نیست، نرخ موفقیت قابل محاسبه نیست. صفر درصد یعنی کاربر داشتید و هیچکس موفق نشد؛ نبود کاربر معنای دیگری دارد.
عدد بهتنهایی علت را نمیگوید.
ممکن است زمان کمتر شود چون افراد مرحلهای را رد کردهاند. کنار عدد، مشاهده و گفته کاربر را بخوانید. کاربر میگوید: «فکر کردم یادداشت کافی است و جلسه را ثبت نکردم.» این جمله نشان میدهد موفقیت ظاهری با کار کامل فرق دارد.

بازخورد را به یک تصمیم کوچک برسانید
صندوق پیشنهاد پر از جملههایی مثل «صفحه شلوغ است» میشود. برای هر بازخورد، کار، نقش و موقعیت را بپرسید. صفحه برای چه کسی شلوغ بود؟ هنگام کدام کار؟ کدام بخش او را متوقف کرد؟ آیا دیگران هم همان مشکل را داشتند؟ مثلا در یک برگه مسئله بنویسید: «سه فروشنده هنگام ثبت تماس، وضعیت مشتری را با مرحله فرصت اشتباه گرفتند و دو پرونده در جای نادرست ثبت شد.» حالا میتوانید تعریف، آموزش یا تنظیم بخش را بررسی کنید. شاید مسئله با تغییر نرم افزار حل نشود و اختلاف فرایند تیم باشد.
در هر دور یک یا دو تغییر بردارید. اگر نام مرحله، فرم، آموزش و دسترسی را همزمان عوض کنید، معلوم نمیشود کدام تغییر مفید بوده است. نسخه قبلی تعریف و تاریخ تغییر را نگه دارید. سپس همان سناریو را دوباره اجرا کنید.
گزارش استفاده را با نتیجه فروش یکی نکنید
کامل بودن پرونده میتواند نشان دهد روش ثبت اجرا شده است. فرض کنید در یک روز ثابت، شصت پرونده فعال دارید و چهلوپنج پرونده مالک، وضعیت و اقدام بعدی تاریخدار دارند. نسبت کامل بودن ۴۵ تقسیم بر ۶۰ یا ۷۵ درصد است. اگر پرونده فعالی ندارید، این نسبت قابل محاسبه نیست. این عدد نمیگوید فروش ۷۵ درصد بهتر شده است.
پرونده فعال را پیش از شمارش تعریف کنید. شاید منظور مشتری یا سرنخی باشد که یک کار باز دارد. همان تعریف را در دور بعد نگه دارید. اگر حجم ورودی، تعداد فروشنده یا فصل عوض شده، کنار مقایسه بنویسید.
داشبورد کلید اطلاعات فروش، بازاریابی و پشتیبانی را نمایش میدهد و مدیر میتواند گزارش دریافت کند. این گزارش را جای سنجش تجربه کاربر نگذارید. زمان کلیک، مسیر حرکت در صفحه و رفتار کاربر را با مشاهده کار و دادههای عملیاتی خودتان بسنجید.
پیش از خرید، جزئیات تجربه را جدا آزمایش کنید
داشبورد شخصی هر کاربر، منطق شرطی فیلدها، ویرایش سریع جدول، تکمیل خودکار، جستوجوی داخل پیوست، ثبت خودکار تماس و ایمیل، تنظیم اعلان، تحلیل رفتار، نقشه کلیک یا آزمون A/B را امکان قطعی کلید فرض نکنید. اگر یکی برای کار شما حیاتی است، همان عمل را در نسخه موردنظر انجام دهید. فرایند راهاندازی کلید بررسی نیاز، تنظیم دسترسی، شخصیسازی بخشها و آموزش را پوشش میدهد. سه کار روزانه و یک موقعیت خطاپذیر را به جلسه ببرید و نتیجه هرکدام را ثبت کنید.
فردا ده دقیقه کنار یک کاربر بنشینید
از کارشناس بخواهید پرونده یک مشتری را باز کند، آخرین گفتوگو را ثبت کند و اقدام بعدی بگذارد. زمان بگیرید، اما بیشتر از ساعت به مکثها نگاه کنید. هر بار که سؤال میپرسد یا از همکار کمک میگیرد، همان لحظه را بنویسید.
بعد فقط یک مانع را انتخاب کنید. شاید نام مرحله نامفهوم است، شاید مسئول پرونده معلوم نیست یا آموزش مثال واقعی نداشته است. تغییر کوچک را انجام دهید و هفته بعد همان کار را دوباره ببینید.
تجربه بهتر با شعار «کاربرپسند» ساخته نمیشود. وقتی فروشنده وسط تماس شلوغ بتواند حرف مشتری و قدم بعدی را درست ثبت کند، نرم افزار از بار اضافی به بخشی روان از کار روزانه تبدیل میشود.



