Send gate

Overview

Dispatch Queue is the approval surface for outbound. Your scheduled runs draft messages; this page is where a human reviews one, sets the channel and recipient, and approves it to dispatch. Every attempt runs through the same deterministic dispatcher the rest of the platform uses, and every attempt, sent or held, is recorded to the sends ledger shown at the bottom of the page.

The send-layer kill-switch

Sending is off by default, per tenant. The toggle at the top of the page is the kill-switch: with it off, approving a draft records the attempt and reports it as held, but nothing is sent. Turn it on only when you are ready to send for real. This means you can wire up and review the whole flow, approvals included, before a single message leaves, and turn everything off instantly if something looks wrong.

Approving a draft

Each draft carries content, not a destination, so you choose the channel (email or LinkedIn) and enter the recipient when you approve it. The dispatcher gates the send in order: approval, then the send-layer toggle, then the channel configuration, then the send. The result is shown inline on the draft, one of sent, held (send layer off), held (provider not configured), or an error, so you always know exactly what happened.

A channel with no way to deliver at all, such as LinkedIn or an email address with no mailbox connected behind it, is refused at the click rather than accepted and then held. The message names the reason and the one setup step that fixes it (connect a mailbox, or copy the draft yourself for LinkedIn), and the refused attempt is still written to the ledger so it is not missing from the history.

Approving the same draft twice, from a double click or a second tab, does not send twice. The first approval takes the draft, and a second one that arrives while the first is still in flight is told to check the Sent folder rather than being sent again; once the first has an outcome, the second approval is shown that same outcome and says plainly that nothing went out a second time.

Running an Instantly campaign action

The Instantly panel uses the campaign and sending account saved on Connections. Enrollment starts from one queued draft and one recipient. The first click stores an exact review receipt. The second click executes only that saved receipt. Editing the draft or changing the connection invalidates the review.

Pause and resume apply only to the saved campaign. Removing a recipient requires the request receipt from an accepted enrollment and a separate confirmation. If Instantly times out or returns an uncertain result, the panel holds every equivalent request instead of trying it again. Instantly remains a preview connection until these operations pass a controlled live run.

Honest about what is live

Email goes out through the Google account you connected under Settings, Connections. Your address is the From line, your domain carries the reputation, and the reply lands in your own thread. That path is capped at 200 messages an hour per account, which is far above working a queue by hand and far below a script.

The cold email vendor, Instantly, is a separate motion and stays gated until it is verified against a real account. Instantly runs a campaign whose content and sending accounts live in Instantly. It does not take the body of a draft from this queue as a raw send. The execution contract therefore requires the exact campaign, sending account, recipient, saved approval revision and request ID before it can create an enrollment. Pause and resume act on that campaign. Stopping one recipient requires the Instantly lead reference and removes that lead from the campaign. Until a controlled account run proves that adapter, this queue reports the action as held.

Why LinkedIn is held

Approving a draft on the LinkedIn channel reports it as held, and it will keep doing that. The reason is not that we have not got round to it.

The LinkedIn tool we route through is a campaign platform, and its API has no endpoint that sends a message. You add a person to a campaign that is already running, and that campaign's own sequence, written inside their tool, does the outreach. There is no way to hand it the words drafted here and have those words go out.

So enrolling somebody there and reporting your draft as sent would tell you a message went out that never did, while a different message reached your prospect. The held state is the honest one, and the reason shown on the draft says exactly this.

The obvious workaround is a hosted LinkedIn login that drives your account directly. We are not building that. It is automation against a platform whose terms forbid it, and it is not a risk to take on your behalf.

Exporting as ad copy

The queue can hand you your approved drafts as a CSV in the shape an ad platform's bulk importer wants: Google responsive search ads, LinkedIn single-image ads, or Meta feed ads. Pick the platform and download it.

It touches no ad account. We do not create a campaign, set a budget or spend anything. You get a file and you upload it, which keeps the approval gate the shape it has everywhere else here: a person is still the last step before words reach a stranger.

