Why Sent SMS and Delivered SMS Mean Different Things to a Voice Assistant

Sent versus delivered SMS context is more than a reporting detail. It changes what a voice assistant can responsibly assume during the next conversation. A message request accepted by a provider may still fail later, and a delivered message may remain unread.

When an assistant refers to a previous text, its wording should match the evidence. “A message was requested” and “the provider reported delivery” are different statements. Neither proves that the customer followed the instructions inside it.

Follow the message through its stages

A message can be queued, accepted for processing, sent onward, delivered or failed according to the provider's status model. Use the actual source and final receipt available to your workflow rather than treating the first successful response as the end of the story.

Twilio's message-status documentation explains its outbound status lifecycle. Other providers may use different names, so the operator should understand the configured route instead of memorizing one universal label.

The central principle is stable: evidence that a provider accepted work is not evidence that the destination received it.

Give staff a place to see the latest receipt and its source, so they do not have to infer delivery from a conversation timestamp.

Understand Burki's current context rule

For call-origin SMS to enter Burki's shared voice/SMS context, a delivered receipt is required. That keeps an unverified call-side message from being treated as something the caller necessarily received.

Ordinary AI SMS replies can be retained after provider acceptance. That is a different retention boundary and should not be described as delivery proof. The assistant must still avoid assuming the customer read the reply.

The voice/SMS continuity guide introduces the cross-conversation use case. The delivery rule determines which call-origin messages qualify, while current privacy settings and recent-history limits still apply.

A hypothetical missed instruction

Imagine an assistant requesting a text with directions after a call. The provider accepts the send, but no delivered receipt is available. The customer calls back asking where to go.

An unhelpful response would be, “I already sent you the directions; follow those.” It assumes both receipt and understanding. A better response answers the current question and, if relevant, explains that the earlier delivery could not be confirmed.

Now imagine the receipt does show delivered. The assistant can still ask whether the caller needs the directions repeated. Delivery is not a reason to blame the customer for asking again.

Separate message content from business outcomes

A delivered appointment-related text does not prove an appointment exists. A delivered payment link does not prove payment. A delivered callback acknowledgement does not prove a person returned the call.

Inspect the business action in its own system. Message delivery is evidence about the communication path, not about everything described or linked in the message.

This distinction is especially useful in staff review. If the customer disputes an appointment, start with the booking result and attendee details rather than treating a delivered text as conclusive scheduling evidence.

Give staff a practical review sequence

Locate the exact message and its source call, inspect the current provider status, then check the business outcome the message discusses. If the receipt is absent or conflicting, preserve that uncertainty rather than manually marking success for convenience.

Do not resend solely because a history row looks incomplete. Review the existing send and receipt first. Repairing a conversation display should not create another customer message or another charge.

The voice-assistant testing guide can help structure a controlled review. A simulated browser action is not handset delivery proof, and a working inbox screen does not establish an eligible live sender.

Before enabling context-dependent wording, write two versions of the assistant's response: one for verified delivery and one for unknown delivery. Both should help the caller complete the current task. That small copy decision prevents a status label from becoming an unsupported assumption about what the customer knows.