Privacy policy

PleaseMeet is operated by Please Meet, LLC (we, us), and runs a referral service at pleasemeet.app. A company hires us to help it get warm introductions. One of that company's customers, the introducer, connects their Google account, reviews a list of people they know, and sends introductions from their own Gmail account to the person being introduced, the introducee.

Both the company's representative and the introducer can sign in at pleasemeet.app with the Google account they connected. Signing in uses Google only to confirm which account you are; it requests no access to your data and adds no permission to the ones described below.

A company can also sign up on this site. That sign-up asks Google, in one step, to confirm which account the representative is and for the permissions the representative is asked for, listed below; nothing more.

This policy covers all three, plus anyone who simply visits this website. It explains which Google permissions we ask for, what we do with the data behind them, who else sees it, how long we keep it, and how to have it deleted.

Two kinds of people connect a Google account, and they grant different permissions. These lists are the complete set. This page is generated from the same constants our sign-in code uses, so it cannot describe more or less access than we actually request.

PleaseMeet's use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

In practice that means we use Google user data only to provide the feature the person granted it for, we do not transfer it except as described on this page, we do not use it for advertising, we do not sell it, and no human reads it except with the account holder's explicit permission, to resolve a support problem they raised, for a narrow security investigation, or where the law requires it.

An introducer grants access for one purpose: making the introductions for the company whose link they opened. Any other use of their contacts or calendar is a separate purpose that needs their separate, explicit consent, asked for on screen, in plain language, next to the button that gives it.

Concretely: we do not analyse an introducer's network to sell them something, to build a product for somebody else, or to work out what an account of their own might be worth, unless and until they have clicked to agree to exactly that. Recording that somebody expressed interest is not the same as computing something from their data, and we do not do the second one first.

If an introducer does click to run PleaseMeet for their own company, the consent text next to that button says what happens, and this is it: after they have set up their own account and signed in, we rank the people they have met with, from their calendar, as possible referrers for them: the same list a client sees, and nothing more. Their contacts are not read to build that list. From then on they are a client, and the section below applies to them, including the check that keeps people they already know off their own introducers' lists.

From the introducer's Google account we store:

• Their own name and email address.
• For each person we suggest: name, email address, and the company domain from that email address, or the company recorded on their contact card, taken from their contacts. For a person the introducer adds themselves: the name, email address and company they typed, marked as typed in rather than suggested.
• For each of those people: how many events they and the introducer both attended in the last two years, and the date of the most recent one. Event titles, descriptions, locations, attachments and other guests’ details are not stored or used.
• A relationship score computed from those counts, used only to order the suggestions.
• A correction the introducer makes to a person’s first name or company name, used for that introducer’s own introductions and, where the company record we hold for that domain was only a guess, to improve that record.

With each introduction they send, we also keep the wording it used, as a template: the text with the places for each person's name and company left unfilled, which suggested wording it started from, and how much they changed it. We keep it so we can see which wording leads to meetings. It holds no one's name, email address or company, unless someone typed one into the wording itself.

The client never sees a contact the introducer did not approve, and never sees the scores. The introducer is never shown who declined an introduction, or any ranking of their own relationships.

We store the representative's name and email address and the introductions made for their company. From their calendar we do three things, and only these three. From their contacts, if they allow it, we do one more, described after them.

First, we suggest who they might ask for introductions. We read the events on their primary calendar from the past two years and rank the people they have met with by how often and how recently, using only attendee names, attendee email addresses and event start times. The list is built fresh from the calendar each time it is shown, and the ranking itself is not stored. What we do store: the email address of each person we have suggested and when, so that our email about new names (sent at most once a month, and only when the list has changed) does not repeat people they have already seen; the people they chose to ask, with the name they gave for each; and, for two weeks, anyone they said they would ask themselves.

Second, we check whether an introducee's email address appears as an attendee on an event created after the introduction went out. That is how a booked meeting is counted. The event may have been booked through a colleague's booking page, as long as it appears on the representative's calendar.

Third, when the reply to an introduction is sent from the representative's account, which happens automatically a few minutes after the introduction unless they have turned that off, we offer the other person two or three free times, found by reading the start and end times of the representative's events over the next few working days. Only the gaps are used. Nothing about the events themselves is shown to anyone, and the free times are not stored once the reply is sent.

We do not use or store event titles, descriptions, locations, attachments or anything else from their calendar.

Fourth, and only if the representative allows “See your contacts” and “Other contacts” on Google's screen (both are optional, and the account works without them), we make sure nobody they already know is suggested to their introducers. About once a day, when an introducer's list is being prepared, we read the email addresses in their Google Contacts and “Other contacts” and keep only a scrambled fingerprint of each address: a one-way code that lets us recognise the same address again, from which the address itself cannot be read back. We keep no names and no addresses. Anyone on an introducer's list whose address matches is left off it. The fingerprints are used for nothing else, are never shown to anyone (the introducer is not told why someone is missing), and are deleted when the representative disconnects Google or Google stops accepting the connection, when their account is closed and its tokens are deleted, or when the client is deleted.

When a client pays the activation fee, the card is entered on a page hosted by Stripe, not by us. The card number never reaches our servers or our database. We keep the card's brand and last four digits, so the client can see which card is on file, and Stripe's own reference numbers for the customer and the payment.

A client can upload a list of their own customers, so those people appear on the client's screen among the people they might ask for introductions. From that list we keep only each person's email address and first name. We never email anyone on it, and nobody but that client sees it. Before anyone is added we check, from the domain of their address alone, whether their company uses Google Workspace; people who don't are not kept. An entry is deleted when that person becomes an introducer, when the client cancels, and 12 months after it was added. If you think you are on a client's list and want to be taken off, write to us and we will delete you. When a client removes someone from the people they might ask, we keep only a scrambled fingerprint of that address, not the address itself, so the person isn't suggested to that client again.

