Privacy

Two different groups, with different relationships to Bonjo.

Account holders are clients and callers who signed up. Prospects are the people a caller contacts on a client's behalf. Prospects did not sign up for anything, and this policy is mostly about them.

Your name, email address and password, which is stored only as a one-way hash and cannot be read by anyone including us.

For clients: your company details, any sales material you upload, the bounties you post and the meetings delivered to you.

For callers: your profile, the bounties you work, the meetings you deliver and what you have been paid.

For both: the messages you write in Messages and the chat room, and when you last read each conversation.

You can download your account at any time: Settings, then Download my data. The file holds your account, your company or caller profile, your claims and your payouts. For a copy of anything else Bonjo holds about you, your messages included, email hello@bonjo.io.

Name, job title, company, and where provided an email address, phone number or LinkedIn profile. This comes from a list a client uploaded, from contacts or mobile numbers Bonjo found for a client, from a caller recording a meeting they booked, or from a booking made on a client's Cal.com page, as described below.

Bonjo processes this to run the marketplace: to prevent the same person being contacted twice, to enforce suppression lists, and to record what a client paid for.

Where a client uploads a list, the client is responsible for having the right to share it.

A client can connect an account executive's Google Calendar or Microsoft 365 calendar to Bonjo so that a caller can book a meeting straight into it. On Google, Bonjo asks to see and edit events on calendars that person owns and to read their calendar settings, such as the timezone; on Microsoft, to read and write that person's calendar. Both permissions would allow more than Bonjo does, so this section sets out exactly what Bonjo reads and writes.

To work out which times are open in the coming days, Bonjo asks the calendar for each event's start, end, whether it shows as busy, and whether the account executive declined it. It never requests the titles, descriptions, locations or attendee lists of the account executive's own events, and it does not copy the calendar into Bonjo. Those times are used for the one page they are shown on and are not stored.

For a meeting Bonjo itself booked, Bonjo reads that one event back to see whether the prospect accepted, declined or did not answer, and whether it was cancelled or moved. It reads this after the caller marks the meeting held, when a problem is reported, and once after the meeting time, and keeps the answer with the meeting record as evidence.

Bonjo writes to the calendar only when a caller books a meeting: one event, on the account executive's calendar, with the prospect, the account executive and (if they chose to attend) the caller as guests, and a Meet or Teams link. That event is the meeting the client paid for. Bonjo keeps a record of it (who was booked, when, and the link) because it is the evidence behind the payment.

The access tokens Google or Microsoft issue are encrypted at rest and are never sent to a browser or shared with anyone, including callers. Bonjo does not sell calendar data, use it for advertising, or share it with third parties. Bonjo's optional AI features never receive any calendar data: open times, event details and the timezone are read only by Bonjo's own code and are never sent to any AI or machine-learning service. Google user data is handled in line with the Google API Services User Data Policy, including its Limited Use requirements, and is never used to develop, improve or train any AI or machine-learning model.

The client can disconnect a calendar at any time from Account executives. Disconnecting deletes the stored tokens immediately; events already created stay on the calendar, because they are the client's own meetings. Access can also be revoked from the Google or Microsoft account's security settings, which has the same effect.

A client can connect a company mailbox so that the follow-up emails a caller writes for their prospects go out from the client's own address. On Microsoft 365 this uses a Microsoft sign-in that lets Bonjo send mail as that account and read its basic profile (name and address); it cannot read the mailbox. On Google Workspace the client creates an app password in their Google account and gives it to Bonjo, and Bonjo uses it only to send mail through Google's outgoing mail server. With any other email provider, the client gives Bonjo the provider's outgoing mail server and a login for it (a username and a password), and Bonjo uses them only to send mail through that server. Bonjo never uses a mailbox connection to read, search or delete mail.

Every email sent this way is written by the caller from the client's own template, goes to one prospect, and has the account executive as the reply-to address. Bonjo keeps a record of each one (who it went to, the subject, the body, the address it left from and whether it sent), which the client sees on their Emails page. Sending is capped per day.

Mailbox credentials are encrypted at rest and never sent to a browser or shared with callers. The client can disconnect the mailbox at any time from the Emails page or Settings, which deletes the stored credential immediately; an app password can also be revoked in the Google account, Microsoft access in the Microsoft account's security settings, and another provider's login by changing its password there.

A client whose account executive takes meetings on a Cal.com booking page can turn on “Bookings log themselves”. Cal.com then sends Bonjo each booking made, moved or cancelled on that page, by webhook: the attendee's name, email address and time zone, the meeting's time, and the answers given on the booking form. Bonjo keeps those with a record of the booking and logs the meeting from them, as if the caller who booked it had noted it.

A booking Bonjo cannot match to a caller is shown to Bonjo's admins, and its attendee's name and time to the callers working that account executive's bounties, so that the caller who booked it can claim it. The client can turn the webhook off at any time from their Team page.

