MailCircle's idea fits in one line: Start with a chat. See the email. This article walks through what that looks like inside the current interface preview, one step at a time, and marks clearly where the preview stops. Four verbs carry the whole flow: draft, preview, reuse and define.
Before you start: what you are looking at
MailCircle is a concept and interface preview for writing email in a familiar chat or conversation view. The screens come from the Business OS source, so you will see Business OS branding on them. MailCircle is the name for this scoped product direction, not a separately shipped app.
Everything below happens locally in your browser. Nothing is sent anywhere. Keep that in mind as you read, because the whole point of the walk-through is to show you the experience honestly, including its edges.
Step 1: Draft — begin in a conversation, not a blank form
Pick the conversation view that matches the situation
The preview uses a chat-style layout. On the left you find channels, groups and direct-message draft views. There are also threads and mentions views, so a side discussion or a "can you look at this?" note has a natural home.
Imagine a small physiotherapy clinic that needs to confirm a revised appointment time with a patient. The front-desk person opens the direct-message draft view for that patient's conversation rather than a blank email window. The context is right there: this is the person, this is what the message is about.
You can explore these views on the conversations preview.
Open the email draft composer
When the message needs to go out as a proper email, the preview's email draft composer holds the four fields that matter:
- To — who the email is for.
- Cc — anyone who should be kept informed.
- Subject — a short, findable line.
- Body — the message itself, written in the plain, direct way you would write a chat.
The clinic's message might be just three sentences: the new time, a reminder to bring previous reports, and a line on how to ask for a different slot. There is no need to inflate it.
Step 2: Preview — see the email the recipient would read
Writing in a chat-like way is comfortable. Reading it as an email is what keeps you careful. The composer includes a preview, so you can check the message the way the recipient would see it: recipients, subject and body together.
This is the moment to catch the usual slips. Is the time correct? Is the subject specific enough that the patient will find it later? Did you Cc the right colleague?
Then you save the draft. In the current preview, saving stores the draft in your browser's local storage. Come back later on the same browser and it is still there. Open a different browser or device and it is not, because drafts are not synced or backed up.
Notice what the preview does not do here. Send is disabled. That is deliberate. The draft is real. The delivery is not connected.
Step 3: Reuse — keep the wording you write again and again
Quick replies
Most people who send a lot of short emails write the same few sentences repeatedly. "Thank you for your enquiry, sharing the details below." "Your appointment is confirmed for the time mentioned." "Please let us know if you would like to reschedule."
The preview has local quick replies: reusable wording you can save and pull into a draft. They live in the same browser as your drafts. For the clinic, a handful of quick replies could cover confirmations, reschedules and report reminders, so each new email starts from wording the team has already agreed on.
Find drafts again
Drafts are only useful if you can find them. The preview offers draft list, conversation and inbox-style views, with filters for mine, unassigned and all. For teams, there are assignment and quick-reply surfaces in the interface. These are UI only in the preview: they show what a team view could look like, not a live shared inbox with routing.
The email drafts preview shows these views in more detail.
Step 4: Define — decide what live use would need
This last step is the one most product tours skip. After you have drafted, previewed and reused, ask: what would have to be true for this to handle my real email?
For most people, the list looks something like this:
- Mailbox connection. Which account would the email go from? The preview does not connect to Gmail, Outlook or any mailbox.
- Delivery. The preview does not deliver chat messages as email. A live version would need a real, visible send step.
- Replies returning. In the preview, replies do not come back into the chat. For a conversation view to stay true, they would need to.
- Durable storage. Drafts are browser-local today. Live use would need them stored, backed up and available across devices.
- Attachments. Not available in the preview. Many real emails need them.
- Recipient requirements. Whether recipients would need any particular account is not settled. That matters before you plan anything around it.
Writing this list down is useful whether or not you ever use MailCircle. It turns a vague "this looks nice" into a clear scope you can discuss. The evaluation page has more on how to do that.
The edge of today, in one picture
Here is the line between what works now and what remains product direction:
- Works now, locally: conversation views, threads and mentions; the email draft composer with preview; saving drafts in the browser; local quick replies; draft lists and mine/unassigned/all views; team assignment surfaces as UI.
- Product direction, not built: sending, mailbox connection, chat-to-email delivery, replies returning to the chat, attachments, AI writing or rewriting, synced drafts, and a live shared inbox with routing.
We call that line the edge of today, and we would rather you see it clearly than discover it later.
