Privacy policy

Last updated: 2026-08-07 · Version 0.1 · Status: Draft for legal review — not yet in force

This policy describes what [COMPANY LEGAL NAME] does with personal information when a business uses our phone assistant, our chat assistant, or both. Every statement below was written from the code that runs the service. Where the software does something a privacy policy would rather not admit, the admission is here instead of an omission.

Two audiences, two documents. This page is for the business that buys the service and for the staff who log in. If you are a member of the public who telephoned a business and spoke to its assistant, the page written for you is Call recording & AI disclosure. If you are a business deciding what to tell your own callers, read both.

1. Who we are, and which role we play

[COMPANY LEGAL NAME], [REGISTERED ADDRESS], operating the phone assistant and the chat assistant described at this site.

For information about a business's own customers — the people who call its phone number — that business decides what is collected and why. We process it on their instructions and under contract. Under PIPEDA the transfer of that information to us is a use by that business, not a disclosure, and the business remains accountable for it. Where the business is an Ontario health information custodian we are an electronic service provider and, in most configurations, an agent under PHIPA.

For information about the business's own staff — login email addresses, which member of staff used the assistant and how much — we decide the purposes ourselves, because that is how we run and bill for the service.

Review note — remove before publishing. The two-role split above has real legal consequences (who notifies on a breach, who answers an access request, who signs what). It needs a lawyer, and it needs to match whatever the customer contract and the PHIPA agent agreement actually say. Do not publish this section before those exist.

2. What we collect

2.1 Telephone calls

For every call answered by the phone assistant we store:

the caller's telephone number, the business number dialled, and the caller's name if the assistant was told it;
the complete transcript of the conversation, word for word;
a link to the recording, where recording is switched on (it is on by default) — the audio itself is held by our telephony provider, not by us;
the duration, the time, the cost of the call, and flags marking a call as spam or as needing follow-up.

The transcript is not summarised, filtered or redacted. Nothing in the software limits what a caller may say into it. For a dental practice that routinely means health information — symptoms, medication, why an appointment is wanted. For a law firm it can mean information subject to solicitor-client privilege.

2.2 Automated analysis of calls

After a call ends we send the transcript, together with the caller's number and the number dialled, to OpenAI, and store what comes back: a written summary, a sentiment reading, a satisfaction score, a list of topics, action items, and a reconstructed question-and-answer version of the conversation. The instructions we give the model also ask it to pick out the caller's name, email address and company from what was said, and we store those too.

2.3 The contact record built from your callers

Unless the business turns the feature off, the end of a call automatically creates or updates a contact record keyed to the caller's telephone number, holding their name, email, company, address, free-text notes, a lifecycle stage and a lead score — plus an interaction record containing a second copy of the transcript, the recording link, the AI summary, the sentiment and the action items.

Read this together with our retention schedule

That second copy is the reason we cannot honestly tell you "we keep call transcripts for six months". Our scheduled purge deletes the call record at six months. It does not touch the contact record, and today nothing else does either. See Data retention & deletion, where this is set out in full and where we say what we intend to do about it.

2.4 The chat assistant

The chat assistant runs on a virtual machine rented for the business that uses it. The messages live on that machine, not in our database. What our database keeps is a pointer to each conversation: an identifier, which business and which user it belongs to, timestamps, and a title — and the title is the first 120 characters of the first message you sent, so it is content, not just a label.

2.5 Files you attach to a chat

Images, PDFs, Word documents, text files and MP3 audio are read inside our application: images are described by OpenAI's vision model, audio is transcribed by OpenAI, and documents are parsed in memory. The assistant never receives your file — only the text. That has not changed and will not: your document is never placed on the machine your assistant runs on.

We now keep the file itself, so you can get it back. Previously the text was extracted and the file was discarded, which meant that asking your assistant for a receipt you had just sent produced nothing. A photograph of a receipt may be the only copy you have, and it may be a record you are required to keep, so discarding it was the wrong default.

