Privacy Policy

Effective date: 1 September 2026

Who we are: Jadin Roste Andrews, trading as Chatleadr, a sole proprietor trading in the Republic of South Africa, of 71 Old Main Rd, Hillcrest, 3650. Chatleadr is not a registered company, and one person trading in their own name has no registration number to publish. In this policy "we", "us" and "Chatleadr" mean that person.

Information Officer: Jadin Roste Andrews, support@chatleadr.com. POPIA makes the head of a private body its Information Officer, so this is the position whether or not registration with the Information Regulator has been completed.

Contact: support@chatleadr.com

1. Two Roles in This Policy#

Chatleadr handles two different kinds of personal information, and we are not in the same legal position for each. Reading the rest of this policy without this distinction will give you the wrong answer.

Account information is ours to answer for. When you sign up, buy a plan or email support, we decide why and how that information is processed. Under the Protection of Personal Information Act 4 of 2013 ("POPIA") we are the responsible party; under the General Data Protection Regulation ("GDPR") we are the controller. Sections 3, 5 and 8 of this policy describe that information.

Conversation information belongs to the customer whose bot collected it. When a visitor talks to a bot built by one of our customers, the customer decides what that bot asks, what it stores and what it is for. The customer is the responsible party or controller. We process it only on their instructions, which makes us the operator under POPIA and the processor under GDPR. The terms of that processing are in the Data Processing Terms.

If you are a visitor who spoke to a bot and you want your information removed, the business that runs the bot is the right place to ask. Section 10 explains what to do if you cannot identify them.

2. Who the Parties Are#

Where an Agency runs a bot on behalf of a Client, the Agency is responsible to us for that bot and the Client's own relationship is with the Agency. Clause 4 of the Data Processing Terms sets out what the Agency has to have in place before it does that.

3. Account Information We Collect#

Collected from you directly, when you create an account or use the Dashboard:

• Identity. Your email address and, if you provide it, your full name. Sign-in is handled by Google Firebase Authentication; we store the account identifier it issues, not your password. We never see your password.
• Workspace and configuration. Your bots, their settings, your knowledge documents and your workflows.
• Usage records. Conversation counts per day, workflow executions, and the credit ledger that supports your invoice.
• Billing records. Which plan you are on, when it renews, and the reference our payment provider gives each transaction. We do not receive or store your card number. Payments run through our payment provider, which is the merchant of record and holds the card details. The providers we currently use are named on the Sub-Processors page.
• Support correspondence. Anything you send us by email.

4. Conversation Information a Bot Collects#

This is the information described in section 1 as belonging to the Customer. We process it on their behalf. What a bot collects depends entirely on how that Customer configured it, so the list below is what the software is capable of storing rather than what any particular bot does.

• The conversation. Every message in the exchange, the bot's replies, and the record of which workflows ran.
• Lead details, if the bot asks for them. Name, email address and phone number are stored as named fields. Anything else a form collects is stored with it.
• Channel identity. On WhatsApp or Instagram this is the account the visitor messaged from. On the web widget there is no such identifier.
• Uploaded files, where a Customer's form includes a file upload. A curriculum vitae or an identity document uploaded this way carries far more personal information than the rest of a conversation, which is why documents have the shortest retention of any class we hold.
• Traffic source, meaning the page the widget was opened on and any campaign parameters in its address.

We do not record a visitor's IP address or browser user agent. No field for either exists on any record the chat runtime writes.

5. Why We Process Account Information#

Marketing email is separate from service email and you can withdraw consent at any time without losing access to anything you have paid for. Service email about a failed payment or an outage is not something we can exclude you from, because it concerns the contract itself.

6. How Long We Keep It#

Retention differs by class of data and by plan. These windows are enforced in software rather than by policy alone: transcripts and technical logs expire automatically, and stored documents are swept by a job that deletes the encrypted file as well as the record pointing at it.

Daily analytics totals are kept for 400 days on every plan, so that a year-on-year comparison still works in January.

Leads and contacts are not deleted by age on any plan. A contact list that empties itself is not a contact list. They are deleted when the Customer deletes them, or under section 7.

Opt-out and suppression records outlive every window above. If someone asks not to be contacted, we have to keep enough information to honour that. Deleting the record of an opt-out would cause the very contact it was meant to prevent.

A Customer may choose a shorter window than their plan allows. They cannot choose a longer one.

When a Customer moves to a plan with a shorter window, nothing is deleted for at least 30 days, so that there is time to export first.

7. Deletion, and What It Removes#

Three different things can be deleted, and they behave differently. All three are available in the Dashboard.

Erasing One Person#

A Customer can erase a single contact from their workspace on request. This is the mechanism a Visitor's erasure request is answered with, and it is irreversible.

What is destroyed: the lead record and its tags, and every file that person uploaded. Each file's encrypted contents are destroyed before the record pointing at it, so nothing is left behind that we hold but can no longer identify.

What is redacted rather than deleted: the conversation transcript. Every message is replaced with a marker, and the sender identity, the stored summary and the channel account the person messaged from are removed. What remains is how many turns there were and when. That is billing evidence for a month already invoiced, and it identifies nobody once the contents are gone.

