Privacy Policy

Who we are

Sayora is an AI phone-answering service for UK small businesses. We answer your inbound calls when you can’t, capture lead details, answer common questions from a knowledge base you provide, and notify your team by SMS, email or both. Optionally, Sayora can also book, reschedule, and cancel appointments in a calendar you connect.

Sayora is operated by Sayora Ltd, a company registered in Scotland with company number SC888928. Our registered office is 13/4 Grindlay Street, Edinburgh, Scotland, EH3 9AT.

We are the data controller for personal data we collect about you when you sign up as a Sayora customer (a “client”), and the data processor for personal data we handle on your behalf about people who call you (your “callers”).

In this policy:

• “We”, “us”, “our” means Sayora.
• “You” / “your” means a Sayora client, a UK business owner using Sayora to answer calls.
• “Caller” means an end-user who calls a phone number Sayora answers on your behalf.

What we collect

From you (as a Sayora client)

• Account details: name, business name, email address, phone number, postal address (required by our telephony partner for the UK Ofcom regulatory bundle).
• Authentication: email address and the authentication records needed for email and password or Google sign-in. Password handling is provided by our authentication provider, and passwords are not stored in Sayora’s application database.
• Configuration you provide: business hours, knowledge-base entries (FAQs, services, pricing), greeting and policy preferences, optional calendar connection details.
• Our record of your trial: when your free week or trial starts, our team keeps a record of your account in our customer relationship management (CRM) system, so we can see how it’s going and help: your first name, email address and, if you gave us one, your mobile number; your business’s name, its web domain and the area you serve; and how far the trial has got (running, paid or ended). The texts and emails Sayora sends you about your account, such as your free week’s reminders, a call-back confirmation, and trial and billing emails, are copied to that record, for as long as you have an account. Messages about your callers, such as lead summaries, are never copied.
• Call backs you ask for: if you ask our team to ring you back while you’re on a free week, or after it ends before you’ve paid, the mobile number to ring, the time that suits you, what the call is about and any note you add. Our team keeps a record of your business and of each call back in our customer relationship management (CRM) system: your first name, email address and that mobile number; your business’s name, its web domain and the area you serve; and the call back’s time, topics and note.
• Communications with us: support emails and messages, including messages you send using our support chat. When you use support chat while signed in, we provide our support-chat provider, Crisp, with your account email address and display name so our team can identify the conversation.

From visitors to our website

If you use support chat while not signed in, we receive the messages and any information you choose to provide. Crisp may also use cookies or similar local storage to operate and remember the chat, as described in the Cookies section below.

If you look up your business to build a receptionist, on our website or in the Sayora app, what you type is sent through our servers to Google’s Places service to find matching public business listings. We use it only for that search and do not keep the search itself; the one exception is a website address you type and then choose to use, which is saved as your business’s website. Because the request comes from our servers, Google receives the text you typed but not your IP address or anything else that identifies you. Google handles that text as an independent controller under its own privacy policy, and may use it to improve its services. When you pick a listing, we fetch its public details (the business name, phone number, website, address, opening hours and the kind of business Google lists it as) and use them to build your receptionist. This is part of building a demo, before you sign up. Nothing is sent until you have typed at least three letters, or followed a link from our website that names the listing you picked.

If you book a demo with us, our booking page on Cal.com collects your name, your email address and anything you add about your business, so we can hold the call and follow it up. Cal.com acts for us in this, and we keep the booking while we’re in touch about Sayora.

If you allow optional analytics, we use Google Analytics and Mixpanel to measure page visits, page engagement, selected button clicks, opened FAQs, calculator use, and progress through the demo, signup, onboarding, and product journeys. We use account, user, and device identifiers where needed to connect those steps. We do not send phone numbers, search text, call content, payment details, or raw error messages to Mixpanel. The one place a name and email address reach it: if you are a signed-in Sayora customer and allow analytics, your Mixpanel profile carries your name, email address, account, business name, account status and when you signed up.