Clients and callers can write to each other inside Bonjo. Messages is a conversation between a client's team and one caller who has taken one of the client's bounties, started by the first message either side sends. The chat room is one room for each client company, shared by the client's team, the callers working its live bounties at the time, and Bonjo.

Bonjo stores every message, who wrote it and when, and when each reader last read the conversation, to count what is unread. A conversation in Messages is read by everyone on the client's team, by the caller, and by Bonjo's admins, who can also write in it as Bonjo. A chat room is read by the client's team, by Bonjo, and by the callers in it at the time, who read its whole history while they are in it and lose access when their work for that client ends. A caller appears to clients and to other callers as a first name and last initial, and a client's people appear to callers as a first name and the company. Messages stay in Bonjo: none is sent by email or to Slack.

Before a message with an email address or a phone number in it goes, the writer is asked to keep the conversation on Bonjo. If they send it anyway, Bonjo flags the message for its admins to review. The people in the conversation never see the flag.

Messages are kept as the record of the work, because they can be the evidence when a meeting is disputed. A message that names a prospect, by email address, phone number, LinkedIn profile or full name, is replaced with “Removed at the person's request.” when that prospect's data is deleted, and when the meeting record or call log that names them reaches the end of its retention period, below. The message itself stays, in that form.

Callers use their own dialling software and can upload its call log against a bounty. That log holds the number dialled, when, what the outcome was, and where their tool provides them, a link to a recording of the call and notes such as the objections raised.

For a meeting they booked, a caller can also attach the recording itself, as an audio file or a link, so the client can hear the call. An attached file is stored by Bonjo; a link points to the caller's own system, where the audio stays. We can remove a link but cannot delete audio held elsewhere. If you want that audio deleted, tell us and we will pass the request to the caller, who is the party that holds it.

A client is shown the calls with the person they were introduced to, and not the caller's wider dial log, which contains other companies' prospects. Phone numbers are partly masked in that view.

Recording a call is subject to the law where the parties are, and in some places every party must consent. Callers are independent contractors and are responsible for recording lawfully; Bonjo does not make the recording and does not operate the dialler.

Uploaded contact lists are deleted 180 days after the bounties using them close.

Meeting records are kept for 730 days because they are the evidence behind a payment, then the prospect's identity is stripped and only the anonymised financial record remains.

Imported call logs are kept on the same clock and stripped the same way: after 730 days the number, the name and the recording link are removed, and what remains is that a call happened and how it went.

Messages and chat room posts are kept as the record of the work. Any that name the prospect of a meeting record or a call log are scrubbed of them on that record's clock, just before it is stripped.

Cal.com booking records, with the attendee's name, email address and booking-form answers, are kept with the client's account. They are not yet removed on a clock of their own, or when a prospect's other data is deleted.

Suppression records are kept indefinitely, and deliberately so. They are the only way to honour a request never to be contacted again: deleting the record would mean the next upload could add that person back.

You can ask what Bonjo holds about you, ask for it to be deleted, or ask never to be contacted again. Email hello@bonjo.io.

When we delete a prospect's data, we remove them from uploaded lists and strip their name and contact details from meeting records, from any imported call log, including the link to any recording, and from any message or chat room post that names them. The records and messages themselves are kept in anonymised form, because they are the evidence behind a payment already made.

We also add them to every suppression list, which is what stops a future upload putting them back in front of a caller.

Cal.com booking records are not yet stripped this way: the attendee's name, email address and booking-form answers stay on the record of the booking.

Bonjo uses a small set of service providers to operate, and each receives only what it needs for its part: Stripe processes payments and caller payouts and holds all card and bank details; Resend sends Bonjo's emails and, where a client verified a sending domain, their follow-up emails; Neon hosts the database; Vercel hosts the application; Cloudflare stores uploaded documents, photos and recordings.

Google and Microsoft receive requests only when a client connects a calendar or a mailbox there, as described above. Cal.com receives requests only when a client gives Bonjo a Cal.com API key, which Bonjo uses to read the next open times on that booking page and to register the webhook that sends Bonjo its bookings. Cal.com sends Bonjo booking details only when the client turns that webhook on, as described above.

Slack receives booking updates: Bonjo's own internal channel gets each booked meeting's prospect name, title and company, the meeting time, the caller, a line about the call (its length and the objections raised) and the caller's pay, and a channel for callers gets only the title and company of a colleague's booking and, once that meeting is released, what the colleague earned. A client who connects their own Slack workspace receives their own bookings there with the same details and no prices. When we delete a prospect's data, Bonjo rewrites its Slack messages about them to remove their name.

Where our AI features are enabled, Anthropic (the Claude API) receives what those features need: the company profile, website and sales material a client provides, to research the company, write the call script and suggest who to meet, and the descriptions of target prospects a client types, to turn them into titles, seniority and company size. Under Anthropic's commercial API terms this content is not used to train Anthropic's models. The AI features never receive any data from a connected calendar or mailbox.

Call recordings sit with the caller's own dialling tool, not with Bonjo. They hold it because the caller made the call; Bonjo only links to it.

Bonjo does not sell personal data.