top of page
Image by Natalia Arkusha

Automate Service
Unhappy Flows ðŸ¤–

To alleviate a heavy reliance on handling rescheduling and cancellation requests via Customer Service Team, I automated the processes on mobile app to save 384 man-hours.

Consumer can reschedule and cancel services on mobile app effortlessly.

Toby-DB-Service-Detail-Bank-Paid.png

The rescheduling button is displayed more upfront to encourage the action and maintain the fulfillment rate.

Toby-DB-Service-Detail-Bank-Paid-1.png

The cancellation button is shown after user clicked the Help button on the top right corner.

Hotline Consultant

​Problem

In Q1 2023, 382 man-hours were spent handling rescheduling and cancellation cases for direct booking home services per month, resulting in 2 problems:
 

  1. The Customer Service Team (CS) spent significant man-hours handling cancellation & rescheduling cases, which has overwhelmed the team.
     

  2. The limited manpower causes a lack of responses & quality service, which decreased customer satisfaction and trust in Toby as per online complaints.

Solution

Two things have been done to serve consumers better and save manpower.
 

First, the business unit has standardized the rescheduling and cancellation policies.
1. Consumer needs not to pay an admin fee if rescheduling a session that hasn't been matched with cleaners but needs to pay if canceling one.

2. Consumers cannot get a refund if canceling a matched session 24 hours before the service time and are not allowed to reschedule one either.

The terms encourage consumers to reschedule first for a higher fulfillment rate and discourage them to change at the last minute.
 

Second, the Product Team optimized these rescheduling and cancellation features:

Screenshot 2023-08-06 at 9.50.11 PM.png

Key User Flows

Rescheduling

Toby-DB-Full list service date-selected.png

1. User chooses a session to reschedule

Toby-DB-Full list service date-picker-selected.png

2. User chooses
a new date & time

Toby-DB-Service-Reschedule-Payment-1.png

3. User sees the rescheduling summary

Toby-DB-Service-Reschedule-Paid-1.png

4. User is notified about the successful rescheduling

​

Cancellation

Toby-DB-Service-Cancel-Within24.png

1. User chooses a reason to cancel

Toby-DB-Service-Cancel-Within24-1.png

2. User is recommended to reschedule

Toby-DB-Full list service date.png

3. User chooses a session to cancel

Toby-DB-Full list service date-1.png

4. User fills in bank account details if default payment is bank transfer

Toby-DB-Service-Reschedule-Payment.png

5. User sees a cancellation summary

Toby-DB-Service-Reschedule-Paid.png

6. User is notified about the successful request

DB-Order Detail section break down-1.png

7. User is notified about the refund progress

Result

We saved 382 man-hours per month to handle rescheduling and cancellation cases for direct booking services. Only 2 Custom Service staffs are needed to handle cases instead of 6.

Challenges & Mitigation

Rock Climbing
  1. Dispute on handling edge cases

    2 edge cases were found during the product design process:
    A. Platform needs to pay for the consumer when the consumer reschedules to a new time slot 
    B. Consumer needs to pay for the platform to cancel a session

    We have 3 options to handle these edge cases:
    i. Reuse the refund or payment flows to handle them online
    ii. Direct customer to handle offline
    iii. Forfeit the payment to customer or their payment to us

    When evaluating our decision, we prioritized Return on Investment (ROI) as the decision factor and chose to do #3. It is because option #1 complicates the process and option #2 consumes manpower. With the lack of data on how many such edge cases, we decided to do #3 first and review the no. of customer inquiries after the launch to assess the need for optimization.

     

  2. Refund calculation may not be precise without considering the distribution of surcharge per session

    Our existing refund calculation didn’t cater to the surcharge that is calculated per session because the backend doesn’t have a clear classification on the charge type (e.g. basic charge, surcharge & admin fee) and level of the charge (order level or session level). We simply calculate the refund amount via “no. of order amount/ no. of the session in an order”. This may not truly reflect the exact amount customer should be refunded.

    We decided to keep the current calculation as it takes more effort to revamp the data structure on the backend and may delay the project. After calculating the risk, we decided that the benefit of automating the refund process online outweighs the concern about less precise refund amount because solving the problem of heavy reliance on CS is more vital at the moment.

bottom of page