A property portal can have thousands of listings and still leave money on the table. A property agency can receive hundreds of enquiries and still have a lead problem.

Those two statements sound contradictory until you separate an enquiry from a lead, and a lead from the human work required to turn one into a transaction. That distinction is where we started with Propertyzone.

The Number That Changed the Problem

At the Zimbabwe Real Estate & Tech Summit in March 2026, Propertybook presented data that made a problem in the industry's digital sales workflow difficult to ignore. In one 30-day period, 13,223 WhatsApp enquiries were generated, and 2,410 went unanswered. That is not a shortage-of-demand problem. It is a response-system problem.

Techzim's coverage of the summit also highlighted the industry's response-time problem, with the discussion centred on how quickly agents act after an enquiry arrives.

The significance for us was not the performance of one portal or one agency. It was the question underneath the number:

What happens when a market becomes good at generating enquiries but has no reliable system for turning those enquiries into managed opportunities?

That is a software problem. But it is not a "build a CRM" problem.

Zimbabwe Real Estate Had a Distribution Problem

Before Propertyzone, much of the industry's internal matching infrastructure was surprisingly simple. It lived in WhatsApp groups. An agent would post something like:

"Looking for a 3-bedroom house in Mount Pleasant, under USD 180,000, cash buyer."

Another agent might have exactly that property. They might see the message immediately, six hours later, or not at all. By then, the property might already be under offer, or the buyer might have found something else. The system worked because estate agents are resourceful. It also worked poorly for exactly the same reason: the information lived inside conversations rather than a system.

We wrote about this before building further into Propertyzone: Zimbabwe effectively had a property database already. It was just distributed across WhatsApp groups, individual agents' memories and disconnected listing systems. The problem was not that the industry had no information. The problem was distribution, retrieval and timing.

An Enquiry Is Not a Lead

This became one of the most important distinctions in the product.

A person clicking WhatsApp is not automatically a qualified prospect. A person asking whether a property is available is not the same thing as someone actively trying to buy. A person asking for the price is not necessarily a buyer.

And a person who is not a buyer today may still be the right customer for a different property three weeks from now. So there are actually several states:

Interaction → Enquiry → Qualified Lead → Conversation → Viewing → Negotiation → Transaction

Most digital property systems are very good at creating the first two. The interesting engineering problem begins after that. The question becomes:

What does the system know about the person, what should happen next, and who needs to act?

The Agent's Problem Is Not Another Dashboard

This is where the obvious software answer starts to break down. Give an agent another dashboard. Give them another login. Give them another notification centre. Give them another CRM to check between viewings. On paper, that is digitisation. In practice, it can simply add another place where the work gets lost.

The agent is already dealing with:

• clients
• listings
• viewings
• calls
• WhatsApp conversations
• follow-ups
• negotiations
• paperwork
• other agents
• new enquiries arriving while they are doing all of the above

Propertybook itself described the resulting environment as a glut of information, contacts and leads that can become difficult to prioritise without structure. That is the part of the problem that interested us.

The objective was never to give agents more software to manage. It was to make the software manage more of the work.

So We Changed What a Property Portal Was Responsible For

The conventional portal model is straightforward:

• Put properties online.
• Help people find them.
• Let them contact the agent.

That model is useful. It just stops too early. We asked what would happen if the platform retained enough information about demand to do something useful after the search.

What if a buyer's requirements could remain in the system? What if the next suitable listing could find that buyer? What if an agent did not have to remember every active requirement? What if the platform could tell the right agent when a relevant property entered the system? What if the same logic worked in reverse?

That became Propertyzone.

We Built Around Intent, Not Just Inventory

Propertyzone treats the property listing as one side of the system. The buyer or renter is the other. A buyer has a set of requirements:

• Suburb
• Budget
• Property type
• Bedrooms
• Purpose
• Timing

A property has a corresponding set of attributes. The value comes from connecting the two. That sounds obvious. It is much harder to do reliably when those attributes are buried inside descriptions, WhatsApp messages and inconsistent listing information.

So we moved the system towards structured data. Propertyzone's listings capture detailed attributes around the property itself, including utilities and other infrastructure information, while the platform also maintains structured agency and neighbourhood information.

The goal is not to make the form longer. The goal is to make the data useful after the listing has been published.

The Matching Engine Came From an Existing Human Behaviour

We did not invent the idea of matching buyers to property. Agents were already doing it manually.

An agent receives a new buyer requirement and remembers, or searches through, properties that might fit. A new property arrives and the agent remembers a buyer who asked for something similar.

We looked at that behaviour and asked a more useful question:

Why should software wait for the customer to search before it helps the agent match demand to supply?

