AutomationKing AI
Privacy Policy
Version 1.0 · Effective 2026-09-02
AutomationKing AI provides an AI receptionist that dental clinics use to answer patient enquiries and manage appointments over WhatsApp and website chat.
This policy explains what information the service handles, why, and who it is shared with. It is written to describe what the software actually does today rather than what it may do in future.
1. Who we are, and our two different roles
AutomationKing AI operates this platform and the software described below.
We act in two distinct roles, and which one applies changes who is responsible for your information:
- For the clinics who are our customers, and for the staff who hold accounts with us, we decide how account and business information is handled. We are the controller of that information.
- For patients and website visitors who message a clinic, the clinic decides why and how that information is used. We handle it on the clinic's instructions, as its processor. If you are a patient, your relationship is with the clinic, and the clinic is the right first point of contact about your information. We will still help — see section 13.
2. Information we collect
Clinic staff accounts. An email address (held by our authentication provider), the staff member's name, the roles they hold at their clinic, and optionally a WhatsApp number.
Clinic and business information. The clinic's name, address, phone number, contact email, time zone, working hours, staff directory, treatments and prices, policies, and the knowledge base the clinic maintains. Where a clinic completes business onboarding, this also includes its registered legal name, tax identifier, address, country, and website.
Website chat conversations. The full text of messages exchanged with the AI receptionist, and a randomly generated visitor token stored in the visitor's browser so a returning visitor keeps their thread. No account, name, or email is required to use website chat.
WhatsApp conversations. The full text of messages exchanged with a clinic's WhatsApp Business number, the sender's WhatsApp phone number, and the message identifiers the messaging platform assigns.
Patient records. A patient's name, and where provided, phone number, email address, date of birth, and notes added by clinic staff. The system also stores short factual points drawn from conversations (for example a stated treatment preference) so the receptionist does not have to ask the same question twice.
Appointments. Requested and confirmed times, the staff member assigned, treatment type, status, and any notes staff add.
Files. Documents a clinic uploads to build its knowledge base, documents staged during onboarding, and photographs of clinic staff.
Operational records. Message delivery status, timestamps, error records, and counts of AI usage such as tokens consumed per request.
Administrative access records. When an action is taken through our internal administration console, or by clinic leadership accepting an agreement, we record the IP address and browser user-agent string alongside the action.
3. Why we collect it
- To answer patient enquiries and to book, reschedule, and cancel appointments on behalf of the clinic.
- To maintain the clinic's own patient and appointment records.
- To operate, secure, monitor, and debug the service, including detecting abuse and diagnosing faults.
- To produce the analytics a clinic sees in its own dashboard, and to track our own service usage and cost.
- To administer accounts, billing, and support.
- We do not sell personal information. We do not use patient conversations to train AI models. We do not use patient information to advertise to patients.
4. How WhatsApp messages are processed
Messages sent to a clinic's WhatsApp Business number are delivered to us by Meta through the WhatsApp Business Platform. We store them against that clinic and nowhere else.
Message text is sent to our AI provider to generate a reply, as described in section 7. Meta handles the transport of the message itself under its own terms and its own privacy policy, which we do not control.
We keep a short record of the identifier of each inbound message so the same message is not processed twice. That record contains no message content and is automatically deleted after 30 days.
5. How website chat is processed
Website chat conversations are held against a randomly generated visitor token rather than an account, so a returning visitor keeps their thread without signing in.
Website messages are processed in the same way as WhatsApp messages for the purpose of generating a reply, and are stored against the same clinic on the same terms.
6. How appointments are handled
Appointment times are stored as absolute moments in time and displayed in the clinic's configured time zone.
The system will not create an appointment that would double-book a staff member. That rule is enforced by the database itself rather than by application code alone.
Cancelling an appointment marks it cancelled and keeps the record; it does not erase the history.
Appointment information is not currently sent to any external calendar service. The platform contains the beginnings of a calendar integration, but no appointment data is synchronised to Google Calendar, Outlook Calendar, or any other calendar provider today.
7. How the AI processes information
Replies are generated by Anthropic's Claude models. We send the model the patient's message, the recent conversation, and the specific clinic information needed to answer. We do not send the clinic's full patient database.
To find the right clinic information to answer with, the text of a patient's message may be sent to our embeddings provider, which converts it into a numerical representation used for search. Where that provider is not configured, the system falls back to keyword matching and no message text leaves our infrastructure for this purpose.
The receptionist answers from the clinic's configured knowledge base, treatments, staff, and hours. It is instructed not to invent facts, and to ignore attempts to change its role or reveal its instructions.
The AI does not diagnose, does not prescribe, and does not give clinical advice. Replies are checked automatically for diagnosis-like language and for prices that are not backed by the clinic's own configuration, and are flagged for staff review when either is detected.
The AI escalates to human staff where it cannot answer, and clinic staff can override or correct anything it does. Automated replies are an operational convenience, not a substitute for clinical judgement.
8. Service providers we share information with
We use the following providers. Each receives only what it needs to perform its function, and each handles that information under its own terms:
- Supabase — database, authentication, and file storage. Holds substantially all of the information described in section 2.
- Vercel — application hosting and request logging.
- Anthropic — the Claude models that generate receptionist replies. Receives message and clinic context as described in section 7.
- Voyage AI — text embeddings used for knowledge-base search. May receive the text of a patient's message and of a clinic's knowledge-base entries.
- Meta Platforms — the WhatsApp Business Platform, which transports WhatsApp messages to and from a clinic's number.
- Resend — delivery of transactional email such as staff invitations and password resets. Receives the recipient's email address and the content of that email.
- Stripe — subscription billing. Receives the clinic's name and its owner's email address as billing contact details. Stripe does not receive patient information.
- Twilio — where a clinic chooses to connect its own Twilio account, we store that account's credentials so the connection can be shown as configured. No calls or SMS messages are currently sent, received, or stored through this integration.
9. Storage, security, and access
Each clinic's data is isolated from every other clinic's. That isolation is enforced by database row-level security rather than by application filtering alone.
Traffic to the service is encrypted in transit. Data at rest is encrypted by our database and storage provider under its own arrangements. Credentials we hold for a clinic's own integrations are additionally encrypted by our application, using AES-256-GCM, before being stored.
Access is authenticated and limited to what each role needs. Administrative actions are written to an audit log, and records of agreement acceptance cannot be altered or deleted once written.
Information can be accessed by: authorised staff at the clinic, according to the roles the clinic assigns; a limited number of our own personnel for support, incident response, and maintenance; and the providers in section 8, to the extent needed for their part of the service.
Photographs of clinic staff are stored in a bucket that is publicly readable, so a staff photograph published by a clinic can be retrieved by anyone holding its URL. No other file type is stored this way.
No system is perfectly secure, and we do not guarantee that it is. We hold no security certification, and this policy should not be read as claiming compliance with any particular regulatory framework.
10. How long information is kept
We want to be precise here rather than reassuring, because most of the service does not have a fixed retention schedule.
Conversations, patient records, and appointments are kept for as long as the clinic's account is active. The clinic relies on them operationally, and there is no automatic expiry.
Two automated retention rules exist today, and they are the only ones: the record of processed inbound WhatsApp message identifiers is deleted after 30 days, and the counters used for webhook rate limiting are deleted after 24 hours.
When a clinic's account is deleted by us, its data is removed from our live systems, including its patients, conversations, messages, and appointments. Records of agreement acceptance and administrative audit records are deliberately retained after that point, because they exist to evidence what was agreed and what was done.
Backups held by our infrastructure providers expire on those providers' own cycles, which we do not control.
11. Correcting and deleting information
Clinic staff can update a patient's record, delete notes they have added, and delete knowledge-base entries directly from their dashboard.
Deleting an individual patient record in full is not currently a self-service action in the dashboard. A clinic that needs a specific patient record deleted should contact us at the address in section 13, and we will carry it out.
If you are a patient or a website visitor and you want your information corrected or deleted, please see our Data Deletion Instructions, which set out exactly what to send and what happens next.
12. Responsibilities of clinics using the service
Clinics remain responsible for the accuracy of the information they configure, since the AI answers from it; for obtaining any consent or giving any notice their own law requires before handling patients through an automated system; for controlling their own staff accounts and removing access promptly when someone leaves; and for reviewing escalations and flagged replies and exercising clinical judgement.
Where a clinic's patient is a child, the clinic is responsible for any consent its local law requires. We do not knowingly collect information directly from children other than as part of a clinic's own patient records.
13. Contact
Privacy questions, and correction or deletion requests: privacy@automationking.site
Security reports: security@automationking.site
If you are a patient of a clinic that uses our service, contacting that clinic directly is usually fastest, because the clinic controls its own records. You are welcome to contact us either way.
14. International handling of information
Our providers operate internationally, and information may be processed in a country other than the one where a clinic or a patient is located. We do not currently commit to a specific storage region or to a particular transfer mechanism, and we would rather say so plainly than imply a commitment we do not yet make.
15. Changes to this policy
This is version 1.0, effective 2026-09-02.
If we change this policy materially, we will publish a new version at this same address with a new version number and effective date.