This is the third part of an 8 part series called ‘User Journey on an On-Demand Business Platform’
On-Demand platforms enable the customers to summon the service providers by making the right matches. The efficiency of the matching algorithm is intrinsic to the success of any such platform and is connected directly and indirectly with network effects and unit economics associated with the on-demand platform. Matching logic of an application determines which service provider is to be allocated to a new customer request. In this follow up analysis, we have provided insights into how our matching module has been designed to satisfy the core requirements of different business models. How the marketplace is structured is the first thing that needs to be factored in on how you are going to match the two sides. With numerous on-demand players in the market, it is not unlikely that the road to success will be decided by the efficiency of one’s matching algorithm, as has been explained in this Uber vs. Lyft matching algorithm. On-Demand Matching algorithms can be broadly classified into two categories: Automatic and Manual.
Automatic matching takes place when logic to assign (or shortlist) service providers is built into the application code. There are certain variants when it comes to the automatic matching algorithm (you can find different types of marketplaces here )
1. Supplier Pick Model – Buyer selects the variables associated with a service and system makes a match by sending out requests to the most optimum list of service providers. e.g. in case of Uber, a ride request is first sent out to nearest available driver (determined by app by comparing driver ETA to customer location). Driver can then accept or reject the request. The model works well where the nature of transaction is highly commoditized (number of variables that the customer has to decide before being matched are minimum). More the difference between the perceived or actual quality of service providers for the customers, less optimum this type of a model and matches made become. This is used in providing generic services such as Taxi or A2B courier service, where customer experience is not greatly influenced by choice of service provider. In case of time bound meal delivery – many businesses choose to automatically pick the delivery person depending on their current location, ETA to customer location, number of meals vs jobs at hand.
Supplier pick models are Single Commit models i.e. one side (service provider in this case) commits to perform a job and no corresponding confirmation is required from the customer to agree to have his request served by that service provider.
2. Buyer Pick Model – Buyer fills in certain details or chooses certain filters and is presented with an optimized list of service providers that match the criteria. Buyer then goes on to check available options and sends a request to service providers in the list and is matched with the one who accepts the request. AirBnB’s matching algorithm now factors in host preferences in its visitor matching algorithm.
Buyer Pick models are usually Double Commit models i.e. after customer selects a service provider, latter gets a notification on her phone along with task and customer details. At this point, she accepts or rejects the request. e.g. on-demand massage services often follow a double commit model where a customer selects from a shortlist of therapists and matching is complete when selected therapist accepts the task.
These matches are based on certain hard filters and soft filters that characterize the system.
Hard filters refer to criteria that help in defining a list of SP’s that can be considered for a particular transaction. Some typical hard filters associated with many such platforms are:
- Type of requested service – Selected service provider should be able to provide the type of requested service, e.g. a request for Uber Black (premium service) can not be matched with UberX drivers, or stylists doing only manicures can’t be matched to a request for a blowout.
- Location where the service has to be performed – Service providers generally have their defined areas of operations controlled through geo fences. Matching logic should also ensure to match only against those service providers whose service areas overlap with desired location of service.
- Time of service – i.e. Scheduling preference by customer. An instant service request will be matched against currently available service providers only, whereas request for a later appointment will look up calendars of service providers against availability for requested slot (taking into consideration buffer time between two consecutive services).
- Pricing – Business models such as TaskRabbit that allow service providers to choose their own prices, often provide customers a filter to look up service providers based on how much they will be willing to pay.
- Specific preferences – Highly dependent on business model, such as preference for a Male/Female therapist in case of an on-demand massage service.
Soft Filters – After applying the hard filters, matching logic is configured to apply certain soft filters to further narrow down or sort the list of matches in a particular order.
- ETA (Tiers) – For any on-demand request, time taken for the service provider to reach the service location is a critical factor in shaping customer experience. In a supplier pick model, Request Dissemination is often based on shortlisted service providers’ ETA to customer location. e.g. platform may send requests to all matched suppliers in 5 mile radius first, and in case none of them accepts the request within a set timeframe, requests are disseminated to suppliers within 8 mile radius and so on. In a buyer pick model, customer can sort the list of shortlisted service providers on the basis of their ETA before making a choice.
- Preferred Service Providers – Some platforms allow customers to tag certain service providers as ‘favorites’ and pick directly from that list in the future.
- Curation/Ratings – Matching logic compares the overall ratings of service providers and presents customer with a sorted list. In a supplier pick model, system also makes sure not to send a customer’s request to a particular service provider rated 3 or below by same customer.
- Freelance vs. Contracted – Some businesses have both employees and freelancers serving on their platform. Contracted employees are paid fixed monthly wages, whereas freelancers are paid on per-job basis. Rest of the factors remaining same – system gives precedence to contracted employees over freelancers in matching customer requests.
- Load Balancing – Matching logic keeps a tab on number of orders placed (orders delivered / in-progress / not started yet) with each service provider to ensure not to overbook a particular service provider, leaving others under-utilized. e.g. for a meal delivery app, it is important to consider the number of orders placed with a service provider vs. number of meals available with him before assigning him a new request.
- Route Optimization – Application takes into account the route a service provider needs to take in order to complete booked services, to ensure he does not have to go too much out of the way to serve a new request falling between two already booked requests.
Manual Matching (by Application Administrator)
This is the most simplistic configuration of matching module. In such models, app administrator manually assigns the customer request to one of the service providers.
When a customer submits a new service request, administrator gets a notification on admin panel, where he also has a view of service providers registered with her platform along with their profiles (services they can provide), current location, availability and assigned jobs. Based on these factors, she picks and allocates the request to one of them. At this point, assigned service provider gets a notification on her phone with the details of task. Some platforms provide service providers a button to simply acknowledge the task, whereas some give them an option to accept or reject the task. As service provider acknowledges or accepts the task, Matching is complete. In case they reject the task, administrator would pick someone else and same process is repeated.
Caveat: Though manual matching may work for businesses with small volume of transactions and small number of registered service providers, as business scales up it becomes difficult and inefficient to continue with a manual matching process because of limitations of manual effort in dealing with a high number of incoming requests and continuous dependency on administrator function.
Get in Touch with us if you are looking to create the next big disruption with your on-demand business idea! We have got your tech covered. No worries.
Subscribe to our newsletter
'Jungleworks Entrepreneur's Den' to get access to the latest industry & product insights.