A privacy-first CRM for Gmail: what we don’t read
Most Gmail CRMs want to ingest the mailbox so they can “find deals.” We don’t. You choose the thread. Here is exactly what that means.
A CRM next to Gmail sounds convenient until you read the permission screen. Many tools ask to read or modify mail so they can create contacts, suggest boxes, and log everything. That can be a fair trade if you want automation. It is a bad trade if you only wanted columns and a next step, and your inbox also holds family mail, client secrets, and the password reset from your bank.
KanbanMail is a free Chrome extension and Gmail add-on that puts a Kanban board inside Gmail. The privacy model is the product: we do not scan your mailbox, we do not request gmail.modify, and we do not read the mailbox from our servers. You pick the emails that become deals. The legal detail lives on our privacy policy.
What “privacy-first” means here
It does not mean we store nothing. A board that syncs across devices has to store something. It means the default is opt-in per thread, not ingest then filter.
When you connect Google, we ask for basic profile — email and name — so we can attach the board to you and greet you. That is OAuth for identity, not a Gmail API session on the server. We keep our own session token. We do not keep a Google token around to crawl mail later.
When you add a card, the extension or add-on sends the contact and thread metadata you explicitly attached: sender, subject, a snippet, a thread id, plus the CRM fields you type (company, value, next step, notes, close date). We do not store the full body of the email. The card is a pointer back to Gmail, not a copy of the conversation.
What we don’t do
- We don’t scan the inbox to auto-create opportunities.
- We don’t request
gmail.modify. We don’t label, archive, or send mail as you from our servers. - We don’t call the Gmail API on the server to read the mailbox.
- We don’t sell, rent, or share your board with advertisers.
- We don’t need to “train a model on your mail.” There is no mailbox dump to train on.
The Gmail add-on can see the message you have open — that is how a side panel works — so you can move the deal without leaving the thread. It is not a license to list every other conversation in the account. The Chrome extension’s board is filled by the threads you send to it.
Why we refuse mailbox-wide magic
Auto-detection sounds kind. In practice it creates junk cards, false contacts, and a permission that is hard to unwind. It also trains you to stop thinking. The whole point of a small CRM is that you know which emails are deals. A freelancer’s inbox is not a lead database. It is a life.
Skipping gmail.modify is the same idea. That scope would let an app file and alter mail. We do not need it to draw columns. If a product’s core loop is “we organize Gmail for you,” they will ask for it. Ours is “you put a thread on a card.” Different loop, smaller ask.
There is a cost: we will not auto-file your inbox, we will not sync every sent mail into a timeline, and we will not promise AI that has read everything. If you want that, other Gmail CRMs exist. Choose them with your eyes open.
What you still share, on purpose
Privacy-first is not “nothing leaves the browser.” If you type a note that says the deal is €40,000, that note is stored with the card so the board can load tomorrow. If that is unacceptable, do not put it on any cloud CRM — including ours. Keep it in a local doc.
Same for company names and emails of people you add as contacts on the card. That is customer data you chose to file. Treat KanbanMail like a slim database of the deals you opted in, not like Gmail itself. Our privacy policy lists the controller, what we keep, and how to ask for deletion.
Revoking Google access is always yours: Google’s account permissions page. That stops new sign-in. It does not magically empty our database until you ask us to delete the account; those are different switches. We would rather you know that than hide it behind a slogan.
How this compares to “Gmail CRM” as a category
Tools that log every email into HubSpot or Salesforce need mailbox access. That is the product. Tools that send later or track opens need it too. A Kanban of chosen threads does not. Mixing those jobs on one permission screen is why people search for a lighter Gmail CRM and still grant a heavy scope.
Be fair to the other side: if you want mail merge across a list, or shared boxes, or automatic logging, a privacy-minimal board will feel incomplete. Do not install us as a protest and then demand sequences. Pick the trust model that matches the job.
For a map of those jobs, see how to use Gmail as a CRM. To install the board without a mailbox grant, follow the Chrome walkthrough. The field we care about most on the card is still a written next step — not a hidden copy of the thread.
A practical check before you install anything
- Read the OAuth screen. If it asks to read or modify Gmail and you only wanted a board, stop.
- Ask whether the vendor’s servers need a standing Gmail token. If yes, you are in mailbox-sync land.
- Ask who decides what a deal is. If the answer is “our scanner,” that is a different product than “you click.”
- Put one dummy card of a non-sensitive thread first. See what appears on the card. Then decide.
We built KanbanMail for people who already know the answer to (3): they do. The scanner is them. That is less magic. It is also less of your mail in someone else’s index.
If that is the trade you wanted, install the extension and send one thread to a column. If it is not — if you need the mailbox ingested to feel that the CRM is “working” — you will be happier with a heavier tool, and you should grant it on purpose, not by accident.