بازطراحی تجربه پس از خرید

در سال 2024، لوکین‌شور (LookInsure) با این ایده‌ وارد بازار بیمه‌ امارات شد:
خرید بیمه‌ خودرو نباید بیشتر از چند دقیقه طول بکشد. رانندگان باید بتوانند در یک پلتفرم آنلاین، گزینه‌های مختلف را مقایسه کنند و بیمه‌ی متناسب با خودرو خود را بخرند.

سه ماه پس از عرضه‌ MVP، داده‌ها نشان داد محصول در مسیر درستی قرار گرفته و کاربران خریدشان را با موفقیت انجام می‌دهند؛ اما با بررسی داده‌های پشتیبانی مشخص شد ۳۹٪ کاربران بلافاصله پس از خرید، با پشتیبانی تماس می‌گیرند و می‌گویند هنوز بیمه‌نامه‌شان را دریافت نکرده‌اند.

در این کیس‌استادی توضیح می‌دهم چگونه با پر کردن شکاف میان انتظار کاربر و واقعیت سیستم، شفافیت و اعتماد را به محصول بازگرداندیم و ۷۲٪ تماس‌های پس از خرید را کاهش دادیم.

نقش من

من از May تا August سال 2024 (حدوداً ۴ ماه)، مسئولیت بازطراحی تجربه‌ی پس از خرید لوکین‌شور را برعهده داشتم.

• تعریف استراتژی
  در شروع پروژه، همراه الهام (مدیر محصول) محدوده و اولویت‌ فازهای مختلف بازطراحی را مشخص کردم تا تا تمرکز تیم روی مهم‌ترین نقاط اصطکاک باشد.

• تحلیل داده
  در همکاری نزدیک با علیرضا از تیم عملیات و فاطمه از تیم پشتیبانی، داده‌ها و بازخورد کاربران را جمع‌آوری و تحلیل کردم. این تحلیل‌ها به بینش‌هایی رسید که مستقیماً تصمیم‌های طراحی و توسعه قابلیت‌های جدید را شکل داد.

• یکپارچگی تجربه
  برای حفظ یکپارچگی تجربه، با یک UX Writer عربی‌زبان همکاری کردم تا پیام‌های درون‌محصول با زمینه فرهنگی کاربران عرب‌زبان هماهنگ باشد.

چالش

تقریبا نیمی از کاربران لوکین‌شور بلافاصله بعد از خرید بیمه خودرو، با پشتیبانی تماس می‌گرفتند و یک سوال تکراری می‌پرسیدند:
"من پرداخت کردم، پس بیمه‌نامه من کجاست؟"

از نگاه کاربر، پرداخت به معنای پایان سفر بود. او انتظار داشت بعد از پرداخت، بیمه‌نامه خودرو خود را دریافت کند. اما در واقعیت عملیاتی بازار بیمه امارات، صدور بیمه‌نامه آنی نبود. بعد از پرداخت، تیم عملیات باید با کاربر تماس می‌گرفت، مدارک را دریافت می‌کرد و اطلاعات را در پنل شرکت بیمه ثبت می‌کرد تا بیمه‌نامه صادر شود. این فرآیند، به دلیل وابستگی به تعامل انسانی، ممکن بود از چند دقیقه تا چند ساعت زمان ببرد.

چالش اصلی ما همین شکاف بین انتظار کاربر و واقعیت سیستم بود.

با وجود اینکه در صفحه پرداخت موفق به کاربران اطلاع می‌دادیم "تیم ما تا یک ساعت آینده با آن‌ها تماس می‌گیرد"، اما به‌طور میانگین روزانه ۳۹٪ کاربران پیش از تماس تیم ما، با پشتیبانی تماس می‌گرفتند. برخی هم این ابهام را در قالب بازخورد منفی در Google Reviews بازتاب می‌دادند.
از طرفی، با رشد فروش در ماه سوم، این مسئله فشار زیادی بر تیم پشتیبانی ایجاد کرده بود و بخش قابل توجهی از ظرفیت تیم صرف پاسخ دادن به سوالات تکراری کاربران می‌شد.

