The outbound ledger
Outbound is the record of everything your business sends — what is in flight right now, and what already left. It is the proactive mirror of Inbound: same operator seat, opposite direction. The point of it is accountability, not composition. You do not write anything here; you see what went out, on which channel, decided by which head, and whether a person approved it.
It is live today at /outbound, and it is read-only by design.
Where do I find the outbound ledger?
Section titled “Where do I find the outbound ledger?”Open Outbound in the left navigation, in the Operate group, sitting next to Inbound and Approvals — the three operating axes of the day. It loads as one screen with three tabs and a row of counts across the top.
The counts are the headline: how many items are in queue, how many were sent, how many of those were autonomous, and how many were human-approved. Those four numbers are the fastest read of your send posture, and everything below them is a way of drilling into one of them.
What is the difference between the Queue and the Sent tabs?
Section titled “What is the difference between the Queue and the Sent tabs?”The Queue tab holds sends that have not finished, and the Sent tab holds sends that have. That is the only split — it follows the status on each record rather than any judgment about importance.
Queue covers the in-flight states: draft, staged, approved and sending. A staged reply sitting behind an approval appears here, which makes the Queue a useful cross-check against your approval list — if something is staged that you did not expect to be staged, you find it here.
Sent covers the terminal states: sent and failed. Failures are deliberately shown alongside successes rather than hidden.
What does a row tell you?
Section titled “What does a row tell you?”Each row carries the channel, where the send came from, whether a person approved it, what it says, who it went to, and how it ended. The layout is the same in both tabs.
- The channel it went out on, as a pill — email, LinkedIn, whatever the record holds.
- The source — the kind of work that produced it, such as an inbound reply, a sales outreach or a marketing send.
- The trust badge — either Human-approved or Autonomous.
- The subject and a short preview of the body. When neither can be resolved from the underlying record, the subject shows a plain em dash rather than a guess.
- The deciding head, by name, and the recipient — a named contact where one resolves, otherwise an honest recipient count.
- The status, and links: Source back to what produced the send, View to the send’s own detail page, and on queue rows, View approval, which deep-links straight to that item in the approval queue.
The detail page behind View adds the autonomy mode, the created and sent timestamps, a link back to the gating approval, and the per-recipient delivery rows with their individual statuses. When there are no delivery records it says so, rather than showing an empty list you might read as a clean sheet.
What does “Autonomous” mean on a row?
Section titled “What does “Autonomous” mean on a row?”It means no human approver is recorded on that record — nothing more. It is a flag on the data, not a statement that the system decided to send something by itself.
That distinction matters, because the platform’s floor has not moved: autonomy is supervised, proposals do not execute themselves, and anything that sends externally is approved by a person, every time. The live send paths run through an approval and record the approver, which is why they show as Human-approved.
So when you see Autonomous, read it as a question rather than an accusation. The common, benign case is a draft that was staged before anyone approved it — the record exists from the moment the draft does, so it has no approver yet and is labelled accordingly while it waits in the Queue.
The reason the label exists at all is that it is the only instrument that would catch the case that is not benign: a send that left with no person attached to it. Background on the floor itself is in autonomy and the hard floor.
How do you narrow the list down?
Section titled “How do you narrow the list down?”Two filters sit above the tabs: a trust filter and a channel filter, and both apply to whichever tab you are on. They are the whole filtering story on this screen.
Trust is three buttons — All, Autonomous, Human-approved. Channel is a dropdown built from the channels actually present in your data, so it never offers you a channel you have never used, and it does not appear at all until there is something to choose between.
Both filters live in the page URL, so a filtered view is a link you can paste to a colleague and they will see the same thing.
What is not there is worth knowing before you go looking: there is no free-text search, no date range, and no filter by head on this screen. The list reads the most recent records and stops — there is no paging back through history and no export.
What does the Governance tab show?
Section titled “What does the Governance tab show?”The third tab rolls the last 30 days of finished sends into an autonomous-versus-human breakdown, per head and per channel. It answers one question: where is unapproved sending concentrated?
At the top you get the totals and an overall autonomous rate as a percentage. Below that, two tables — By Head and By channel — each row showing how many sends, how many autonomous, how many human, and that group’s own percentage, ordered busiest first. A record with no head or no channel is grouped as Unknown rather than being dropped or attributed to something it does not belong to.
If nothing has been recorded yet, the tab says so in words. It does not render a wall of zeros that could be misread as a clean bill of health.
What can’t you do from here?
Section titled “What can’t you do from here?”Outbound is read-only. There is no send, no cancel, no retry, no resend and no bulk action anywhere on the screen — every row is a record of something that already happened or is already moving.
That is intentional. The decision surface is the approval queue; this is the audit surface. If you want to change an outcome, follow the row’s approval link and act there.
Two more honest limits. The screen shows what was recorded, so a send made before the ledger was switched on for your environment simply is not in it. And a filter refresh that fails leaves the last good data on screen rather than blanking the page — so if the numbers look unchanged after you click a filter, reload before you conclude anything from them.
Next: read how a send comes to exist at all in the inbound → approve → execute loop, or work the other side of it in the inbound triage cockpit.