A correction log for live AU/NZ portal listings
May 25, 2026
9 min read
The awkward portal mistake usually isn’t the one you catch before launch.
It is the one a buyer spots at 8:10pm. The one a vendor screenshots from Domain because the photo order has changed. The one where realestate.com.au shows a corrected status but the agency website still says available. The one where a Trade Me Property enquiry mentions a feature that should have been removed from the description last week.
By then, “is this listing ready?” is the wrong question. The listing is already public. The better question is, “what exactly changed, where did it change, who approved the fix, and how do we prove every public version now matches?”
For a newer agent, a correction record is the incident note for a live listing. Keep blame out of it. The job is to stop a correction turning into three private messages, one portal update, and no shared memory.
A correction is different from an update
Every campaign has updates: a new open home time, a refreshed description, a price change, a status move after a contract becomes unconditional. Those can be planned, approved, and queued.
A correction starts when the public listing is wrong, incomplete, out of sync, or likely to mislead someone if it stays live.
That difference matters because a correction needs the before and after state. If the public wording said “two secure car spaces” and the contract paperwork supports one, the agency should know when the wrong wording was live, which destinations showed it, who was told, and which replacement wording was approved.
This is where searches for realestate.com.au listing software, Domain listing software, property portal software in Australia, or Trade Me property software can point at the wrong fix. Publishing tools move data. They don’t automatically leave a clean correction history after something has already reached the market.
The five facts every correction record should capture
Use a small correction log. It can sit inside your agency system, a shared register, or the listing record itself. The important thing is that it belongs to the property, not to a person’s inbox.
| Correction field | What to record | Why it matters |
|---|---|---|
| Trigger | Who noticed the issue and how: buyer enquiry, vendor message, portal change, team review, manager check | Shows whether the problem came from public reaction, internal review, or an automated status change |
| Public issue | The exact field or claim that was wrong, including a screenshot or copied wording where useful | Stops the team arguing later about what the public saw |
| Approved fix | The replacement wording, media, price, status, category, or display setting, plus who approved it | Separates “we noticed” from “we are allowed to change it” |
| Destinations | Every place that needs fixing: realestate.com.au, Domain, Trade Me, OneRoof, agency site, brochure, email alert, social post | Prevents the common problem where one public version is fixed and another keeps circulating |
| Confirmation | Who checked each destination after the update and when | Gives the team a closed loop, not just a sent update |
The correction record should be short enough to finish during a busy day. If every typo becomes a full post-mortem, agents will avoid the process. Capture enough to correct the public record, then learn from the cause.
Some corrections need evidence before speed
Speed matters, but some fixes need a pause.
If the mistake is a duplicate photo or a typo in the street name, the team can usually correct it quickly after checking the source record. If it involves price, status, a property feature, an overlaid boundary line, a disclosure point, or a vendor-approved claim, pause long enough to collect evidence and approval.
Trade Me’s guidance on misleading listings gives a useful operating standard: listings need full, accurate descriptions, and claims should be backed by evidence. That logic travels well, even when the correction is happening somewhere else.
New Zealand agents should also know the Real Estate Authority’s marketing and advertising guidance. It covers accurate marketing, vendor sign-off, substantiated claims, and what to do when new information contradicts existing advertising. The operating lesson is simple: when the public record is wrong, fix the public material and tell the right people.
Do not turn this into legal advice at the branch desk. Turn it into a decision rule:
| If the correction affects… | Treat it as… | Minimum action before changing |
|---|---|---|
| Spelling, image order, duplicate media, broken link | Routine correction | Check the source record, update destinations, confirm public display |
| Viewing time, open home, contact routing, agency site mismatch | Service correction | Confirm the new instruction, update all enquiry paths, notify affected team members |
| Price, public status, sold or leased detail, auction or deadline wording | Approval correction | Get written approval or manager sign-off before publishing the fix |
| Feature claim, boundary, title, disclosure-sensitive wording, material defect context | Evidence correction | Attach supporting evidence, escalate if uncertain, and record what buyers or enquirers need to be told |
This table gives the person on desk duty a next move. They don’t need the whole file history before acting. They need to know whether they can fix, hold, or escalate.
Portal differences make the public check essential
Australian and New Zealand agencies often publish the same campaign across several public destinations. The same update may appear differently in each place.
realestate.com.au has a specific help article on Listing Status Correction, explaining that some public status changes can appear on realestate.com.au without changing the status inside an agent’s CRM, Agent Admin, or Ignite. A correction record should catch that split.
Domain has its own listing admin paths. Trade Me Property has its own account and listing rules. OneRoof and agency websites can carry their own versions of images, descriptions, and status. Treat “sent” as a middle state, not proof that the public record is fixed.
Use destination states instead:
| Destination state | Meaning |
|---|---|
| Needs change | The public version is still wrong or unconfirmed |
| Sent | The update has been submitted, but public display has not been checked |
| Live checked | Someone has viewed the public listing and confirmed the corrected field |
| Held | The destination cannot be changed yet because approval, evidence, or access is missing |
| Not applicable | The issue never appeared in that destination |
The useful habit is the live check. A feed run or saved manual edit only proves that someone submitted a change. If the wrong status caused buyers to keep enquiring, someone should open the public page and confirm the status now reads correctly.
AvaroAI’s role is to keep the correction attached to the listing
A correction record works best when it sits next to the listing data, media, notes, documents, tasks, and events. Otherwise the team recreates the problem it is trying to solve: one person has the screenshot, another has the vendor approval, and a third knows which portal still needs checking.
In AvaroAI, a team can keep the listing lifecycle visible from draft through active to closed, then attach correction-specific tasks to the listing. The task should say more than “fix portal”. It should name the field, destination, owner, approval state, and public confirmation step.
For example:
| Weak task | Useful correction task |
|---|---|
| Fix photos | Replace rejected pool image on Domain and agency site, then confirm live gallery order |
| Check status | Confirm realestate.com.au public status matches internal active status after automatic correction |
| Update Trade Me | Remove unverified “subdivision potential” wording from Trade Me Property and record vendor-approved replacement |
| Website wrong | Change agency site open home time to Saturday 11:00am and notify applicants who enquired after the old time was published |
Search and filtering then become practical. A manager can filter open corrections by owner, destination, reason, approval state, or repeat cause. Instead of a broad exception dashboard, the team gets a live correction log for public listing errors.
The design rationale is simple: the public mistake and the fix must stay with the property. If a similar issue appears next month, the team should be able to see whether it came from media approval, status handling, copied copy, a portal-specific field, or a missing final check.
Run a same-day correction review
You can start this tomorrow without changing your whole system.
Pick any live listing that needed a public correction in the last week. Spend 15 minutes filling in these fields:
- What public field was wrong?
- Who noticed it first?
- Where was it visible?
- What was the approved replacement?
- Which destinations have been live checked?
- Who, if anyone, needs to be told because they saw or relied on the old version?
- What would stop the same issue next time?
The last question is where the review earns its time. The answer might be “vendor approval needs to include photo order”, “status wording needs manager sign-off”, “Trade Me category selection needs a second check”, or “agency website updates aren’t being checked after portal changes”.
Don’t try to fix every past listing. Start with the next correction. Make the public issue visible, attach the fix to the listing, check every destination, and close the loop only when someone has seen the corrected public version.
Related reading
Disclaimer: This page may contain AI-assisted content. The information is provided solely as a general guide and may not be correct, complete, or current, including, but not limited to, our full or applicable service offerings. While we strive for accuracy, no guarantee is made regarding correctness or completeness, and no expectation should be made as such. Please contact us directly to confirm any details before utilizing our service.