Fathom measures visits to our public website without setting analytics cookies, independently of your cookie choice. We exclude staff traffic, and send only the public page URL and how long it was open, the referring website origin, the tags Fathom reads from the link that brought you, whether the business search box was used and whether a business or website was picked from it, and whether a signup button was clicked on that page. Those tags are a fixed list: the campaign tags utm_source, utm_medium, utm_campaign, utm_term, utm_content, ref and via, an advert’s click id (gclid or msclkid), and keyword, q, s, action, name, pagename and tab. Nothing else in the address is sent. What you type into the search box is not sent to Fathom. See Fathom’s privacy policy.

Fathom also counts visits to the Sayora app’s pages for building and trying a demo, signing up and claiming a receptionist, and the steps through them as far as buying a phone number and opening your account, in the same way: without analytics cookies, independently of your cookie choice, and never for staff. For each page we send only the type of page, never its full address; the five campaign tags utm_source, utm_medium, utm_campaign, utm_content and utm_term, each cut to 80 characters, and nothing else from the address; and, on the first page each time the app loads, the origin of the website that sent you, if it was another site. For each step we send its name and whether you started from our website or from a link we sent you (such as “Demo Opened: inbound”), and the type of page it was counted on, nothing more. One step, buying the number, is counted the first time your account’s home page shows your number, in the same browser tab. So that each step is counted once, the app keeps a short note in that browser tab’s session storage of the steps already counted, each with your account’s identifier, and of the one step waiting to be counted on the home page; it is cleared when the tab closes, and your account’s identifier is never sent to Fathom.

On our website (sayora.ai), if you separately allow session recording, Mixpanel can reconstruct how pages behaved during your visit. All on-screen text and form inputs are masked. Images, audio, video, canvases, embedded frames, support chat, and areas marked as private are blocked. We also disable console and network recording. Mixpanel receives the page URL needed to show the replay, so we limit recording to pages without query details or account-specific paths.

In the Sayora app (app.sayora.ai), session recording uses LogRocket instead. It runs only when you have allowed both analytics and session recording, and never for signed-in Sayora staff. LogRocket can reconstruct how app pages behaved, including the demo, signup, sign-in, and signed-in account pages. All on-screen text, form inputs, and images are masked, including the text in tooltips, with one exception: our own fixed wording (headings, labels, buttons, and messages, such as “Build my receptionist”) is recorded as written on the pages where you build and try a demo; on the free week’s screens, including its welcome, its tasks on your account’s home page, adding your card in Billing and the offer to ring you to set it up; and on the settings screen where you choose what Sayora does for you (such as whether Sayora books appointments). This is so we can see where someone got stuck. That wording can show what happened, for example whether you said you travel to customers, or that a test call took a lead. What you type, your business’s details, and who rang and what was said stay masked there too. Audio, video, embedded frames, support chat, and link addresses are removed, and page titles are not recorded. We configure LogRocket to reduce the page addresses in recordings to the type of page, so recordings do not include account numbers, call identifiers, or search text.

For each network request, LogRocket receives only its method, the type of address it went to, its status, and how long it took, never its content or headers. When an error occurs, LogRocket records only that an error happened and on which type of page, never the error message. The error itself goes to our error-monitoring provider, with a link to the session recording when one exists, so our team can replay what led to it. That error report includes the page address. LogRocket does not record your IP address, and we do not send LogRocket your name or email address. Signed-in sessions carry only a random analytics identifier, which we delete when your account is deleted. When you build a demo while recording is on, we keep a link to that recording with the demo, so our team can open it from the demo. The link stays with us: LogRocket is not told which demo or business a recording belongs to.

From the point a personalised demo starts building, we also record a limited set of server-side product events. These events tell us whether a demo, signup, trial, onboarding step, call, lead, integration, or billing step succeeded or failed, and how long a call lasted. They use internal identifiers and restricted categories rather than the content you entered. This server-side measurement does not use optional cookies and may continue if you reject optional cookies.

If you subscribe to Many Hands

Many Hands is our blog, at sayora.ai/many-hands. If you sign up for new posts by email, we send you one email to confirm, and your address goes on our list only if you do: the link carries it in encrypted form, so we hold nothing in the meantime. When you confirm, we use your address to send you new Many Hands posts and nothing else. Every email has an unsubscribe link. Our email delivery provider sends the emails and, as with any email we send, keeps a record of each one, the confirmation included, in its sending log for a short while.

