Matching Sellers to Agents with AI: A Case Study in Intelligent Assignment
The Problem with How Agents Get Assigned
Most brokerages assign agents to sellers through some version of the same logic: availability, geography, round-robin rotation, or seniority. The assumption is that a licensed agent is a licensed agent, and any reasonable match will do.
That assumption costs deals.
A homeowner selling a property to fund their retirement thinks differently from one selling to upgrade to a larger home. The retirement seller is often risk-averse, emotionally attached to the property, and primarily concerned with certainty of outcome over maximising the final price. The upgrade seller is typically transactional, focused on speed, and relatively detached from the asset. These are not subtle differences. An agent who excels at hand-holding a nervous seller through a emotionally charged process may frustrate an upgrade seller who wants direct communication and fast decisions. The reverse is equally true.
When mismatches happen, they rarely produce a dramatic failure. They produce something quieter and harder to trace: slower deal progression, more friction in communication, sellers who disengage, and eventually a conversion rate that underperforms what the brokerage’s agent quality should produce.
A client came to us with exactly this problem. They had been tracking it in their data for years without having the tools to act on it systematically. They asked us to build a matching engine that could identify the right agent for a new seller based on who that seller actually was, not just where they lived and when the listing came in.
What the Client Brought to the Table
The most important thing about this engagement was the data the client already had. Thousands of completed transactions, each with a documented seller profile, a matched agent, and a set of outcomes: whether the deal closed, how long it took, what the final price achieved relative to the asking price, and in many cases, seller satisfaction records.
Alongside the structured transaction data, the client had accumulated years of communication records: email threads between agents and sellers, text message logs, and call notes. This unstructured data was largely sitting unused, treated as an archive rather than a signal source.
The combination of those two things — outcome-labeled transaction history and a large archive of agent-seller communication — was what made a serious matching model possible. Without the outcome data, you can build a recommendation system. Without the communication data, you miss the most predictive signals about both sellers and agents. Together, they provided the training material for a system that could match on something meaningful.
How We Thought About the Design
The matching problem has two sides. Both need to be profiled before a match can be made.
The seller side requires extracting a meaningful profile from what is known about the incoming seller at the moment of assignment. Some of that information is structured — property details, location, price range, how the seller came in. Some of it requires inference — their motivation, their communication style preference, their emotional state, their actual priorities. A seller who lists “upgrading to a larger home” as their reason for selling and a seller who mentions needing to fund a parent’s care have fundamentally different needs, but both would check the same box on a standard intake form.
The agent side requires building a performance profile for each agent derived from historical outcomes, not self-reported specialties. An agent who says they work well with all seller types is not a useful profile. An agent whose historical data shows a 74% closure rate with financially-motivated sellers and a 43% rate with emotional attachment sellers — that is actionable. Those patterns exist in the data. They just need to be extracted.
The matching model then learns which seller profile characteristics predict good outcomes with which agent profile characteristics. It does not need to reason about why a particular combination works. It learns the pattern from thousands of historical examples where the outcome is already known.
Building the Seller Profile
The first processing step takes everything known about an incoming seller and constructs a structured profile that the matching model can work with.
The structured inputs are straightforward: property type, location, estimated value range, listing timeline, how the seller came in. These go directly into the profile.
The more valuable inputs come from the initial engagement. Most brokerages have some form of intake — a form, a phone call, an initial email exchange. That initial communication, even if it is brief, carries signal about who the seller is.
We built a language model layer that processes the seller’s initial communication and extracts a set of profile dimensions:
Motivation type. Retirement, upgrade, relocation, financial pressure, estate sale, investment exit, life event. These are not always stated directly. “We need to be out before the school year starts” signals relocation. “We’ve lived here for 32 years” often signals emotional attachment. The model reads the full context, not just keywords.
Communication style. Some sellers write in bullet points and want direct answers. Others write long, detailed messages and need to feel heard before they can move forward. The model classifies the seller’s natural communication register so the matched agent knows how to engage from the first contact.
Priority signals. Speed vs price maximisation vs certainty vs discretion. Most sellers have a primary concern even when they say they want all of them. The model identifies which signals dominate the communication.
Anxiety level. High-anxiety sellers need different agent behavior than confident, low-maintenance ones. Frequency of questions, uncertainty language, and emotional markers in the initial communication all contribute to this dimension.
The output is a seller profile vector — a structured representation of who this seller is across all relevant dimensions — that the matching model can score against the agent pool.
Building the Agent Performance Profile
Each agent in the system has a performance profile built entirely from historical transaction data and their past communication records. This is reconstructed automatically and updated as new transactions complete.
Outcome segmentation. For each agent, we calculated performance metrics broken down by seller motivation type, property price range, location, and transaction complexity. An agent with 200 closed transactions has a meaningful performance record across these dimensions. Their closure rate with retirement sellers, their average time-to-close with upgrade sellers, and their price-achievement rate with financially-motivated sellers are all calculable from the transaction history.
Communication style profile. Using the same language model approach applied to seller intake, we processed each agent’s outbound communication history — their emails, texts, and follow-up messages — to construct a communication style profile. Some agents write warmly and frequently. Others are efficient and data-forward. Some adapt their style across seller types. The profile captures how each agent actually communicates, not how they describe themselves.
Specialisation signals. Beyond explicit performance metrics, the model identifies patterns in which types of engagements produced the agent’s best outcomes. These are not always the types the agent would self-identify. An agent may think of themselves as a luxury specialist but their outcome data shows their strongest segment is first-time sellers navigating an emotional transition.
Capacity and availability. A strong match is only useful if the agent can take the listing. Current pipeline load, scheduled vacations, and recent assignment volume factor into the ranking at the output stage.
The Matching Model
The matching model takes a seller profile vector and scores each available agent against it, producing a ranked list with match scores.
The model was trained on historical pairings: known seller profiles, known agent profiles, and known outcomes. A match that produced a closed deal at strong price achievement within expected timeline was a positive training example. A match that produced a slow, friction-heavy process or an unclosed listing was a negative one. Thousands of labeled pairings gave the model strong signal about which profile combinations predict good outcomes.
We used a gradient boosted model on the structured features and a separate embedding-based model for the communication style compatibility component — how well does this seller’s communication style align with how this agent naturally operates? The two model outputs are combined into a final match score.
The output is a ranked shortlist of agents with individual match scores and, crucially, a plain-language explanation of why each agent was recommended. The explanation answers the question the assigning manager will ask before accepting the recommendation: “Why this agent for this seller?”
For a retirement-motivated seller with a high anxiety signal and a preference for frequent communication: “Agent has a 71% closure rate with retirement-motivated sellers, above-average response frequency in past engagements, and a communication style profile consistent with the seller’s preference for detailed, reassuring updates.”
That explanation matters. A matching score without reasoning is a black box. A system that cannot explain its recommendations will not be trusted, and a system that is not trusted will not be used.
Handling the Cold Start Problem
Two cold start situations needed to be addressed.
The first is new agents — agents without enough transaction history to have a meaningful performance profile. For these agents, the system defaults to a content-based approach: matching based on stated specialisations, training background, and any available early transaction data. As transaction history accumulates, the performance-based profile progressively replaces the content-based one.
The second is unusual seller profiles — motivations or circumstances that appear infrequently in the training data. For these, the model relies more heavily on communication style compatibility and general agent quality metrics, with a flag in the recommendation output indicating lower confidence. The assigning manager is informed that the match is based on limited precedent and their judgment should carry more weight.
Both cold start cases are handled explicitly rather than silently. A system that produces high-confidence recommendations when its confidence is actually low erodes trust faster than one that is honest about its uncertainty.
Evaluation and Validation
Before deployment, the model was validated against a held-out subset of historical transactions — matches the model had not seen during training, where the outcomes were already known.
The evaluation metric we focused on was ranking quality: given the pool of agents available at the time of a historical assignment, how highly did the model rank the agent who actually produced the best outcome? In a strong model, the agent who eventually closed the deal quickly and with high seller satisfaction should appear near the top of the ranked list. Across the validation set, the model placed the eventual best-outcome agent in the top two recommendations for a significant majority of cases — a meaningful improvement over the historical assignment pattern.
We also evaluated communication style compatibility independently, measuring whether sellers matched with style-compatible agents showed better engagement metrics — faster response times from sellers, fewer escalations, lower dropout rates before listing.
Post-deployment, a controlled comparison tracked outcomes between agent assignments made using the matching engine and those made through the prior manual process. The tracked metrics were closure rate, time to close, and seller satisfaction scores. The comparison ran for a defined period before the matching engine became the default.
Deployment and Integration
The matching engine was deployed as an internal API that the brokerage’s CRM calls when a new seller is assigned. The CRM passes the seller profile inputs to the API and receives back a ranked shortlist of agents with scores and explanations.
The system was not designed to make the assignment automatically. It was designed to make the recommendation clearly and let the assigning manager accept or override it. Every override is logged, and over time those overrides become additional training signal — cases where human judgment diverged from the model, with outcomes that either validate or challenge that divergence.
The feedback loop is important. A matching model trained once and left static will drift as agent performance profiles evolve, market conditions shift, and the seller population changes. Building in continuous retraining from new completed transactions and logging human overrides as data kept the model current without requiring periodic manual retraining decisions.
Where This Pattern Applies Beyond Real Estate
The design described here is not real-estate-specific. It is a two-sided matching problem with outcome data, and that structure appears in many industries.
Healthcare. Matching patients to therapists, specialists, or care managers based on patient profile, communication preference, condition complexity, and provider track record with similar cases. The outcome signal is treatment adherence and patient satisfaction.
Legal services. Matching clients to attorneys based on case type, client communication style, budget sensitivity, and attorney performance history with analogous matters. First impressions and communication fit predict retention as strongly as technical capability.
Financial advisory. Matching investors to advisors based on risk tolerance, financial goals, communication preferences, and life stage. An advisor with a strong record on retirement planning is not automatically the right match for an early-career wealth accumulation client.
Education. Matching students to tutors or mentors based on learning style, subject needs, pace preference, and tutor effectiveness with similar student profiles.
Customer success in SaaS. Matching accounts to CSMs based on account complexity, industry, communication style, and the CSM’s track record with similar accounts and expansion or retention outcomes.
The underlying architecture is the same in each case. Two-sided profiles, outcome-labeled historical data, a model that learns which combinations work, and an explanation layer that makes the recommendation usable for the person making the final call.
What to Think Through Before Building This
The technical components here are well-understood. Language model extraction, gradient boosted matching models, embedding-based similarity scoring, and API-based CRM integration are all standard work for an experienced team.
What determines whether the system is actually useful is the quality of the outcome labeling in the historical data. If the training data does not contain reliable outcome information — whether transactions closed, how long they took, how satisfied sellers were — the model cannot learn what a good match looks like. Before scoping the build, the first question to answer is: do we have outcome-labeled match history, and is it clean enough to train on?
The second question is whether the organisation will trust the recommendations enough to use them. A matching engine that sits in the system and gets overridden on every assignment produces no value and will eventually be turned off. Building in the explanation layer, designing the interface so recommendations feel like a useful input rather than an instruction, and running an honest evaluation period before full deployment all matter for adoption.
The best matching systems are not the most technically complex ones. They are the ones that earn the trust of the people making the final call.
Next in the series: Auction Asset Valuation and Bidding Strategy — using historical transaction data and real-time signals to give buyers and sellers a structured view of fair value.
GTC builds AI-powered systems for real estate platforms and enterprise software clients. If you are thinking through a matching or assignment problem in your business, let’s talk.