Chatbot & Commerce

Blocked on LINE: Your Order Update Still Reads Sent

LINE's own API returns a success response when a push message reaches a blocked customer — the order update never arrives, and nothing flags it.

Papercraft pop-up card — a smiling green chat bubble holding a paper megaphone

LINE’s own API documentation confirms it: a push message sent to a customer who has blocked your LINE Official Account still returns a normal success response. Nothing errors, nothing bounces — the order update just never arrives. For a support team, that failure looks identical to a customer who’s simply stopped replying.

Why LINE says “sent” when it wasn’t received

LINE’s Messaging API reference spells out the exact condition. Under “Conditions for sending push message,” a user who blocked the LINE Official Account is listed as a case where “status code 200 will be returned, but the users won’t receive the message” (LINE Messaging API reference: Send push message). The multicast endpoint, used to send the same update to several customers at once, documents the identical behavior for the same case (Send multicast message). Neither call returns an error — the request succeeds, and the message goes nowhere.

The one place LINE does surface a block is a different call: asking for the customer’s profile. That request returns a 404, “Unable to get profile information,” and the documented reason is specific — “the user blocked the target LINE Official Account after adding it as a friend” (Get profile). A profile lookup isn’t something an agent runs mid-conversation, so in practice the block stays invisible until a customer who should have gotten three shipping updates says they got none.

What a block actually shuts off

Once a customer blocks your OA, every push-type message — one order update, a multicast to a segment, a broadcast to every friend — stops reaching them the same silent way. LINE’s own documentation on sending messages confirms blocked users are excluded from the monthly message count precisely because the message never lands (Sending messages) — answering “did it get delivered” the hard way, by checking whether it also failed to count.

What doesn’t change: a customer can unblock the OA and resume the conversation any time, and anything they sent before blocking stays in your inbox. The block runs one way and stays silent on LINE’s side — reason enough to treat a LINE order thread that’s gone fully quiet differently from one where the customer is just slow to answer, not to assume the order itself is dead.

Set up in 1CS

Build a check for this pattern instead of waiting for a customer to ask where their order is. Open AI > เงื่อนไขอัตโนมัติ (Automation Rules), add a rule, and set the event (เมื่อ) to “การสนทนาไม่มีการตอบสนอง” (conversation idle). Add a condition (ถ้า) for channel = LINE plus a label such as “order-update-sent” — applied by whichever agent or automation sends the shipping or payment confirmation — then set the action (จะ) to add a label like “verify-delivery” and assign the conversation to a teammate. This doesn’t detect the block itself; LINE never tells 1CS that one happened. It catches the only symptom visible from your side — a LINE thread that should have had a reply and didn’t. This sits inside 1CS’s unified inbox; the Thai help center walks through the same screen at Automation rules (in Thai).

The actual fix for a flagged thread is a second channel, not a retry on the first. If you already collect a phone number for a COD confirmation or a stock check before you split an order, that’s what to send the update through next. The LINE broadcast quota math covers push and multicast from the cost side — switching channels for one flagged thread doesn’t touch it either way.

A message and checklist to copy

Send this the first time a flagged thread crosses your own waiting period — a recommended starting point, not a rule LINE enforces:

Hi [customer name], we sent an update about order [order number] on LINE but haven’t heard back. If messages aren’t reaching you here, could you share another way to contact you — WhatsApp, email, or a phone number — so we can get this to you?

Checklist for whoever reviews a flagged thread:

  1. Confirm the update actually sent — check the conversation log, not just the automation rule that should have fired.
  2. Check whether the customer has replied to anything since, on LINE or elsewhere.
  3. If there’s no alternate contact on file, ask for one in the message above instead of guessing.
  4. Resend the specific update — order number, amount, or tracking link — on the new channel, so the customer doesn’t have to ask for it from scratch.

Sources