Why Does a Real Estate Transaction Still Require So Many Phone Calls?

There is a particular sentence that makes my systems-integration brain itch: “I’ll call them and find out.” Sometimes a phone call is exactly the right thing. But when an entire business process depends on people repeatedly calling each other to determine the state of the process, we don’t have a communication problem. We have a systems problem. Real estate is full of this. Did the documents go out?

Did the signer confirm? Has a notary been assigned? Did the appointment happen? Were there corrections? Were the documents scanned back? Has somebody reviewed them? Where is the original package? Who has it? Has it shipped? Did it arrive? None of those are particularly exotic questions. Yet answering them can involve escrow, title, lenders, signing services, notaries, borrowers, shipping carriers, and multiple software platforms. Every organization may have a perfectly functional system.

The transaction still becomes fragmented because the systems don’t share a common view of what is happening. This is one of my favorite kinds of engineering problems. Not because it’s glamorous. Because it isn’t. Nobody gets excited at a conference and announces that they’ve revolutionized the world by eliminating six unnecessary phone calls. I do. Six unnecessary phone calls multiplied by hundreds or thousands of transactions is a tremendous amount of wasted human attention.

More importantly, every manual handoff creates ambiguity. One person believes something happened. Another person doesn’t know it happened. A third person has the information but hasn’t entered it yet. Somebody leaves a voicemail. Somebody sends an email. Somebody updates a status field in a completely different system. Congratulations. We have accidentally invented distributed computing using humans. Humans are extremely expensive message queues. They’re also terrible APIs.

This problem is one of the reasons I built Coverity the way I did. I don’t think the answer is another isolated portal where everybody has to log in and manually tell yet another application what happened. The better answer is integration. If an upstream system knows a signing has been created, that information should be able to flow downstream. If the assignment changes, the interested systems should know.

If an appointment is confirmed, completed, delayed, or has an exception, that state should propagate. If scan-backs are required, that shouldn’t live exclusively inside somebody’s memory. And when a human does need to intervene, the software should make the exception obvious instead of forcing somebody to hunt for it. That’s the difference between digitizing a workflow and actually designing one. I have spent a large part of my career joining systems that were never designed to talk to each other.

That experience changes how you look at software. I don’t particularly care whether every component was built by the same vendor. In fact, it usually wasn’t. I care whether the boundaries are defined well enough that the whole thing behaves like a system. Real estate doesn’t need one gigantic application that attempts to replace everything. It needs better connective tissue. That is where APIs matter.

It’s where event-driven architecture matters. It’s where good status models matter. And, occasionally, it’s where somebody has to sit down with the people actually doing the work and ask: “Why are you calling them?” The answer to that question is often a product roadmap. Technology should not eliminate every phone call. People should still talk to each other. Relationships matter. Judgment matters. Sometimes a five-minute conversation solves something no software ever will.

But those conversations should be about things requiring humans. They shouldn’t be: “Hey, did the notary get the documents?” We have computers. They are remarkably good at remembering things. Let’s let them.

To discover how status updates, and dashboards can reduce friction in notarization, visit coverity.io