Shared email support for founders and small teams

A shared support inbox gives teammates one place to read customer emails, see earlier replies, and decide who handles the next response. It helps when you keep having to ask each other who has replied.

We’re building Pipp, and we run into this problem ourselves at Lumenfall. This guide draws on that experience and the choices we’ve made for Pipp’s v1 design. Pipp is at the waitlist stage, so those choices describe what we’re building. The handoff walkthrough below is fictional.

What is a shared support inbox?

The shared address is where customers write. The shared inbox is where your team works on those messages together. A useful setup lets the next person see what the customer asked, what the team already sent, and who owes the next action.

Several kinds of setup can do parts of this job:

The labels overlap. Microsoft describes its shared mailbox as a way for a group to monitor and send email from a common address. Google Groups offers a Collaborative Inbox with conversation assignment and a completion state. You may already have something suitable in your existing email setup. Microsoft shared mailbox documentation, Google Collaborative Inbox documentation.

Check where sent replies end up. Microsoft says outgoing messages are saved in the sender’s Sent Items by default, rather than the shared mailbox’s Sent Items. Configure shared sent items if the rest of the team needs that history, then test with a second teammate. Microsoft shared mailbox settings.

When does a small team need one?

At our other project, Lumenfall, we use a simple Google Groups setup. An email sent to our shared info@ address reaches both founders. We then need a second channel to agree on who is handling which topic.

We keep asking each other, “Did you already reply to X?” or “Shall I answer Y?” Often, we both think the other person has dealt with it. We each have a copy of the email, but we still have to check who is handling it.

That is how we use Google Groups at Lumenfall. Its optional Collaborative Inbox features, linked above, include assignment. Whether you use those features or a dedicated support tool, record who owns a conversation where your teammate can see it.

Look for a coordination problem before shopping for software:

• Two people sometimes answer the same email.
• A message goes unanswered because each person thinks someone else has it.
• Covering for a teammate means asking them to forward the conversation.
• A promised follow-up lives in someone’s memory or private to-do list.
• A developer fixes the problem, but nobody tells the customer.

Email volume alone won’t tell you when to change your setup. Ten messages with complicated handoffs can require more coordination than many straightforward questions handled by one person.

If one person handles support and can find every outstanding promise, keeping the current mailbox may be the right choice. If several people help, try a shared mailbox and an explicit ownership routine first. Consider a dedicated tool when maintaining that routine becomes work of its own.

How to organize replies

Give each conversation one owner

The owner is responsible for the next customer update. They can ask a developer to investigate without handing over that responsibility.

Choose who checks new, unassigned mail during your working hours and who covers when that person is away. Agree when they will check it. The schedule should fit your team; publishing a response-time promise is a separate decision.

Claim a conversation before writing a reply. If ownership changes, record the new owner where both people can see it. Avoid making “I opened the email” mean “I’m handling it.”

In Pipp’s v1 design, reading status is per person, while assignment belongs to the conversation. Replying to an unassigned conversation will assign it to the person who replies. We chose that fallback for missed assignments; agree on ownership before writing when you can.

Separate attention from completion

Use a small set of states with meanings your team agrees on:

We chose these state names for Pipp’s v1 design. You can use the same rules in another tool even if its labels differ.

Put a return time on anything you set aside. “Waiting for engineering” describes a dependency, but it doesn’t tell anyone when to look again. If your tool has no snooze or reminder, put the follow-up in the owner’s existing task system.

We chose “Closed” in Pipp rather than “Resolved.” Moving an email out of an active list does not prove the customer’s problem is fixed. Keep a conversation due for review if you still owe an answer, even after sending an acknowledgement.

Leave a handoff someone can act on

An internal note should explain what is known, what is still uncertain, and the next commitment to the customer. Keep it separate from the outgoing reply and check the composer mode before sending.

A fictional handoff for a small software team:

Customer cannot finish a CSV import. I reproduced the failure using the sample file. Lina is checking the parser. I told the customer we’d update them tomorrow by 14:00, even if the fix isn’t ready. Sam owns that update.

Sam keeps the customer conversation assigned to them. Lina owns the technical investigation in the team’s development tracker. Sam sets a follow-up for before the promised update. This avoids making Lina’s code change the only reminder to write back.

If Sam goes away, the handoff needs a named replacement and that same commitment. “Can someone follow up?” leaves the job unclaimed.

Check the thread before sending

Read the latest customer message and the latest team reply. A teammate’s viewing or typing indicator is useful context, but it is not a guarantee that another reply cannot be sent.

In Pipp’s design, presence helps teammates avoid double replies without locking anyone out of sending. Teammates will also see that a draft exists, while its text stays private to the author.

Check send status too. In Pipp’s specification, “Queued” means the reply is waiting on the device, “Sent” means the email provider accepted it, and “Delivered” requires a delivery event from the provider. These are the status rules in our design.

In whichever tool you use, learn what its status labels actually confirm before telling a customer that a reply has arrived.

Try the routine before changing tools

Use a few fictional emails to test a candidate setup with a teammate:

1. Send a question from an external address. Have one teammate reply and the other find the sent reply. Check the address the customer sees.
2. Assign a question to yourself, ask for internal help, then hand it over. Can the new owner find the promise you made without asking you?
3. Set a conversation aside until a specific time. Check how it returns to attention and who is responsible when it does.
4. Have the customer write again after you close the conversation. Check how the new message becomes visible.
5. Start a reply at the same time as your teammate. Check what each person can see and what the tool actually prevents.

During a short trial, record missed follow-ups and duplicate replies, plus any work you still track elsewhere. Choose based on how well the setup handles your handoffs and follow-up commitments.

Where Pipp fits

We’re building Pipp as a simple shared email inbox for founders and small teams, with AI assistance. We’re designing for teams of one to ten people; that isn’t a published seat limit.

The planned core includes assignment, Open, Later and Closed states, internal notes, and teammate presence. These features are not publicly available yet.

Our v1 scope has limits worth checking before you depend on it. Email is the only v1 channel. Sending from your own domain is on the roadmap; the v1 plan uses a Pipp sender address for customer organizations. Tags and saved replies are outside v1. Desktop and email notifications are also later work, so don’t assume an assignment will email a teammate.

Pipp’s rollout starts with a waitlist, followed by internal dogfooding and invited beta. We haven’t set an invitation date. Keep your current support running while you evaluate it. If you need a working replacement immediately, choose a product whose required features you can test today.

AI assistance is part of the product we’re building. The first beta may open before AI is enabled, and we haven’t verified its availability for external teams. You can follow every step in this guide without AI.

The non-AI core is free forever. AI features are free during beta and paid afterward. We haven’t announced post-beta AI prices.

Join the Pipp waitlist.

About this guide

Written for Pipp, a product of Telesoft AG, a Swiss company. Sources checked on 24 September 2026.

Microsoft and Google’s official documentation supports the mailbox details linked above. Our founder supplied the Lumenfall account from experience with its Google Groups setup. It describes the problem we face, with no claim that Lumenfall has adopted Pipp or measured an improvement. The Pipp examples come from our recorded v1 design decisions. The fictional handoff illustrates the advice and is not a customer story.