What is kept, deliberately: the record that the person asked. We keep a one-way fingerprint of their email address, phone number or channel account so that the same person is not captured again by any bot in that workspace. The record applies only in the workspace where the erasure was made. It is copied to another workspace only when a bot is moved there, and it does not apply anywhere else on the service. Deleting that record would cause the contact it exists to prevent. Billing and usage totals are kept for the same reason as always: they are financial records and carry no contact details.

The Customer receives a receipt setting out exactly what was removed. It names nobody, because reprinting the address would undo the erasure.

Deleting a Bot#

Archiving a bot stops it answering on every channel at once, removes it from your lists, and frees the plan slot immediately. Nothing is destroyed and it can be restored whole.

Erasing an archived bot destroys its workflows, knowledge documents, conversations, leads, uploaded files and analytics. It is irreversible, and a bot has to be archived before it can be erased.

Deleting a Workspace or Closing an Account#

Deleting a workspace is reversible for 30 days, and the workspace is still billed for that period, because we are still storing it. Restoring it during that window brings everything back.

Erasing a workspace destroys everything in it: every bot, workflow, knowledge document, conversation, lead, uploaded file, integration, invitation and usage record. The per-workspace key that the uploaded files are encrypted under is destroyed last, which makes any remaining file permanently unreadable. Live WhatsApp and Instagram bindings are released with the provider, so a number is not left pointing at a bot that no longer exists.

A workspace that pays for client workspaces cannot be deleted until those are transferred or deleted first.

Where the Customer does not ask, we erase a closed account's data within 90 days of it closing. Backups follow their own cycle and are overwritten within 35 days.

8. Who Else Processes It#

We use other companies to run parts of the service. Each one receives only what it needs for its function. The current list, with what each one does and where it does it, is on the sub-processors page, which we update when the list changes.

Three of them are worth naming here because of what they receive:

• The model provider receives the conversation text and the bot's configuration in order to generate a reply. It is instructed not to use that content to train models.
• Our payment providers are the merchants of record for purchases, and each is named on the Sub-Processors page. Each collects and holds payment details directly and is a controller in its own right for that information, not our processor.
• Postmark delivers email. That includes account messages such as workspace invitations, and the lead notifications a Customer switches on, which carry a lead's contact details and a summary of their conversation.

Integrations you switch on with your own credentials are different. If a Customer connects ClickUp, that service receives lead information because the Customer told us to send it, under the Customer's own account. That is the Customer's own arrangement and the Customer is responsible for having a lawful basis for it.

Email notification is switched on the same way and is not the same thing. It runs on our Postmark account and sends from our address, so Postmark is our sub-processor rather than the Customer's.

9. Cross-Border Transfers#

Our infrastructure and several sub-processors are outside South Africa, in the United Kingdom and the United States. Sending personal information out of the country engages section 72 of POPIA, and out of the European Economic Area engages Chapter V of GDPR.

We transfer personal information to a recipient outside South Africa only where that recipient is bound by terms giving it protection substantially similar to POPIA, including a restriction on passing it on again. In practice that is the data processing agreement each provider on the sub-processors page publishes and we have accepted, which where the recipient sits outside the European Economic Area incorporates the European Commission's Standard Contractual Clauses.

We will not add a sub-processor that will not agree to those terms.

10. Your Rights#

Under POPIA you may ask us to confirm what we hold about you, give you a copy, correct it, or delete it where we have no lawful ground to keep it. You may object to processing based on legitimate interests. You may complain to the Information Regulator of South Africa.

Under GDPR, if it applies to you, you additionally have the right to restrict processing, to receive your data in a portable format, and to complain to your own supervisory authority.

How to exercise them. Email support@chatleadr.com. We will respond within 30 days. We may ask you to verify your identity first, because acting on an unverified erasure request is itself a breach.

If you are a visitor rather than a Customer, the business whose bot you spoke to has to answer your request, not us. Their name is usually on the website the bot was on. If you cannot work out who they are, write to us and we will pass the request to them and tell you we have done so.

Some things survive an erasure request, and the law allows this: billing records we are required to keep for tax purposes, and the suppression records described in sections 6 and 7.

11. Security#

• Traffic to and from the service is encrypted in transit.
• Uploaded documents are encrypted at rest under a key held per workspace, so one Customer's files cannot be read with another Customer's key.
• Sign-in is delegated to Google Firebase Authentication, so we hold no passwords.
• Each workspace's data is separated at the query level.
• Access to production systems is limited to named administrators. There is currently one.

No system is immune. If a breach affects your personal information we will notify you and the Information Regulator as POPIA requires.

12. Children#

Chatleadr is sold to businesses and is not directed at children. We do not knowingly collect information from a child. A Customer who configures a bot to collect information from children is responsible for the consent that requires, and POPIA treats a child's information as a special category.

13. Changes#

We will post any change on this page and update the date at the top. If a change materially affects a Customer's rights we will email them before it takes effect.