A property offer can change several times in one afternoon. A buyer sends a price in chat, adds a completion date on a call, then changes a condition. If the team keeps only the last message it saw, nobody can tell which terms are current or whether the seller has decided.
An offer log gives each proposal a version, an owner and a clear state. It supports the conversation; it does not replace the formal process required in the property’s jurisdiction.
Separate an enquiry from an offer
A buyer who asks whether the price is negotiable has not necessarily made an offer. Record the moment they state proposed terms and follow the agency’s formal submission process. Keep the property reference, buyer identity, amount, conditions, desired completion date, financing position and expiry together.
Link the offer log to the authorised record instead of copying sensitive evidence into chat notes.
The existing guide to property enquiries and viewings covers qualification, verified listing facts and post-viewing follow-up. The offer log starts when a buyer proposes terms that the team must present, compare or negotiate.
Give every change a new version
Do not overwrite the first offer when one term changes. Preserve version one and create version two with the changed field, source and time. A verbal update such as “same price, faster completion” still needs a complete record.

- 1RecordCapture the complete proposal and its source.
- 2VersionPreserve the old terms and create a new version.
- 3CloseMark the final state through the approved process.
Use a compact structure:
| Field | What to record | Why it matters |
|---|---|---|
| Offer ID and version | One stable ID plus a new version | Keeps proposals together without erasing history |
| Property reference | The exact listing or unit | Prevents terms moving to the wrong property |
| Terms | Price, dates, inclusions and stated conditions | Shows what the buyer has actually proposed |
| Source and time | Channel, sender and received time | Points back to the original evidence |
| Current state | Received, clarifying, presented, countered, accepted, rejected, withdrawn or expired | Stops a reply being mistaken for a final decision |
| Next owner and due time | Named colleague and agreed follow-up | Makes the next action visible |
The two-listing enquiry guide keeps buyer preferences and property decisions separate. One buyer can hold different positions on two units.
Treat acknowledgements as acknowledgements
“Received,” a read receipt and a request for more detail do not prove acceptance. Use plain state language in both the internal record and the customer message. For example: “We received your revised proposal at 14:20 and will present it to the seller. We will confirm the seller’s response separately.”
Rules vary by jurisdiction. The UAE Government property guide explains that ownership laws differ between emirates and that Dubai title deeds are issued by the Land Department. A messaging workflow should not announce that a sale is complete.
Check the rules for the property and use the agency’s approved process. Keep chat focused on receipt, clarification and the next confirmed step.
Record counters without creating a mixed offer
A counteroffer is a new proposal, not a silent edit inside the buyer’s version. Record its source, full terms, expiry and required response. If one condition changes, create the next version and restate the complete position.
During a handover, the next colleague should see the latest complete proposal and preceding versions. The guide to confirming project changes from voice notes uses the same principle: convert an informal message into a reviewable record, then confirm the decision through the proper route.
Keep messaging and the transaction record aligned
Choose one person to own the next reply. Use a shared team inbox for assignment and private coordination where supported. Keep the approved offer in the agency’s transaction or customer record, with the required access controls.
DripTell supports configured conversations, assignment and internal context. It does not verify ownership, decide whether an offer is valid, or replace a conveyancer, regulator or transaction platform. Confirm available channels, fields and integrations.
Before sending an update, compare it with the current version: property, price, conditions, expiry, state and decision owner. Ask for clarification instead of filling a gap from memory.
Close the loop with a final state
An offer should not remain “open” because the chat went quiet. Mark it accepted through the approved process, rejected, withdrawn, replaced or expired. Close the follow-up while preserving required history.
Review a sample for overwritten terms, missing owners and claims the record does not prove. Use an anonymised sequence in a DripTell walkthrough to test assignment.
Frequently Asked Questions
Is a WhatsApp message a formal property offer?
That depends on the jurisdiction, wording and required process. Record the message accurately, then follow the agency’s approved legal and transaction route. Do not assume a chat message is binding.
Should agents delete an old offer after a counteroffer?
No. Preserve the earlier version and mark its state. The history shows what changed and prevents the team from quoting an obsolete term.
Can a shared inbox replace property transaction software?
A shared inbox can keep connected conversations assigned and visible. The authorised transaction record, identity checks, documents and legal steps should remain in the systems and processes approved for them.
Want help applying this guide?Ask the DripTell team
From reading to action
Want help applying this to your business?
Share your details. We will read the article you are on and start with a useful answer for your team.
DripTell Editorial
Practical guidance reviewed by the DripTell product and customer workflow team.
See how DripTell checks product claims, uses primary sources and handles corrections.
Editorial and source policy