چطور می‌توانیم تجربه پس از خرید را طوری بازطراحی کنیم که کاربر پس از پرداخت، احساس اطمینان داشته باشد و نیازی به تماس با پشتیبانی نداشته باشد؟

راه‌حل اول

در اولین قدم، ساده‌ترین فرضیه را آزمایش کردم؛ احتمال می‌دادم اگر کاربر پس از پرداخت، به‌وضوح ببیند که خریدش ثبت شده و از مرحله‌ بعدی مطلع باشد، با اطمینان بیشتری صفحه را ترک می‌کند و کمتر با پشتیبانی تماس می‌گیرد. به همین دلیل صفحه پرداخت موفق را با دو تغییر ساده بازطراحی کردم:

• برجسته‌کردن متن راهنما
  متن تیم ما با شما تماس می‌گیرد، در میان سایر محتوای صفحه گم شده بود. آن را از متن اصلی جدا کردم و جایگاه بالاتری به آن دادم تا توجه کاربر را جلب کند.
  

• نمایش وضعیت سفارش
  بخش جدیدی در صفحه اضافه کردم تا وضعیت سفارش را نشان دهد. در این بخش به کاربر اطلاع می‌دادم که سفارش او با موفقیت ثبت شده و باید منتظر تماس ما بماند.
  

  
  

دو هفته پس از پیاده‌سازی تغییرات، داده‌ها نشان داد نرخ تماس بعد از خرید کاربران تقریباً تغییری نکرده است. بررسی تماس‌ها نشان می‌داد سؤال کاربران همچنان همان است: "من پرداخت کردم، پس بیمه‌نامه‌ام کجاست؟"

این نتیجه نشان داد احتمالا مشکل فقط رابط کاربری صفحه یا سلسله مراتب بصری نبود. حتی وقتی پیام واضح‌تر شد، باز هم حس اطمینانی که کاربر بعد از پرداخت نیاز داشت شکل نگرفت. بنابراین در قدم بعدی، به‌جای توضیح بیشتر، سراغ راه‌حلی رفتم که بتواند حس اطمینان را بازسازی کند.

بینش‌‌هایی از رفتار کاربران

وقتی نسخه اول اثر معناداری نداشت، گوش دادن به تعدادی تماس پشتیبانی و بررسی بیش از ۶۰ ویدیو ضبط شده از رفتار واقعی کاربران، ما را به بینش‌‌های عمیق‌تری رساند.

• نیاز به تایید انسانی
  در تماس‌های پشتیبانی نکته جالب این بود که کارشناس ما اطلاعات تازه‌ای به کاربران نمی‌داد؛ صرفا همان پیام صفحه پرداخت موفق را تکرار می‌کرد. اما شنیدن این توضیحات از زبان انسان، باعث اطمینان کاربران می‌شد.
  این رفتار نشان می‌داد متن راهنما در صفحه پرداخت موفق نامفهوم نبود، بلکه به‌تنهایی حس اطمینان را در کاربر ایجاد نمی‌کرد.
  

• عدم اطمینان از ثبت سفارش
  بررسی ویدیوهای ضبط‌شده نشان داد حدود ۱۹٪ از کاربران پس از پرداخت موفق، الگوی رفتاری خاصی دارند. آن‌ها پس از بازگشت به صفحه اصلی و جستجوی بی‌نتیجه برای یافتن تاریخچه سفارش‌ها، مجدداً وارد فرآیند خرید می‌شدند؛ اما این بار پس از رسیدن به مرحله پرداخت، مسیر را رها می‌کردند.
  این رفتار را به‌عنوان نشانه‌ای از اضطراب یا عدم اطمینان پس از خرید تفسیر کردم؛ کاربران احتمالا برای اطمینان از ثبت سفارش خود، دست به آزمون و خطا می‌زنند.

راه‌حل دوم

با درک نگرانی کاربران، به این نتیجه رسیدم که اگر بعد از پرداخت، یک تاییدیه‌ی فوری و معتبر به آن‌ها بدهیم تا از ثبت سفارش خود مطمئن شوند، احتمالا اضطرابشان کاهش یافته و کمتر با پشتیبانی تماس می‌گیرند.

