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?

Book a demo