We write the blog on Hashnode, a blogging platform. When our site is built, it copies each post’s images onto sayora.ai, so reading a post, or one of our emails, never makes a request to Hashnode. Hashnode never receives your email address or learns who reads our posts.

From your callers (on your behalf)

When a caller dials a Sayora-managed phone number:

• The caller’s phone number (always, automatically, needed to route the call).
• Call audio. Calls are recorded so we can transcribe them, so you can listen back to a call, and so quality issues can be investigated. Recordings are stored in Sayora’s own private file storage. We keep a restricted recording reference and stream the audio on demand through an authenticated route when an authorised user listens back, and the recording leaves your account automatically 90 days after the call. After each call we automatically remove sensitive details a caller happened to say, such as a card number, from the stored transcript, and bleep them out of the recording. Where that step cannot complete, for example during a provider outage, only phone numbers and email addresses are removed from that call’s transcript and recording; occasionally the recording is left unedited, or replaced entirely by a tone. The caller’s name and the address they gave you are deliberately kept in the transcript and recording, as is an answer you asked Sayora to collect that looks like a vehicle registration. Your lead summary also keeps the details you have set Sayora to collect, because it is no use without them.
• Transcribed text of the conversation.
• Caller-provided details: typically name, reason for call, preferred callback time.
• Call metadata: start/end time, duration, call outcome (for example: lead captured, abandoned, marked as spam) and the spam classification recorded for the call (a flag and a short reason).
• Appointment details for bookings made by Sayora, mirrored into our database and into your connected calendar (cal.com or Google Calendar).

Every caller hears an audible notice that the conversation is recorded, either in Sayora’s opening words or at the start of Sayora’s first reply, and always before Sayora asks for any of their details. Recordings may be reviewed by a human. Recording cannot be switched off for an individual caller. If your business requires an unrecorded contact route or a particular recording-permission process, establish it before diverting calls to Sayora.

Automatic processing redacts detected sensitive details from transcripts and recordings, but it does not guarantee removal of every sensitive detail.

From your connected calendar (if you enable calendar booking)

Sayora supports two calendar providers: cal.com and Google Calendar. Connection is optional.

If you connect cal.com, we receive: your cal.com username and email, the list of your event types (slug, label, duration), and OAuth access + refresh tokens. Tokens are stored encrypted. We also receive cal.com’s notices whenever a booking on your account is rescheduled or cancelled; we act only on the bookings Sayora made, and the others change nothing.

If you connect Google Calendar, we receive: your Google account email address, the list of calendars in your Google account (so you can pick which one Sayora writes to), and OAuth access + refresh tokens. Tokens are stored encrypted. See the dedicated Google API Services User Data Policy section below for the full disclosure required by Google.

From a connected CRM or stock system (if you connect one)

If you connect Sayora to the CRM or stock system you already use, Sayora reads your live stock or listings from it so it can answer callers about them, and sends each lead it captures there: the caller’s name, phone number and email address if they gave one, the call summary, whether the call is urgent, and the details you asked Sayora to collect. Appointments Sayora books may be added to it too. The transcript and recording are never sent. The credentials for the connection are stored encrypted. That system is yours, and its provider handles what we send under your own agreement with them.

Why we collect it (legal basis under UK GDPR)

How we use it

• To answer your phone calls when you can’t.
• To send your team a lead summary by text, email or both after each captured call.
• If you turn on texts to your callers, to text each caller a short recap of their enquiry after the call.
• To text a caller to confirm an appointment Sayora booked, moved or cancelled for them.
• To book, reschedule, or cancel appointments in your connected calendar when you’ve enabled that feature.
• To send the leads Sayora captures to a CRM or stock system you’ve connected, and to answer callers from your stock or listings there.
• To investigate and resolve technical issues, security incidents, or abuse.
• To measure where visitors and clients get stuck in demo, signup, onboarding, and product journeys.
• To respond to support requests you send through email or support chat.
• To keep a record of your trial, and of the messages we send you about your account, in our CRM, so our team can see how it’s going and help.
• To ring you back when you ask us to, text you to confirm the time, and keep a record of your business and the call in our CRM.
• To comply with legal and regulatory obligations (Ofcom records for the UK number assigned to you).

