Detect a new recorded sale before launching the post-sale journey

A post-sale journey often starts with a status change in the CRM. That works when every record is updated promptly. When a status is missed, the team may discover the gap only when someone checks the property by hand.

A recorded sale gives the CRM another way to spot work that needs attention. Compare the newest returned recorded sale date with the date already held in the CRM. If the returned date is later, create a review item and show the evidence that caused it. A person still decides what happens next.

One date comparison creates a useful exception

Consider 22 MARY ST, RICHMOND VIC 3121. In the fixed HtAG snapshot captured on 21 September 2026, the accepted address match led to one recorded sale:

• Sale date: 6 May 2026
• Recorded sale price: AUD 1,250,000
• Property: house with 3 bedrooms, 1 bathroom and 1 car space
• Land area: 217 m²

For the product example, the CRM’s last-known sale date is 30 April 2026. That date is illustrative CRM state, supplied by the workflow rather than returned by HtAG. The newest recorded sale is six calendar days later, so the record enters the review queue.

The rule is simple:

review item = newest returned recorded sale date > CRM last-known sale date

An equal or earlier date leaves the record out of this particular queue. A later date gives the reviewer a specific reason to open it. The six-day gap is the comparison that creates the exception; it is not a measure of processing speed.

Interactive product concept using a fixed HtAG snapshot captured 21 September 2026. The CRM date is illustrative. The controls preview local review states and do not start a journey, send a message or write to a CRM.

Start by confirming the property

The workflow begins with the address already held in the CRM. Address geocoding returns a candidate identity and structured address details. For this example, the returned components matched 22 Mary Street, Richmond VIC 3121, so the accepted address identifier could be used to request the property’s sale history.

That order matters in a real product. The reviewer or matching logic should inspect the returned address before asking for history. A match connects the CRM record to an address in the source. It does not identify an owner, occupant or CRM contact.

The history request then asks for sales only. Results are ordered with the most recent sale first, which makes the comparison direct: take the newest returned recorded sale date and compare it with the CRM’s date. The same response supplied the property type, bedrooms, bathroom, car space, land area and recorded sale price used in the review card, keeping this example to two operations.

Show the evidence beside the decision

A good exception row should answer the reviewer’s immediate questions without making them hunt through several screens. Show the accepted address, both dates, the six-day difference and the recorded sale price. The property attributes help the reviewer confirm that the evidence belongs with the intended record.

Keep the labels precise. AUD 1,250,000 is the price on the recorded sale dated 6 May 2026. It is not a current property value. The 21 September 2026 timestamp tells the reviewer when this fixed snapshot was captured. Treat it as retrieval time rather than the time the record entered the source.

The sale was 138 days before the capture date. That interval describes the age of the recorded event at the time of this check. It does not show a 138-day ingestion delay. The record may have become available earlier; this response cannot answer that question.

Keep outreach behind a human decision

The later date is enough to create a useful review task. The reviewer can then reconcile the sale with the agency’s own file and choose an appropriate disposition: approve the existing authorised post-sale process, suppress the item or investigate it further.

Recorded sale evidence and customer authority are separate. The property record does not confirm settlement, current ownership or the identity of a CRM contact. It also does not supply consent or permission to contact anyone. Those checks remain with the agency’s records, policies and reviewer.

This separation makes the queue easier to trust. The data explains why the item appeared. The CRM explains which relationship, if any, the agency has with the people involved. The reviewer brings the two together before any journey starts.

Prevent the same evidence from creating repeat work

Once a reviewer has handled an item, store the accepted address identifier and a last-seen transaction signature with the CRM record. A later scheduled check can compare the newest response with that saved state. If the evidence is unchanged, the CRM can preserve the previous disposition instead of creating the same task again.

This also leaves room for corrections. A transaction record may be revised after it first appears. A change to an existing record can go to the team’s data-quality process, while a genuinely later sale date follows the new-sale rule. The labels in the interface should tell the reviewer which condition occurred.

Refresh frequency depends on how quickly the team needs the queue and how many properties it monitors. Cache accepted identifiers, query only monitored records and make the sale-only history request with sold=true and rented=false. The production capture used two data requests across two operation types and returned three rows in total. Check current pricing against the intended workload rather than inferring cost from the request count.

Implementation appendix

This workflow uses two operations. GET /address/geocode resolves the free-text CRM address for inspection and supplies the accepted address identifier. GET /property/history receives that identifier with sold=true and rented=false, returning the sale history with the newest record first.

The reader-facing demonstration uses the fixed, reviewed snapshot, so its controls make no live HtAG requests. For a first CRM implementation, start with a small monitored set and test whether reviewers can understand each exception from the evidence shown. The goal is a dependable prompt for review: one later recorded sale, one clear reason for the task and a human decision before the post-sale journey proceeds.