Privacy Policy

Orgatlas Pty Ltd ABN 39 679 164 740, trading as The Listing Collective
Level 2, 220 St Georges Terrace, Perth WA 6000
daniel@thelistingcollective.com.au
thelistingcollective.com.au

Effective 16 September 2026. Version 1.0.

1. Who this policy is for

This policy covers personal information handled by The Listing Collective ("we", "us", "our") in connection with our conversational SMS platform (the "Service"), which real estate agents and agencies use to hold two way text message conversations with the contacts in their own databases.

Two different groups of people appear in it, and the distinction matters throughout:

Customers and their users. The agency or agent who holds an account with us, and the individuals who sign in to use it. We decide how their information is handled, so we are responsible for it.

Contacts. The people a customer messages through the Service: their past clients, buyers, sellers, landlords and enquirers. We do not choose these people, collect them from the open market, or decide to message them. The customer loads them, states the basis on which they may be contacted, and directs the messaging. We handle that information on the customer's behalf and on the customer's instructions, under our agreement with them.

If you are a contact who received a message and you want it to stop, section 9 tells you how, and it works immediately.

We handle personal information in accordance with the Privacy Act 1988 (Cth) and the Australian Privacy Principles (APPs), and we apply them in full whether or not the small business exemption would otherwise be available to us. Conversations of this kind carry material people would not want mishandled, and the exemption is not a good reason to handle it any differently. Where the Service is used to send commercial electronic messages, the Spam Act 2003 (Cth) also applies, and section 8 explains how responsibility for that is divided.

2. What we collect about customers and their users

Identity and account details: name, email address, agency name, the account's time zone and settings.

Authentication data: a one way hash of your password (we never store the password itself), session records, sign in timestamps, failed sign in counts and the IP address a sign in was attempted from.

Configuration you enter: the assistant's name, tone and sign off, allowed sending windows, frequency caps, status thresholds, approval stage, and the operating knowledge you write into the assistant's fact memory (for example how your commission works, or what the assistant must never say).

Credentials for third party services you connect, including your own messaging carrier account details. These are encrypted at rest and are write only: once entered, they are never returned by the Service, and the interface shows only a masked fragment and whether they still work.

Audit records: who changed a setting, who restored a contact's consent, who overrode a status, who read a transcript, who exported data, and when.

Correspondence with us.

3. What we hold about contacts

Loaded by the customer or synchronised from the customer's CRM:

Name, mobile number, property address, suburb, state and postcode, and other attributes the customer's CRM sends.

The customer's own record identifier. The customer's system owns contact identity; ours never masters it. There is no function that lets a name, number or address be changed in our system, and the capability is switched off at the source.

Created by the Service in the course of messaging:

Consent records: whether the contact may be messaged, the basis for that, who attested it and in what words, and every opt out event with its timestamp and how it was detected. This is an append only ledger. It is not edited, and the application has no ability to delete from it.

Message content, in both directions, with delivery status and carrier error codes.

Learned profile facts: durable things a contact says about themselves during a conversation, such as a tenant being in place until March, or a renovation being finished first. Each fact carries where it came from and when it was learned. Facts are learned only from what a contact says. The assistant's own outgoing messages are never analysed, so nothing the assistant asserts can come back as a recorded fact about the contact.

A timeline of what happened, written for the customer to read.

A relationship status and the counts behind it: activations sent, replies received, time elapsed.

Sensitive information

Conversations between real people sometimes carry sensitive information as defined in the Privacy Act, including health information, and material about relationship breakdown, bereavement, or financial distress. We do not seek it and the Service is deliberately built not to pursue it: the assistant has no goal it must reach, no field it must fill, and no instruction to ask about circumstances. Where such a subject appears, the intended behaviour is to hand the conversation to a human rather than to continue it.

Where sensitive information is volunteered by a contact and stored, it is stored because the contact chose to say it in a conversation their agent's service initiated. Customers are responsible for handling it appropriately once it is in their account, and access to full transcripts is logged for that reason.

