Introducing Incentives for Seamless Showing Scheduling in Real Estate

Every real estate agent can tell you this. Booking showings is part of their job that sucks and gets in the way of a seamless experience for their clients. This is because it is a coordination challenge that involves a large group of people who sometimes have differing motives and lack reasons to coordinate. This problem has affected the industry for many years, and is difficult to solve. But today, we will try.

In section 1, I’ll briefly describe the problem domain. In section 2, I will demonstrate how the problem can be rephrased as a coordination and incentives challenge. Finally, I will present a concept for a mechanism design which incentivizes all actors to cooperate

1. Problems in the Real Estate Context

The Showing Schedule Coordination Problem

Briefly, this is how it works in a typical scenario for a buyer (note: buyer can be swapped for lessee).

1. Buyers would like to view a property, so they send a message to their agent, Buying Agent BA telling them the Requested Time. The Requested Time is given with 24 hours notice for a tenanted unit.
2. BA must now send a message to Sellers Agent SA to request a showing.
3. If unit is vacant, the BA must check with their own schedules for conflicts against the Requested Time. If there is a conflict, start over at 1 with a different Requested Time. If no conflict, proceed to showing.
4. If unit is tenanted, SA must now send a message to Tenants asking whether the requested time works for them. Tenants sends a response back to SA, which is either to confirm or request a different time.
5. If Tenants confirms, the SA sends a message to BA, who then forwards to Buyers. If Tenants request a different time, BA forwards request to SA who then forwards to Buyers. Start back at 1.
6. Tenants must either be present for the showing or have their keys available in a lockbox.

In some cases, the scenario above is delayed even more due to the intervention of either the Buyers Agent Brokerage or Listing Agent Brokerage, or both. This process might seem somewhat bearable to a naive reader, but the problem is magnified at scale when it has to be repeated on an often daily basis by thousands of agents for thousands of transactions.

This is what I call the showing schedule coordination problem. You’ll notice that there are multiple middleman in this process, each potentially causing a delay or presenting a conflict which means the process has to start over.

Tenanted Unit Problems

If the unit is tenanted, more barriers present themselves. Firstly, the Buyers must book a showing with some notice, typically 24 hours. In our impulsive and fast-paced environment today, this is a pretty big delay. It’s a barrier for an interested Buyer, and everyone has to accept it because that’s how the system works and there is no other way. Except for issuing a special request, which often happens and is at the Tenants discretion so it is not guaranteed.

Tenants can also refuse the showing request and generally be uncooperative. These are the two classes of problems that are barriers to a seamless showing experience. They are connected because an uncooperative or unprepared Tenant can affect the showing for a Buyer. In a hot market, the difference between a sale and a miss could come down to: Were the buyers able to see the unit in time to place an offer? So at a macro-level these problems have real fiat dollar consequences attached to them. The quantification of these problems economically ($$$) is outside the scope of this article, but is potentially worth researching. This also involves the economic productivity gains of the agents.

2. Coordination and Incentives

Let’s take a fresh look at this problem from a mechanism design perspective. Mechanism design is an engineering-based field of game theory and economics and is about designing mechanisms — also known as games — in such a way that the players are influenced to reach a certain set of objectives. It is often called reverse game theory, where game theory is the science of how to win the game, and mechanism design is the science of how to design the game.

To start, we specify our Players and our Objectives. Then, we try and figure out a set of rules that would encourage the Players to achieve those Objectives.

Game Environment

• Assumption 1: Interested real estate buyer is someone who values their time
• Assumption 2: Buyer is interested in a showing for a tenanted unit
• Assumption 3: Tenants are uncooperative
• Assumption 4: Tenants are simultaneously Buyers or Lessees for another Game with a different set of players

Player Types

• Buyer
• Tenants
• Owner of the property
• Buyers Agent and Sellers Agent

Objectives

• For Buyer and Owner: Tenants to cooperate with showings, comply with showing requests under 24-hours
• For Tenants: Minimize personal disruption caused by showings, be compensated for urgent showing requests or cleaning/staging the unit
• For Buyers Agent: Provide seamless showing experience for their clients, maximize the number of properties available for showing to increase buying options, minimize scheduling coordination difficulty
• For Sellers Agent: Maximize number of buyers viewing the property physically which increases competition, minimize scheduling coordination difficulty
• For the System: As a macroeconomy, the mechanisms goal is to make the showing transaction more seamless for all parties, improve the competitiveness for sellers and improve the number of visitable options for buyers

3. The Mechanism Design