If you received an introduction, your name, email address and employer came either from the contacts of the person who introduced you, somebody who had your address already, or were typed in by them. We keep those details, and a record of the introduction, so that we never send you a second one by accident and so the client can be billed if you book a meeting.

Email hello@pleasemeet.app and we will add you to a do-not-contact list that applies across every client we work with, and delete your details if you ask us to.

These are all of them. We will update this page before adding another.

Google

Gmail, Google Contacts and Google Calendar are where the data comes from, and Gmail is how introductions are sent. Sending an introduction means handing Google the message, exactly as any mail app does. Our encrypted nightly database backups are also stored in our company’s Google Drive; Google holds them, encrypted, and has no key to open them.

Postmark

Sends our own system email: the note telling a client representative that an introduction went out, the at-most-monthly note naming new people on their own calendar they might ask, one reminder to a representative who set up an account but did not activate it, and alerts about a broken account connection. These go to our clients’ own staff, never to an introducee. Postmark sees the recipient’s address and the message.

Anthropic

Identifies what a company does, from its public website, and checks a company against the signals a client has listed (for example, whether it recently raised funding). We send the company’s internet domain, the text of its public web pages, public news results about it and public regulatory filings in its name. We never send a person’s name, email address, contact list or calendar data to Anthropic.

Brave Search

A web search, used to find public news about a company when a client has listed signals to check for. We send the company’s name and internet domain as a search query, and nothing else: no person’s name, email address, contact list or calendar data.

Railway

Hosts the application and the database it stores everything in.

Stripe

Takes the client’s activation payment and keeps the card on file for later charges against the monthly statement. The client enters their card on a page Stripe hosts; the card number never touches our servers. Stripe receives the client representative’s email address and the company’s name, so the record can be found, and, on each monthly invoice, the date and price of each booked meeting. Nothing else: no introducer’s data, no introducee’s name, address or company, and nothing from anyone’s Google account. The named list of meetings stays in the client’s own PleaseMeet account.

Google Analytics

Counts visits to the public pages of this website only: the home page, the FAQ, this policy and the terms. It receives the page opened, an approximate location from the visitor’s internet address, and the kind of browser and device. It is not loaded on any page an introducer or client uses, and it receives nothing from a connected Google account: no contacts, no calendar, no introductions.

Sentry

Records errors from our own servers, so that we find out when something breaks rather than waiting to be told. Error reports are stripped before they are sent: no email addresses, no contact lists, no calendar entries, no access tokens. What Sentry receives is the fault itself, where in our code it happened, and our own internal record numbers. Nothing runs in your browser.

We do not sell personal data, we do not share it with advertisers, and we do not use it to train machine-learning models.

Google access and refresh tokens are encrypted before they are written to our database, using AES-256-GCM with a key held outside it. Tokens are never shown in our own admin screens, never returned by our API, and never written to a log or an error message.

Access to the production database is limited to the people who operate the service.

Once a night we make a backup copy of the whole database, so that it can be recovered after a failure. Each copy is encrypted with AES-256-GCM before it leaves our hosting provider, under a key kept separately from the copies, and is stored in our own company Google Drive. It is used for nothing but restoring the service.

You can act on your own data at any time, in three ways:

• Click Cancel at the bottom of your own screen: the client page if you are a client, or your introductions page, after signing in, if you are an introducer. That cancels anything not yet sent, revokes our access with Google and deletes the stored credentials on our side, immediately.
• Or revoke our access directly, at myaccount.google.com/permissions. That takes effect immediately and stops us reading or sending anything further. Revoking there does not by itself erase what we already stored.
• Email hello@pleasemeet.app and ask us to delete your data. We will delete your Google tokens and the contact and calendar-derived data associated with you, and confirm when it is done. We aim to do that within 30 days.
• A client's contact fingerprints are deleted automatically: at once when the representative clicks Cancel; as soon as we next find that Google no longer accepts the connection, if access was revoked at Google instead; and when the stored tokens are deleted 30 days after an account is deactivated.

Two things we keep after a deletion request, and why: a record that an introduction was sent to a particular address, so nobody sends that person another one, and the invoice records a business is required to retain. If you would rather we did not keep the do-not-contact record either, say so and we will remove it, but then we have no way to recognise the address again.

The public pages of this site (the home page, the FAQ, this policy and the terms) use Google Analytics to count visits: which pages are opened, roughly where from, and on what kind of device. It sets its own cookies to tell one visit from another. Its advertising features are switched off, and we send it page addresses without anything typed into them. You can block it with Google's opt-out browser add-on or any content blocker, and the site works the same.

Google Analytics is not loaded on any page an introducer or a client uses: not on an introduction link, not on the pages for approving a message or a list, not in the client area. Those pages set only a session cookie needed to keep you signed in and the page working, as does the admin area our own staff sign into. There are no advertising trackers anywhere on this site.

One more: when you introduce someone through a company's shared link without connecting Google, the page remembers the name and email address you typed, in a cookie on that device, for a year, so that the next time you open such a link it does not ask again. “Not you?” on the page removes it. It identifies you to nobody else and opens nothing.

PleaseMeet is a business tool, not intended for anyone under 18, and we do not knowingly collect data from children.

If we change how we handle Google user data, we will update this page and the date at the top of it before the change takes effect.

Questions, deletion requests, and anything else: hello@pleasemeet.app. A person reads that address.

See also our terms of service.