BlogWe don't want your inbox
4 min readKramova Solutions

We don't want your inbox

A tool asks to connect to your email. The consent screen comes up and it wants to read, send, delete and manage your mail. You wanted it to pick up the three action items a client sent on Tuesday.

Most people click Allow. The alternative is not using the tool, and the work still needs doing.

We decided Servanda would not ask.

The ask is normal, and there are honest reasons for it

It would be easy to treat full inbox access as carelessness. It usually isn't.

Mailbox-wide access is the straightforward engineering path. The tool can search everything, so it finds the commitment buried in a long thread. Nobody has to learn a new habit. The demo works on the first day, with the customer's real mail, which is the only demo anyone finds convincing.

And the vendor generally means it when they say they are only looking for action items. We believe them.

The problem is not intent. It is that the permission does not distinguish. The same scope that lets a tool find Tuesday's client email also covers the thread about someone's salary, the message from your lawyer, and the one where a colleague told you something they would not have put in writing if they had thought about it.

That access is granted once, by one person, in a hurry, on the way to doing something else. Then it stays granted. Nobody revisits it. The person who clicked Allow may have left the company a year later and the permission is still there.

What Servanda does instead

Email capture is forward and CC only. Work arrives because somebody chose to send it — a forward, or your Servanda address on the CC line. Nothing is read that was not deliberately handed over.

Anything wider is a separate decision. Labelled capture, full-inbox auto-detection: these exist, but as an explicit opt-in that somebody turns on knowingly, not a default and not a checkbox buried in onboarding where it will be agreed to without being read.

Detections are suggestions, too. When Servanda thinks an email contains a commitment, that lands in a review lane someone accepts or dismisses. The system does not quietly decide that something is now your job. A task exists because a person said it does.

What this costs us

It would be dishonest to present this as free, so: forward-only is worse in one specific way, and it is not a small way.

It needs a habit. Somebody has to forward the email. A tool with full mailbox access catches the commitment that nobody remembers to forward — the one made in passing, three replies deep, on a thread you were CC'd into and stopped reading. Ours does not. That work stays invisible to us until a human involves us.

We think the trade is still right, and the reason is asymmetry. A missed action item costs one task, and it is recoverable — somebody notices, the work gets done late, you are annoyed for an afternoon. A mailbox-wide permission costs every conversation in the organisation, it is granted once and then forgotten, and it is not recoverable at all. You cannot un-read something.

We would rather lose the occasional task than hold access we cannot justify.

This is not really a decision about email

The same instinct runs through everything we build.

Managers see their direct reports and nothing wider, because the reporting line your organisation already has is the right boundary and we have no business inventing a different one. Data stays inside your tenant, with no sharing across organisations. Every tool connection is granted by the individual who owns it, and can be revoked by them without asking us.

None of those are email decisions. They come from the same question, which we ask about every feature before we build it: not what access would make this easiest to build? but what is the least access that still does the job?

Those two questions produce different products. The first one produces a tool that works brilliantly in the demo and that nobody in security wants to approve. The second produces something slightly less magical that you can actually deploy across an organisation without a difficult conversation.

We would rather build the second one.

Back to that consent screen

The best answer to a permission that makes you uneasy is not a longer privacy policy explaining why it is fine. It is a product that never asks for it.

That is the one we are trying to build. Servanda is where it lives.