Ordering Food Online
When a customer orders on Zomato, certain systems are brought to life. The restaurant managers accepts the order, invoicing happens in the background, the food is cooked and then the delivery personnel brings the order to the customer. There are many problems that can arise throughout these processes. Payment gateway failures, lengthy and confusing flows for building cart and delay in food reaching the customer are some of them.
Our broader goal with this project was to identify and solve these suboptimal experiences. We did this by dividing the ordering food online journey in to three flows:
- Pre-checkout: Customer deciding a restaurant and the dishes to order
- Checkout: Building the cart and confirming the order
- Crystal: Everything which happens after the customer has ordered online. We named it crystal since we wanted to be ‘crystal clear’ with the customers here.
I worked with fellow designer Aiswarya and to limit scope we decided to specifically focus on the checkout and crystal flows with this project.
Our goal was to reduce drop-offs when the customer is placing the order. We did this by separately optimising the flows for first time users (placing their first order online) and returning users.
First Time users
A first time user is generally anxious about placing an order online since it is their first time using the service. Our goal is to walk them through the process by giving them clear visibility about the step they are in and the step that is coming up next. The user is also made aware of the fact that these processes are only for the first time and will make future checkouts faster.
For returning users, we made the checkout flow faster by defaulting to the pre-saved personal details and address details (if ordering from the same delivery sub-zone)
Our goal with the post ordering part of the flow was to give exact and timely updates about the customer’s order to them. We also wanted to encourage the users to utilise the wait by giving back to the platform. Ask them to review the app, checkout new products (like Zomato Treats) or rate a previous order.
Solving for delayed orders
Another problem that we tried to solve with crystal were delayed orders. Designing a solution which completely prevented delays was futile since a lot of variables(like cooking time & actual delivery time) were not in our control and would change depending on the physical reality of the restaurant. We thought of ways in which we could pacify the hungry customers through the app itself.
The solution was two fold
1. Telling the user about the delay as soon the restaurant accepts the order with an increased delivery time (to know more about the restaurant side, read Zomato for restaurant managers). This makes the users instantaneously aware of the reason for the delay and there is lesser load on the chat support tea
2. On getting to know that the order has not be delivered on time, we move the users directly to chat support. This was done to reassure the anxious users that the whereabouts of their order are being actively tracked down.
The biggest takeaway for me with this project was how good design can solve for suboptimal business constructs as well. Since, at that time Zomato did not have their own delivery fleet, tracking of delivery personnel was impossible and that lead to frustrated customers when the order was not delivered on time. To curb the negative effects of a delayed order with the business constraint was a challenging yet fun project. We were also successful at it as we saw the average rating of a delayed order increase, a clear indication that the users were less annoyed with delays.