در MVP، قرار بود ایمیل این نقش را ایفا کند؛ اما داده‌ها نشان داد این روش ناکارآمد است؛ کاربران ایمیل‌ را بلافاصله چک نمی‌کنند.
پس از بررسی گزینه‌هایی مثل بهبود مجدد رابط کاربری و یا ارسال پیام در واتساپ، در نهایت ارسال پیامک انتخاب شد؛ راهکاری که سریع‌تر دیده می‌شد، با عادات روزمره کاربران سازگار بود و نقش همان تأیید فوری را ایفا می‌کرد.

چالش هزینه و توجیه منطق کسب‌وکار
ارسال پیامک برای لوکین‌شور هزینه عملیاتی داشت. برای توجیه این تصمیم، هزینه ارسال پیامک به همه خریداران در یک بازه دو هفته‌ای را محاسبه کردم. این هزینه تقریباً معادل هزینه روزانه پاسخ‌گویی تیم پشتیبانی به تماس‌های تکراری بود. بنابراین تصمیم گرفتم در یک دوره دو هفته‌ای تست، بلافاصله پس از پرداخت، به خریداران پیامک ارسال کنیم.

طراحی کلمات
برای اثربخشی این راه‌حل، همه‌چیز به کلماتی بستگی داشت که انتخاب می‌کردیم. به دلیل محدودیت کاراکتر، باید در چند جمله کوتاه، هم ثبت سفارش را تأیید می‌کردیم و هم مرحله بعد را توضیح می‌دادیم.
با همکاری بابک از تیم محتوا و Nivin (طراح تجربه‌نویسی)، متن پیامک بارها بازنویسی شد تا لحنی شفاف و اطمینان‌بخش داشته باشد:

پس از دوره دو هفته‌ای تست، داده‌ موفقیت این راه‌حل را تایید کردند. نرخ تماس‌های پس از خرید از ۳۹٪ به ۲۴٪ کاهش پیدا کرده بود و آمار کاربرانی که از روی نگرانی دوباره اقدام به خرید می‌کردند از ۱۹٪ به حدود ۷٪ رسیده بود.

عبور از راه‌حل‌های موقت

ما با کمک چند راه‌حل سریع، کم‌هزینه و اثرگذار، توانسته بودیم حجم تماس‌های پشتیبانی پس از خرید را کاهش دهیم؛ اما می‌دانستم این راه‌حل‌‌ها تنها یک مُسکن موقت هستند.
در واقع ما فقط به کاربر اطمینان داده بودیم که «پول شما گم نشده، نگران نباشد، لطفاً منتظر بمانید!»، اما مشکل همچنان پابرجا بود:
کاربر پس از پرداخت، انتظار دریافت فوری بیمه‌نامه‌اش را داشت.

بنابراین در قدم بعدی، تمرکزمان روی کاهش زمان صدور بیمه‌نامه بود. با اینکه محدودیت‌های زیرساختی امکان صدور آنی بیمه‌نامه را فراهم نمی‌کرد، اما می‌توانستیم فرآیند صدور را سمت خودمان بهینه کنیم.

بینش‌هایی از فرآیند صدور بیمه‌نامه

برای درک بهتر آنچه بعد از پرداخت اتفاق می‌افتاد، یک روز کنار تیم عملیات نشستم و مسیر سفارش‌ها را تا صدور بیمه‌نامه دنبال کردم. در این مشاهده، چند نقطه اصطکاک مهم آشکار شد:

• وابستگی صدور بیمه‌نامه به تعامل انسانی
  تیم عملیات برای دریافت مدارک و ارسال بیمه‌نامه با اکثر خریداران از طریق واتساپ در ارتباط بود. هر تبادل پیام به‌طور میانگین حدود ۳ تا ۴ دقیقه زمان می‌برد و در مواردی مثل پاسخ دیرهنگام کاربر یا ارسال مدارک ناقص این زمان طولانی‌تر می‌شد.

