The Modern Game of Telephone

If you've read A Before-and-After Story, you'll recognize the scene where the AI agent Hans took over answering tenant calls.

The crazy part isn't really that Hans takes over for me — it's that he's the better phone operator. But honestly, I'm a professional in my field, not an answering machine. Hans speaks so many languages, is never sick, never sleeps, and doesn't even lose his patience with Mr. Meyer (unbelievable!). Sure, Hans isn't humanly intelligent, but wherever a real expert is needed, I take back over.

But how is such an agent actually built?

Technically, a phone agent consists of several agents, each performing a small specialized task, recording the result, and then passing the note along. Essentially like a clever assembly line — or a modern game of telephone.

Hans, then, is really a team of Hanses. When a call comes in, the language specialist takes it first. They hand off to the tenant-recognition specialist, who in turn passes it to the damage expert. Eventually the whole matter goes to the ticket creator, who records all the notes correctly in a ticket. Each agent's particular strengths get used along the way. It's a bit like borrowing one employee's voice, another's patience, a third person's property management know-how, and a fourth's knowledge of the building.

If you want to build an agent like this, you quickly run into the challenge of how to break down system walls. Unlike the children's game, the various Hanses aren't just supposed to pass along a fixed phrase to the next Hans. Each one has a specific task and is meant to enrich the information. And that requires a whole series of data queries across all kinds of systems to be possible — no easy task in the property management world (more on that in the CEO foreword).

Who is the tenant?

Let's take the example of a tenant who runs into a problem while booking the guest room in her building and therefore picks up the phone. Here you quickly see how real the problem of broken data flows is, unless the groundwork has already been done. The tenant first needs to be identified. That requires matching against master data — in other words, an interface to the ERP, or a data layer that provides this data.

Which room should be booked?

Based on the tenant's identity, the guest room for the building can then be found and the failed booking attempt analyzed, provided the booking system allows this access.

We're convinced that within a few years, every building will have its own agents in use that can retrieve this information. Today, our application at least needs the flexibility to feed the property management and building context into a data layer in a simple way, so that Hans can retrieve this information quickly and securely.

Where's the contractor job? And how do I get to the contract document?

In this example, we talked about master data and booking systems. Of course, a tenant also calls about other topics, such as a damage report, a question about the contract, or information about the last statement. The situation is the same for these requests. It always comes down to having the right interfaces so the necessary information can flow. Only then can a phone agent check whether the job has already been logged in the contractor portal, whether the requested document is available in the DMS, or whether pets are allowed in that specific apartment. Without an API, all that's left is the generic answer “I'll transfer you.” And then the game of telephone ends with a human, who has to log into every system individually after all, to sort out every question one by one, by hand.