What we do with it:

Where it is kept. In Microsoft Azure Blob Storage, in Canada, in a container belonging to your business alone — not shared with any other customer. Azure is already our hosting provider (see subprocessors); no new company receives your files.
How long. Seven years, because attachments are often business records — receipts, invoices, statements — and tax authorities in Canada and the United States expect those to be kept for six to seven years. Files your assistant creates for you are a different thing and are deleted after seven days.
You can delete it. Any file, at any time, from the Files section of your settings. That is a real deletion of the file itself, not a hidden flag, and we do not keep a copy afterwards.
If you close your account, your business's entire storage container is deleted with it.
Who can see it. You and colleagues at your business who are signed in. Not other customers, and not your assistant.

One honest caveat: deletions are recoverable by us for 30 days in case a deletion was a mistake, after which they are unrecoverable. If you need a file destroyed immediately rather than in 30 days, ask us.

The text does, however, reach the assistant, and the assistant may commit it to its long-term memory, which is shared by everyone at your business and which deleting the conversation does not purge. A patient chart pasted into a PDF is therefore not stored as a file by us, and also not removable by you.

2.6 What you tell the assistant about your business

Opening hours, services, policies, greeting text and general information — up to 40,000 characters — plus a save history so a bad edit can be undone. The history keeps the last ten versions and nothing older than 180 days.

2.7 Reminders and notifications

A reminder stores the text you wrote, its schedule and timezone, when it last fired, and a snapshot of the title of the conversation it was created from. The text is delivered verbatim and is never sent to any AI model. If you allow browser notifications we also store, per browser, the push service's address and the two public keys your browser generated; the notification content is encrypted so that the push service itself cannot read it.

2.8 An email account you connect to your assistant

There are two kinds you can connect on the Integrations tab, and you may connect both.

Your own Gmail account. We store the address and the 16-character app password you paste, encrypted, in our database.
An AgentMail inbox. This is an email address your assistant has of its own, at a company called AgentMail that you sign up with and pay directly. We store the inbox address and the API key you paste, encrypted, in our database. The mail itself lives with AgentMail, under your account with them and their privacy terms, not ours — we hold no copy of it. An AgentMail key reaches only the inboxes created under your AgentMail account; it cannot see your Gmail or any other mailbox.

In both cases we keep the credential because we do the emailing and the reading, on our own servers: your assistant is never given the password or the key. You choose separately, for each account, whether it may read and whether it may send, and what you do not tick is not given to it at all.

What that means for the mail itself. If you allow reading, our servers sign in to that mailbox and fetch the sender, date, subject and the first few hundred characters of the most recent messages, and hand that text to the assistant so it can answer your question about your inbox. That text is processed by the same AI model as the rest of the conversation. We do not download attachments, do not copy the mailbox, do not mark anything as read, and store no copy of the messages we read. If you allow sending, mail goes out from that account's own address — your Gmail address, or the AgentMail one — and the provider files its own copy in its Sent folder.

Everyone who writes to that mailbox is affected, not only you. Your correspondents did not choose our assistant, so only connect an account whose contents you are entitled to process this way. An AgentMail address is narrower than your own mailbox — it starts empty and only ever holds mail sent to it — but the people who write to it did not choose our assistant either.

We keep a record of every email your assistant sends, from either account — who it went to, the subject, its length, when, and whether it was delivered. We do not store the body. That record is on your Integrations tab.

Review note — remove before publishing. A customer's mailbox will contain personal information about third parties who never dealt with us. Confirm whether we are processor or controller for that content, whether a DPA amendment is needed before this feature is offered, and whether Quebec Law 25 requires this to be covered by the privacy impact assessment referred to below.

Review note — remove before publishing. AgentMail is a SECOND question, not a repeat of the Gmail one. The customer contracts and pays AgentMail directly and the mail is held there, so our reading of it is arguably not the same relationship as reading her own Gmail — decide whether AgentMail is her provider (our position here, hence no row on the sub-processors page) or ours, and whether that survives the fact that WE hold the API key and make the calls. Also: AgentMail is a US company founded in 2025, so confirm cross-border transfer wording and whether a young vendor needs its own diligence note before this is offered.

