Self-ship Rate Card

Zilingo - Target Market & Users

Zilingo’s primarymarkets are Bangladesh, India, Sri Lanka, Thailand, Indonesia & Vietnam. Our products and services are also used across the world, especially in Latin America and Asia.

​

Zilingo’s core users are manufacturers, suppliers, retailers, and factories - leadership, ground ops, floor manager, maintenance manager, planning manager etc.

Designing Self-ship Rate Card

An interface to manage the rate-card for self-ship orders on the Zilingo Seller Centre platform.

Design Challenge

What is Self-ship Rate Card?

Zilingo offers different logistics options to our users to enable the timely delivery of orders. Mainly 2 types of logistics were offered - Zilingo fulfilled and 3rd party logistics. Users on our sourcing platform(Z-Trade) wanted to also offer the self-ship option to their customers.

​

Self-ship is the practice of shipping/delivering products by the seller/supplier directly. Providing self-ship is an industry-standard practice because a lot of the users/companies are either equipped with logistics capabilities (availability of delivery vehicles, personnel) or are associate with logistics companies to help them streamline all their logistics needs.

​

Based on user requests we decided to build and offer self-ship feature to our customers. For a supplier, enabling self-ship is not as easy as an on/off toggle.

Background

Why is it a problem?

There are various factors that needs to be considered when they decide to offer self-ship.

​

• Where is the customer located?
• Where are the warehouses located?
• How long will it take to ship?
• How much will it cost to ship?
• What should be the minimum order value to offer self-ship?

​

Our users wanted location-specific control of rates & delivery time to optimize their costs. Some of our users(~20%) had multiple warehouses across the country. Extrapolating such use-cases to a national level operation creates a complicated price matrix. The task was to design an intuitive interface to manage the self-ship rate card across multiple warehouses, regions, and other parameters.

Problem Statement

Mapping User Journey

Design Challenges

There are many challenges while designing this interface. Some of the main challenges we have identified are -

​

• Designing a selection interface for countries that have hundreds of unique zip codes.
• An interface to define unique cost and lead time for any region or combination of regions.
• Mutually exclusive rules
• An interface to cater to sellers with and without multiple warehouses

Design Decisions

The problems and challenges were discussed in the brainstorming session with the team. We arrived at the following design decisions to help create the intial designs -

​

• Self-ship delivery can be enabled at the store level. Once enabled the customer will see self-ship as an option in the checkout flow, along with other logistics options.
• Self-ship MOV will appear as a store level setting if self-ship is enabled.
• Self-ship can also be controlled at the rate card or warehouse level.
• Include FUE and communication to the user journey to help sellers understand and use this feature easily.
• Keep the region/rate/time rules mutually exclusive. If the seller is adding a new rule, keep the previously selected regions as unselectable, to help sellers in avoiding errors while creating the rate card rules.
• Rate type and lead time parameters should be optional.
• Rae type can be a flat rate or free and lead time can be captured in days and weeks.
• Most sellers don't have multiple warehouses, so create a version of the interface for such use cases.

Initial Design

View Prototype

High Fidelity Wireframe

Testing & User Feedback

We ested the initial design prototype with 8 users. Following is a summary of the feedback we have collected -

​

Optional and Mandatory

• Sellers should be able to enable self-ship without providing location preferences and provide location preferences without providing rates.
• Sellers should also be able to provide no rates for some combinations but rates for some combinations.
• However if rates are provided, then lead time should be mandatory and vice versa.

​

Self-ship_1 ->

• Copy of 'manage rate cards' can be updated to indicate "preferences" as rates are not mandatory

​

Self-ship_2 ->

• Entry point into rate cards in case of multi warehouse - It is not clear from the down arrow that clicking it would lead to expanding rate cards. This entry point can be more explicit and clearer.

​

Testing & User Feedback

Self-ship_3 ->

• Perhaps it might be useful if the seller can optionally expand the location preferences into a modal for higher visibility. This might be more useful for those sellers who have a lot of preferences to provide and not a simple select all.
• Since the preferences are complex, if the seller clicks on 'remove' by mistake it would be a lot of rework. Can have a confirmation after the seller clicks remove, or probably not have it altogether?
• Since the combinations can be many, allowing sellers to provide an optional name, which can then be used to display as a Title when not expanded

​

Self-ship_6/7 ->

• Feedback to the seller after clicking 'submit' - Since it is possible that the rate card update be failed, we can have a clear communication that it is updated. If it is not, then we can show the relevant error message and retain the seller in the edit/update mode.
• Parallelly, apart from a timeout issue, we will try to come up with an exhaustive list of reasons why a rate card can be rejected so that relevant error messages can be shown.

Final Design

View Prototype

Impact in Numbers

• 60% of the seller use seller center by themselves while in 40% cases admins use the seller center (among the 60%, admins also use the seller center)
• Among actual sellers, 35% of the seller access SC via mWeb.

Google Analytics, Mixpanel

• 25% of the sellers access only via mWeb.
• About 15% of the sellers also use android app, while 3% use iOS app

​

Learnings from Project

The learnings from the project helped us make furher changes to the designs. Some of our key learnings were -

​

• Better communication was needed to make sure the feature reaches all our users and we can have beter adoption. We intiated email campaigns, included the feature in multiple newsletters and also persisent notification on the dashboard were introduced to address this.
• Given the learnings from analytics, it would make sense to design the seller self-ship rate cards experience for mobile web too and later expand it to apps.
• Mobile web and app experiences were deprioritized because of the lack of resources(covid impact).

Takeaways