• توقف صدور در خارج از ساعات کاری
  تحلیل داده‌های فروش نشان داد ۳۱٪ سفارشات در ساعات غیراداری ثبت می‌شوند و فرآیند صدور آن‌ها تا روز کاری بعد متوقف می‌ماند. هم‌زمان، محدودیت منابع در تیم پشتیبانی باعث بی‌پاسخ ماندن تماس‌های شبانه شده بود. پنج بازخورد منفی طی یک ماه در Google Reviews این زنگ خطر را به صدا درآورد که کاربران از یک سرویس آنلاین انتظار خدمت‌رسانی لحظه‌ای دارند و توقف فرآیندها به دلیل اتمام ساعات کاری را نمی‌پذیرند.

• نگرانی درباره اعتماد و حریم خصوصی
  تیم عملیات برای تکمیل صدور بیمه‌نامه از خریداران می‌خواست مدارک و اطلاعات هویتی خود را از طریق واتساپ ارسال کنند. با اینکه این روش برای تیم عملیاتی سریع و در دسترس بود، اما برای بخشی از کاربران حس ناامنی ایجاد می‌کرد؛ این موضوع به‌ویژه برای مهاجران می‌توانست به کاهش اعتماد و تعلل در ارسال مدارک منجر شود.

بعد از جمع‌بندی این یافته‌ها، با الهام (مدیر محصول) بررسی کردیم که انتقال دریافت مدارک از واتساپ به داخل محصول چه اثری بر زمان صدور و فشار عملیاتی دارد. برآورد ما این بود که اگر فقط ۴۰٪ از این رفت‌وبرگشت‌ها را کم کنیم:

• میانگین زمان صدور بیمه‌نامه حدود ۵ دقیقه کاهش پیدا می‌کند.

• روزانه تا ۱۵۰۰ درهم در هزینه‌های تیم عملیاتی صرفه‌جویی می‌شود.

• با رشد فروش، صدور بیمه‌نامه به بحران عملیاتی تبدیل نمی‌شود.

طراحی ویژگی آپلود مدارک

برای طراحی نسخه اولیه این قابلیت فقط دو هفته زمان داشتیم، بنابراین تمرکزم روی تجربه‌ای ساده و کم‌اصطکاک بود. یکی از تصمیم‌های کلیدی این بود که دریافت مدارک بعد از پرداخت انجام شود، نه قبل از آن؛ قرار نبود فرایند خرید را طولانی‌ کنیم یا باعث ریزش کاربران قبل از خرید شویم.

نسخه اول: آپلود مرحله‌ای مدارک

در اولین قدم، با کمک فاطمه از تیم عملیات، مدارک موردنیاز برای صدور بیمه‌نامه را بررسی کردم. مشخص شد برای تکمیل این فرآیند، باید تصویر پشت و روی سه مدرک اصلی از کاربر دریافت شود.

برای طراحی نسخه اولیه، تصمیم گرفتم در هر صفحه فقط یک مدرک را دریافت کنیم. این تصمیم به ما کمک می‌کرد بار شناختی کاربر را کاهش دهیم و فرآیند آپلود را، مخصوصاً در موبایل، ساده‌تر و قابل‌کنترل‌تر کنیم. از طرفی، احتمال سردرگمی، ارسال اشتباه یا رها کردن فرآیند را هم کاهش می‌دادیم.

بینش‌‌هایی از رفتار کاربران

وقتی نسخه اول جریان آپلود را با تیم عملیات به اشتراک گذاشتم، یکی از اعضای این تیم اشاره کرد که بسیاری از کاربران، پشت و روی کارت را در قالب یک فایل PDF ارسال می‌کنند. با بررسی داده‌های واتساپ متوجه شدم حدود ۷۶٪ فایل‌های دریافتی PDF هستند و کاربران معمولاً این فایل‌ها را از قبل در گوشی خود دارند. به همین دلیل تصمیم گرفتم، به‌جای درخواست آپلود تصویر پشت و روی مدارک، تجربه را بر آپلود PDF متمرکز کردم. این تغییر تعداد فایل‌ها را از ۶ عکس به ۳ فایل کاهش داد و احتمال خطا را کمتر کرد. البته این انتخاب بدون ریسک نبود. مثلاً کاربری که فایل PDF مدارک خود را ندارد باید عکس پشت و روی مدارک را آپلود کند.