2.9 A code repository you connect to your assistant

If you connect a GitHub repository or a GitLab project on the Integrations tab, we store the repository name, the address of your GitLab if you self-host, and the access token you paste, encrypted, in our database. The token is held for the same reason the mailbox password is: we make the calls to GitHub or GitLab from our own servers, and your assistant is never given the token and never has it written to any machine of yours.

What it can and cannot do. If you allow reading, our servers fetch the files it asks for and hand that text to the assistant, which means the contents of those files are processed by the same AI model as the rest of the conversation. If you allow proposing changes, it can create a new branch and open a pull request or merge request for you to read. It cannot push to your branches, cannot merge anything, and is refused outright if it tries to change your CI configuration — nothing lands in your repository until a person presses Merge. We keep no copy of your code: what it proposed lives in the pull request, in your own account.

We keep a record of every change your assistant proposed — the repository, the branch, the title, how many files, when, and the link — but never the diff. That record is on your Integrations tab.

Review note — remove before publishing. A source repository may contain secrets, customer data and code owned by the customer's own clients rather than by the customer. Confirm the contractual position on processing a customer's source code through a third-party model, and whether the same DPA amendment covers it.

2.10 A calendar you connect to your assistant

If you connect a Google Calendar on the Integrations tab, you are sent to Google's own screen to agree, and what comes back to us is a permission rather than a password: we store that permission, encrypted, in our database, together with the address of the Google account that granted it and the name and time zone of the one calendar you nominate. We never see or store your Google password. The permission is held for the same reason the mailbox password is: we make the calls to Google from our own servers, and your assistant is never given it.

This is the assistant you chat with on this site. The assistant that answers your telephone cannot see or change your calendar, and nothing about connecting one changes how your callers are answered.

What it can and cannot do. You choose separately whether it may read the diary and whether it may book into it, and what you do not tick is not given to it at all. If you allow reading, our servers fetch the entries in the days it asks about — their titles, times, locations and any description — and hand that text to the assistant so it can tell you what a day looks like; that text is processed by the same AI model as the rest of the conversation. If you allow booking, it can create one appointment at a time, on that calendar's own clock, and it checks the slot first and refuses rather than booking over anything. It cannot cancel, move or change an existing entry, and nobody is emailed: whoever the appointment is for is not invited and receives nothing from us. We keep no copy of your diary — what it books lives in your own calendar, where you can move or delete it.

Everyone in that diary is affected, not only you. A clinic's calendar names the people it is expecting and when, which for a health practice says something about them by itself. Your patients and clients did not choose our assistant, so only connect a calendar whose contents you are entitled to process this way.

Review note — remove before publishing. A customer's calendar will name third parties, and for a medical or dental practice an appointment time is arguably health information about an identifiable person even with no clinical detail attached. Confirm whether we are processor or controller for that content, whether the same DPA amendment covers it, whether PHIPA (Ontario) or the equivalent provincial health statute is engaged for our customers who are health information custodians, and whether a privacy impact assessment is required before this is offered. Google's API Services User Data Policy also governs what we may do with Calendar data and requires the app to pass Google's verification for this scope — confirm the Limited Use commitments are reflected here and in the terms.

2.11 Usage records

Every metered action writes a row recording the business, the individual user, the conversation, what kind of work it was, the token counts, the model label and the time. This is how the bill is produced and how a surprising charge can be traced. It is also a record of which member of staff used the assistant, when, and how much.

2.12 Accounts, forms and operational logs

