WhatsApp Business

Sent, delivered, read: what a WhatsApp status proves when a client says the notice never arrived

Two grey ticks are not proof of receipt. What sent, delivered, read and failed mean on the WhatsApp Business Platform, and what a broker should file instead.

Published on 7 min readFCB.ai
Contents
  1. What the four statuses actually mean
  2. Why the absence of a read receipt proves nothing
  3. The rules ask about the medium, not about the ticks
  4. The record that survives a complaint
  5. What to do when a message stays on one tick
  6. Frequently asked questions

The complaint lands eleven months after the event and says one thing: I never received the renewal notice, and I found out I was uninsured when I tried to claim. The account handler opens the thread, sees two grey ticks against the message, screenshots it, and considers the matter closed. It is not. A screenshot of two ticks answers a question nobody asked, and the questions an adjudicator does ask — what exactly was sent, to which number, when, and on what medium — are usually the ones the brokerage cannot answer from a phone.

Delivery statuses are useful. They are also routinely over-read. Here is what each one means on the WhatsApp Business Platform, what it cannot tell you, and what belongs in the file instead.

What the four statuses actually mean

The first thing to unlearn is the API response. Meta's send-messages documentation is explicit that a successful response "only indicates that the API successfully accepted your request — it does not indicate successful delivery of your message". Delivery is reported afterwards, by webhook, as a sequence of status updates. Their definitions in Meta's status webhook reference are narrower than the words suggest:

StatusMeta's definitionWhat it does not tell you
sentThe message was successfully sent from Meta's serversNothing about the client's phone. A message can sit at "sent" for days.
deliveredThe message was successfully delivered to the user's deviceWho holds the device, whether the number still belongs to your client, whether anyone opened it.
readThe message was displayed in an open chat thread on the user's deviceWhether a human read it, understood it, or was even the policyholder.
failedFailure to send or deliver the message to the user's deviceWhy, unless you keep the error code that came with it.

Two mechanics matter for the timeline you will one day have to explain. Undelivered messages are retried for a time-to-live period — 30 days for everything except authentication templates — so a "delivered" webhook can arrive long after the send, which is no use at all if the deadline was the renewal date. And a status is only considered read once it has been delivered, so where a client is already sitting in the chat when the message lands, you may see the read status without a separate delivered event. Statuses can also arrive out of the order you expect; what a broker should record is each transition with its own timestamp, not a single current state.

Why the absence of a read receipt proves nothing

WhatsApp users can switch read receipts off in their privacy settings, in which case no read receipt is generated for one-to-one chats — including chats with a business. The setting has known exceptions: read receipts are always sent in group chats, and turning them off does not stop play receipts for voice messages. A brokerage that treats "no blue ticks" as evidence the client ignored the message is reading a privacy preference as behaviour.

The reverse inference is just as weak. A read status means the message was displayed in an open thread on a device — a screen unlocking in a pocket, a spouse checking the phone, a WhatsApp Web session left open on a shared laptop. For a firm that has to think about the Consumer Duty's consumer understanding outcome, "displayed" is a long way from "understood". The only reliable signal of engagement is a reply that answers the question you asked, which is why renewal messages that end in a question or a quick-reply button generate better evidence than the ones that end in a full stop.

The rules ask about the medium, not about the ticks

None of this is what the Handbook is measuring. ICOBS 4.1A requires information to be communicated in a clear and accurate manner and provided on paper, on another durable medium, or via a website, with a paper copy available on request and free of charge; the choice of a non-paper medium has to be an active and informed one, and firms are told not to treat a pre-ticked box as consent. The durable medium test is about storage and unchanged reproduction — which a message a sender can delete for everyone does not obviously satisfy, but an attached PDF that the client can save does. The nuances are set out in our definition of durable medium.

The practical consequence for renewals is a two-part pattern. Send the regulated document — the renewal notice with the disclosures required by ICOBS 6.5, the statement of demands and needs, the policy summary — as a file on a medium the client can keep, and use the chat as the nudge that gets it read. Structuring that message is the subject of our renewal notice template. What you must never do is rely on chat alone for something the rules require in a durable medium, then argue about ticks.

The record that survives a complaint

An adjudicator or a compliance reviewer is looking for a reconstruction, not a screenshot. Keep, per message:

  1. The message identifier issued when the message was accepted, so the send and its statuses can be tied together.
  2. The exact content as sent — the template name and version, and the values put into each variable, not the template with placeholders.
  3. The recipient number, plus the record showing that the client gave that number and had opted in to be contacted on it.
  4. Every status transition with its timestamp, including failures and their error codes, rather than the latest state.
  5. The document version attached, and the fact and date of any paper or email copy sent alongside it.
  6. What happened next: the reply, the call made when no delivery status arrived, or the letter sent instead.

Retention is a separate question from capture, and the periods, personal-device problem and export format are covered in our guide to archiving WhatsApp under ICOBS and SYSC.

This is the unglamorous half of what a platform such as ORIS does. Each outbound message is queued with proof of send stored before it is confirmed, statuses are recorded as they arrive and only ever move forward — Meta does not guarantee the order of its notifications, so a late "sent" webhook must never overwrite a "delivered" already on file — and every message sits against the customer record in a shared inbox that a CSV export can hand to a compliance reviewer. Consent is rechecked at the moment of sending, not only when the audience was built, and opt-outs stop messages already in the queue. If you want to see what that record looks like when a complaint arrives, take the walkthrough.

What to do when a message stays on one tick

A message stuck at "sent" is a signal with a short shelf life. The usual causes are mundane: the number is no longer on WhatsApp, the client changed handset, the phone has been off, or the number was mistyped at onboarding. The workable rule is a deadline of your own, not Meta's — if a renewal message has no delivered status a set number of days before cover expires, it stops being a messaging problem and becomes a contact problem, resolved by phone, email or post, and recorded as such. Firms that write that threshold into their renewal timetable stop discovering silent failures at the point of claim.

Frequently asked questions

Does "delivered" prove the client received the renewal notice?

It proves the message reached a device registered to that number at that time. It does not prove the person who holds the device is your client, that the file attached opened, or that anyone read it. It is good evidence of dispatch and weak evidence of receipt, which is why it belongs alongside a durable-medium copy rather than instead of one.

Why do some clients never generate a read status?

Because they have turned read receipts off in WhatsApp's privacy settings, which suppresses them in one-to-one chats. It is a user preference, applied to everyone they message, and it says nothing about your firm or your message. Group chats are the exception — read receipts are always sent there.

How long does Meta keep trying to deliver an undelivered message?

Messages other than authentication templates have a 30-day time to live, so delivery can be attempted long after you sent it. For anything with a deadline that is far too long to be useful: treat a message with no delivery status within your own service window as undelivered and switch channel.

Is a screenshot of the thread enough for a complaint file?

Rarely. A screenshot shows a rendering at one moment on one device, without message identifiers, template versions or status timestamps, and it can be produced from a phone that has since left the business. An export from the system of record, tied to the customer file, answers questions a screenshot cannot.

Can we ask clients to confirm receipt instead?

Yes, and it is the strongest evidence available to you. A message ending in a question or a quick-reply button produces an inbound message from the client, stored against their record, which shows engagement rather than delivery. It also has the side effect of opening a conversation window, which makes the follow-up cheaper and more human than another template.

See ORIS in action

Shared WhatsApp inbox, client records, follow-ups and opportunities for the whole brokerage. 15-minute demo.

Book a demo
Book a demo