نسخه دوم: آپلود مبتنی بر PDF

در نسخه دوم، کاربر می‌توانست با یک کلیک، فایل PDF شامل پشت و روی کارت را آپلود کند و مرحله را به پایان برساند.
با این حال، مسیر کاربرانی که مدرک را به‌صورت عکس‌های جداگانه آپلود می‌کردند هم حفظ شد. وقتی کاربر یک فایل آپلود می‌کرد، بخش جدیدی در همان صفحه نمایش داده می‌شد تا بتواند تصویر سمت دیگر کارت را هم اضافه کند. به این ترتیب، تجربه اصلی ساده و متمرکز بر آپلود PDF باقی ماند، بدون اینکه مسیر آپلود عکس مختل شود.

نسخه سوم: وضعیت بررسی مدارک

تجربه‌ی صفحه پرداخت موفق به ما یاد داده بود که هرجا حس پایان فرآیند را منتقل کنیم، ممکن است کاربر انتظار دریافت فوری بیمه‌نامه را داشته باشد. همین ریسک در جریان آپلود مدارک هم وجود داشت؛ بنابراین صفحه موفقیت آپلود را به‌عنوان یک وضعیت میانی طراحی کردم.

هدف این بود که کاربر از ثبت موفق مدارک خود مطمئن شود و همچنین بداند باید کمی منتظر بماند تا مدارک بررسی شوند.

این وضعیت با مدل ذهنی کاربر هم هم‌خوان بود؛ چون در بسیاری از پلتفرم‌ها، بعد از ارسال مدارک، کاربر انتظار یک مرحله بررسی و تأیید را دارد. بنابراین این موضوع برای او آشنا و قابل‌درک بود.

نتایج

پس از ۴۵ روز بعد از پیاده‌سازی ویژگی آپلود مدارک، داده‌ها را بررسی کردیم. نتایج نشان داد این راه‌حل به‌خوبی توسط کاربران پذیرفته شد و تأثیر خوبی بر تجربه پس از خرید گذاشته است.

• ۹۶٪ کاربران، بعد از خرید، مدارکشان را هم آپلود کرده بودند. این عدد نشان می‌داد این ویژگی به‌خوبی توسط کاربران پذیرفته شده است.

• براساس داده‌های تیم عملیات، ۸۸٪ مدارک به‌صورت PDF آپلود شده بودند. این موضوع باعث شده بود نرخ مدارک ناخوانا به حدود ۳٪ برسد و فقط در تعدادی محدود، تیم عملیات برای دریافت مجدد مدارک اقدام کند.

• ویژگی آپلود مدارک باعث شد فرآیند صدور بیمه‌نامه هم سریع‌تر شود؛ البته این بهبود فقط ناشی از ویژگی آپلود مدارک نبود و تغییرات ساختاری تیم عملیات نیز در آن نقش داشت؛ با این حال، استاندارد شدن نحوه دریافت مدارک یکی از عوامل مهم این نتیجه بود.

• با شفاف‌تر شدن وضعیت سفارش و روشن شدن انتظار بررسی مدارک برای کاربر، تماس‌های کاربران بلافاصله پس از خرید، از ۲۴٪ به حدود ۹٪ کاهش پیدا کرد.

• در نهایت، این تغییرات فشار تیم عملیات را کاهش داد و مقدار قابل توجهی در هزینه‌‌های ماهانه این تیم صرفه‌جویی کرد.

مهم‌ترین یادگیری من از این پروژه این بود که بخش زیادی از تماس‌های پشتیبانی، نه به‌دلیل خرابی سیستم، بلکه به‌خاطر ابهام در وضعیت‌ها و ناهماهنگی میان مدل ذهنی کاربر و منطق داخلی سرویس شکل می‌گیرند.
وقتی کاربر دقیقاً بداند چه اتفاقی افتاده، الان در چه مرحله‌ای است و قدم بعدی چیست، اضطرابش کمتر می‌شود و نیازش به تماس هم کاهش پیدا می‌کند.