Propertyzone therefore works in both directions. A new buyer requirement can surface against existing inventory. A new property can surface against known buyer requirements.

The software is not replacing the agent's judgement. It is reducing the amount of remembering, searching and forwarding required before the agent can use that judgement.

And Then There Was WhatsApp

There was another obvious decision. The agent was already on WhatsApp. The customer was already on WhatsApp. The problem with many software workflows is that they assume the user wants to leave the environment in which they are already working. We did not.

Propertyzone uses WhatsApp as part of the delivery layer because the useful action is often not:

"Open Propertyzone."

It is:

"This property matches the buyer you registered. Here is the reference. Here is the agent. Start the conversation."

When WhatsApp is where the business already operates, forcing users into a second communication environment creates unnecessary friction. The technology therefore sits underneath the workflow. It does not ask the workflow to change first.

This Is Also Why Connectivity Became an Engineering Problem

Zimbabwe does not operate with perfectly reliable connectivity.

For an office worker, that can mean an email arriving late. For an estate agent standing outside a property with a buyer, it can mean something more consequential.

The page does not load. The listing photo does not load. The buyer asks:

"What else do you have around here?"

And the agent is suddenly trying to answer a sales question while waiting for a network request. Software built for environments where connectivity is assumed is often technically correct and operationally wrong.

Propertyzone therefore needed to tolerate degraded connectivity rather than treating it as an exceptional failure state. Recently accessed listing information can remain available on the device, interactions can be deferred, and the application can reconcile state when connectivity returns.

That work is invisible when it functions correctly. That is precisely why it matters.

The Second Problem: A Listing Is Not Enough Information

The traditional property listing is largely descriptive: A price. A suburb. A few photographs. Bedrooms. Bathrooms. A paragraph written by the listing agent. That is enough to display a property. It is not enough to build useful property intelligence.

A serious property decision often depends on questions such as:

• What is the water situation?
• Is there a borehole?
• What is the borehole depth?
• Is solar installed?
• How reliable is electricity?
• What is the tenure position?
• What is actually around the property?
• What does the neighbourhood look like beyond the listing description?

Propertyzone deliberately pushed more of those attributes into structured information. The platform's current listings include utility and infrastructure information, while its neighbourhood system is designed to make location-level information part of the decision rather than an afterthought.

This is not just a UX decision. It is a data architecture decision.

Why This Matters Beyond Today's Buyer

This is where the product becomes more interesting from an engineering perspective.

Structured property data is useful today because it helps a buyer compare properties. Tomorrow, the same structure becomes useful for:

• better search
• property matching
• demand analysis
• lead qualification
• recommendation systems
• market intelligence
• AI-assisted property search

Those things cannot be layered reliably onto a database where the important information exists only inside free-text descriptions. That is why our earlier work on AI readiness in Zimbabwe real estate focused on data before AI. The AI problem is downstream. The schema problem is upstream.

Trust Had to Be Engineered Into the Marketplace Too

Property is not an ordinary ecommerce transaction. The consequences of bad information are much larger. The platform therefore needed to answer another question:

Who is allowed to participate in the marketplace?

Propertyzone restricts its professional supply to EAC-registered agencies and maintains an agent directory around those registered professionals. That decision is important because verification is not something that should be added as a badge at the end. It needs to exist in the underlying data model.

The agency is a known entity. The agent belongs to the agency. The property belongs to an identifiable listing relationship. The buyer is dealing with a professional record rather than an anonymous contact. Again, this is infrastructure disguised as interface.

We Also Had to Think About the Agency Website

The portal is only one place where demand begins. A buyer can discover an agency through Google, arrive on an agency's own website, find a property, click WhatsApp, submit a contact form or ask for a viewing.

None of that guarantees that the agency has captured the interaction as a structured lead. The agency website is often excellent at presenting inventory while remaining disconnected from the system that manages the resulting demand. That is the next area we are engineering around. The long-term model is not:

Propertyzone gets all the leads.

It is:

Wherever the lead enters, the agency should not lose the lead.

That means the same lead infrastructure should eventually sit behind the portal, agency websites, landing pages and other acquisition channels. The brand and website can remain the agency's. The workflow underneath becomes connected.

What We Built Is Therefore More Than a Portal

Propertyzone now combines several pieces that are normally treated as separate products.

A property marketplace
for discovering verified properties.

A structured property database
that captures more than just a title, price and description.

A professional directory
built around registered agencies and agents.

A demand capture system
that turns property interest into usable buyer or renter information.

A matching layer
that connects demand and inventory.

A WhatsApp delivery layer
that moves useful actions into an environment agents already use.