We may use anonymised, aggregated data (e.g., “average call length”, “common intent categories”) to improve the service. This data cannot be linked back to a specific caller or client.

Who we share it with (subprocessors)

We use specialist providers to run Sayora. We treat who they are as commercially sensitive, so this policy lists them by what they do for us rather than by name, and you can ask us for the names at any time (see below). Every provider is bound by a data-processing agreement, and none of them may use your data, or your callers’ data, to market to anyone. Since 26 September 2026 our speech-recognition and voice providers have also been opted out of using what they process for us to train or improve their models. Our payment provider is an exception to pure processor status: it is also a controller in its own right for the fraud-prevention and financial-reporting duties that apply to it, as payment providers are. Google, whose Places search finds your business listing, is not our processor at all: it receives the search text as an independent controller, as described under What we collect.

Delivering the service. These handle call audio, the transcript, your account data, or the messages we send on your behalf:

• Telephony and call routing, including the UK phone number assigned to you.
• The real-time voice platform that carries the call audio and runs the receptionist.
• Speech-to-text transcription, and the word timings we use to bleep sensitive details out of a recording after the call.
• Large language models, for what Sayora says on the call and for the post-call analysis that produces your summary.
• Text-to-speech, the voice you hear.
• Cloud hosting, the database, and file storage for call recordings.
• Encrypted offsite backup of that database and those recordings.
• Email and SMS delivery, for lead summaries, texts to your callers, account mail and the Many Hands newsletter.
• Payment processing and subscription billing.
• Internal alerts to our team about accounts, such as a free week starting, an account starting to pay, or a sign-up that needs our help.
• Customer relationship management, where our team keeps a record of your business, your trial, the messages we send you about your account, and the call backs you ask for.
• Website crawling, to build your receptionist from your business’s website.
• Error monitoring for the Sayora app and voice runtime. App error reports include the page address and, where a session recording exists, a link to it.

If you want the names, ask and we will give them to you. Email hi@sayora.ai. We will ask you to keep the list confidential, which is about not publishing it or handing it to a competitor: it never stops you naming a provider where your own data-protection duties, a regulator, or a customer’s due diligence require it. Where a provider handles your callers’ data, we will tell you before we add or replace it, and you can object. You do not need to be a customer to ask, and you do not need a reason: if you are weighing Sayora up and this matters to your own compliance, that is reason enough.

Named, because withholding them would be no use to you. These you either choose yourself, or they run in your own browser where you can see them anyway:

None of the three measurement providers, nor the app’s session-recording provider, sees call content. Your cookie choices switch Mixpanel’s browser analytics and LogRocket’s app recording on and off (Mixpanel’s limited server-side events, described above, run either way) and set Google Analytics’ consent mode; Fathom sets no analytics cookies and runs either way. See Cookie settings.

We do not sell personal data. We do not share data with any third party for that party’s own marketing purposes.

A note on where processing happens. Several of the providers in the first list do not guarantee in-region processing, some of them route between regions on their own, and we have not independently verified residency across all of them. A per-provider location would therefore read as a promise we cannot stand behind, and it would go out of date quietly. What we can say is that we choose European infrastructure where it is available to us: your account database and all call recordings are held in Europe, and our speech-to-text providers are configured to European endpoints. The language models should be assumed to process outside it. If residency matters to your business, ask us and we will tell you what we know about a specific provider.

Transfers outside the UK rely on regulations under Article 45A of the UK GDPR (including the EU-US Data Privacy Framework and its UK Extension, where the recipient is certified), or on the International Data Transfer Agreement or the International Data Transfer Addendum to the EU Standard Contractual Clauses.

Retention

Account lifecycle

Your account is in one of three states, and what we keep depends on which:

