ProductInbox & Email
Inbox and Email
One thread list over every mailbox in the workspace, and one send path underneath it. A reply is not just delivered to a folder: it is classified, and the classification decides what the system asks you to do next.
One list, three sources
The inbox is a merge rather than a folder. Mail synced from your connected mailbox, sends made by a sequence or a campaign, and messages handled by the SAGARIS mail platform are three different records in three different places, and the inbox resolves them into one sent-and-received history per thread.
That merge matters because campaign sends never landed in the provider mailbox cache. A view built on the provider sync alone shows you a conversation with half of your own side of it missing. Each row keeps its origin, so you can always tell whether a message came from the provider, a sequence, a campaign or a person typing.
What a reply becomes
Every inbound reply is classified, and each classification carries exactly one required action. This is the part that makes the inbox a queue rather than a pile.
- positive, question
- Book a meeting or reply.
- objection
- Handle the objection.
- not_now, future_interest
- Schedule the follow-up. A later or next-quarter reply is a live re-engage signal on the timeline the message itself gave, not a dead objection.
- competitive_opportunity
- Run the repositioning play. An incumbent mention is an active buyer to win. It is never collapsed into an objection and never suppressed.
- questions
- Draft an answer for review.
- out_of_office
- Pause until they return.
- unsubscribe
- Suppress the contact.
- bounce
- Suppress the bounced address.
- referral
- Route the referral.
- wrong_person
- Update the contact owner.
- neutral
- Draft a reply.
- needs_human
- Review manually. The classifier says so rather than guessing.
Sending, and why volume starts low
A new sending identity does not start at full volume, because a cold mailbox that sends like a warm one is how a domain gets filtered. Volume ramps on a day-indexed curve, and the curve is one committed file that both the mail plane and the application read, so the two cannot disagree about what today's cap is.
- Per mailbox
- Weekly milestones of 5, 10, 20, 30 and 40 sends a day, plateauing there, with a hard ceiling of 50 a day.
- Per domain
- Weekly milestones of 15, 30, 60, 90 and 120 sends a day, with a hard ceiling of 150 a day.
The expansion between milestones is clamped so a cap can never more than double week over week, and a milestone that would dip below the previous one is raised to it rather than allowed to fall.
Unsubscribe and suppression
Commercial mail carries a signed RFC 8058 one-click unsubscribe: the List-Unsubscribe and List-Unsubscribe-Post headers a mailbox provider turns into an unsubscribe button in its own interface.
One provider is an exception and it is deliberate. Microsoft Graph rejects a custom header named List-Unsubscribe outright, and the Outlook send path throws on a rejected request, so setting it would turn every commercial Outlook send into a failure. The Gmail, SMTP and mail-platform routes carry the headers. A missing header on one connected provider costs a little deliverability; a thrown send is an outage.
An unsubscribe is not a flag on a contact row. It is written to a suppression store keyed on the email address or the phone number, so it survives the contact being edited, deleted or re-imported, and it applies across every channel: an opt-out on one channel suppresses the others. A suppressed contact also cannot be advanced through the pipeline, and that hold is not overridable.
AI-drafted mail is marked
A message whose body was drafted by an AI system carries a machine-readable X-AI-Generated header, and the same provenance is stored with the send record rather than only on the wire.
It is marked even when a person reviewed or edited the draft before it went, because AI-drafted and human-reviewed is the true provenance: the marker is a statement of origin, not of who pressed send. This over-discloses on purpose while the scope of the EU AI Act's Article 50(2) marking duty for a human-approval workflow is still an open question.
Behaviour on this page is read from
- src/lib/mailbox/unified-record.ts
- src/lib/unified-inbox.ts
- src/lib/inbound-reply.ts
- mail/mailconfig/mail-system.json
- src/lib/warmup-ramp.ts
- src/lib/mailbox/gmail-api.ts
- src/lib/mailbox/outlook.ts
- src/lib/suppression-store.ts
- src/lib/email/ai-provenance.ts
Was this page helpful?