A neighbourhood information layer
that makes infrastructure and location part of the property decision.

An architecture designed for imperfect connectivity
rather than pretending the network is always available.

Those are not seven disconnected features. They are pieces of one workflow.

The Thing We Deliberately Did Not Build

We did not try to solve everything with automation. That would have been the easy way to make the product look sophisticated. Instead, one of the lessons from shipping Propertyzone was that manual-first is often the more intelligent engineering decision.

When agencies joined the platform, the fastest way to understand the onboarding problem was not to build another complicated import engine. It was to help get the first listings onto the platform.

Once the real workflow became visible, the automation opportunities became clearer. That philosophy now shapes how we approach custom systems more generally:

Run the workflow manually. Learn where the friction actually lives. Automate the part that deserves automation.

That is considerably cheaper than automating a theory.

What Propertyzone Is Solving Now

The first version proved that the model could work in production. The next stage is deeper operational infrastructure.

Response Management

An enquiry should have a state:

• Received.
• Contacted.
• Qualified.
• Viewing.
• Negotiation.
• Closed.
• Lost.

"Unanswered" should not be invisible. It should be measurable.

Lead Ownership

A customer should not disappear because the agent who first received the enquiry is busy, offline or unavailable. Lead ownership needs to belong to the agency workflow.

Response-Time Intelligence

If speed matters, the system should measure it. Not as vanity analytics, but as operational information.

How many enquiries arrived? How many were answered? How quickly? How many died without a response? Which sources produce actual opportunities? Which agents are overloaded?

Lead Recycling

A lead should not become useless simply because the first property was wrong. The buyer who rejected one house may be the exact buyer for the next house. The system should remember that.

Agency Website Integration

A property enquiry originating on an agency's own site should be capable of entering the same lead workflow as an enquiry generated inside Propertyzone.

Better Matching

As the dataset grows, matching can become more useful in both directions:

buyer → property

and

property → buyer

That is where the platform begins to behave less like a catalogue and more like a market intelligence system.

The Real Problem Was Never "Zimbabwe Needs Another Property Portal"

That would have been an easy conclusion. There were already property websites, listings, agencies, WhatsApp conversations and demand. What was missing was the connective tissue.

The market had:

• inventory without enough structured context
• enquiries without enough intent
• leads without enough workflow
• agents without enough time
• WhatsApp conversations without enough system memory
• websites without enough connection to the sales operation

The opportunity was therefore not to build another place to put houses. It was to connect the pieces that already existed.

What Building Propertyzone Taught Us About Solutions Engineering

This is the part that matters most to Sparkline Labs. A software brief could easily have said:

Build a property listing platform.

That specification would have been technically clear. It also would have produced the wrong product.The better questions were:

• Where does the agent actually lose time?
• What is the difference between an enquiry and a commercially useful lead?
• Where does demand disappear?
• What information does an agent need before acting?
• What happens when the connection fails?
• How does the agent already communicate?
• What information needs to become structured so that the system can do more later?
• Which processes should be automated, and which should remain human?

Those questions produced a very different architecture. That is solutions engineering. Not starting with:

"What software should we build?"

Starting with:

"What is the business failing to do, why is it failing there, and what is the smallest reliable system that changes that?"

Propertyzone Is the Product

The Method Behind It Is What We Sell

We built Propertyzone for property. The same thinking applies elsewhere.

A logistics business does not necessarily need another dashboard. A school does not necessarily need another management system. A financial services company does not necessarily need another mobile app.

A distributor may need a WhatsApp order workflow. A service business may need a lead-routing system. A growing company may simply need the five spreadsheets and twelve WhatsApp processes it relies on to finally become one system.

The technology changes. The engineering principle does not.

Understand the workflow first.

Model the real constraint.

Design around the operating environment.

Build the riskiest part first.

Ship it into production.

Then automate what has actually been proven to work.

That is how we built Propertyzone. And that is how we approach software for African businesses.

Propertyzone Today

Propertyzone is live in production with more than 1,000 listed properties, EAC-registered agencies, structured property information, neighbourhood data, buyer/renter request workflows and WhatsApp-based agent interactions. But we do not regard the current product as the finished answer.

The interesting part of building a system like this is that every production interaction reveals another layer of the underlying problem. The unanswered enquiry pointed to response management. The WhatsApp workflow pointed to lead routing. The matching problem pointed to structured demand. The listing problem pointed to structured property data. The connectivity problem pointed to offline tolerance. The agency website problem points to distributed lead capture.

Each one is another engineering problem. That is the work. And that is why Propertyzone is more than a property portal. It is a live experiment in what happens when software is designed around the way a Zimbabwean industry actually operates.