Nothing is rewritten. The headline is your draft's subject and the description is its first sentence, unaltered. An exporter that tightened a headline to make it fit would be putting words you never read in front of your buyer, on the way out of the queue that exists to stop exactly that.

Copy that is too long is flagged, not cut. Every row carries a status in the first column and, when something is over, how many characters over it is. A headline sliced mid-word still gets served, so silent truncation would ship the defect rather than report it. Fix the flagged rows before you upload, or upload them and let the platform decide: Google refuses an over-length headline at import, while LinkedIn and Meta accept it and clip it in the feed, which is worse because it looks right in the editor.

Only drafts still in the queue are exported. Something you dismissed is not copy you approved, and putting it into an ad account would be the same mistake as sending it.

Character counts are approximate. Platforms count emoji and non-Latin script differently from each other, and the file says so.

What came back

An hour after a send, and hourly after that for thirty days, the platform reads the thread your message landed in and records what arrived. The Reply column on the ledger carries one of four states: no reply yet, replied, auto-reply, or bounced.

Those last three are kept apart on purpose. An out-of-office and a dead address are not answers, and folding them into one reply count is how a reply rate stops describing anything. A reply also goes onto the event bus, so the rest of the platform reacts to it the same way it reacts to a reply that arrived through a connected CRM.

An auto-reply does not close a thread out the way a real reply or a bounce does. It moves the next touch instead: the sweep reads a return date out of the message when it gives one ("back on the 28th") and waits until then, or waits a week when it does not, and the ledger row shows the new date next to the auto-reply chip. The thread is checked again the next day rather than every hour, so the same away message is not re-read thirty times before the person is back. A reply from the person, on the same thread, after the away message still ends the wait and reads as a reply.

Only threads from your own mailbox are swept, because that is the mail we can see. Nothing is read but the sender, the subject, the date and the auto-reply headers, plus the one-line preview Gmail already returns. The message body is never fetched. If your mailbox is disconnected the sweep stops and the rows keep their last state, rather than being recorded as unanswered: not being able to look is not the same as nobody writing back.

The CRM sees the send

Once a provider confirms a message went out, the queue logs it to whichever CRM you have connected (Salesforce, HubSpot, Pipedrive or Outreach, in that order, first connected wins) as a completed activity: the recipient, the subject, when it sent, and the account it was about. The Role and CRM columns on the ledger show which skill drafted the send and whether the log landed.

This never blocks or repeats the send. A CRM that is slow, unreachable, or not connected costs the ledger a "not logged" row, not the send itself, and a retried approval that finds the send already logged for that provider's message id does not log it a second time.

When a send's outcome is unknown

If the connection drops between the provider accepting a message and the queue hearing back, the draft is left in a state that refuses a second approval rather than guessing: a retry would risk a second email exactly when honesty matters most. Check the Sent folder of the connected mailbox for that recipient. If the message is there, the send happened and no action is needed; the ledger will show it once the record catches up. If it is not there, this is a rare case a support request resolves, not a self-serve retry, because clearing it today means removing the stuck claim record directly.

When the send layer cannot be read

The send layer is a kill switch, so the page never guesses at it. If the setting cannot be read, the panel says the state is unknown and the button offers to retry, rather than showing "Off, nothing sends". That is a claim about whether mail can leave your account, and a failed request is not evidence for it.

A toggle or daily-cap save that fails tells you so and names what is still in force, so a click that did not land never looks like one that did.

What is not shown

The design mockup drew a fuller "outbound execution" cockpit with active-campaign analytics (sends, opens, replies, deliverability), inbox rotation, and sequence detail. Those are omitted here because this surface is the dispatch approval queue, and we do not track open, reply, or deliverability metrics or run inbox rotation on it, so showing them would mean inventing the numbers. The page shows the honest core: the send-layer state, the drafts awaiting approval, and the real sends ledger.