← Quay lại community
Category:

BAEMIN case: Giảm tỉ lệ hủy đơn hàng sau khi order vì lý do giao sai địa chỉ.

Đây là 1 case study nhỏ mà mình thực hiện 1 giải pháp tương đối đơn giản đối với 1 vấn đề khá phức tạp về mặt kỹ thuật (liên quan đến location, vị trí và hành vi người dùng) và đã đạt được metrics đề ra. Hi vọng chia sẻ thêm được cho các bạn về mặt giải pháp

Background

Trong số các user hủy đơn hàng sau khi đã order trên app BAEMIN, có khoảng 30% lý do là giao sai địa chỉ, vốn dĩ là khá cao so với tổng thể. Vì vậy team mình đã tiến hành inspect và phỏng vấn user để tìm hiểu các tình huống mà user gặp phải, qua đó hiểu được rằng họ thường rơi vào 2 trường hợp sau đây:

  • Người dùng di chuyển trong khi đặt hàng: user 1 ở địa điểm A, tìm món ăn và cho vào giỏ hàng, lúc này địa chi được tự động detect ở location A. Sau đó user đóng app và chạy sang địa điểm B, ấn order nhưng địa chỉ giao hàng vẫn là A -> sai địa chỉ, hủy đơn
  • Người dùng chọn mặc định địa chỉ giao hàng đã lưu là Nhà, sau đó đến cty, order, lúc này giao hàng vẫn đến địa chỉ nhà chứ ko phải cty.

Đây là tracking về tình trạng hủy đơn do sai địa chỉ:

Objectives của dự án

  • giảm tỉ lệ hủy đơn vì sai địa chỉ xuống còn dưới 15%
  • Tạo trải nghiệm tốt hơn (user ko thấy khó chịu) khi bị sai địa chỉ

Một vài issues/findings khác mà mình tìm hiểu được

1. Thiết kế to, ấn tượng ko hẳn là user sẽ thấy

Như vậy, sau khi xem xét lại màn hình giỏ hàng:Như các bạn đã thấy, phần địa chỉ được thiết kế rất to và rõ, trong team ban đầu nghĩ rằng chữ to và ấn tượng vậy thì user sẽ thấy địa chỉ của mình đang đúng hay sai, nhưng thực tế khi tìm hiểu từ người dùng thì đa số họ sẽ 1 cách nào đó (cognitive) lướt qua thông tin này. Đây là 1 dạng bias về thông tin, vì hầu hết các trường hợp thông tin này đều đúng, nên người dùng có xu hướng bỏ qua mà chỉ tập trung vào thông tin quan trọng hơn là đơn hàng, khuyến mãi và thanh toán.

2. Auto detect địa chỉ ở Việt Nam rất khó

Đối với các nhà trong ngõ/hẻm, thì việc auto detect địa chỉ có nhiều trở ngại, ví dụ địa chỉ đc detect có vẻ gần với địa chỉ của user theo đường chim bay, nhưng thực tế vì ngõ ngách phức tạp có thể đến được đúng nhà của người dùng phải đi vòng rất xa.

Giải pháp

Giải quyết vấn đề ở điểm quan trọng nhất trong 1 flow

Trong trải nghiệm người dùng, việc cung cấp trải nghiệm tốt tại thời điểm quan trọng nhất có thể "cứu vãn" tình huống, hoặc nâng tầm trải nghiệm lên mức cao nhất. Vì vậy, đối với dự án này, vì sự phức tạp trong các vấn đề về location, mình quyết định lựa chọn giải pháp cứu vãn ở thời điểm quan trọng để tránh làm user cảm thấy ko bực mình, tức giận.Đây là flow order cơ bản:Chiều dài của các ô thể hiện tương đối thời gian user trải qua để thực hiện đơn hàng. Ta có thể thấy rằng user tốn rất nhiều thời gian để tìm, chọn món, vì vậy nếu như sau khi order mà lại sai địa chỉ, phải cancel chọn lại, user chắc chắn khó tránh khỏi cảm giác tức giận. Vì vậy mình chọn thời điểm Order/Checkout để giải quyết vấn đề.

Vì sao không cố gắng báo user về địa điểm ở bước giỏ chọn món ăn?

Điều này chỉ đúng trong các trường hợp người dùng vô tình di chuyển khỏi địa điểm ban đầu, đối với các trường hợp ng dùng cố ý giao hàng đến 1 địa chỉ khác, bản thân app cũng không thể xác định được ý muốn thật sự của người dùng trong các case như vậy. Vì vậy tạm thời mình sẽ xử lý vấn đề pre-order ở các giai đoạn sau, thay vào đó như đã nói, sẽ tập trung xử lý điểm quan trọng nhất trước.

Reconfirm với user về địa chỉ giao hàng trước khi chính thức đặt hàng

Đây là giải pháp mà mình đưa ra. App sẽ cố gắng xác định vị trí vật lý hiện tại của user so với địa chỉ trong giỏ hàng, nếu xa hơn 500m, app sẽ thông báo với user rằng họ đang ở xa so với địa chỉ giao hàng

Hiển thị 1 tooltip highlight nhỏ ngay địa chỉ giao hàng là 1 nỗ lực cuối cùng trong việc cố gắng thông báo cho user 1 cách nhẹ nhàng, tuy nhiên nếu user vẫn ấn order, 1 popup sẽ thông báo cho user rằng bạn có chắc sẽ giao đến địa chỉ này không.

Kết quả

Sau khi release vào giữa tháng 3, tỉ lệ cancel vì sai địa chỉ đã giảm dần và ổn định trong dao động từ 10 - dưới 20%. Có thể ko perfect như metrics ban đầu là dưới 15%, nhưng là 1 tín hiệu tốt và team có thể tiếp tục cải thiện ở 1 số bước khác như đã đề cập