Building ZendoLead: The Product Decisions Behind an AI Lead Marketplace

Figuring out what we were actually selling

We are building ZendoLead at Intellixio to help property sellers connect with buyers whose requirements fit their listings. Buyers explain what they are looking for through WhatsApp, the system turns those conversations into structured requirements, and relevant properties can then be matched. Sellers review those leads and can unlock the buyer’s contact information when they want to follow up.

The harder part was defining what a lead actually means. One buyer can match several apartments from the same seller. Their budget or preferred area can change during the conversation. They can withdraw consent, or the seller may already have paid to contact them through another property. Those cases affect much more than the UI because they influence matching, pricing, refunds, counts, and whether the marketplace feels fair to the seller.

AI helps us extract buyer requirements from conversations and qualify property matches, but we do not treat every AI decision as final. Our team can inspect the original conversation together with the extracted requirements, consent, and matched properties. If something is wrong, an operator can correct it and run the matching again. We also allow unclear qualification results to stay in REVIEW instead of forcing the system to return a confident yes or no.

We followed the same approach for property entry. Sellers often already have their listing details inside an advertisement or WhatsApp message, so we built Magic Paste to extract fields such as price, location, bedrooms, and area into the listing form. One early version exposed a mismatch between the readable values the AI was working with and the internal identifiers expected by the form. We changed the boundary so the AI works with readable values and the application maps them back to the internal representation. Missing information remains missing for the seller to complete rather than being hidden behind placeholders.

How lead unlocking works

One of the more important decisions came from a simple case: the same buyer matches three properties from the same seller.

At the data level, those are three property matches. But from the seller’s point of view, it is still one person. Showing three separate lead cards made it look like three leads and created an obvious pricing problem. It did not make sense for a seller to pay three times to contact the same buyer.

We decided to group those matches into one lead. The seller sees the buyer once, with the matching properties inside the same card. If they unlock the buyer through one property, that contact remains unlocked across the other matches from the same seller. If another property matches later, it can join the same lead without requiring another payment. Refunds and lead counts follow the same rule so the product does not use different definitions of a lead in different places.

Our first approach tried to synchronize the paid state across the related property matches. That created unnecessary downstream updates whenever one lead was unlocked. We removed that propagation and kept the purchase as one event, then calculate the combined lead state when displaying the matches. The implementation became simpler once the product rule became clear: the seller is paying for access to the buyer, not for every matching property row.

Pricing and payment decisions

ZendoLead originally used a mostly flat 10-credit unlock price. We later moved toward configurable pricing based on the property’s value. That created another problem we had to think about early: what happens when the property price or pricing rules change after a seller has already paid?

We wanted old transactions to remain explainable. Each unlock therefore keeps the pricing context from the time of purchase, including the pricing version, the property-price snapshot, the credits charged, and the seller’s balance around the transaction. A later refund can refer to what the seller actually paid instead of calculating the amount again using today’s rules.

The payment path also changed where we drew the system boundary. Unlocking a lead requires several things to agree at once: the seller must have enough credits, the buyer must still have valid consent, the balance has to be deducted, the purchase has to be recorded, and the unlock has to succeed. Earlier in the project, more of this logic passed through workflow automation. Once credits were involved, we moved the critical purchase operation into one atomic transaction and kept automation for the surrounding workflows.

The reason was practical. If a notification fails, we can retry it. If the seller loses credits but the lead does not unlock, we have created a financial problem. That difference mattered more than which technology was used to implement it.

Admin and operational workflows

The admin side of ZendoLead is mainly about understanding where the marketplace stops working. A high-level number is not very useful if we cannot see the records behind it. We need to know whether buyers are dropping before consent, whether verified buyers have no matches, whether some areas have demand without enough inventory, or whether sellers are receiving matches but not unlocking them.

That work also exposed how important terminology is. We changed some parts of the product from inactive to idle because those words mean different things. Someone who has not been active recently may still be eligible for matching. Consent, activity, and participation are separate states, and combining them under one label makes both the product and the implementation harder to reason about.

Deletion created similar operational questions. Removing a property is not always just deleting one row because that listing may already be connected to referrals, visits, deals, or other historical activity. We added flows that can end or detach those relationships while preserving the operational history that still matters. That is the kind of work that does not appear in the main marketplace flow, but becomes important once real records start depending on each other.

Lessons from building ZendoLead

A lot of the difficult work on ZendoLead has come from product definitions rather than technology choices.

What counts as one lead? What exactly does the seller pay for? When should AI be allowed to make a decision, and when should uncertainty remain visible? What happens when the buyer changes their requirements after matching? How do we make an old transaction understandable after the pricing rules have changed?

Those questions shaped the architecture more than any individual framework or database feature. Once we agreed that one buyer should remain one lead for a seller, grouping, unlocking, refunds, and counts became easier to reason about. Once we decided financial operations could not partially succeed, the payment boundary became clearer. Once we accepted that AI can be uncertain, REVIEW and operator correction became normal product states instead of exceptions.

That has been the main lesson for me while building ZendoLead: a technically clean system can still be wrong if the product model underneath it is unclear. The more precisely we define what a lead, match, unlock, consent, and payment mean, the simpler the engineering decisions become.

Last updated: October 6, 2026