Stop Listing Drift by Making the Website a Projection of the CRM

Walk into any real estate operation and ask a simple question: is this home still on the market?

The answer should be one fact. In practice, it is usually two facts that disagree. The website says the listing is active — the home appears in search, sits on the map, and still accepts inquiries. The CRM says it is sold — the agent logged the status change days ago, but the update never made it to the site.

This is not a data problem. It is a coordination problem dressed up as one. Somewhere between the CRM and the public website, a human is manually copying status changes, dragging listings between categories, or re-uploading images that already exist on a server somewhere. Every manual step is a place where the two systems can quietly diverge.

We have seen this pattern repeatedly across property businesses, and it usually shows up in the same symptoms:

• Sold properties linger on the site for weeks — sometimes months — generating inquiries that go nowhere.
• “Featured” listings are chosen by hand, so the most urgent inventory sits below the fold.
• Images pile up: duplicate uploads, orphaned files, and the same photo saved six different ways.
• An agent edits a price in the CRM, then manually edits the same price on the website. Forgetting to do it twice is the failure mode.

The operational cost is real. Time is spent reconciling what should be one source of truth. Revenue leaks when buyers inquire about homes that are no longer available. And every manual edit multiplies the chance of a listing drift — a moment where what the company believes and what the public sees are two different things.

The better way to think about this is not “keep the website and the CRM in sync.” It is to stop treating them as two systems that need syncing at all.

Drift is not a fluke. It is the structural result of building a website as a separate rendering of data that already lives somewhere else.

Most property sites have the same architecture. The CRM is the system of record — it holds the truth about listings, statuses, prices, and images. The website is a separate application with its own database, its own admin panel, and its own assumptions about what a listing looks like. Between them sits a human being who moves data from one to the other.

The problems appear the moment that arrangement is under load. As the portfolio grows, the manual work grows with it. More listings mean more status changes, more image uploads, more feature decisions — all of which flow through the same bottleneck: a person.

This may indicate a deeper architectural issue. When the website maintains its own copy of listing data, every update must be duplicated by hand or by fragile script. The website is not a view of the CRM — it is a shadow copy that must be kept in alignment. Alignment work is the drift.

We have also noticed that the failure is not always visible. A listing can look correct for weeks and then silently fall behind. The cost of that invisibility is that nobody notices until a buyer asks why a sold home is still online — or an agent realizes their featured property has been underwater for a month.

The fix is not more syncing. It is removing the separate copy altogether.

Octacer typically approaches this by turning the website into a projection of CRM state. The CRM remains the single source of truth. The website becomes a rendering layer that reflects whatever the CRM currently says — nothing more, nothing less. No shadow database, no manual reconciliation, no second place where a status can be edited independently.

Scheduled imports: the pragmatic starting point

In many cases, the website already has a database and the CRM has an API, and a full live-read architecture is more change than the business needs right now. The smallest credible step is a scheduled import that replaces the website's copy of listing data at a fixed interval.

The distinction matters. A scheduled import is not a sync job that merges changes — it is a replace. On a schedule (every fifteen minutes, hourly, nightly), the website pulls the full listing state from the CRM and rebuilds its local view. There is no diffing, no conflict resolution, no “which one is newer.” The CRM is the truth, unconditionally.

CRM (source of truth)
        |
        |  API export, on schedule
        v
Website (projection layer)
        |
        |  deterministic rendering rules
        v
Public site (HTML + images + search)

This makes drift structurally impossible within the import window. Whatever the CRM says at import time is what the site shows. If a sold listing lingers, it lingers because the CRM was wrong — and fixing the CRM fixes the site. The human is out of the data path entirely.

Field-driven ribbons: deterministic presentation

The “featured” problem deserves special attention because it is the purest example of manual work that should be a rule.

In the manual model, a person decides which listings are featured. That decision is subjective, inconsistent, and slow. By the time someone gets around to it, the inventory has moved.

In a projection model, featured status is a computed field. The website applies rules to the CRM data it already has — no separate decision required.

For example:

• Featured = available AND price change within the last 7 days.
• Featured = available AND listing age under 14 days.
• Featured = available AND inventory tag = “hot” (set once in the CRM).

The rules can be configured, but they are rules. The same data always produces the same featured set. Sales can influence which rules matter, but they do not hand-pick individual listings on the site. This concentrates human attention where it belongs: deciding the business logic, not executing it.

This is deterministic automation at its most useful. No AI is needed to decide what to feature — the business already knows the criteria, or can define them. The website just applies them. Worth mapping which rules your sales team actually uses to decide what goes on top?

Images are where property platforms quietly fall apart. The same photo uploaded once for the CRM, again for the website, and again for the portal syndication is not one asset — it is three, and they will drift.

