Property data checks to run before adding AI

The same property has three names. One appears in the booking system, another in the cleaning schedule, and a third on the invoice. A coordinator knows they are the same place. The automation does not.

This is a practical starting point for property management data quality checks: find the assumptions people currently resolve in their heads. A language model might suggest a plausible match, but similarity is not confirmation. Check the property before sending an access instruction, assigning a turnover, or explaining an expense to an owner.

You do not need a company-wide cleanup before every useful improvement. You do need to know whether the specific facts your next workflow uses are fit for that job.

Start with one decision and work backward

Suppose you want a daily list of properties at risk of missing their next arrival. The report needs a reliable property identifier, the next confirmed arrival, the latest turnover status, relevant open maintenance, and the time each source was checked.

It does not need every historical amenity description to be perfect. Cleaning unrelated fields first can postpone the useful work indefinitely.

Write down what an incorrect value would cause. A missing image might make a report less informative. A wrong property match could send a cleaner to the wrong address. This tells you which failures should stop publication, which should produce a visible caveat, and which can wait in a repair queue.

The Government Data Quality Framework distinguishes completeness, uniqueness, consistency, timeliness, validity, and accuracy. These are useful questions for an operating system too. The framework is general guidance, not a property-industry benchmark. The checks below apply that distinction to an illustrative workflow.

Build a small check register

A record may pass one check and fail another. A well-formed date can be the wrong date. A status can be current and incorrectly entered. Filling every blank does not establish accuracy.

Give each check a named owner and an explicit reason. “Bad data” is not enough for a coordinator to fix. “Reservation R-104 points to property P-7, but its turnover points to P-9” is actionable.

Use stable IDs and keep aliases visible

Keep the source system's identifiers, plus a deliberate mapping to your internal property record. Names are useful labels; they are weak join keys. A renamed listing should not become a new property, and two similarly named apartments should not be merged automatically.

An alias table can preserve familiar names without asking staff to abandon them overnight:

The last row should remain unresolved until someone with the right information checks it. An AI suggestion can narrow the candidate list, but it should not turn an ambiguous reference into a financial attribution.

When properties are combined, split, sold, or removed from management, preserve the effective date of the mapping. Historical reports may need the relationship that existed when the work happened. Overwriting the old mapping with today's organization can rewrite the past unintentionally.

Treat booking changes as updates to a relationship

A reservation can move dates, change status, or be reassigned. Its related tasks may still contain the old values. Checking each table independently will miss that problem.

Compare the current reservation to the tasks created from it. Record which reservation version or update time the task reflects. A changed checkout should trigger a review of the related cleaning window, rather than simply adding another cleaning task.

Breezeway documents how dynamic workflows can move task dates after reservation changes and cancel tasks when reservations are removed. The operational implication is worth checking in any setup: are those changes actually enabled, and are committed assignments handled as your team expects? Native behavior can cover part of the job, but only the configuration and resulting records tell you whether your process is correct.

Test a cancellation after a cleaner has accepted the job. Test a date change after the daily report is prepared. Test a manual task that resembles an automatically created one. These are different cases, even if they all appear as rows on the same calendar.

Keep timestamps that answer different questions

Three timestamps are often useful: when the event happened, when the source recorded it, and when your workflow last retrieved it. They answer different questions.

A maintenance repair may have happened yesterday, been entered this morning, and been imported five minutes ago. The fresh import does not mean the repair happened five minutes ago. Likewise, a successful connection does not guarantee every expected record arrived.

An unchanged task can still be current. Do not flag every old modification date as a stale connection. Check when the source was last read successfully and whether the expected records arrived; separately decide whether the work itself needs a fresh status confirmation.

Store a time zone or a clear conversion rule with operational dates. A US property managed by a team in another country needs deadlines in the property's relevant local time. Around daylight-saving changes, a fixed UTC offset is not always equivalent to the property's time zone.

Display the age of important data in the report. If a source has not refreshed, say “task status last checked at 07:40” rather than presenting yesterday's clean status as a current fact. Readers can then decide whether to use the report or verify the source directly.

Repair the cause and preserve the evidence

A good exception record identifies the failed check, affected record, source value, expected condition, detection time, owner, and resolution. Include the downstream actions held because of the issue. This prevents a repaired record from leaving a forgotten blocked task behind.

Fix the authoritative source where possible. Patching a spreadsheet export every morning is a recurring manual process disguised as automation. If the source cannot be changed, make the transformation explicit, versioned, and testable. Record why it exists and who will remove it when the source improves.

Do not overwrite suspicious values simply to make the checks green. For a conflicting arrival date, retain both observations until the authoritative record is confirmed. For a possible duplicate expense, avoid deletion until you know whether it represents a retry, a split charge, or genuinely separate work.

Some failures can be corrected automatically, such as trimming accidental whitespace from a reference. Others need a person. Document that boundary. A system that quietly fills missing facts with plausible guesses may produce cleaner-looking data and worse decisions.

Test the checks with deliberately awkward records

Use a small test set containing an absent property ID, duplicate event, renamed property, reversed dates, stale task feed, unknown status, and conflicting source values. Include records that should pass, so the checks do not block legitimate work unnecessarily.

For each test, specify the expected action before running it. Does the report omit one property, publish it as uncertain, or stop entirely? A source outage affecting all arrivals may justify a different response from one incomplete vendor note.

Also test recovery. Once a mapping is corrected, the affected record should be processed once, the exception should close, and the next report should show the current state. Repeated retries must not create duplicate tasks or repeat messages.

Track recurring failure types over time. If staff repeatedly select the wrong property because two labels are indistinguishable, a clearer selection screen may be more valuable than a smarter matcher. If updates arrive late because a team lacks connectivity on site, a new model will not fix the delay.

The useful standard is whether the data supports the chosen action and whether someone can resolve the exceptions. Use it in the workflow audit, carry it into the daily digest, and test it in the AI pilot. Expand the checks when the workflow starts using another field or making another decision.