Privacy policy

Last updated: 2026-09-29 · Version 0.3

This policy describes what Moneli Automation 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.

1. Who we are, and which role we play

Moneli Automation, 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.

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 our AI provider (Azure OpenAI; section 4 says where it is processed), 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.

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 Azure OpenAI (section 4 says where), audio is transcribed by Azure Speech in Canada, 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.

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.

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.

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.
• Your browser's time zone (such as America/Toronto), when you create an account from our sign-up page with scripts on. It becomes your account's time zone setting, is shown to you on the first page you see, and can be changed in Settings. Nothing else is read from your browser to set up the account.
• 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.
• The in-app Assistant: when it cannot help with a request, the words typed are kept for up to 30 days so we can improve it, and only our own staff can see them.

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, and we do not use call transcripts or chat messages to train our own models. The one advertising tool we use — Google Ads conversion measurement on our public pages and when a sign-up is completed — is described under Our own website, and Google Ads, and you can opt out of it. What our AI providers may do with what we send them is governed by our agreements with them; see the sub-processor list.

Our own website, and Google Ads

We advertise on Google search and use Google Ads to measure whether an ad brought you and whether you then created an account or asked for a demo — and the steps on the way: pressing Try it free, opening the sign-up page, starting the demo form. This happens on our public pages and once more when a sign-up is completed. We configure the tag to switch ad personalisation off and do not use it to build remarketing audiences. To do this, Google may receive cookie and ad-click identifiers, page addresses, the address of the page that sent you, your IP address, browser information and these conversion events. We do not include call transcripts, chat messages, visitor records or your customers' information in anything we send to Google.

We also use Google Analytics 4 on our public pages to count visits: which pages are opened, how you arrived and roughly how long you stay. It is never loaded inside the product. To do this, Google may receive the same kinds of identifiers and browser information as above, and it sets its own cookies, named _ga and _ga_ followed by an identifier. Everything below about opting out and about when we ask first applies to Google Analytics in the same way, and opting out also removes the _ga and _ga_ cookies we can reach.

Google Ads measurement normally starts automatically when a page loads. Our marketing pages show a short notice saying so; the sign-up page does not, and closing the notice does not opt you out. To decline, press Opt out on the notice, or open Ad cookie settings in the footer of our marketing pages and choose Opt out (or No thanks where we ask first, below). We try to save your choice both in this browser's storage and in a first-party cookie, and while it remains saved in either we stop sending conversion events and keep the tag from loading on later pages. Opting out also removes the Google Ads click cookies we can reach and updates the consent setting of a tag already loaded on the current page; requests already queued on that page may still be sent. Opting out does not erase what Google already received. Clearing this site's data removes your saved choice.

If your browser sends a Global Privacy Control signal, we treat it as an opt-out, even if you accepted earlier. As a precaution, when you have no saved choice and French appears among your browser's languages, or its reported time zone name begins with "Europe/", we keep the Google Ads tag off until you press Accept on the notice on our marketing pages. These signals are not a reliable indicator of where you are; if you would rather not be measured, choose Opt out, or No thanks when asked.

Separately, we note how you first reached our site — the campaign tags on the link you followed (for example "google, cpc"), the name of the website that sent you, and the page you landed on — and, if you tell us, how you heard about us. These details are held in a signed cookie during your visit and kept with your sign-up or demo request; they are also included in the lead-notification email our team receives through our email provider. We use them to learn which of our efforts work, and we do not send them to Google or any advertiser.

Optional visit counting

Separately from Google, and only if you choose Allow visit counting at the foot of one of our marketing pages, we count which of those pages are read using Umami, an analytics tool we run ourselves on Microsoft Azure in Canada Central. It is off until you allow it, and allowing Google Ads measurement does not turn it on. For each page you open we send its address without anything after a ? or #, a fixed title (“Digital Front Desk”), and, if you arrived from another of these pages, that page's address; the address of another website you came from is not sent at all. Our server also sees your IP address and browser details, as any website does; Umami uses them to tell visits apart and to record the browser, operating system, device type and approximate location (country, region, city), and does not store the IP address itself. It sets no cookies, and it never runs inside the product, on the sign-up or contact forms, or once you are signed in. Your choice is kept in this browser's storage; if the browser will not save it, counting stays off. Choose Turn off in the same place to stop it; the page also tries to cancel a request not yet received, but a visit already counted is not erased. If your browser will not save the Turn off, the notice says so, and the next page you open may count again until you clear this site's data. A Global Privacy Control signal keeps it off.

4. Where it goes — stored in Canada, processed in Canada and the United States

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

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

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 info@digitalfrontdesk.ca. We will respond within 30 days, which is the outer limit PIPEDA allows.

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.

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 — info@digitalfrontdesk.ca — 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).