Effective November 6, 2026. Covers the Emma Chrome extension, the Emma web app at emmalabs.ai, the Emma app for Zoom, and the public demo on this website.
Emma is an AI sales engineer: a Chrome extension and web app that lets a sales rep ask product questions during a live call and get answers grounded in their company's own documentation. Emma is installed and configured by a company for its own sales team — the only credential involved is a shared workspace code, not a personal account or login.
Workspace binding. When a rep pastes in a workspace code, the extension stores the resolved workspace (an internal ID, company name, and domain) inchrome.storage.local, on-device. This is not sent anywhere except back to our own API to identify which workspace's knowledge to answer from.
Questions typed into the demo on this website. Anyone can try Emma here without signing up. What we keep for those questions, and for how long, is set out in full under “The demo on our website” below. It is a separate store from any customer workspace and never mixes with one.
Questions you ask Emma. The text of each question you type, and Emma's answer, are sent to our production API (emmalabs.ai) and logged server-side against your workspace, so a team can see what prospects are asking in aggregate. This log is workspace-scoped, not tied to an individual rep's identity — we don't collect names, emails, or any personal login for the extension.
Whether your rep used Emma's answer. When Emma shows your rep an answer, we record what the rep did with it — whether they copied it, or sent the question to their own team instead. We keep the workspace, the call it belonged to, which of those two things happened, how long the rep took to do it, and which surface it happened on.
We do not keep the question or the answer in this record. In their place we keep a short fingerprint of the question, computed with a secret key that only we hold, so that repeat questions can be counted together without us storing what was asked — and so that the fingerprint cannot be matched back to a question by anyone who does not have that key.
What it is for. One thing only: to tell whether Emma is useful on a call. A rep copying an answer is the clearest sign it helped; a rep asking their team instead is the clearest sign it did not. We use it to decide what to improve. It is never used to assess the rep, it is not shown to anyone outside your workspace, and it is not combined with anything to identify a person.
How long we keep it. As long as your workspace exists, the same as the questions and answers themselves. Email the address at the end of this page and we delete it.
How well Emma heard the call. While listening is on, the extension keeps a running count of a few things and sends them to us about once a minute: how long it listened, how many spoken questions it picked up and passed to Emma, how many pieces of speech it decided were not questions, and how many words those were. We keep the workspace, the call it belonged to, those counts, and the version of the extension that sent them.
There is no speech in this record — only numbers. We do not keep the words themselves, or any part of them. The word count is a total, not a sample: it tells us how much talking Emma set aside, and nothing about what was said.
What it is for. To find out when Emma is missing real questions. A prospect asks something, the extension decides it was not a question, and Emma never sees it — today we have no way of knowing how often that happens. These counts are how we find out. They also tell us what a call costs us to transcribe.
How long we keep it. Twelve months, then a scheduled job deletes it. Email the address at the end of this page and we delete it sooner.
Meet call presence. The extension checks whether your currently-focused browser tab's URL matches a live Google Meet call pattern (meet.google.com/xxx-xxxx-xxx), purely to show a "listening" indicator in the side panel. This is a URL-pattern check only — there is no reading of the Meet page's content, no DOM scraping, and no screen or audio capture in this check. It never leaves your device; it only changes what the side panel displays locally.
Call audio, when you turn listening on. Starting audio capture is a manual action — you click Emma's toolbar icon while on a live Meet call. When it's on, Emma captures the other call participants' audio directly from the browser tab (not your own microphone — this version does not listen to your own voice) and streams it in short real-time chunks to Deepgram, a third-party speech-to-text provider, so it can be transcribed live. We do not write this audio to disk or store it as a file; it exists only as a live stream and is discarded once transcribed.
Questions asked on the call. While listening is on, transcribed segments that look like a question are sent to our own API, which uses Anthropic's Claude to decide whether it is a question Emma should answer and to clean up transcription noise. We store the text of those questions in your workspace. That includes questions Emma answered, and questions she did not — for example commercial ones about pricing, timelines, references or contract terms — so that after the call your team has a record of everything that was asked and a follow-up list of what still needs an answer. We store the cleaned-up question text, the time it was asked, and whether Emma answered it. Where Emma answered, we also store her answer and which of your documents she used.
What we do not keep from the call. We keep questions, not conversation. We do not store a transcript of the call, we do not store the speech around a question, and we do not store audio — audio is streamed for live transcription and discarded, as described above. Utterances the filter decides are not questions at all — small talk, thinking aloud, colleagues talking to each other — are not stored.
Who can see it. Stored questions are scoped to your workspace and are never combined with, or visible to, another customer's workspace. They are readable by members of your own workspace who hold its access key, and by Emma Labs staff through an internal, credential-protected dashboard, and we use them to operate and improve the product. We do not sell them, and we do not use them for advertising.
Separately from the above, a narrowly-scoped debug log of raw candidate text remains available to us and is off by default: it can only be switched on for named individual workspaces, never for everyone at once, and doing so requires a code deployment rather than a setting someone can toggle. It is not switched on for any customer workspace. This is a diagnostic tool and is distinct from the question record described above, which is a product feature.
Security telemetry. When someone enters a wrong access key for a workspace ledger, we record that a failed attempt happened, so we can limit how many times a credential can be guessed. That record contains the workspace, the time, and a one-way keyed hash of the requesting IP address — not the address itself, which we do not store and cannot recover from the hash. It exists only to bound guessing, is kept per-day, and is never used to identify or profile anyone.
This is live, not upcoming: when you turn on listening (see "What we collect" above), Emma's extension requests Chrome's tabCapturepermission for your current Meet tab only, and streams the other participants' audio to Deepgram for real-time transcription. Our commitment: audio is never written to disk or stored as a recording by us, and it is discarded once transcribed. Transcribed text that looks like a question is then checked against our own API (using Anthropic's Claude) before any card appears — see "Detected question text" above for what that step does and what we do and do not log.
If you connect Slack, Emma can ask your team a question she could not answer from your documentation — and bring the answer back onto your rep's screen while the call is still happening. Connecting Slack is optional and off until an admin turns it on.
It is your Slack, not ours. Emma is installed into your own Slack workspace by one of your admins, who chooses the single channel she may post in. The question goes to your team, in your workspace. We do not run a Slack workspace that your questions pass through, and nothing is shared with any other customer.
She posts the question, and nothing else.What reaches Slack is the text of the question Emma could not answer. Not the transcript, not the rest of the call, not your documents, not the prospect's name or company, and not who was on the call. A teammate reading the channel sees a question, not a recording.
How often she can ask. Emma asks your team at most a set number of times in any one call — your admin picks that number in the workspace settings. When she reaches it she stops asking for the rest of that call, and says so on your rep's screen. She also never asks the same question twice in one call, even if it comes up again.
It happens automatically, and your rep can stop it. By default, when Emma has no answer she tells your rep she is asking the team and gives him five seconds to cancel before anything is posted. An admin can switch this to ask-only-when-tapped instead. Changing an existing connection to the automatic setting requires a fresh admin approval — we never migrate that silently.
What we keep from Slack. The reply, and the display name of the person who wrote it, so your rep can see who answered. It is shown on the call as coming from a person via Slack, never as something Emma found in your documentation. Replies that arrive after the call ends are kept with that call's follow-up notes.
The permissions we ask Slack for. To post in the one channel your admin picked; to read replies in the threads Emma started, so she can bring an answer back; to read a profile display name, so a reply has a name on it; and to see when someone mentions Emma directly, which is how an admin will be able to point her at a channel without copying an ID. We do not ask for permission to read your channel list, your other channels, or any message outside a thread Emma started.
Turning it off. An admin can disconnect Slack at any time from the workspace settings page. Disconnecting revokes our access token with Slack immediately. Questions and replies already recorded stay with the calls they belong to, as described above.
If we ever send Slack a summary. We are building an optional weekly digest — the questions Emma could not answer, so your team can fix the gaps. It is off unless an admin turns it on, it goes to the same channel, and it carries questions and counts, never transcripts or prospect details.
Emma can run as an app inside a Zoom meeting. What she does there is the same as in Google Meet — she listens for questions about your product and answers them from your own documentation — but she receives the audio differently, and that difference is worth being precise about.
How the audio reaches us. In Google Meet, your browser sends the meeting audio to our transcription provider directly. In Zoom, Zoom itself transcribes the meeting and sends us the resulting text over a connection we hold open for the length of the call. We do not receive the audio and we do not store it. The connection is held by a small relay service of ours, listed on our subprocessors page.
We receive your own speech, and we discard it. Zoom sends us the transcript of everyone on the call, including the rep running Emma. We do not keep the rep's own speech and we never put it to a model. It is identified and dropped when it arrives.
While Emma is working out which voice is the rep's, she holds what she has heard in the relay's memory for up to three minutes. It is never written to disk. It is discarded when the call ends, or when the time runs out, whichever comes first. Until she works it out, she answers nothing from the call — questions your rep types into the panel still work.
One tap can release a held question. If Emma cannot tell whose voice is whose, your rep can mark a voice as not his. That releases the questions from that voice to be answered. He can never mark his own voice this way — the check refuses it.
Zoom tells the meeting that Emma is there. Zoom shows its own "Active Apps" notice to participants. We do not hide her.
What we store from a Zoom call is the same as anywhere else: the questions asked, Emma's answers, and which of your documents she used. Not a transcript, not the speech around a question, not audio.
When you open Emma inside Zoom, Zoom tells us who you are — it sends a signed value identifying your Zoom account, which only we can read. We use it to find the workspace you linked, so your rep does not type a workspace code on every call.
We store a one-way hash of your Zoom user identifier, not the identifier itself, alongside the workspace you linked it to.
Anyone who controls your Zoom account can reach your Emma workspace. That is what signing in through Zoom means, and it is the trade for not typing a code every call.
Unlinking removes the connection. Uninstalling the app from Zoom removes it too.
Emma answers from your documentation, and she says so when your documentation does not cover something. Your team can then answer that question themselves. When they do, that answer becomes part of your workspace's knowledge and is credited to the person who wrote it, so anyone reading it later can see where it came from.
After a call, your rep can create an answer pack: a page holding some of the questions asked on that call and the answers Emma gave, which they can send to you to share internally. Creating one is private to your team. Publishing one is a separate, deliberate action by your rep, and it is the only thing that makes any of it readable outside your team.
A published pack is reachable only through a single unguessable link. It needs no account to read, it is marked so search engines do not index it, and the link stops working 30 days after it is published — your rep can also switch it off at any time from their dashboard.
A pack contains only questions and answers. It does not contain a recording, a transcript, the names or email addresses of anyone on the call, or any internal note. Where Emma had no answer in your documentation, the pack says the team is confirming it — it never shows a guess. Where a colleague answered in Slack, the pack shows their answer as coming from your team; their name is not included unless your rep chooses to add it.
Anyone can try Emma here without signing up. You type a question, and Emma answers from the published documentation of a fictional company we invented for the demo. It is not a real customer's workspace, and nothing you type reaches one.
What we keep, for 30 days: the question you typed, when you typed it, whether Emma answered it or said she did not have it, and a keyed one-way hash of your IP address.
If the demo stops you — because you have used your questions for now, or because it is busy — we keep a smaller record for the same 30 days: the time, which limit stopped you, and the same keyed one-way hash of your IP address. It does not include anything you typed. We keep these so we can tell when real visitors are running into a limit, and to spot abuse.
Why. We keep the questions to see what people actually ask Emma — that is how we decide what to improve. We hash your IP address so that one person cannot use up the whole day's demo. We store only a keyed one-way hash, never the address itself, and we never use it to identify you — it exists to count requests and nothing else.
Where your IP address does exist, briefly. It reaches our hosting provider, Vercel, because that is simply how a web request arrives. Their standard logs may hold it for a short period — on our plan, runtime logs are kept for one day — and we do not copy it into our own systems. Vercel is listed on our Subprocessors page.
Your question is read by an AI provider. Emma's answers are written by a model run by Anthropic, so the text you type is sent to them. Under Anthropic's commercial terms they do not train their models on it, and they delete it within 30 days — longer only if something is flagged under their usage policy. Anthropic is listed on our Subprocessors page.
What we do not keep when you ask a question: your name, your email, your raw IP address, or anything that follows you to other websites. The demo sets one short-lived cookie whose only job is to count how many questions you have asked during this visit. The cookie lasts an hour. It carries no advertising or tracking identifier. If you choose to ask us for a private session, that form is the one place the demo collects anything about you — see If you ask us for a private session below.
Emma's video answers, and speaking to her. If we have switched these on, you can hear Emma answer in her own voice, and you can speak your question instead of typing it. Both are optional and the typed demo is always there.
Your microphone, and the one place your voice goes. When you speak to Emma, your microphone audio goes only to our speech provider, Deepgram, to be turned into text. We ask them not to keep it or train on it; their documentation says data from opted-out requests is kept only for as long as the request takes. We never store the audio, and no recording is made. We keep the text of your question for 30 days, exactly as we do for a typed one. A session lasts up to 90 seconds. We never ask for your camera.
Who renders Emma's face. Her picture and voice come from Tavus, and the call itself is carried by Daily. Your browser connects directly to Daily to receive Emma's video, so Daily receives your IP address and connection details — that is how any video call works. Tavus receives only the text of Emma's answer. Your microphone audio never reaches Tavus or Daily: it travels on a separate connection to Deepgram and nowhere else. Tavus makes no video or audio recording, though it keeps its own record of the call — the time, how long it lasted and whether it worked — along with the text of Emma's answers and its operational logs, under its own policy. Both are listed on our Subprocessors page.
You are told it is an AI. The first thing Emma says in every session is that she is an AI assistant. There is no step where you could mistake her for a person.
We do not keep Emma's answers. They can be reproduced from the demo company's documentation at any time, so storing them would add nothing.
After 30 days everything we keep is deleted automatically.
One honest consequence of keeping so little: because we deliberately store nothing that identifies you, we usually cannot find your particular questions on request. That is the trade — we hold nothing that points back to you, and it is all gone within 30 days regardless. If you tell us roughly what you asked and when, we will do our best to find and delete it sooner.
If you ask us for a private session
When Emma's video answers are unavailable, you can ask us to send you a private link. We collect your name, your company and your work email, and we use them for two things: to email you that link, and to follow up about Emma. We keep them until you ask us to delete them — email privacy@emmalabs.ai and we will. We record when a private link is created, used or expires, without the questions asked during the session; those rows are deleted after 30 days, like every other demo record.
We do not sell your data. We do not share it with data brokers or ad networks, and we do not use it for advertising.
We use a small number of service providers to run Emma, each for one purpose:
None of them receives anything from your Google Calendar. Nothing we read from your calendar — no event title, no meeting time, no video link, no guest list and no email address — is sent to any of these providers, or to anyone else. It travels between Google, our own server, and your browser, and stops there.
We will disclose data if the law requires it of us. If Emma Labs is ever acquired or merged, data would transfer as part of that business, and we would say so here before it happened.
Every provider is named, with what it receives, at emmalabs.ai/subprocessors.
Connecting is optional and you start it. Emma works without your calendar. If you choose to connect it, we ask Google for permission to read your calendar events, and Google shows you exactly what you are agreeing to before anything happens. You can disconnect at any time from your dashboard, and you can also remove our access from your Google account settings.
We can only read. We cannot write. The permission we ask for does not allow us to create, change or delete anything in your calendar. We never edit an event, and we never add anything to an invitation — the people you are meeting are not notified of anything by us, and they see nothing we have done.
What we read. For your events: the title, when it starts and ends, the video link attached to it, and who is invited. We ask for the narrowest permission Google offers for this. We do not read your contacts, your email, your files, or anything else in your Google account.
Finding the meeting link. To match your live meeting to the right event, we look for a meeting link in three places on it: the conferencing details, the location field, and the description. We read those fields only to find a meeting link — anything else in them is discarded immediately and is never stored, logged, or sent to a model.
The guest list. When you write a follow-up, we look at who was invited to that meeting so we can fill in the "to" field for you. We read it at that moment and we do not keep it— no guest list and no email address is ever stored. If we cannot tell who the right person is — because several people from the other company were invited, which is common — we leave the field blank for you to fill in rather than guessing.
What we use it for today. Two things, and only these two: showing you your next meeting on your dashboard, and filling in the "to" field when you write a follow-up, as described above.
What we keep. Nothing from your calendar. We store the permission itself — the token that lets us read. Your events are read when a page asks for them and are gone when the answer reaches your screen. No event, no title, no meeting time, no guest list, no name and no attendee address is ever written to our storage.
Who can see it. Only your workspace. What we read from your calendar is never shared with, shown to, or combined with any other customer's workspace.
If you disconnect. We delete the permission immediately and stop reading anything. Because we never stored anything from your calendar in the first place, there is nothing else of yours to delete — your past calls and their questions are your own record and are unaffected.
In transit. Every connection is encrypted with HTTPS — between your browser and us, between your browser and the speech-to-text provider, and between us and Google. Unencrypted connections are not possible; our host does not permit them.
At rest. Everything we store sits in a private store on Vercel, encrypted at rest with AES-256. The store has no public addresses: every read requires our own credential, and a request without one is refused.
The calendar permission. The token that lets us read your calendar is never sent to a browser — not to your dashboard, not to the extension, not to anyone. The only thing any page of ours can learn is whether a calendar is connected, as a yes or no. The token is read by one function, used only to ask Google for short-lived read access, and deleted when you disconnect.
Separation between customers. Access is scoped to one workspace. A key for your workspace cannot read another workspace's data, and this is enforced on every request rather than assumed.
Least privilege. We ask Google for the narrowest permission that does the job — read-only access to calendar events. We cannot create, change or delete anything in your calendar, and we ask for no access to your contacts, your email or your files.
Emma's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.
Emma uses AI, and no Google data reaches it. Emma answers questions using Anthropic's Claude. Nothing from your Google Calendar is part of what she is asked, or of what she is given — not the event, not the title, not the time, not the guest list, and not the email address we fill into your follow-up. When Emma drafts that follow-up, she is given the questions from the call, the answers she already gave, and the first name and your name as you typed them. The address in the "to" field is placed there by your browser and is never sent to a model.
We do not use Google user data to train or improve AI models. Not ours, and not anyone else's. We do not use it — raw, aggregated or derived — to create, train or improve any machine-learning or artificial-intelligence model, and we do not transfer or sell it to anyone who would.
When you ask for it, and only then. If you ask Emma to prepare a brief for a named company, we look up a small number of that company's publicly published web pages — the sort of pages anyone can open without logging in. We do this only when you ask, and only for the company you name. We do not do it in the background, and we do not do it for everyone you happen to meet.
What we look at. Publicly published pages on the company's own website — an engineering or product blog, the roles they list on their own careers page, public documentation, and an about page. Nothing that requires a login, and nothing behind a paywall. We do not read job boards or other third-party sites. We do not buy data about companies or people, we do not use data brokers, and we do not try to identify individuals — we are reading what a company has chosen to publish about itself, not building a profile of the people who work there.
What we keep, and for how long. For each item we keep the text of the claim, the address of the page we read it on, and the date we read it. We keep the source address specifically so you can check it yourself and decide whether to believe it. We stop showing you research after 30 days without re-checking it, because this kind of information goes out of date quickly — a job posting that was open in March tells you very little in July — and we delete it after 90 days.
What we do with it. It appears in the brief you asked for, and nowhere else. It is kept separate from the documents Emma answers questions from, and it never reaches her answers on a call. That separation is deliberate and is enforced in our code, not by policy alone: Emma answers only from your own documents, and research about another company cannot become one of them.
Facts and guesses are labelled. Where the brief states something we read, it is marked as a fact and carries the address of the page it came from. Where the brief offers our own reading of what that might mean for your call, it is marked as a guess and carries no source, because it does not have one — it is our inference, not something anyone published.
Who can see it. Only your workspace. Research gathered for your workspace is never shared with, shown to, or combined with any other customer's workspace.
Questions, answers, and the documents Emma was trained on are retained for as long as your workspace exists, so your team can review what prospects are asking. We do not currently apply a shorter automatic expiry to workspace data, and we would rather say so plainly than publish a period we do not enforce.
The one exception is the public demo on this website. Questions typed into it are deleted automatically after 30 days by a job that runs daily — see “The demo on our website” above. That period is enforced, not aspirational, which is why it is stated as a number here and the rest of this section is not.
Deleting a workspace deletes its stored data — every question, every answer, and every compiled document held under that workspace — and there is no undo. To delete a workspace, to request a copy of what is stored for you, or to ask any question about it, email us at the address below and we will action it.
storage — to remember your workspace binding and mute state on-device.sidePanel — to show the Emma panel next to your browser window.tabCapture — to capture the other call participants' audio directly from a live Meet tab so Emma can detect spoken questions. This only activates when you click Emma's toolbar icon on that tab (Chrome requires this direct action before the permission can be used) — it cannot capture any other tab's audio.offscreen — Chrome's Manifest V3 requires audio processing to happen in a hidden offscreen document rather than the extension's background script; this is an internal processing detail, not an additional data source.activeTab — confirms Emma was directly invoked on your current tab (by clicking its toolbar icon), which is what makes the tabCapture permission usable for that tab, per Chrome's own security model. It does not grant access to any other tab.Questions about this policy or your data: privacy@emmalabs.ai.
Every rep answers like your best engineer.