Knowledge · Business Operations

    Message Delivery States Explained

    The seven distinct states between writing a message and getting a reply — and why 'sent' proves far less than most teams assume.

    What does 'delivered' actually mean for a text or email?

    Delivered means the carrier or provider accepted responsibility for handing the message to the recipient's device or mailbox. It does not mean a person saw it, understood it, or will reply. Composed, attempted, accepted, delivered, received, read and answered are seven different facts.

    Key takeaways

    • Provider acceptance and delivery confirmation are different events.
    • Email offers no reliable read confirmation; treat any read claim with suspicion.
    • A failed text needs an alternative channel, not a repeat of the same send.
    • Automatic retry is a specific capability — verify it before relying on it.
    • 'No reply' is a state you should be able to see and act on.

    The seven states, in order

    • Composed: the message exists in your system but has not left it.
    • Attempted: your system handed it to a provider.
    • Accepted: the provider queued it and returned an identifier.
    • Delivered: the carrier or mailbox provider confirmed handoff.
    • Received: it is physically on the recipient's device or in their mailbox.
    • Read: a human looked at it — usually unverifiable.
    • Answered: a reply came back, which is the only state that proves anything.

    Why teams over-trust 'sent'

    Most interfaces collapse the first three states into a single tick, so a message that a provider accepted but a carrier later rejected can look identical to one that arrived. The consequence is a team that says 'we texted them' when the customer genuinely never received anything.

    Email is worse because the failure is silent. A provider can accept and deliver an email that a spam filter then hides. There is no state in the send log for 'delivered but never seen'.

    What to do with a failure

    Distinguish permanent from temporary. A wrong number, a disconnected line or a hard bounce is permanent — the record needs fixing, not another send. Temporary failures are worth one retry, then a channel change.

    The reliable escalation is always the same: if the written channel fails twice, call. A phone call resolves in two minutes what four unanswered texts will not resolve in a week.

    Where URBLD fits

    For outbound text, URBLD records the carrier status reported back by the telephony provider — queued, sent, delivered, undelivered and failed — against the message log, and feeds delivery successes and failures into number health tracking. Read status is not reported by SMS, and URBLD does not claim it. Failed sends are surfaced rather than retried automatically.

    Principles reinforced

    This page rests on the following foundational ideas.

    FAQ

    Frequently Asked Questions

    Straight answers about how URBLD runs the business end-to-end.

    More in Business Operations

    The daily mechanics: workflows, checklists, scheduling and handoffs.

    Browse Business Operations
    Share this page