• Active. Your account is live, on a free trial or a paid plan. The retention periods above apply.
• Archived or suspended. Your service has ended, whether you asked us to close the account, you cancelled, or payment stopped. Calls are no longer answered, but the account can still be restored.
• Deleted. Your account, call records, transcripts, lead summaries, calendar connections, credentials and login are purged from the live service.

If you have paid for your plan, your account is held for 90 days after your service ends and then deleted, however it ended. You keep your phone number for those 90 days, so coming back inside the window means picking up where you left off. Call audio is the exception: each recording is deleted 90 days after its call, whether or not the account is still open. We email you 7 days before the deletion and again when it completes.

If you never paid, your account is deleted 30 days after calls stop. Calls stop at the end of the trial if you cancelled it or it ended without a card, or 14 days after a first payment fails if it is still unpaid by then, and we email you at that point. A demo you claimed but never turned into a trial is deleted 30 days after the claim, with no further email. If you ask us by email to close a trial account instead, it is held for the same 90 days as a paid one.

You can ask us to delete your account sooner at any time (see “Your rights” below).

A few things survive a deletion. We keep a permanent record that the deletion happened, carrying the business name, the owner’s email address and phone number, and the email address of each login removed. We keep billing records, including the records of billing events, for up to 6 years, as tax and accounting law requires; they carry the billing email address. A support-chat conversation, or your entry on our marketing email list, is removed by hand when you ask. A session recording of a sign-in or sign-up page expires on our session-recording provider’s one-month retention. And our encrypted offsite backups can hold a deleted account’s data for up to 30 days (the database) or 90 days (call audio) from when the copy was taken, plus a short recovery window; nothing in the product reads them, and we do not edit a backup to remove one account. None of this is used to contact you or to rebuild your account. Separately, if your account had a trial with us or you asked us to ring you back, our CRM keeps, until you ask us to remove them, the record of your business (its name, web domain and area), the record of your trial and whether it went on to pay, and any contact record our team already had for you or another of your accounts still uses, which may now also carry the first name and mobile you gave us; deleted CRM records sit in its recycle bin for up to 90 days.

Your rights (UK GDPR)

You have the right to:

• Access the personal data we hold about you.
• Have inaccurate data corrected.
• Have your data erased (subject to legal retention requirements).
• Restrict or object to processing.
• Receive your data in a portable format.
• Withdraw consent at any time, where consent is the legal basis.
• Complain to the Information Commission (formerly the Information Commissioner’s Office, ICO) at ico.org.uk.

To exercise any of these, email hi@sayora.ai. We respond within 30 days.

If you are a caller (not a Sayora client) and want your data removed from a Sayora client’s records, please contact the client directly. We act only as their processor for caller data; the client decides what to retain.

Google API Services User Data Policy

Sayora’s use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.

When a Sayora client connects their Google Calendar, the following applies.

What Google data we access

