بیمه خودرو؛ فرایند استعلام قیمت

در سال 2023، تحقیقات داخلی لوکین‌شور (LookInsure) نشان داد که بیشتر رانندگان در امارات، بیمه خودروشان را با مراجعه به دفاتر بیمه خریداری می‌کنند؛ مسیری که گاهی ساعت‌ها زمان می‌بُرد و با گزینه‌های محدودی همراه بود.
از طرفی، خرید آنلاین هم هنوز آن‌قدر ساده و بی‌دردسر نبود که بتواند جایگزین مناسبی برای این روش باشد.

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

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

نقش من

من در January 2024 به عنوان طراح محصول به تیم لوکین‌شور پیوستم. مسئولیت من طراحی MVP بود؛ از استعلام قیمت تا خرید بیمه.

در ابتدای مسیر، همراه با رامین (مدیر محصول)، محدوده MVP را مشخص کردم.
بعد از انتشار MVP، با بررسی داده‌ها، بازخوردها و رفتار واقعی کاربران، تمرکزم را روی ساده‌سازی مسیر استعلام قیمت گذاشتم؛ مسیری که هم برای محصول حیاتی بود و هم بیشترین ریزش کاربر در آن اتفاق می‌افتاد.

چالش: رساندن کاربر به قیمت، سریع و مستقیم

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

چالش ما شکستن الگوی رایج بازار و ساخت یک تجربه ساده بود.
چطور می‌توانستیم کاربر را در کمتر از ۲ دقیقه به لیست قیمت‌ها برسانیم؟

بینش‌های اولیه

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

این بررسی‌ها، به چند بینش مهم برای شروع طراحی منجر شد:

• شروع مسیر برای همه رانندگان یکسان نیست
  همه رانندگان در شروع خرید بیمه، اطلاعات یکسانی از خودروی خود در دسترس ندارند. همین تفاوت، بخشی از کاربران را از همان ابتدا دچار سردرگمی می‌کرد.

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

این بینش‌ها نشان می‌دادند که شروع مسیر باید تا حد ممکن ساده، سریع و قابل‌اعتماد باشد.

راه‌حل

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

شماره پلاک بهترین نقطه شروع به‌نظر می‌رسید؛
ورودی‌ای آشنا که می‌توانست مسیر استعلام را کوتاه‌تر و مستقیم‌تر کند.

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

طراحی MVP: شماره پلاک به‌عنوان نقطه شروع

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

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

برای حل این مسئله، ورودی پلاک را به سه مرحله تقسیم کردم:

• انتخاب امارت

• انتخاب کد پلاک

• وارد کردن شماره پلاک

فرایند استعلام از کجا شروع شود؟

وقتی نسخه اول را با رامین، مدیر محصول، مرور کردم، یک سؤال ساده مطرح شد:
این فرایند باید از کجا شروع شود؟

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

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

دو ماه بعد از انتشار MVP، داده‌ها نشان دادند کاربرانی که مسیر را کامل می‌کردند، در کمتر از ۲ دقیقه به صفحه قیمت می‌رسیدند. این نتیجه امیدوارکننده بود.

اما معیار اصلی ما فقط سرعت نبود، بلکه نرخ رسیدن به صفحه قیمت بود. در ماه اول ۲۴٪ کاربران و در ماه دوم، با وجود رشد ترافیک، فقط ۱۹٪ کاربران به صفحه قیمت می‌رسیدند.

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

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

داده‌ها نشان می‌دادند حدود ۳۵٪ از کاربرانی که وارد Landing می‌شدند، هیچ تعاملی با ورودی پلاک نداشتند.

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

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

نسخه دوم: واضح‌ کردن نقطه شروع

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

• فعال‌کردن دکمه CTA
  دکمه Continue را حتی وقتی که ورودی پلاک خالی بود، فعال نمایش دادم تا کاربر یک نقطه اقدام واضح ببیند.

  هم‌زمان، رفتار آن را طوری طراحی کردیم که اگر اطلاعات ورودی ناقص بود، کاربر را به تکمیل فیلدهای لازم راهنمایی کند.

• بزرگ‌تر کردن ناحیه تعاملی ورودی پلاک
  ناحیه کلیک‌پذیر کامپوننت ورودی پلاک را بزرگ‌تر کردم تا کاربر فقط به فیلدهای کوچک محدود نباشد.

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

پس کاربر دقیقاً کجا دچار اصطکاک می‌شد؟

بازگشت به رفتار واقعی کاربران

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

براساس داده‌ها، نرخ تکمیل پلاک در موبایل حدود ۳۵٪ بود. بازبینی ویدیوها نشان می‌داد بسیاری از کاربران در اولین برخورد با منطق و ترتیب ورود اطلاعات پلاک دچار ابهام و اشتباه می‌شوند. آن‌ها Bottom Sheet را چند بار باز و بسته می‌کنند، بین گزینه‌ها جابه‌جا می‌شوند، روی بخش‌های اشتباه کلیک می‌کنند و در نهایت مسیر را رها می‌کنند.

این الگو با داده‌های کمی هم هم‌راستا بود. نرخ تکمیل پلاک در دسکتاپ حدود ۷۸٪ بود؛ اختلافی معنادار که نشان می‌داد مدل تعامل در موبایل، به‌ویژه Bottom Sheet، اصطکاک بیشتری ایجاد می‌کند.

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

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

• ابهام در تعامل با Bottom Sheet

• نیاز به اطلاعات دقیق در همان قدم اول

• حساسیت بالای شکست در ابتدای قیف

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

نسخه سوم: ساده‌تر کردن نقطه شروع

در نسخه سوم، سه تغییر اصلی با هدف ساده‌تر و شفاف‌تر کردن شروع فرایند انجام شد:

تغییر اول: ساده‌سازی نقطه شروع
ورودی پلاک را از Hero حذف کردم و به‌جای آن یک CTA واضح قرار دادم.

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

تغییر دوم: ورود اطلاعات پلاک در ۳ مرحله
الگوی Bottom Sheet را حذف کردم و اجزای پلاک را در مراحل جداگانه از کاربر گرفتم.

این تغییر شاید مسیر را کمی طولانی‌تر نشان می‌داد، اما بار ذهنی هر مرحله را کاهش می‌داد.

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

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

نتایج

سه ماه بعد از پیاده‌سازی این تغییرات، داده‌ها نشان دادند که مسیر استعلام قیمت نسبت به نسخه MVP ساده‌تر شده است:

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

• با دریافت اطلاعات پلاک در مراحل جداگانه، میانگین نرخ تکمیل پلاک از ۵۶٪ به ۷۲٪ رسید.

• با وجود این تغییرات، کاربرانی که مسیر پلاک را انتخاب می‌کردند همچنان می‌توانستند در کمتر از ۲ دقیقه به قیمت برسند.