One OM. Three Revisions.

A brokerage wins a listing. Someone builds the offering memorandum: property description, financials, tenancy, photos, positioning. It goes out. Everyone moves on.

Then the asking price changes.

The broker sends a message. Marketing finds the file. Someone edits the price, checks the surrounding paragraphs still make sense, sends it back for review. A new version goes out.

A few days later, the underwriting assumptions shift — a new rent comp, a revised cap rate, an updated expense number. Same sequence, again. Notice, communicate, locate, edit, review, correct, redistribute.

Then the owner wants the positioning changed. Maybe a tenant renewed. Maybe the story of the building is different than it was three weeks ago.

Three edits. Three times through the same chain. And the OM was never the hard part — a price change is one line. What's hard is everything wrapped around that line.

A price change is one line. What's hard is everything wrapped around that line.

That wrapper is the actual cost of doing business in CRE marketing, and it's mostly invisible on anyone's calendar.

The coordination tax

Call it what it is: a coordination tax. It's not the minute it takes to change a number. It's the sequence that number triggers — someone has to notice the change, someone has to say it out loud, someone has to find the right file among however many versions exist, someone has to make the edit, someone has to check it, and someone has to make sure the corrected version actually replaces the old one everywhere it lives.

And it scales with the number of changes a property goes through — which, for any listing on the market for more than a few weeks, is not a small number.

And the OM is just one document.

The same three facts — new price, new assumptions, new positioning — likely also need to move into:

• The brochure and one-pagers
• The listing presentation used to win the assignment in the first place
• The BOV
• Social graphics announcing the listing
• Email campaigns to the buyer list
• The newsletter blast
• The website or listing page
• Any investor or buyer-facing summary already circulating

One change to the property. Eight or nine places that change needs to land. Multiply three revisions by eight assets and the brokerage isn't managing an OM anymore — it's managing roughly two dozen separate update events, each with its own small chance of being missed, delayed, or done inconsistently with the others.

This is not a story about CRE teams being disorganized. Most brokerages run this process reasonably well, given the tools they have. The problem sits one level up, in how the tools were built to think about the work in the first place. The same pattern shows up in the hidden cost of keeping CRE marketing up to date: the invoice is visible; the coordination around it is not.

Document-centric vs. property-centric

Most CRE marketing software — and most CRE marketing habits — are organized around the document. Property data flows into an OM. Property data flows into a brochure. Property data flows into a social post, a campaign, a website page. Each output is its own object, built once, then maintained on its own.

That structure made sense when a listing produced a handful of static materials and rarely touched again after launch. It makes much less sense now, when a listing is marketed across many channels simultaneously and expected to stay accurate through every price change, tenancy update, and repositioning along the way.

Under a document-centric model, "the property changed" always has to be manually translated into "which documents need to be found and edited." That translation step is where the coordination tax lives, and it's paid every single time, by a person, from memory.

The alternative is to organize the work around the property instead of the document.

In a property-centric model, there is one underlying record of what's true about the listing — price, assumptions, tenancy, positioning, photos, whatever else defines it. The OM, the brochure, the social post, the campaign, and the listing page are downstream expressions of that one record, not independent objects that happen to share some numbers.

Document-centric

• Each output is its own object to find and edit
• "The property changed" means which files to touch
• Drift across assets is almost inevitable
• The coordination tax scales with every asset

Property-centric

• Outputs express one underlying property record
• "The property changed" means what should happen now
• Facts stay consistent because they share a source
• Coordination stops scaling linearly with assets

The mental shift is small to describe and significant in practice: instead of thinking "we need to update the OM," the operating model becomes "the property changed" — and the question shifts from "which files do I need to touch" to "what needs to happen now that this is true."

That is the same architectural idea as treating listing data as the brokerage system of record: one fact, many expressions.

Why this is bigger than saving time on documents

It's tempting to file this under productivity — fewer clicks, faster turnaround, a marketing coordinator who gets an afternoon back. That's real, but it's the smaller part of the argument.

A property-centric operating model changes things that compound:

Speed to market. A listing that can absorb a price change or a repositioning without a multi-day document-chase gets back on the market faster, with fewer stale assets circulating in the meantime.

Broker productivity. Every hour a broker or their support staff spends chasing the current version of a document is an hour not spent on the parts of the job that actually require judgment — pricing strategy, buyer conversations, negotiation.

Consistency. When each asset is edited independently, drift is inevitable. A price is updated on the OM but not the flyer. A tenant renewal makes it into the BOV but not the listing page. Clients and buyers notice inconsistency faster than brokerages think they do — the same failure mode as common OM mistakes like version chaos and stale figures.

Operating leverage. A brokerage that can support more active listings without proportionally more marketing headcount has a structurally different cost base than one where every listing adds a fixed amount of coordination work, regardless of team size.

Scale. The document-centric model doesn't just slow individual deals down — it puts a ceiling on how many active listings a given team can support well. The property-centric model raises that ceiling because the coordination tax stops scaling linearly with the number of assets per listing.

None of this is really about how fast an OM can be produced. It's about whether the brokerage's operating model treats a piece of property information as one fact that has many expressions, or as many independent facts that happen to look similar. That is the difference between a faster document tool and a commercial real estate operating system.

Where Antela fits

This is the problem we started Antela to work on. Not "how do we generate documents faster," but "how do we make the property — not the document — the unit the brokerage's software actually understands."

Antela is built around the idea that a brokerage should be able to work from a single property record and generate the outputs that come from it — OMs, brochures, amenities maps, and other marketing materials — without recreating the underlying property knowledge for each one. We're not claiming every asset already updates itself the moment a property record changes; we're building toward an operating layer where that kind of connection between property data, workflows, and outputs is the default, not something a brokerage has to engineer for itself deal by deal.

That's a different kind of product than a faster document generator, and it's a different kind of question than "how quickly can AI produce an OM."

The more useful question is this: why should a brokerage have to recreate the same property knowledge over and over again, once for every asset it produces?

If you're rethinking how your brokerage moves from winning a listing to taking it to market — and keeping it accurate the whole way through — that's the operating problem we're building Antela to solve.