Accounts: email address and a hashed password. There are exactly two roles: a customer user, and our own administrators.
Signup requests: business name, contact name, email, telephone, whatever you typed in the message box, the source of the form, and the IP address it was submitted from. A signup creates this row and an email to us, and nothing else — no account, no telephone number, no machine.
Contact and intake forms from our marketing site are emailed to us and not stored in the application at all.
Operational events record things like a blocked caller or a rejected webhook. Some of these contain a caller's telephone number in plain text, and an appointment your assistant books is recorded here with the title it was given — which is usually somebody's name — so that a run of them can be looked at. They are deleted after 90 days.
Server logs written by the operating system also contain caller telephone numbers. Their lifetime is controlled by the server's log configuration and not by the application; API keys, authorisation headers and request bodies are deliberately never logged.
Machine health: how full each customer's chat machine's disk is, sampled every fifteen minutes and kept for 30 days. No personal information is in these rows.

3. Why we collect it

To answer the telephone. A transcript is how the business finds out what its caller wanted.
To tell the business what happened. Summaries by email and SMS, follow-up items, and the contact record.
To run the chat assistant and to give it the facts about the business it needs to answer correctly.
To bill accurately and to warn a customer before they pass an allowance.
To keep the service working — spam and abuse controls, rate limits, disk and error monitoring.

We do not sell personal information, we do not share it for advertising, and we do not use call transcripts or chat messages to train our own models. What our AI providers may do with what we send them is governed by our agreements with them; see the sub-processor list.

Review note — remove before publishing. Confirm the training claim against the actual OpenAI, Azure OpenAI, Vapi and Twilio contracts and their current terms — API data is normally excluded from training by default, but 'normally' is not a basis for a published sentence. If any agreement does not exclude it, this paragraph has to change or the setting does.

4. Where it goes — all of it is in the United States

There is no Canadian region anywhere in this system

Our application, our database and our nightly backups run in Amazon Web Services in the United States. Each customer's chat assistant runs on a Microsoft Azure virtual machine in the United States and answers using Azure OpenAI in the United States. Call transcripts are analysed by OpenAI in the United States, as are uploaded images and audio. Telephony, SMS and the voice models are provided by Vapi, Twilio and OpenAI in the United States. Summary and notification email is relayed through Zoho. If you connect your own Gmail account, our servers in the United States sign in to Google's servers to read and send on your behalf; if you connect an AgentMail inbox, they call AgentMail's servers in the United States to do the same; and the same is true of a Google Calendar you connect, which our servers in the United States read and write on your behalf.

While personal information is in another country it is subject to that country's laws, and may be accessible to that country's courts, law enforcement and national security authorities. No contract we sign can override that. We remain accountable to you for the information throughout, and we require comparable protection from each provider by contract.

A complete list of who receives what is at Sub-processors. One item on it is worth repeating here: our telephony provider uses its own speech-to-text vendor, which we do not currently pin to a named company, so caller audio is heard by a provider we cannot name for you today.

Review note — remove before publishing. If any customer is in Quebec, Law 25 requires a privacy impact assessment BEFORE personal information is communicated outside Quebec — which is every operation in this system. That is a blocker, not a cleanup item.

5. How long we keep it

In summary: call records and their AI analysis are deleted six months after the call; operational events after 90 days; the knowledge save history after 180 days; machine health samples after 30 days. Several other tables — including the contact records built from your callers, the usage ledger, chat conversation pointers, signup requests and the record of email your assistant sent — are not deleted by anything today. Backups are kept for a further period after deletion.

The full table-by-table schedule, including the gaps, is at Data retention & deletion. We publish the gaps rather than a rounded-off promise because a retention period that is not enforced by a running job is not a retention period.

6. What deleting something actually does

The honest version

