Treedots: A pooled delivery service
We ran a strategic sprint for Treedots, a group-buy delivery platform in Malaysia. See how a seemingly simple UI complaint turned into a larger problem strategic problem with the business model.
This was done in partnership with Xintian Zhang and DBS Bank where we were awarded the most innovative solution award.
A small ask with bigger problems
The Malaysian delivery service we worked with pools nearby orders into a single delivery drop point with a minimum order amount. This allows them to save money on delivery which they then forward those savings to their buyers. The challenge customers were facing was that if orders didn't hit the minimum, the whole order was cancelled. This logic was applied to both the consumer and businesses, without warning.
During our initial audit, the selection and food items seemed clear enough, the only question we had was what the progress bar indicated. The client stated that its the amount remaining before the food will be delivered.
You were still able to complete an order, even if the minimum order was not been met. The business logic was that they had hoped others in the area would buy and order to deliver at the same time to join the first buyers delivery pool. There was just one small problem, if nobody joined? Your order was cancelled.
We were asked to fix a progress bar that indicated customer order status. What we found was a coordination problem between strangers who'd never agreed to share their delivery time.
Three issues we found
01. An all or nothing experience
If a shared delivery didn't hit its minimum order quantity, the whole order was cancelled—no partial fallback. Many customers would only found out when they realized their delivery never came. Imagine a restaurant or business that ordered ingredients which never showed up, yikes!
02. People were meant to communicate
The progress bar in the application was meant to explain the requirements, but without reading the documentation, customers had no context on what it tracked or why it mattered. It simply showed a progess bar that could indicate anything. Nowhere in the interface at the time of checkout and delivery slot would users know that they should invite others to join their delivery time. Plus, putting the communication on customers to coordinate with neighbors? It probably isn't the most delightful experience.
03. Unattended drop-off
Drivers sometimes arrived before customers could be at the common drop point. Delivery drivers also can't be expected to wait around, so they would leaving food at the drop point to sit out under the Malaysian sun and heat until someone showed up.
It could be argued that this last point is an issue on the customer, however, creating an experience that reduces customer error is also a key value proposition the business has to consider.
Our delivery was left on the street, the meat and dairy products we ordered went bad by the time we picked it up. Completely unacceptable.
Our recommendation was a solution that builds a community
Although we delivered some design proposals, we highly emphasized the need to fix their business model to increase the reward and reduce the punishment that was applied to users for no fault of their own. Our direction was a proposal that would be focused around a business model that builds trust between the business and its customers.
A progressive reward system
We really appreciated the idea of a pooled delivery to have greater savings, but the execution needed some adjustments. We proposed to reframe the delivery as a progressive discount. This means that prices may start with a smaller discount, but the larger the delivery pool became, greater discounts would be applied. This allows for the delivery to happen at no risk to the customer and no loss to the business. The same progress bar becomes a shared-savings meter: discounts grow as your shopping cart grows, or as neighbors join in, and the best part? no order get cancelled.
Encourage community communication
As a part of our efforts to help the business build trust. Our next proposal was to assign the same driver to the same delivery areas. This would allow customers to build a relationship with the driver. We also suggested a single group chat with the driver and participants of a single pooled delivery time to be together, so communication is clear. A familiar face and a shared discussion can turns strangers into a small community where trust and relationships are built.
Nearby pool visibility
When it comes to the actual application interface, its important that delivery pools that already exist are shown to customers. This enables them to see what pools are nearby, what the current discount is, and what the discount would be when they join. Discoverability of these pooled delivery times would be a major factor that defines the success customers have, and ultimately the success the business will have.
Procuring safe drop-points
A long-term goal we proposed was to partner with nearby businesses to have available freezer space for deliveries. This would work a lot like the Amazon locker. This enables the delivery to be safely received, even if something comes up and the customer cannot be at the drop point at the designated time.
The result was an entirely new direction, not proposed
This is one of those cases where the business liked the solution but changed direction entirely. At this time they no longer do deliveries, and have built software focused on business shipping and logistics.
This case study is worth sharing regardless of its application because it really shows how one design element can ripple through the entire customer experience and be the deciding factor on the success of the business.