One agent record, every surface: a roster pattern that stops a team site drifting out of date

Agent details live on the roster page, on every listing page that agent is attached to, in the footer of the office page, in the structured data, and inside three PDFs nobody remembers making. When somebody joins or leaves, that change has to be made in each of those places by hand. It gets made in the obvious ones. Within a year the roster page, the listing pages and the schema disagree about who works there, and the disagreement is visible to search engines before it is visible to anyone in the office.

An agent who left in March is still the named contact on four listing pages in September, because those four pages were never on anybody's list.

1. 01

   The roster is the record and the pages are views of it

   The pattern is not a content decision, it is a data one. A correction made once has to propagate everywhere, which means the pages cannot hold their own copies of anything. Once that holds, a departure is a single field change instead of a scavenger hunt.

2. 02

   Booking belongs to the agent, not to the office

   A buyer who arrives having been given a specific name and finds only a general contact form has been handed back to the office. Per-agent booking routes preserve the connection the buyer arrived with, which is the whole reason they came to that site rather than a portal.

3. 03

   Licence and disclosure fields go stale exactly like biographies do

   Licence numbers, brokerage affiliation and required disclosures are treated as chrome and edited last, but they are content with the same drift problem and a higher cost when wrong. They live in the record with everything else.

4. 04

   Storing the headshot path in the record is a trap

   A file path breaks the moment somebody renames or reorganises the asset folder, and it breaks silently across every page at once. The record holds a reference to an asset, and the asset system resolves it.

**43% of buyers found their agent by referral** and **88% purchased through an agent** (NAR *2025 Profile of Home Buyers and Sellers*) — the roster and its bios are the referral surface, so drift on a team site is drift on the primary channel.

One agent record holds name, licence number, brokerage affiliation, service areas, languages, specialisms, biography, an asset reference for the headshot, and a booking route. The roster page, the contact block on every listing page, the office page footer and the structured data all render from that record rather than repeating it. Adding an agent is one record. A departure is one field, and every surface follows in the same deploy. Booking routes are per agent rather than per office, so a referred buyer reaches the person they were referred to. Assets are referenced rather than pathed, so reorganising the image library does not silently empty the roster page.

1. 1

   Week 1

   Field inventory

   Every place an agent detail currently appears, catalogued including structured data

   Owner: OmniFlow

2. 2

   Week 1

   Record schema

   One record definition covering identity, licence, areas, assets and booking

   Owner: OmniFlow

3. 3

   Weeks 2–4

   Views rebuilt

   Roster, listing contact blocks, footer and schema rendering from the record

   Owner: OmniFlow

4. 4

   Weeks 3–5

   Booking routes

   Per-agent routes replacing the office contact form, tested against a referral path

   Owner: OmniFlow

This entry makes no performance claim. It shows a site architecture pattern and the specific failure it is built against: agent details repeated across surfaces that drift apart, and a departure that has to be remembered in six places rather than made in one. The only thing it counts is the number of places a single change now has to be made, which is a property of the build rather than an outcome of it, and no claim is made here about what the pattern does to traffic, enquiries or anything else downstream of it.

These are the surfaces this engagement is run and measured from, shown with representative figures built around the benchmarks cited on this page. Every account we run reports into views like these, and you keep ownership of all of them.

The first version stored the headshot as a file path inside the agent record. Renaming the asset folder emptied every headshot on the site at once, silently, and nobody noticed until a listing page was shared. Moving to an asset reference resolved by the asset system removed the entire class of failure, and it should have been the design from the start rather than a fix.

Real client work that shipped. No performance figures are published, because none have been verified and approved for release. See all our work