4. Technical information we collect automatically

Server logs: IP address, request path, timestamp, user agent and error detail.

Two cookies, both strictly necessary: a session cookie that keeps you signed in, and a cross site request forgery token that protects forms. Both are marked secure, the session cookie is HTTP only, and they expire when your session does.

We do not use analytics, advertising, profiling or cross site tracking cookies. There is no tracking pixel, tag manager or third party analytics script in the product.

5. How we collect it

From you directly, when you create an account and configure it. From the customer's CRM or other source system, through our integration interface, when the customer connects it. From contacts, when they reply to a message. From the messaging carrier, in the form of delivery receipts and error codes, including the code that tells us a person opted out downstream by texting a stop keyword.

6. Why we use it

To provide the Service: deciding whether a contact is eligible to be messaged, composing messages, running conversations, recording what happened, and showing it to the customer.

To enforce the sending rules: consent state, allowed hours, frequency caps, volume ceilings and one conversation at a time.

To keep an evidentiary record of consent and opt out, which is the point of the ledger.

To secure the Service, investigate misuse, and support customers.

To keep account level records of usage and cost.

To improve the Service. Operational logs of what was sent, what came back and what the outcome was are used to evaluate and improve message quality. Where we use conversation content for that purpose we use it within the account it came from, or in de-identified form.

To meet our legal obligations.

We do not sell personal information. We do not disclose it for anyone else's marketing.

7. Automated processing and artificial intelligence

The Service uses automated processing, including large language models, and you should understand where.

What the models do. Read an incoming message and identify whether it carries an intention to stop, what durable facts it contains, and whether the customer should be alerted. Decide whether to reply, close the conversation quietly, hand it to the customer, or stop. Draft the text of messages. Summarise a week's activity. Interpret search queries typed by the customer.

What the models never do. They do not grant consent, restore consent, or override an opt out. They do not decide whether a message is allowed to be sent. That decision is made by a separate deterministic gate that reads the consent ledger directly, and no text a contact sends can influence it. Consent moves one way automatically: the system can revoke it, and only a person can restore it, with a written attestation of how the contact agreed.

Failure behaviour. If the analysis of an incoming message fails, nothing is sent. Silence is the default, because a failed analysis means stop intent was not checked.

What is sent to model providers. To produce a reply, the relevant conversation, the contact's profile facts, the customer's assistant configuration and the customer's fact memory are sent to a third party model gateway. Contact names and message content are part of that. Credentials are never included. One account's data is never used to build another account's context.

Human oversight. Every account can require that messages be approved by a person before they are sent, and new accounts start that way. Loosening it is a decision the customer makes and it is recorded in the audit log.

Decisions with consequences. The automated decisions that affect a contact most are the decision to send them a message and the decision that they have opted out. The opt out decision is deliberately biased toward stopping: a plain keyword match stops the account messaging that person before any model reads the message, and inferred stop intent writes to the same ledger. The decision to send is constrained by rules the customer sets and a person can override at any time. A contact who believes an automated decision about them is wrong can contact us or the agency using the details in section 13.

The customer obtains consent, not us. We provide the mechanisms. We do not obtain, verify or warrant consent on any customer's behalf, and we are not in a position to.

We are never present when a contact's number is collected. That happens between the contact and the agency, at an open home, on an appraisal form, over the phone or in the course of a sale, long before we see the record. We have no relationship with that person at that moment, no visibility of what they were told, and no way to observe how they agreed. Contacts must already have consented before they are loaded into the Service. Loading them is the customer's representation that this happened.

Before any contact is messaged, the customer records the basis on which that contact may be messaged, contact by contact, attested by a named person in their own words with a date. Simply loading a contact into the Service does not grant consent and does not make them contactable. There is no way for an integration to assert consent on a contact's behalf during a routine data sync, because an import error would otherwise opt in an entire database.