This won’t be easy. As you can tell, the goals are different for each of the player types. Also, the objectives are not strictly specified and measurable. For example, what does decreasing coordination difficulty even mean? So a solution will have to remove the ambiguity of the objectives by formally defining them. Luckily, you should be able to follow along. Most people are familiar with real estate transactions by necessity of needing a place to live. It is helpful but not required to have some familiarity with programming concepts, as ultimately these rules of the game should become the logic of the program.

Just want to know how it works? You can skip straight to the Mechanics section, but its not that hard. Actually, most of the concepts are built around a few fundamental definitions.

Specification

Minimizing coordination difficulty: Increasing the response time of messages between Buyers through to Tenants via BA, SA. Faster response times mean quicker confirmation and better agent/customer experience.

Tenant Cooperation: Increasing the likelihood of acceptance of showing requests (including in under 24 hours notice), increasing the likelihood of the tenants showing a cleaned and staged property for the showing. For showing requests under 24 hours notice, the less time given as notice then the more Compensation should be.

Compensation: Increasing the set and quantity of incentives available for Players as reward for Tenant Cooperation and Minimizing coordination difficulty. Incentives can either be cryptocurrency or tokens which can be redeemed in other parts of the system. More on this later.

Mechanics

Rule 1: All Players must have access to an Ethereum blockchain account in order to play, with access to the Internet

The reason why is because in order to Minimize coordination difficulty, it helps to have all messages share the same communication medium. So rather than Buyers texting BA who calls SA who emails Tenants, putting these requests on the same medium automatically reduces friction. In this case, that medium is a digital, public ledger maintained by the smart contract. Another reason we’re using the Ethereum blockchain is because the mechanism must hold and transfer value — potentially large amounts of it.

Rule 2: The Owners and Selling Agent must deposit an amount X into escrow, held securely by a third-party or smart contract. This amount is held in escrow and can potentially be earned by the Tenants, if they cooperate. The Selling Agent and Owners should be incentivized to sell the property, so it’s in their interest to make bookings seamless. You can’t get something for nothing, so these players must stake cryptocurrency and put it at risk in order to receive the benefits of seamless showing scheduling. Without incentives, the Owners are risking not being able to sell the unit without having the tenants first move out, risking at least 1 Month of Rent and the costs of staging. Without incentives, the Sellers Agent risks an uncooperative tenant and a delayed property sale.

The most difficult piece of this puzzle is the Tenants. Currently, they have no tangible incentives to cooperate other than good feels. So lets change that. They must be incentivized to take a showing under 24 hours, confirm showing requests as soon as possible, and cooperate with the showing by cleaning and staging.

Rule 3: The Tenants must stake an amount Y, held in escrow The Tenants would like to be compensated for cooperating, so they agree to play this coordination game. They should not be freely given this opportunity; they must also stake, or put at risk, a certain amount of cryptocurrency.

EDIT: Feedback on this from Toronto agent Jeffrey Agyemang is that Tenants staking something monetary is a bad or risky user experience, which I agree with on balance. So alternatively, the Tenants can rely on being able to earn and redeem tokens which provides them the opportunity to have seamless showings too, by playing the Buyer / Lessee role in another game.

Rule 4: Buyers or Buyers Agent must submit a blockchain transaction T with a requested time, including an amount B held in escrow Once the blockchain transaction is finalized, a timer immediately starts. The amount of response time factors into the potential payoff for the Tenant. If the requested time is under 24 hours, the smart contract will check to make sure that the amount X, held in escrow, is enough to cover the reward for the Tenant. The Tenant is given a time window to send response message R, with either a confirm or time change request. With a confirm, the amount of time between T and their response (another blockchain transaction) is factored into their reward. So the longer they take, the less the reward is. This encourages high response speed, which is one the Objectives of the mechanism.

The game is put into motion with these triggers, with funds now at risk and everyone incentivized to cooperate. The challenge now becomes how to ensure that everyone follows the rules and doesn’t try to cheat.

Rule 5: When Tenants submit response R, they submit a question that only a physical visitor to their home would know the answer to. This question should not be changed, and all visiting Buyers or Buyers Agent will need to answer the question.

The Buyers Agent or Buyer now enter into a specialized sub-role called a Verifier. They will physically be visiting the property at Requested Time, so they should be able to answer the question with or without the Tenant being in the property during time of visit. They are given a time window W in order to submit the answer. If your familiar with blockchain terminology, this can be thought of as a Proof-of-Visit. This proof could later be exchanged with something like FOAM, a blockchain-based physical location verifier network.

