Why AI-generated real estate descriptions break at scale
The bottleneck in such projects is not text generation, but the last mile between property export and listing publication.
When several hundred new lots arrive from the agency's CRM at once, managers write descriptions manually: 10–15 minutes per property with photos, specifications, and neighborhood info.
With a stream of exports, the queue of properties grows faster than it can be processed, and some listings are published with no description at all.
Then an accumulation effect kicks in. Listings go live with a delay of a day or two, and desirable properties are snapped up by competitors while the text is still in the queue.
Mass filling of real estate listings turns into a separate manual process that runs in parallel with the agent's core work.
Quality fluctuates from one writer to another.
One writes three paragraphs with details about the building, infrastructure, and layout; another settles for a single line: "spacious apartment, call now." Internal filters and search receive a different set of attributes, and preparing descriptions for the agency's website comes down to manual editing after each manager and repeated approvals.
Mass generation runs up not against the model but against the input data: some fields are empty, some sit in free-form comments, and areas, number of floors, and finish types arrive in different formats.
If this is not normalized, AI generation of real estate descriptions produces smooth text with incorrect facts — wrong area, wrong floor — and the client does not trust such a listing.
That is why automating texts for property listings starts not with a template but with analyzing data sources, required fields, and rules for validating the result before publication. We break down how this works at scale below.
What changes after implementation: speed, consistent style, fewer edits
The first measurable effect is throughput. A single copywriter could complete 15–20 listings per shift; beyond that, deadlines started slipping: the property is photographed, but the ad goes live a day later.
Stream generation removes this limitation — listings are processed in batches, in parallel, each in a matter of seconds, and the bottleneck becomes the availability of photos and floor plans, not the text.
The agency's consistent style no longer depends on who is on shift today.
The tone profile — how the buyer is addressed, paragraph length, the required set of characteristics, a ban on evaluative epithets without facts — is configured once and applied to the entire portfolio: from a studio to a country house.
Generation runs through production-grade language models OpenAI, so the same profile produces predictable results whether a new employee or a contractor brought in for the season is using it.
The third metric is the share of revisions. When writers worked manually, about 40% of texts went back for a second pass: inconsistent tone, forgotten parameters, varying length.
With configured fact-checking and a template, that drops to about 10%, and the edits are targeted — a number, an area, a floor. The freed-up time goes to complex lots that need a human author, not to standard one-bedroom apartments.
To keep the effect from fading over time, we produce a quality snapshot: the share of texts accepted on the first attempt, the average time from listing to publication, and the number of properties per shift.
If a metric declines, the style profile or validation rules are adjusted — not the habits of a particular team member.
Operating modes: batch processing, on-demand flow, hybrid
The launch mode is determined not by the model's capabilities but by two factors: where property data comes from and who is responsible for the final text.
If listings already sit in an export with filled fields, batch text generation is more logical; if a property is unique and a manager handles it manually, on-demand generation is better. Below is a comparison of approaches to text automation as we assemble them on projects.
Batch processing starts from the export: the service picks up properties in portions, inserts facts from fields, and puts finished descriptions back into the listing.
The limitation is predictable — an empty "window view" field becomes a gap in the text for the entire stream at once, so before the first run we check data completeness and separately flag properties that do not pass the required-field set.
| Option | When it fits | Limitations |
|---|---|---|
| Batch processing from export | Homogeneous catalog, mass publications, dozens to hundreds of properties per day | Quality depends on field completeness; an error is replicated across the entire stream; weak control at the listing level |
| On-demand generation by manager | Unique and expensive properties, manual work with the client | Speed depends on the person; throughput is limited by the number of managers |
| Hybrid with mandatory review | Regular flow plus requirements for tone and legal accuracy | Requires an editor role and process; some listings wait for confirmation |
| Templates without a model | Standard properties with minimal variability | Wording repeats, which is noticeable to both buyers and search engines |
The hybrid text preparation mode most often makes it into the production workflow: the model prepares a draft from the export, the manager confirms or edits it, and only then is the listing published.
Edits are collected and fed into settings — the next run already accounts for wording the client approved. The solution is not fixed forever: standard properties can be handled in batches, while premium ones can be handled on demand, within one system.
How the pipeline is built: from property export to publication
The pipeline starts not with text but with data: as long as property fields are described inconsistently, description quality fluctuates — one listing reads like a showcase, the next contradicts itself. So we go from sources to rules and only then to publication.
- Source analysis. We look at where properties come from: export from the CRM, developer's catalog, managers' spreadsheets. We record the format, update frequency, and fields that arrive empty.
- Property fact markup schema. We define what counts as a fact: area, floor, finish type, nearby infrastructure. We bring reference lists to unified values — "panoramic windows" and "floor-to-ceiling windows" should not be treated as different.
- Generation rule setup. We set tone, length, required characteristics, and prohibited wording: you cannot promise profitability or mention a status that is not in the data.
- Validation on a sample. We run the rules on several dozen manually reviewed listings and see where the description diverges from the fields. We make edits here, not after publication.
- Text validation before publication. Automated checks compare numbers and areas against the source fields, catch repetitions and statements outside the allowed list. Listings that fail validation go to manual review.
- Listing release process. We describe who triggers the release, at what frequency, and how edits are made to already published text.
- Handover. We provide access, instructions for managers, and an update scheme: rules live separately from texts, so they can be changed without rewriting published listings.
What you keep: templates, dictionaries, validation rules
The generation system should not remain a black box tied to a contractor. That is why at the end of the project you are left with editable artifacts: your editor or marketer uses them to change tone, structure, and rules without contacting us and without retraining the model.
- Markup schema — which property attribute goes into which description block: area, layout, window view, neighborhood infrastructure, building status, and in what order the blocks follow one another.
- Real estate text templates by property type: new build, secondary housing, apartments, country house, commercial space — each with its own structure and emphasis.
- A dictionary of wording and prohibitions in one file: allowed phrases for your tone, synonyms to avoid verbatim repetitions, and a stop list — unfounded promises, "best on the market," unverifiable characteristics.
- Validation rules: required fields, length limits, repetition control across listings, and checking numbers in the text against the property listing.
- Text edit process: who edits wording at which step, and how a change goes into the template and dictionary instead of settling in one ad.
- Documentation for the generation system: description of input data, template versions, actions in case of failure, and rollback to the previous rule set.
- A test set of listings with reference descriptions — you use it to verify that after editing the dictionary, the result remains correct.
All of this is handed over in text form and stored in your repository: we show you how to make changes and support the first edits; after that, you manage the system yourself.
Case study: an agency cut listing preparation fivefold
An agency with a flow of several hundred properties per month prepared listings manually: a manager gathered facts from measurements, photos, and documents, wrote the text, proofread it, and coordinated wording with the owner.
A listing took about half an hour, publication slipped to the next day, and every third listing came back for edits.
What changed was not the text itself but the data layer beneath it. The listing is assembled from a structured property description — type, square footage, layout, finish, infrastructure — and the language model works only with filled fields.
What is not in the source is not in the text: insertion comes from the reference dictionary, and wording is built from templates for the segment — new build, secondary market, commercial space.
Before and after
On a real stream, the metrics shifted as follows: listing preparation time — from half an hour to five to eight minutes including validation, the share of listings with edits — from one third to 6–8%, publication delay — from a day to two to three hours.
An entire class of errors also disappeared: area discrepancies, invented characteristics, and repeated wording across listings from the same developer.
The editor did not disappear — they shifted to fact-checking and non-standard properties: historic buildings, encumbrances, complex layouts.
Publication on Cian and in the company's own showcase goes through on the first try, and mass price and status updates affect all listings at once.
What if an in-house copywriter already writes property descriptions?
An in-house copywriter is not an obstacle to automation but the most valuable point in the process: they know the brand tone, platform requirements, and legal restrictions on wording.
So the task is framed differently — not "replace" but "take routine work off their plate." The model prepares a draft description from the structured property listing, and the human keeps the final say.
Roles are distributed as follows. The content manager is responsible for listing completeness — area, layout, condition, neighborhood infrastructure. The generator assembles these fields into coherent text in the specified tone and length.
The copywriter checks facts, removes template-like phrasing, and adds details that are not in the data. The editor approves the text and only then sends it for publication.
We make the transition from manual texts to a stream not as a one-time switch but sequentially: first one segment — for example, standard properties in one residential complex. On it, we compare drafts with previous texts by preparation time and share of edits. When edits become fewer, we connect the remaining segments according to the same process.
Editor edits do not disappear: they return to the example set and tone rules, so the next draft already accounts for the comments. Thus automation does not shrink the editorial team but changes its function — instead of writing text from scratch, it becomes quality control.
The department's throughput grows without expanding headcount, and a consistent style is maintained across all platforms.
Common technical doubts before launch
Doubts before launch are usually not about text quality but about controllability: will the model start repeating itself, will it invent a fact, what to do with an incomplete listing.
Will the texts be too uniform?
Template-like output appears when the same model instruction is used for all properties. Speech modes are selected by rules based on property type, location, condition, and audience, so block order and wording differ. We calculate the share of repeated phrases automatically and set a threshold at the start.
Can the model invent property characteristics?
Characteristics that are not in the listing do not make it into the text. Areas, number of floors, and infrastructure are inserted from database fields as is; generation is responsible only for the coherent text around them.
Before publication, every statement is checked against the source record; a discrepancy sends the description for manual revision.
What if the property data is not fully filled in?
The generator does not fill in what is missing. The text is built from filled fields, and for gaps it returns a list — what to complete for a full description. Gaps in the database become a visible task rather than a hidden risk.
How quickly are edits to generation rules applied?
Rules, templates, and the list of prohibited wording are stored in a separate configuration, not in code. An edit applies to future generations; old texts are regenerated in batches if needed. First, the change is run against a test sample of properties, then it goes to the entire database.
Let's discuss the task: what is needed to launch with you
So that the assessment of a text automation project is based on data rather than assumptions, we need a minimum of context about your property portfolio and current processes.
Below is what we will ask for in the first conversation; it is enough to come back with a generation implementation plan, timeline, and integration scheme.
- Property export: 20–30 listings from different segments (new build, secondary market, commercial) as they sit in the CRM or feed — XML, JSON, CSV, without manual editing.
- A set of reference descriptions: 5–10 texts you consider successful, and the same number of unsuccessful ones, with notes on what exactly did not work.
- A dictionary of terms and restrictions: project names, legal wording, mandatory disclaimers, and prohibited promises.
- Publication points: website, aggregators, internal system, messengers — where text goes automatically and where a person reads it.
- Languages and tone: which languages descriptions are needed in and whether the style differs for different segments and platforms.
- Target volume: how many properties appear per month and how many descriptions are needed per property.
- Acceptance criteria: by what criteria a reviewer accepts the text or sends it for revision.
- Responsible people: who on your side is responsible for content and who grants access to systems.
Describe the task and current process — we will come back with an assessment, implementation plan, and launch order for a real estate text project.