Under the Spam Act the burden of proving consent sits with the sender. As between us and the customer, the customer is the sender: the customer holds the messaging carrier account, the customer owns the sending number, and the messages are sent in the customer's name by an assistant the customer named and configured. The customer is responsible for having a lawful basis for every contact, for identifying themselves in messages, and for keeping an unsubscribe facility functional.

Our role is to give them the tools to do it and to keep the evidence, which is the purpose of the append only ledger.

9. Opting out

If you are a contact and you want the messages to stop, reply STOP. Other plain wordings work too, including UNSUBSCRIBE, OPT OUT, REMOVE ME, CANCEL, and ordinary sentences such as "please stop texting me" or "take me off your list". These are recognised as soon as the message arrives, before any model reads it, and the consent record is updated immediately.

What happens then:

Nothing further is sent to you through the Service by that account. No confirmation message, and no closing message.

The opt out is recorded permanently, with the words you used.

It is written back to the agency's own system, so their other channels can act on it. We cannot control what the agency does with that information after we hand it over, but we do not want the failure to pass it on to be ours.

If you message in again after opting out, we send you nothing at all. The agency is notified and may reply to you personally from their own phone.

Your opt out can only be reversed by a person at the agency recording how you agreed to be contacted again. Nothing automatic can undo it.

Opting out of the Service stops the messages that come from the Service. It does not stop the agency contacting you by other means, and we have no ability to make it do so. If you want the agency to stop contacting you altogether, tell them, and you can copy us at daniel@thelistingcollective.com.au.

Configurability. Beyond the stop handling described above, which cannot be disabled by anyone, customers configure the controls that suit their own obligations and practice: the days and hours messages may be sent, how often any one contact may be contacted, daily and monthly volume ceilings, how quickly the system stops trying with a contact who never replies, and whether messages are reviewed by a person before sending. Choosing settings that meet their legal obligations is the customer's responsibility, not ours.

10. Who we disclose information to

A messaging carrier gateway, to deliver and receive text messages. Message content and the recipient's number necessarily pass through it.

A language model gateway and the model providers it routes to, for the processing described in section 7.

Hosting and infrastructure providers, which run the servers, database and queues.

The customer's own CRM or source system, where the customer has connected one. Opt outs are always written back and this cannot be turned off. Outcomes and full conversation history are written back only if the customer turns them on.

Professional advisers, such as lawyers and accountants, where needed.

Law enforcement, regulators or courts, where we are required or authorised by law.

A purchaser of our business, if we sell it, subject to the buyer continuing to handle the information under this policy.

We do not disclose contact information to other customers. Accounts are isolated from one another, and an assistant serving one account has no knowledge of any other.

11. Overseas disclosure

Our application, database and backups are hosted in Australia.

Two categories of processing occur outside Australia:

Message delivery. Our messaging gateway provider operates internationally, and message content and recipient numbers may be processed on infrastructure outside Australia even where the numbers and recipients are Australian.

Language model processing. Our model gateway routes each request to whichever provider is available at the time, and those providers operate data centres in a number of countries. Because routing is decided per request on availability, it is not practicable for us to specify in advance every country in which this processing may occur.

We take the steps reasonably available to us: we use established providers operating under published data handling terms, we send only what is needed to produce the result, we never send credentials, and we hold the primary record in Australia. We will tell any customer, on request, which providers we are using at the time of the request.

By using the Service, customers consent to this disclosure of information to overseas recipients for the purposes described, and acknowledge that APP 8.1 does not then require us to ensure that those recipients handle the information in accordance with the APPs. Customers are responsible for making their own contacts aware of this where their obligations require it.

12. How long we keep it, and how it is deleted

While an account is open. We keep contact records, conversation history and learned facts for as long as the account is open and we need them for the purposes in section 6. A relationship history is what the Service is for, so it accumulates rather than expiring on a timer. A customer can erase any individual contact at any time, and can ask us to delete data at any time. Consent records and audit records are kept longer than the rest, because they are the evidence that the messaging was permitted and that the Service was operated properly.