By answering the proof-of-visit question, what are they verifying? They are verifying that they have visited the home. In addition, they could answer another question verifying that the home is clean and presentable (which is the definition of “staged”).

Rule 6: In exchange for playing this verification game, Buyers Agent or Buyer are entitled to receive back their deposit B if they answer correctly and on time. If they answer incorrectly or late, they lose their deposit B.

A benefit of this rule is that it discourages showing cancellations without notice. The Buyers Agent or Buyer will have to contact the Tenants and ask for the answer to the question, or submit a cancellation transaction to the blockchain, which refunds most but not all of their deposit B.

Rule 7: Games are played within sequential periods of date range E where the proof-of-visit question cannot change within E

This rule must exist due to the requirement that the verification game be decentralized. Within the date range E, all visitors should answer the question with the same answer. This demonstrates that: The Tenant chose a question which is deterministic (has a real objective answer) and understood by the visitors.

The Verifiers used the truth as a schelling point to coordinate

This is critical. There will be different sets of Verifiers coming to see the property, and we are assuming they are strangers and don’t have the means to communicate with each other. The objective truth is the only thing that they can coordinate around. The truth is considered a schelling point from game theory. So the results of their answers will either form a majority towards a single answer, with the assumption that the remaining submissions not in the majority are guesses or attempts to defraud the mechanism.

To demonstrate, I’ll present an example question:

“What is the color of the post it note on the fridge?” Assuming that there is no other way to answer this question correctly without physically visiting the property, then this question is enough to provide a proof-of-visit. In our theoretical scenario, 75% answered red, 5% answered yellow and 20% did not respond. So the correct answer is red.

Rule 8: The mechanism uses this schelling game to determine the valid proof-of-visits and the correct answer used in Rule 6.

Bringing it Home

At the end of date range E, the mechanism rewards Tenants from deposit X and if a majority of Verifiers submitted “YES” to the answer of whether the property was staged. Verifiers receive back some of their deposits, having benefited from seamless showing scheduling. If they accepted a showing request in under 24 hours, Tenants are rewarded from deposit B. If Tenants did not select an appropriate proof-of-visit question or did not cooperate with showings, they lose their deposit Y.

Assumption 4 states that Tenants are also Buyers or Lessees for another game with a different set of players. So we should take a systems perspective and think about how the result of one game can affect the state of the other. In this case, the incentives and rewards for coordination can be “tokenized” so that if you give showings with less than 24-hour notice, you can receive the same in kind by paying with these special crypto-tokens. The idea is that there will be an ongoing market rate for these tokens, so instead of having to earn them you can simply purchase and use as you saw fit.

Conclusion

Bitcoin solved the problem of electronically sending digital value using game theory and economics. With the explosion in interest in blockchain, game theory and mechanism design are receiving equal attention as tools for the emerging field of token engineering. This crash course in mechanism design is useful if wanting to learn more about the discipline.

FAQ

Is it too complex? Critics fail to appreciate one thing when asking this question. Few people are going to want or need to understand the entire mechanism holistically. Rather, you just need to understand how to play the specific role that applies to you. Also, the game contains built-in incentives for users to further educate themselves and reap the rewards. This can create a positive feedback loop where the more you understand the game, the more you get rewarded. Bitcoin and Ethereum are extremely complex in how they actually work. But early users were told they just had to run a program on their computer (mining) and could earn the digital currency. The more the value of their holdings increased, the more they wanted to learn. A dumbed-down campaign for tenants to “Get paid to move out” would be a simple message to initially capture interest. Everything else grows from there.

Is it niche? We’re still so early in the decentralization era. There are a ton of people who still need help understanding how it all works. At the stage that were at, niche dApps can serve as educational trojan horses that introduce new people to the very wide world of blockchain. We need more of these small, focused dApps and less startups that take years to execute a vision which may not even pan out in the end.

What are remaining challenges?

• Perhaps there is need for arbitration if something goes wrong. What are the economics of a third-party who chooses to play role as escrow and dispute arbitrator? Can this mechanism be decentralized on a smart contract.
• Figuring out how to resolve a scenario where the Buyers Agent and Buyer visit a property but experience an issue accessing the property. This means they cannot answer the Proof-of-Visit, even though they legitimately tried to go to the showing on time.

Thanks to David and Nate for presenting the problem and inspiring the solution. Thanks to Jeffrey Agymang and Andrew Weinberger for providing feedback. Disclaimer: I hold some ETH cryptocurrency.