CEDX Mail · Workplace
Support@, sales@, billing@, hello@ and noreply@ land in one place — with a needs-reply queue instead of an unread count, a wait time on every thread, and a delivery score on every sending domain.
The most honest numbers on this page are the ones the software prints on itself: 77 threads need reply, median wait 4.1 hours. A mailbox that can see its own backlog is one you can manage.
Runs on demo data. The sending domains on screen are the demo fleet's, not yours.
What it is
The inbox opens on the 77 threads that owe someone an answer, sorted so the worst wait — 17.4 hours on a billing thread — sits at the top. Every row carries its mailbox, priority, wait and assignee, so triage is a sort, not a scroll.
Labels are inventory, not decoration: 20 built-in system labels and 28 the team defined, each with its thread count, unread count and health. Q3 nurture holds 210 threads; the 13 low-activity labels are flagged stale so the taxonomy gets pruned instead of fossilising.
320 threads across inbox, sent, archive, spam and starred. Each row shows message count, folder, mailbox and who has it — so “where did that customer thread go” is a filter away, not a forward-and-pray.
Product tour
Not a mockup and not a concept deck. This is what opens at /app/mail.
01 — Overview
Unread 104, needs reply 77, queue depth 78 failed-and-retry, delivery score 63, median wait 4.1h. The alerts arrive root-caused: one sending domain at score 5 with bounce 6.2% and an IP reputation of 48, 27 outbound messages needing retry, a nurture sequence losing people at step 3.
02 — Inbox
The needs-reply tab is the work: 77 inbound threads with the clock running, worst first. Password-reset spam after a deploy, a refund inquiry after a migration, a VIP demo request — each with its mailbox, priority and an assignee already attached.
03 — Labels
48 labels with threads, unread and a health column per row. Newsletters and Lifecycle-C carry 88 threads apiece and are marked stale — the list tells you which labels still earn their place.
04 — Threads
All 320 threads in one table — including the ones in spam and the ones someone starred and forgot. Message counts show which threads are growing; the VIP flag shows which ones matter.
Who runs it
Roles, not references. We have no named customers yet, so nobody in these photographs is quoted, credited or claimed as one.
Lives in the needs-reply queue. Owns the median wait and the 17-hour tail, and assigns before the morning standup instead of after it.
needs reply · 77
Watches the per-domain scores and the send queue. When a domain drops to 5 with bounce at 6.2%, that is their page, not a surprise in a weekly report.
delivery score · 63
Works sales@ and the VIP flags. The demo request waiting 15 hours is pipeline, and the queue treats it that way.
VIP threads · 90The shape of it
Every figure below is legible in the captures above. Nothing here is a projection of your estate — it is the state of the demo data.
How it runs
Mail arrives into one of the five shared boxes and joins the needs-reply queue with a mailbox, a priority and a running clock.
Triage works the queue worst-first. Every thread gets an assignee while the wait is still in hours, not days.
Replies go out through the same record. The send queue watches failures and retries — 27 outbound needed retry in the current view.
The overview scores the whole fleet: delivery by domain, waits by mailbox, and root-caused alerts when any of it moves the wrong way.
One record
A mail thread is not an island. It is the same customer, the same conversation and the same identity the rest of the estate works from.
The support@ queue in these captures is the same work Desk drives: refunds, password resets, portal errors — one conversation, two doors.
CEDX ChatWhen a thread stops being a thread, it escalates to a channel without losing the record of how it started.
CEDX CalendarThe demo requests sitting in the inbox land as events, with the organiser's load score already known.
CEDX CopilotAsk AI — ⌘J — sits on every one of these screens, grounded in the same record.
Limits
Finding this out on the third call is worse for you than reading it here, and worse for us.
Start
Open it right now
Your mailboxes, your domains
Mail with the rest of it
Questions
Yes. Every screenshot is a capture of the running build and you can open the same build at /app/mail. It runs on demo data — the threads, waits and scores belong to a demo workspace, not to a customer.
Forwarding gives everyone a copy and nobody a queue. Here the needs-reply tab owns the work: 77 threads with waits, priorities and assignees, so two people never answer the same customer and nobody's thread waits 17 hours unseen.
It is a volume-weighted score across the sending domains in the fleet — 63 in the demo view, with the lowest domains tabled underneath: score, bounce rate and, in the alert, the IP reputation behind it. It exists so a deliverability problem is a page you open, not a rumour.
Yes, per box and per label. The inbox breaks needs-reply, unread and starred into tabs per mailbox, and the labels view carries thread and unread counts per label — Support shows 128 threads with 34 unread in the current view.
They stay in the ledger. The threads view holds all 320 — spam, starred, archived and sent included — with message counts and folders, so nothing disappears into someone's personal archive.
No certification has been issued. What we can evidence about hosting, encryption, tenant isolation and production access is written up on the security page.
Live build, demo data, no card. Then check what your own support@ wait time looked like this morning.