A two-lane Irish listing change log
Jun 17, 2026
8 min read
A live Irish listing rarely sits still.
The vendor accepts that the price needs adjusting after 3 slow weekends. A landlord changes the available date because works have slipped. A tenant can only allow viewings on Tuesday evenings. A BER detail is queried. The lead photo is changed after weak click-through. A sale goes sale agreed, then a chain wobble pushes the agent to hold the public status for a day.
On screen, those can all look like ordinary listing updates. In the branch, they’re different jobs.
Sales and lettings teams often share the same portals, the same admin support, and sometimes the same property record. The change log behind a live sales listing needs different fields from the one behind a live lettings listing. Different people are involved. The evidence is different. So is the next job.
For a newer agent, the change log is the note that explains why the public listing changed after launch, who authorised it, what needs checking next, and who must be told. Treat it as branch memory for a live public promise.
The update is only half the job
Changing a price, rent, photo, status, or viewing note is the visible part. The control sits underneath:
| Question | Why it matters after launch |
|---|---|
| Who asked for the change? | Separates client instruction, agent judgement, admin correction, and buyer or applicant feedback |
| What evidence supports it? | Keeps the branch from relying on memory, WhatsApp snippets, or a half-remembered call |
| Who approved it? | Stops a suggestion becoming a public change before the right person signs off |
| Who made the public update? | Makes it clear who changed Daft, MyHome, the website, brochures, or syndication records |
| Who checks it afterwards? | Catches old photos, wrong status labels, stale viewing notes, or mismatched price/rent |
| What next action did it create? | Turns the update into a vendor call, landlord approval, applicant message, price review, or access check |
This is where sales and lettings split.
The PSRA publishes separate letter of engagement resources for sale of land and letting of land. That distinction matters operationally, not just formally. A sale listing change usually points back to vendor instruction, guide price, status, offer position, viewing feedback, or solicitor/progression context. A letting listing change usually points back to landlord instruction, rent, availability date, tenant or occupier access, applicant communication, and whether property management will continue after letting.
If the branch records both lanes the same way, the next person has to infer too much.
Use a two-lane live listing log
Keep one shared listing record if that’s how your agency works, but split the change log into sales and lettings fields. A price reduction and a rent availability update can both be “listing changes”, but they need different proof and follow-up.
Use this as a starting table in tomorrow morning’s review.
| Change type | Sales listing lane | Lettings listing lane |
|---|---|---|
| Price or rent | Vendor instruction, revised asking or guide price, reason for change, manager approval, public display checked | Landlord instruction, rent amount, effective date, availability impact, applicant messages sent |
| Status | Available, sale agreed, withdrawn, chain or offer reason, who can approve public status | Available, let agreed, reserved, withdrawn, tenant/occupier impact, landlord approval |
| Media | Approved gallery order, lead image, removed photos, floorplan version, vendor sign-off if needed | Current condition photos, access-sensitive images, works pending, landlord approval, tenant privacy concerns |
| Public facts | BER detail, size, tenure, charges, services, parking, boundaries, source checked | BER detail, rent, deposit, furnishing, availability, restrictions, management context, source checked |
| Viewings | Viewing owner, access method, buyer feedback pattern, vendor update due | Viewing owner, access window, tenant or occupier notice, applicant follow-up, landlord update due |
| Client communication | Vendor told what changed and why, next review date | Landlord told what changed and why, applicant pool updated, access constraints confirmed |
The important columns are the reason and owner.
A listing that says “price updated to 395,000” is thin. “Vendor approved 395,000 after 8 viewings and no second viewings, manager checked public display, vendor review due Friday” gives the next person something to work with.
“Available from 12 July” is thin too. “Landlord moved available date to 12 July due to works, tenant access limited to Tuesdays, 4 applicants messaged, viewing slots changed” tells the branch what actually happened.
What changes when sales and lettings share admin
Shared admin works when the task is clear. It breaks when the person keying the update has to decide which context matters.
A sales negotiator might ask admin to update the status after a strong offer. A lettings negotiator might ask for an availability change after a landlord call. Both messages can sound simple. The first may need the manager to confirm whether the public status should move to sale agreed. The second may need access notes, applicant communication, and a rent or move-in date check.
That is why AvaroAI treats a listing as a working record, not just a public advert. Property data, photos, documents, tasks, viewings, and client context need to sit close enough that the next person can see what changed and why.
That design choice matters most after launch, because post-live changes are rarely isolated. A viewing note can trigger a price review. A landlord instruction can trigger applicant messages. A status update can require a client call.
For Irish teams, the software test is plain: can the same property record carry different responsibilities for sales and lettings without forcing everyone into one vague update note?
The 5-minute change test before you press save
Before any live listing change goes public, ask these 5 questions. If one answer is missing, hold the update until the owner fills it in.
| Test | Sales example | Lettings example |
|---|---|---|
| Is the instruction clear? | Vendor approved price change by phone and it is recorded | Landlord approved rent or date change and it is recorded |
| Is the public fact sourced? | BER, size, status, or price source is attached or named | BER, rent, availability, furnishing, or restriction source is attached or named |
| Is the next person obvious? | Manager, sales progressor, or viewing owner knows the update happened | Lettings negotiator, admin, landlord contact, or applicant owner knows the update happened |
| Is the public display checked? | Portal, website, brochure, and shared listing record agree | Portal, website, applicant messages, and viewing slots agree |
| Is the next action dated? | Vendor update, price review, feedback chase, or status check has an owner | Applicant update, access confirmation, landlord call, or viewing window check has an owner |
This is deliberately short because live updates often happen between appointments. The discipline is treating the save button as the middle of the job, not the finish line.
If a change affects price, rent, BER, availability, status, access, or a claim about the property, it deserves a named owner.
Keep the evidence beside the change
Irish agencies already know the pain of evidence sitting somewhere else: the vendor text is on one phone, the landlord email is in a shared inbox, the BER cert is in a drive folder, the viewing feedback is in the diary, and the portal update is in another tab.
That setup works until someone is off, a client challenges the change, or a colleague needs to explain the public listing quickly.
For each meaningful post-live change, keep 6 facts beside the listing: the exact item changed, the lane, the source, the evidence, where the public display was checked, and the next action owner.
The Residential Property Price Register is a reminder that public property records matter long after a listing is edited. Your internal log does not need to duplicate public registers, and it should not pretend to be legal advice. It should make your agency’s own decisions traceable: what changed, why it changed, and who handled it.
Review live changes by lane, not just by date
A weekly live listing review should not be one long list of updates. Split it into 2 short checks.
For sales, look for:
- Price changes without a recorded vendor instruction
- Sale agreed or withdrawn statuses without a public-display check
- Viewing feedback that should trigger a vendor update
- BER or public fact changes without a named source
- Offers or progression notes that affect what the listing should say next
For lettings, look for:
- Rent or availability changes without landlord approval
- Viewing slots that no longer match access reality
- Applicant messages that were not sent after a public change
- Tenant or occupier restrictions that are missing from the viewing notes
- Media that no longer reflects current condition or agreed works
That review takes less than 20 minutes if the log is clean. It takes all morning if the team has to rebuild the story from inboxes, diaries, and memory.
The practical habit is simple: every live listing change gets a lane, a reason, an owner, and a next action. Sales and lettings can share property context, but they should not share a generic log that hides the different work underneath.
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.
