OUTBOUND COMMUNICATION
Know which delivery fact the message actually has.
Distinguish queued, sending, sent and supported provider outcomes, instead of treating a saved draft or successful request as proof of delivery.
Saved, queued and delivered are different facts
Follow the delivery state that the configured channel actually reports.
The send action is only one point in the message lifecycle
A customer answer can be prepared, queued, handed to a transport and later receive a delivery outcome. Those stages do not all mean the same thing. Tsumira retains delivery information alongside supported external messages so the team can inspect the actual state. This helps identify failed or bounced communication without promising that every provider exposes every event or that an opened receipt proves understanding.
Separate preparation from transport processing
A draft is not a sent answer. Once the supported send path creates delivery work, queued and sending describe the processing stage, while sent records a later transport result. The configured worker and channel determine whether that work can progress. If a message remains queued, the team should inspect the actual delivery path rather than sending repeated copies merely because the interface accepted the original action.
- Draft separate from outbound work
- Queued and sending stages
- Configured worker and transport
Read provider outcomes where evidence exists
Supported delivery tracking can report delivered, opened or bounced information from configured authenticated provider events. Failed and cancelled states have their own meanings. A delivery receipt describes a channel event, not guaranteed human attention or consent. Where several recipients exist, a summary status can prioritize a failure or bounce; inspect the available recipient context when deciding whether a specific customer has been reached.
- Delivered, opened and bounced outcomes
- Failed and cancelled distinctions
- Recipient-aware interpretation
Check the worker and provider outcome
An opened or delivered event is not proof that a person agreed with the message.
Confirmed address
Keep the message and its follow-up connected
The delivery belongs with its external message, recipient information and originating record context. Incoming replies are another event with their own routing and authority, not a synonym for delivery. Use the visible state to decide whether to correct an address, investigate configuration or prepare a further response. Do not turn a retry or a provider event into an unsupported statement that the customer has read and accepted a proposal.
- Message and record context
- Reply separate from delivery receipt
- Evidence-based follow-up decision
A concrete workflow
Review before sending
Check the intended recipient, content and supported delivery channel.
Read the processing state
Distinguish queued or sending from a completed transport handoff.
Inspect later evidence
Read available provider outcomes and recipient context, particularly when failures appear.
Follow up appropriately
Resolve address or delivery issues and use the business record to decide the next communication.
An illustrative working example
Illustrative workflow: a proposal email needs attention
An account owner sends a reviewed proposal message. Instead of assuming success from the original request, they later inspect its delivery information. A bounce indicates an address problem, so they clarify the customer’s current email before composing another answer. A different message may show delivered without any reply; that result still does not prove that the customer accepted the proposal.
Questions about this topic
Does sent always mean delivered?
No. Transport handoff and later delivery evidence are different stages, and available outcomes depend on the configured channel.
Does an opened receipt prove the customer read and understood the message?
No. It is a recorded channel signal, not proof of human understanding, acceptance or agreement.
Why can the summary show failure with several recipients?
The summary can prioritize failed or bounced outcomes. Inspect the available recipient context before concluding what happened to a particular destination.
Will every provider show every tracking event?
No universal provider coverage is promised. Tracking depends on the supported integration and configured evidence path.
Explore connections around this workflow.
Ideas for intended connections. Check the actual availability, permissions and supported data for each app before using a scenario.