Deleting a chat conversation removes it from your list in the app. The assistant's own copy of that conversation stays on your machine, and anything the assistant has committed to its long-term memory stays there too. There is no button that reaches into that memory. To have it cleared, ask us — it is done by hand by our team.
Cancelling a reminder disables it and keeps the row, so the page can still show what was sent to you.
Deleting a call record — there is no such button. Call records leave only by ageing out of the six-month purge, or by our staff running a database statement at your request.
Deleting a contact or a transcript from the contact record — there is no such button either, and no scheduled job removes them.
Deleting a staff account is available to our administrators, but on an account that has ever opened a chat or incurred a metered action it currently fails. Ask us and we will do it properly.
Disconnecting an email account deletes the address and the credential from our database immediately, and the assistant loses the mailbox at once. It does not cancel the credential where it was issued — only you can do that, on Google's app passwords page or at console.agentmail.to — and it does not delete our record of what was already sent, or any email that was already sent.
Backups. Anything deleted from the live system may remain in an encrypted database backup for a period afterwards before it is overwritten. We do not restore backups in order to recover deleted information.

We would rather write that paragraph than the sentence a template offers — "you may delete your data at any time" — which in this product would be untrue in five separate places.

7. Your rights, and how to use them

You may ask us for a copy of the personal information we hold about you, ask us to correct it, ask us to delete it, ask how it has been used and to whom it has been disclosed, and withdraw consent subject to legal and contractual limits. Where the information belongs to a business's customer rather than to the business itself, we will normally direct the request to that business, since it decides what happens to it — and we will help them act on it.

Send requests to [PRIVACY OFFICER NAME AND TITLE] at [PRIVACY CONTACT EMAIL]. We will respond within [RESPONSE TIME — PIPEDA'S OUTER LIMIT IS 30 DAYS].

What we can actually do today. Erasure is a manual procedure carried out by our staff — locating the call records, the analyses and the contact records for a telephone number, and clearing the assistant's long-term memory on the customer's machine. It is not self-service and we are not going to describe it as though it were. Building it into the product is on our list.

8. Automated decisions

The assistants generate speech and text automatically, and the analysis assigns a sentiment, a satisfaction score and a lead score to a caller. None of these makes a decision about anyone on its own — they are notes for a human at the business. The assistant can be wrong, and it can misunderstand what was said; its output is not advice of any kind, medical, legal or otherwise.

9. Safeguards

Summarised here, and set out honestly — including what is not protected — in the security overview. Briefly: passwords are hashed; per-customer credentials are encrypted in our database with a separate key; traffic is encrypted in transit; API keys and request bodies are never written to logs; each customer's chat assistant normally has a machine of its own. Transcripts, caller names, telephone numbers and contact notes are stored as ordinary text in the database, not encrypted field by field.

10. Breaches

If personal information in our care is lost, stolen or accessed without authorisation and there is a real risk of significant harm, we will report it to the Office of the Privacy Commissioner of Canada and notify the affected individuals and the affected business as soon as feasible. Where the business is a health information custodian we will notify it at the first reasonable opportunity. We keep a record of every such incident for at least 24 months.

Review note — remove before publishing. The 24-month breach register does not exist yet. The operational events table is the closest thing and it is purged at 90 days, so it cannot serve as one. Stand up the register — a spreadsheet is enough to start — before this paragraph is published, because it is a statutory requirement under PIPEDA s.10.3 whether or not anyone has been harmed.

11. Changes to this policy

The date at the top of this page changes whenever the document does. Material changes will be notified to customers by email before they take effect.

12. Complaints

Complain to us first — [PRIVACY CONTACT EMAIL] — and we will investigate and tell you what we found. If you are not satisfied you may complain to the Office of the Privacy Commissioner of Canada at priv.gc.ca, or to your provincial regulator where one applies (Alberta, British Columbia and Quebec each have one, and Ontario's Information and Privacy Commissioner oversees health information).

This is not legal advice. This document was drafted from what the software actually does, by the people who built it, and it has not been reviewed by a lawyer. It must be reviewed by Canadian privacy counsel — and, where a customer is a health information custodian or a law firm, by counsel familiar with PHIPA, the Alberta Health Information Act, Quebec's Law 25 and professional obligations of confidentiality — before it is published or relied on by anyone. Highlighted [LIKE THIS] are facts we have deliberately not invented; they must be filled in before publication.