An application is not always the best place to start a search. Booking a trip has many differences from selecting a movie. Movie recommendations can include thousands of movies. There can be thousands of passengers waiting for rides at any given moment. Since there is limited availability, platforms need to manage the demand as well as present the options.
Uber explains their matchmaking process by saying they evaluate potential matches based on nearby riders and drivers in groups (batches). Their goal is to minimize the average wait time among all pairs. On a map, the closest vehicle may not be the fastest to get to a passenger. Physical obstructions, roadways and traffic will influence how long it takes to travel.
This provides insight into the financial justification behind automated matching. Automated systems can alleviate the burden of searching for individuals while maximizing utilization of existing resources. Although a simplified interface does not remove underlying decision-making processes, it relocates those decisions into rules for determining who gets assigned which options and under what circumstances.
The Rules Determine What Constitutes Suitable Options
Before a platform can automatically assign options to users, a definition of suitable results must be established. A useful differentiation between the two types of factors includes requirements that must be met versus factors used to create order of preference.
Consider a repair-service booking portal. Whether a technician can perform repairs on a specific appliance is an example of a requirement. Obtaining an earlier appointment could represent a preference. If both were treated interchangeably, a fast booking could potentially solve nothing.
Multiplayer gaming applications have provided numerous examples of utilizing configurable matching criteria. For example, Amazon GameLift Servers FlexMatch allows developers to specify rules based upon player attributes and network latency, the amount of delay experienced communicating with a server. These rules define which players can be grouped together as part of a match.
A general business lesson is that algorithms require an operational definition of suitability. Companies attempting to maximize “speed” may generate different assignments than companies whose primary objective is to find the most closely matched options. Neither objective becomes apparent solely because the application labels the generated outcome as a “match.”
Users Have Options to Select Criteria Rather Than Listings
Automatically assigning users to options does not preclude users from having options to decide on the parameters for creating options, rather than deciding individually on each option created.
In addition to removing the possibility of users manually selecting listings, automatic assignment can also change where users make selections from parameters defining what each listing must satisfy versus from directly selecting each listing.
The GipsyTeam review of Bovada describes Quick Seat, which places players at a table after they choose the game type, stakes and table size. This represents an example of allowing users to elect the parameters of generating options while leaving the ultimate destination to the services. According to Bovada’s official description, Quick Seat only applies to cash games and excludes tournaments and Zone Poker.
For other businesses looking to implement this type of solution, this difference will matter significantly. In a hypothetical scheduling application, users may want to select a visit type and acceptable time frame as opposed to comparing all possible slots. Only in cases where the defined parameters adequately cover what customers care about will such arrangements prove successful.
Although eliminating listings reduces the amount of effort required to compare options, it eliminates relevant information that certain users consider important. Therefore, designs should clearly convey enough information so users understand exactly what choices remain and what decisions they are delegating.
Waiting Time Changes the Tradeoff
A suitable match may not be available immediately. A platform can continue waiting, offer a different option or report that no suitable match is available. These alternatives have different consequences for waiting time and suitability, so the service needs a clear policy for choosing between them.
There are some additional features of FlexMatch, specifically rule expansion. Rule expansion enables a platform to gradually expand the acceptable range of certain criteria (e.g., the developer allows a wider skill difference after a waiting period). An example of this appears in Amazon’s documentation, where the allowable skill differences can be widened while waiting for a match. However, this is just one possible example and not necessarily representative of what is used by all platforms. Additionally, rule expansion is a configurable option within the API and not necessarily indicative of how many of its users utilize such a threshold.
Outside of gaming applications, the concept is similar. Providing a wider time frame for potential users to arrive at an office or location could provide a form of rule expansion. This is a design-based analogy to FlexMatch, and not a direct reference to a specific booking company. The critical aspect is understanding the difference between broadening a preference and silently discarding a requirement.
Additionally, once an initial proposal is made by the algorithm, accepting that proposal can often be done separately. FlexMatch allows developers to ask the player to approve a proposed match prior to finalizing it. Other services may require a similar review process, allowing users to evaluate both the proposed provider and/or the proposed time.
While both automated assignment and automated commitment represent significant steps toward reducing friction and improving efficiency, these are distinct processes. Therefore, measuring success based solely upon how quickly a player can be assigned is not sufficient.