Erasure of an individual contact. A customer can erase a contact at that contact's request. When they do: the contact's profile facts are deleted, the timeline is deleted, conversations and message content are deleted, and the contact's name, number and address are removed from the record. Two things are deliberately kept:

The consent record, as proof that the person asked not to be contacted. Without it, nothing prevents the same person being loaded again and messaged again.

Any message the consent record cites as evidence. These are not kept in readable form: the message body is replaced in place with a note that it was erased at the contact's request.

What remains is a tombstone: an empty record that cannot be refilled. The next synchronisation from the customer's CRM will not restore the erased details, and nothing can be sent to that record again.

After an account ends. The customer can export their data at any time while the account is open, and should do so before it closes. After termination we keep the account's data until the customer asks us to delete it, or until we delete it at our discretion, whichever happens first. We do not undertake to keep it indefinitely. Consent records and audit records may be retained beyond that point where we need them as evidence of compliance or to defend a claim, and are retained in the minimum form needed for that purpose.

13. Access, correction, complaints

If you are a customer, you can see and export everything in your account at any time through the Service: contacts, conversations, learned facts, consent records and the audit log.

If you are a contact, the agency that messaged you holds the relationship and, in practice, controls the record. Ask them first. If you would rather come to us, or you do not know which agency it was, write to daniel@thelistingcollective.com.au with the number that messaged you and we will identify the account, pass your request to them, and act on it ourselves where we are able to. We will respond within 30 days.

You can ask us to:

tell you what we hold about you,

correct anything inaccurate, out of date or incomplete,

erase what we hold, subject to the consent record described in section 12,

stop messaging you, which you can also do yourself at any time by replying STOP.

We may ask you to verify your identity before we act, and we will tell you if we cannot do what you have asked and why.

Complaints. Write to daniel@thelistingcollective.com.au or to Level 2, 220 St Georges Terrace, Perth WA 6000. We will acknowledge within 5 business days and respond substantively within 30 days. If you are not satisfied with our response, you can complain to the Office of the Australian Information Commissioner: oaic.gov.au, 1300 363 992, GPO Box 5288, Sydney NSW 2001.

14. Security

Traffic to the Service is encrypted in transit and the Service is served over HTTPS only, with strict transport security enforced.

Third party credentials are encrypted at rest with keys held outside the database, and are never returned by the Service once entered.

Every query is scoped to a single account by default, so one customer's data cannot be reached from another's session.

The consent ledger is append only, and the application's database user has no ability to update or delete from it.

Reading a full conversation transcript is recorded, including who read it, when, and from where.

The audit log is written by a single sanctioned path and cannot be altered through the application.

Incoming messages from the carrier are signature validated, size capped and rate limited before any processing occurs.

Outbound integration endpoints are checked at delivery time to prevent customer data being sent to internal network addresses.

No system is perfectly secure. If a data breach occurs that is likely to result in serious harm, we will assess and notify affected individuals and the Office of the Australian Information Commissioner as required by the Notifiable Data Breaches scheme, and we will tell the affected customers.

15. Children

The Service is a business tool sold to real estate professionals and is not directed to anyone under 18. Contacts are members of a customer's client database, which we expect to be adults. We do not knowingly collect information about children. If you believe we hold information about a child, tell us and we will remove it.

16. Anonymity

You can deal with us anonymously or under a pseudonym when making a general enquiry. We cannot provide the Service anonymously, because an account has to be identifiable to be billed, supported and held accountable for the messages it sends. A contact asking us to erase their record will usually need to identify themselves so we can find it.

17. Changes

We may update this policy. The current version is always at thelistingcollective.com.au, and the effective date is at the top. Where a change materially affects how we handle personal information, we will tell customers before it takes effect.

18. Contact

Privacy enquiries, requests and complaints:

The Listing Collective
Orgatlas Pty Ltd ABN 39 679 164 740
Level 2, 220 St Georges Terrace, Perth WA 6000
daniel@thelistingcollective.com.au