• Your Google account email address (https://www.googleapis.com/auth/userinfo.email), used to display which Google account is connected in the Sayora portal and to identify the connection internally.
• Your Google Calendar (https://www.googleapis.com/auth/calendar.events and https://www.googleapis.com/auth/calendar.readonly), used to list your calendars so you can choose one, to read free/busy time on the calendar you select, to read the events on that calendar in the ways set out under How we use it below, to create events when Sayora books an appointment on a caller’s behalf, update events when Sayora reschedules, and delete events when Sayora cancels.

How we use it

• Only to provide the calendar-booking feature you explicitly enabled.
• To offer callers free times, we read free/busy intervals on the calendar you select.
• To keep our record of Sayora’s bookings in step with your calendar, we read the events on the calendar you select: every event on it, in full, when you choose the calendar and again whenever Google asks us to start the sync afresh; and each changed event, in full, whenever Google tells us the calendar has changed. From these reads we act only on the events Sayora created, which carry private identifiers we set (callerPhone and sayoraEventTypeSlug), and on their cancellation. Every other event is discarded without being stored.
• To tell a caller about their upcoming appointment, we look up events by the private identifier we set for that caller’s phone number.
• Where travel-aware booking is enabled for your account and you have said appointments happen at the customer’s address, we read the time, the location, any private markers and your own response (whether you declined it) of every event in the period whose times we are about to offer a caller. We use them only to rank the times offered by the travel they would add, and do not store them or send them to anyone else.
• We mirror booking activity into our own database so callers asking about their appointment get accurate answers without an extra round-trip to Google.

What we do NOT do

• We do not use Google user data for serving advertisements.
• We do not sell Google user data.
• We do not transfer Google user data to any third party except (a) as needed to provide the calendar-booking feature back to you, (b) where required by law, or (c) in connection with a merger, acquisition, or sale of assets, with notice to you.
• We do not allow humans at Sayora to read your Google calendar data, except (a) with your explicit consent, (b) for security purposes such as investigating abuse, (c) to comply with applicable law, or (d) in aggregated, anonymised form for internal operations.
• We do not transfer Google user data to AI/ML models for training the underlying model. The AI uses your data only at inference time to handle the current call.

How to revoke access

• In the Sayora portal: go to Settings, then Bookings, and tap Disconnect beside your calendar. The connection is archived, the Google push-notification channel is stopped, and the OAuth tokens are taken out of active use immediately. The encrypted tokens are deleted with the rest of the archived connection record per our retention schedule (or sooner on request).
• Directly with Google: visit myaccount.google.com/permissions, find “Sayora” in the list, and click “Remove access”.

Security

• OAuth tokens and webhook secrets are encrypted at rest with AES-256-GCM. The encryption key is held in our hosting provider’s secret store, separate from the database.
• Data sent over the internet between your browser or app, our systems and our providers is encrypted with TLS. Calls and texts over the public phone network are carried by the telephony providers.
• Database access is restricted by role-based access control plus row-level security; service-role keys are held only by the application server.
• We follow standard security practices: dependency updates, secrets rotation, an audit trail of administrative changes, principle of least privilege.

We will notify you without undue delay after becoming aware of a personal data breach affecting your data or your callers’ data, and report to the regulator where UK GDPR requires it. For your callers’ data, you decide whether the regulator and the callers must be told, and we help you do it.

Children

Sayora is a B2B service for UK businesses. We do not knowingly collect personal data from children under 13. If you believe we have, contact us and we will delete it.

Cookies

Essential cookies keep the service working. These include the session cookie used to keep you signed in, a short-lived __oauth_state cookie used while connecting a calendar, and sayora_privacy, which remembers your cookie choices for 180 days. A short-lived sayora_analytics_excluded cookie keeps Sayora staff activity out of analytics. If Mixpanel has already run, a Mixpanel opt-out marker remembers when that browser should stop sending Mixpanel events. If you close the early bird strip at the top of the website, a sayora-deal-strip entry in your browser’s local storage keeps it closed until you clear your site data; it holds nothing about you. Support chat may also use cookies or similar local storage to operate and remember the conversation.

Analytics is optional. If you allow it, Google Analytics and Mixpanel use browser storage to measure visits and the selected events described above. If you reject it, Mixpanel browser analytics stays off. Fathom runs independently of this choice without setting analytics cookies. Google Analytics remains in denied Consent Mode and may receive cookieless measurement signals. We do not enable advertising or cross-site tracking cookies.

Session recording is a separate optional choice. It only runs when both Analytics and Session recording are on. LogRocket (in the app) or Mixpanel (on our website) may use browser storage to build and send a recording. The masking and blocking rules described above apply.

Choose Accept optional, Reject optional, or Manage choices in the banner. You can withdraw consent or change either optional choice later through Cookie settings in the website footer. The same choice applies on sayora.ai and app.sayora.ai. The limited server-side product journey events described above do not rely on optional cookies and are not controlled by these switches.

Changes to this policy

We may update this policy. When we make material changes we will notify you by email and update the “Last updated” date at the top. Your continued use of the service after the change date constitutes acceptance.

Contact

• Email: hi@sayora.ai
• Postal address: Sayora Ltd, 13/4 Grindlay Street, Edinburgh, Scotland, EH3 9AT
• Complaint to the Information Commission: ico.org.uk/make-a-complaint