Who is asking, and about what

A shared inbox knows the address, not the customer

Every collaborative inbox can tell you a message came from jane@example.com. That is the sender. It is not the same as knowing who is asking.

On a support desk those are different facts, and the second one is the one that matters. Three threads from three addresses at the same company are one customer having one bad week. A shared inbox shows them as three unrelated rows, sorted by the only thing it understands, which is time.

So the desk keeps that knowledge somewhere else. In somebody's head, usually. Sometimes in a spreadsheet, sometimes in a subject-line convention that half the team remembers to use.

Helpdesk mode is Parly learning the two facts the desk was holding for it: who the thread is from, and what it is about.

Company, detected rather than typed

When mail arrives, Parly looks at the sender's domain and works out which customer company it belongs to. jane@example.com and dev@example.co.uk land on the same company record, because a company can own more than one domain and usually does.

Nobody tags anything. The moment mail lands it already carries a company, with the customer's own logo next to it, so the inbox reads as a list of customers rather than a list of addresses.

Three things about how that works are worth saying out loud.

It happens on the way in, not in the interface. Detection sits in the one function every inbound message passes through, so mail from the Resend webhook, the live-chat widget and IMAP sync all get it without three separate implementations. It is wrapped so that a failure to identify a company never costs the message. An unlabelled thread is a small problem. A lost one is not.

The logo comes from the customer's own site. Not from a data broker and not from an enrichment API. Parly fetches the favicon from the domain the mail came from, and falls back to a monogram in a stable colour when there isn't one. The fetch only follows public names, re-validates every redirect hop, times out at six seconds and caps at 256 KB, because the address that decides what gets fetched was written by a stranger.

A company grants nothing. It is a label for triage and display, not a permission. Parly already has a concept that controls who may see which conversations, and this is deliberately not that. Keeping the two apart means a mislabelled thread is a cosmetic mistake instead of a disclosure.

Someone has to say which domain is yours

The first version of detection got this wrong in an obvious way. A colleague wrote in, and Parly created a customer company for the team's own domain.

The fix is not cleverer inference. It cannot be inferred at all. On plenty of desks the team and the people raising tickets share a domain, so the same address is an agent in one thread and a customer in the next. No amount of looking at the mail resolves that.

So the tenant declares it. Internal domains are a plain statement of who counts as "us". Mail from them never opens a customer company, and no company may claim them. Domains you have already registered for sending count automatically, declaring a domain covers its subdomains, and the admin page offers your team's own sign-in domains as one-click adds. Free consumer providers resolve to nothing either, because gmail.com is not a customer.

Categories the mailbox defines for itself

The second fact is what the thread is about, and there is no correct universal list. A desk handling shipping questions and a desk handling API bugs do not sort mail into the same buckets.

Switching helpdesk mode on seeds four categories to start from. They are a seed and nothing more: rename them, reorder them, delete them, add your own, per mailbox, so two desks in the same company can diverge as soon as they need to.

There is an AI suggestion in the thread panel. It may only pick a name from that mailbox's own list, or answer that none of them fit. And it suggests. It never writes.

That last part was a decision, not an oversight. An unreviewed label on every thread is worse than no label at all, because a filter you cannot trust is a filter you stop using, and then you are back to reading everything.

What it looks like at the desk

When a helpdesk mailbox is in scope, the inbox grows a Company column and a Category column, and a filter for each. It also drops the Mailbox column when there is only one mailbox in view, because a column with one value in every row is furniture.

Hovering a row reveals the newest message in the thread. Not the raw body: Parly cuts the quoted history first, including Outlook's bare From: and Van: header blocks and the forwarded chains under them, so the preview is what this person just wrote rather than the fourteenth copy of the original question.

From inside a thread you can create a company on the spot, prefilled from the sender. On the accounts page you rename companies, attach their other domains, upload a logo when the fetched one is ugly, and forget one entirely.

Off by default

Every mailbox starts with helpdesk mode off, and nothing about a plain shared inbox changes until an admin turns it on for one specific mailbox. A team that came to Parly for a shared inbox and a Slack channel never meets the word category.

That is the general shape of the thing. Parly is a collaborative inbox first. A help desk is one way to run an inbox, not the only way, and the software should not decide which one you are.