iMessage delivered vs read: what each status tells you

Delivered, read, and replied are different evidence

Delivered is a delivery status. Read is a receipt made available when the recipient’s settings and channel support it. Replied means an incoming response exists. A message can be delivered without a visible read receipt, and it can be read without the recipient answering.

Apple lets people enable read receipts for everyone or individual contacts. Its iPhone guide describes Read as evidence that the message was opened. The absence of that label is not enough to establish whether someone saw a notification, intends to respond, or has blocked you. Avoid treating a missing receipt as a diagnosis of the recipient’s behavior.

• Apple’s read-receipt settings and meaning

Read the label separately from the bubble color

Apple documents blue bubbles for iMessage and green bubbles for RCS or SMS/MMS. RCS can support delivery and read receipts too. Color identifies the messaging service used for that message; it does not tell a business that a lead has responded or that a sale is likely.

• Apple’s iMessage, RCS, and SMS/MMS comparison
• The broader guide to blue text bubbles

For an API, accepted comes before delivery

An HTTP success response can mean the provider accepted work, not that a person received it. In Miss Blue’s live sending contract, 201 means acceptance. Store the returned message identifier, then observe the subsequent status through the documented API and events. Do not mark a CRM task “customer reached” just because the request returned successfully.

Miss Blue documents message.sent, message.delivered, message.failed, and message.received project events. Read receipts are available through message polling. Do not invent a message.read webhook and wait for an event the integration has not promised. Per-message status callbacks are unsigned; the receiving guide explains verification through a message fetch and the signed project-webhook alternative.

• What an accepted Miss Blue send means
• Events, polling, and callback verification

Work through a conversation timeline

Here is a hypothetical sequence. At 09:00, your application submits a scheduling message and stores its provider ID. At 09:01, it records delivery. No read receipt appears. At 09:08, an incoming message says “Friday works.” That reply is direct evidence of engagement even though your system never observed a read receipt.

In another conversation, a read receipt appears at 09:02 but there is no reply by the end of the measurement window. Count the available read evidence separately. Do not silently turn it into a response because the campaign would otherwise look weaker.

Also distinguish a person’s answer from an automated acknowledgment, an opt-out, or an unrelated inbound message. A reply event tells you something arrived; your documented business definition determines whether it was a qualified response.

Define the numerator before naming a response rate

For a hypothetical cohort of 40 unique new leads, suppose 30 have delivered messages, 12 have observed read receipts, and 8 send a reply within seven days of first outreach. The seven-day text reply rate for that cohort is 8 ÷ 40 = 20%. It is not 30 ÷ 40. If you also want replies per delivered lead, label that separate metric and state its denominator.

Exclude duplicate identities and repeated messages from a unique-lead denominator according to your declared identity rules. Keep the first-contact window, observation window, timezone, and handling of late responses visible. If today’s leads have had only ten minutes to answer, comparing them directly with a seven-day-old cohort can mislead.

If a contact metric combines text replies with calls, require evidence of a human answering for the call contribution. A connected line, call duration, or voicemail should not stand in for a person reached. When human-answer evidence is unavailable, preserve that uncertainty instead of labeling every connection as contact.

• Deduplicate leads and preserve identity
• Measure a messaging program’s outcomes

Handle late and repeated evidence without changing history

Store receipt events independently of the current display label, with their provider IDs and timestamps. A duplicate delivered event should not increase your message count. A delayed older status should not erase an already recorded read receipt or incoming reply.

Keep actual reply records even when receipt enrichment is incomplete. Event arrival order and a customer’s actions are separate timelines. If the provider supports message retrieval, use it to reconcile uncertain state; do not submit a second outbound message merely to make the status easier to interpret.

• Process duplicate and out-of-order events
• Test status handling before live traffic

Choose a follow-up from context

A missing read receipt by itself is a poor trigger for an immediate follow-up. Use the customer’s request, the urgency of the matter, your agreed follow-up policy, and current ownership. Someone waiting for an appointment confirmation needs a different response from someone who never asked for another message.

When a person replies, stop any stale reminder about their silence and route the actual question. When they ask for a teammate, pause automated drafts and preserve the context. Better status reporting should help the team answer appropriately, not pressure customers based on a guessed explanation for silence.

• Write a useful next reply
• Hand the conversation to a teammate