Connecting a business mailbox to a shared inbox

A shared inbox is only useful if email is in it. Text messages, Instagram and web chat in one place, with email still in somebody's personal Outlook, is not one place. This guide covers what connecting a mailbox actually involves, what it changes in that mailbox, and the two or three mistakes that cause the symptoms people report most: duplicates, silence, and replies that break the thread.

What you need before you start

Four things, all from your mail provider:

| What | Example | Where it comes from | | --- | --- | --- | | Mailbox address | hello@yourshop.com | You already have it | | Password | The mailbox password | Your provider's control panel | | IMAP host | imap.yourprovider.com | Your provider's help page | | SMTP host | smtp.yourprovider.com | The same page |

IMAP is how mail is read. SMTP is how it is sent. They are usually two different hostnames on the same provider, and both are published, not secret.

If the mailbox has two-factor sign-in, the ordinary password will not work and you need an app password: a separate password your provider generates for one application. Google, Microsoft and most others call it that. Generate one, use it here, and revoke it if you ever disconnect.

Use a real mailbox, not a person's

Connect hello@, sales@ or support@, not sarah@. Two reasons, and the second one bites later:

1. A shared inbox is shared. Everything in it is visible to the team, and Sarah's mail is not.
2. When Sarah leaves, her mailbox goes with her, and the history of every customer conversation goes with it.

If customers currently write to a person, set up a real address and forward the person's mail to it for a few months.

What changes in the mailbox, and what does not

This is the part people are right to ask about before connecting a live mailbox.

Nothing is marked as read. The mailbox is opened read only. Somebody working the same mailbox in webmail on their phone will not find that a machine has been through it overnight marking things read. Their own read and unread marks do not decide anything either.

Nothing is deleted or moved. Messages stay exactly where your filters put them.

Attachments stay in the mailbox. The shared inbox records that a message had invoice.pdf, 240 KB attached, so the person answering knows what arrived and where to look, but the file itself is not copied out. That is deliberate: customer attachments are a retention question, and an answer of "we keep a copy of everything forever" is the wrong one to give by accident.

Old mail is not imported. A mailbox connected today starts from today. Connecting a ten-year-old mailbox does not replay ten years of conversations into a shared inbox nobody has read, and does not create a contact record for everybody who ever emailed you. If you want history, it is in the mailbox, where it has always been.

Watch a folder, not everything

This is the single decision that determines whether the shared inbox is pleasant or useless.

Most business mailboxes receive far more machine mail than customer mail: invoices, receipts, alerts, newsletters, your own booking confirmations. If you point the connection at the whole of INBOX, all of it becomes conversations somebody has to close.

Nearly every provider lets you write a filter of the form "if it was sent to sales@, file it in the Sales folder". Write that filter, then point the connection at the Sales folder. One test message tells you whether the filter is right, and it is worth sending before you connect anything.

A common mistake worth naming: filters match To, not From. A filter written against the sender matches the wrong half of every message and quietly files nothing.

Threading, and why the reply address matters

When a reply goes out, it carries the headers that tell the customer's mail client which conversation it belongs to, so it appears under the original in their thread rather than as a new message.

It also carries a reply address, and this is the setting people get wrong. If a customer wrote to sales@ and your reply comes from an address that is not watched, the customer's answer arrives somewhere nothing is looking. The thread simply stops, from your side, for no visible reason.

Set the reply address to the address customers write to. Then the answer comes back into the folder that is being watched, and it lands on the conversation it belongs to.

Duplicates, and why you will not get them

Mail is polled: the mailbox is asked what is new, roughly every minute. There is no webhook for an ordinary IMAP account, so there is nothing to push.

Polling raises an obvious risk. If something fails halfway through, does the same message arrive twice? The order of work is what prevents it: the message is recorded first and the mailbox position is saved second, so a crash between the two costs one repeated check rather than a lost message, and every message is matched on its Message-ID before it is taken in. A message that has already arrived is recognised and skipped.

Machine mail is skipped too: out-of-office replies, bounces and mailing list traffic are logged and ignored rather than recorded as customer messages. An automatic reply recorded as a customer message reopens a closed conversation, and, with automations running, can start a machine answering a machine.

Folders are topics, not piles

Inside the shared inbox, a conversation sits in one of a fixed set of folders: sales, support, billing, legal, security, privacy, abuse, partnerships, or unfiled. The folder is chosen from the address it was sent to and the words in it, so mail to billing@ lands in Billing without anybody sorting it.

Two things about that worth knowing:

• A person can move a conversation, and a later reply on the same thread never moves it back. If somebody decided this is a billing question, it stays a billing question.
• Empty folders are still shown. A Legal folder with nothing in it is information: it tells you nothing is waiting, which is different from not knowing.

Before you tell the team it is live

Run the connection test. It signs in to IMAP and SMTP separately and tells you which one refused, which is the difference between a wrong password and a wrong hostname, and saves a lot of guessing.

Then send one message from an outside address to the address you connected, and watch it appear. Reply from the shared inbox, and check the reply arrives in your own client under the original message. Two minutes, and it tests every part of the path.

Frequently asked questions

Do I have to move my email to Frontiva?

No. The mailbox stays with your provider. Frontiva signs in to it the same way your phone does.

Will my staff still be able to use webmail?

Yes, and nothing they do there is disturbed. The mailbox is read without being changed.

What happens if I change the mailbox password?

Polling stops and the connection reports the sign-in failure rather than failing silently. Update the password in the connection settings and it resumes.

Can the AI answer email?

Not today. Messages arriving by email wait for a person. The AI has no email skills, and an AI answering a channel it was never given rules for is how businesses end up apologising for something they did not say.

How quickly does new mail appear?

Within about a minute of arriving in the folder being watched.

What Frontiva does here

Frontiva connects an ordinary IMAP and SMTP mailbox, watches one folder in it, and turns what arrives into conversations in the same shared inbox as text messages and web chat, with the same contact records, tags, assignment and timeline. Replies go back out through the same mailbox, threaded, from the address the customer wrote to.

It does not host your email, import your history, or store your customers' attachments, and it does not let AI answer on this channel. Those are deliberate limits, and each one is easier to live with than its opposite.