The fix is an idempotent image pipeline. An idempotent operation is one that can be run repeatedly and produce the same result. Applied to images, it means the pipeline can be rerun without creating duplicates, orphans, or conflicting versions.

The mechanism is a content-addressed key. Each image is stored once, addressed by a hash of its contents. The same photo uploaded a hundred times is still one file. The listing references that file; it does not copy it.

Uploaded image
        |
        v
Hash the bytes  ->  store once at /images/<hash>.jpg
        |
        |  derived versions (thumbnail, medium, hero)
        |
        v
Referenced by listing, not copied

Running the pipeline twice produces the same result. Re-importing a listing does not create a second copy of the image. Deleting an image removes the reference; the file can be garbage-collected when nothing points at it.

This removes an entire class of operational work: deduplicating uploads, hunting orphaned files, and reconciling which version of a photo is current. The website's image state is a pure function of the CRM's image references — a projection again.

Where the LLM comes in — and where it does not

A property platform is a good place to see the boundary between deterministic and probabilistic work, because both have legitimate roles.

The listing status, the price, the featured flag, the image references — all of these are deterministic. A rule can handle them perfectly, and forcing AI into this path would only add unreliability. The smallest credible solution here is pure automation.

The LLM belongs in the one place deterministic rules genuinely cannot handle: writing the natural-language description. A listing's marketing copy — the tone, the emphasis, the phrasing that makes a property compelling — is context-dependent in a way a template cannot capture well. The LLM reads the same CRM data as everything else and generates a narrative for the listing. It does not decide what is true; it decides how to say it.

The architecture keeps the two cleanly separated: structured data flows to the determinism (import, projection, image pipeline), and only the narrative generation goes to the model. If the model produces something off, the data layer is unaffected — a bad description is a fixable cosmetic issue, not a corrupted listing.

When the website is a render of the CRM, the operational signals are clear.

• Drift stops being a category of bug. A sold listing cannot survive on the site unless the CRM says it is sold. The failure mode moves to where it is visible and fixable — the CRM — instead of hiding in an unreconciled copy.
• The edit path is short. An agent changes a price in the CRM. The next import reflects it. No second edit, no reminder to “update the website too.”
• Featured is self-maintaining. The rules rotate inventory automatically. The sales team decides the criteria once and stops hand-curating the site.
• Image operations are reducible. Duplicate uploads are impossible by construction. Re-imports do not accumulate files. Deleting a listing can clean up its assets because the pipeline is idempotent.
• Human attention moves up. Nobody is copying data. The team spends time on pricing strategy, marketing copy, and inventory decisions — not reconciliation.

These are qualitative improvements, and they are the point. The quantifiable result — fewer hours spent reconciling, faster availability updates, less wasted inquiry handling — follows from the structural change, not from any single feature.

A projection architecture is not universally right, and it is worth being specific about the tradeoffs.

If the CRM API is slow or rate-limited, a full replace on every import may be impractical at large scale. In that case, the principle still holds — the site remains a projection — but the mechanics change to incremental exports with a version token, or a staging table that is swapped atomically. The replace-everything model is the cleanest, but the projection principle is the point.

If the CRM is not the true source of truth, the approach fails. Some operations keep pricing in a spreadsheet and attachments in a shared drive, with the CRM being only a partial record. If the CRM itself is a shadow copy of something else, fix that first — a projection is only as good as the source it reflects.

If the sales team genuinely needs to override featured logic per-listing, rules will feel restrictive. The honest answer is that an override is a business rule too — model it explicitly (a manual feature flag in the CRM) rather than leaving it as an undocumented human action on the website.

If listings are created entirely on the website and pushed to the CRM, then the website is the source of truth and the CRM is the projection. The architecture is identical, just inverted. The requirement is deciding which system owns the truth and then enforcing it in one direction only.

If this pattern sounds familiar — if a property site is drifting from its CRM, or any content platform is holding its own copy of data that already lives in a system of record — the first step is diagnostic, not architectural.

Map the current flow. Where does listing data get created? Where does it get edited? Where does it cross between systems? The manual steps in that map are your drift points. Every human edit between two systems is a place where reality forks.

Then ask the smallest question: can the website become a projection of the CRM within the current stack? A scheduled replace-import, field-driven featured rules, and an idempotent image pipeline will remove most of the manual coordination without a rebuild. The LLM — if it adds value at all — joins later, and only for narrative generation.

If you have a property platform that keeps disagreeing with your CRM, or any system where one source of truth is being duplicated by hand, the pattern here is directly applicable. The fix is not better syncing. It is removing the second source of truth entirely.