From LINE OA Rich Menu to a Live Seat in 3 Taps: Instant Reservation Flow Design That Stops Chat Leakage

1. Define “3 taps” as a contract, not a slogan

Vendors print “book in LINE” on every pitch deck. The implementations are not interchangeable. Write the guest path as three irreversible actions, then reject any design that inserts a fourth.

1. Tap 1. Guest opens the Official Account chat and taps the persistent Reserve cell on the rich menu. The action type is uri, target is a LIFF URL (https://liff.line.me/{liffId}), not an external https:// booking page and not a message action that dumps “I want to book” into the chat.
2. Tap 2. Inside the LIFF browser, the guest picks party size, date, and a live slot. The slot tap acquires a short pessimistic lock on that table-time pair. Name and phone come from liff.getProfile() / ID token claims. The guest does not create a second account.
3. Tap 3. Guest confirms. The ledger commits the reservation, the lock converts to a hold or a paid confirm, and a Flex confirmation lands in the same chat. Google Maps, cancel policy, and (if in scope) a PromptPay deposit QR ride on that card.

Anything after tap 3 is staff work (allergy notes, room assignment) and must not block the commit. Anything before tap 1 that requires the guest to type “book 4 at 20:00” is not a three-tap flow. It is a ticket into a human inbox.

The reason this matters in Bangkok, Taipei, and Tokyo is identical. LINE is already the default business channel. r/AskAJapanese threads treat Official Account chat as the normal way a restaurant talks to a diner, the way a US guest treats OpenTable email. Thai independents put the OA QR on the check presenter and on the door. The failure is not discovery. The failure is that the richest pixel on the chat screen (the rich menu) still routes into the slowest path (an unread chat).

2. Operators and diners describe the same 45-minute hole

Public posts rarely use the words “rich menu.” They describe the symptom.

On the floor. A 48-seat izakaya in Asoke or Thong Lo takes the last prep run at 17:00. Three LINE chats arrive between 17:05 and 17:40: a four-top for 20:00, a six-top asking for the private room, and a tourist writing in English. The host is on the pass. First reply goes out at 18:20. Two of the three threads come back with a variant of “sorry, we booked somewhere else.” That sentence is the standard post-mortem in Bangkok operator groups. It is also the pattern on X from independent Japanese shops that still print “ご予約は公式LINEのチャットから” and then go dark during service.

On the diner side. Japan-travel and Thailand threads treat a restaurant that only answers LINE after 21:00 as closed for booking purposes, even if the kitchen is open. r/Thailand’s running complaint about QR-only menus is the same UX failure in a different costume: the guest is forced out of a native surface into a slow webview, then blamed for not completing. r/solotravel and r/JapanTravel regulars will use Tabelog, Hot Pepper, or a hotel concierge when the Official Account does not confirm inside a few minutes. They do not sit in a chat waiting for a typing indicator.

On the builder side. LINE Developers Thailand group threads keep two incidents on rotation. First, a LIFF deploy that “does not update” because the in-app browser cached the old bundle, so Friday’s slot grid is yesterday’s inventory. Second, a shop that stacked a chatbot SaaS, an agency broadcast tool, and a booking LIFF on one Messaging API channel, then hit 429s and a hijacked webhook. LY Corporation’s 23 July 2026 note is blunt: rate limits, rich menu caps, and audience objects are per channel, not per tool.

The commercial read is simple. Guests already trust LINE. They do not trust a silent chat. The rich menu is the only always-on control you own inside that chat. Spend it on inventory, not on “Contact staff.”

3. Feature comparison: five ways to “take a LINE reservation”

“We have LINE booking” is a slogan. The action type on the rich menu cell, the browser container, and the inventory lock decide conversion and double-booking risk.

Read the table as an operating-risk ranking. Manual chat is free software and expensive inventory. An external booking URL behind a pretty rich menu cell looks modern and then drops guests at the LINE-to-Safari hop, the cookie banner, and the “create an account” wall. A keyword bot feels automated and still has no idea whether table 12 is sat. The only design that earns the phrase “instant reservation” is a LIFF surface that reads and writes the production table grid.

4. Rate limits, quotas, and rich menu constraints to read before you design

Sales decks say “unlimited LINE automation.” The published Messaging API limits disagree. Treat the following as contract due diligence.

Two 2026 platform events belong in the runbook. Messaging API outages on 4 August 2026 and a broader LINE platform incident on 28 July 2026 (LIFF and Login included) are documented on the LINE Developers news feed. A booking flow that is “LINE or nothing” with no local iPad cache will stop seating walk-ins when the platform is dark. Pair the LIFF path with a local-first floor grid.

Thailand and Japan do not share a price list. Quote the country of the Official Account, not a USD blog table.

A reminder that does not fit on the slide: a confirmation card sent as push is a billable message. A confirmation sent as reply is not. Three transactional pushes per booking (confirm, T-24h, T-3h) on 400 covers is 1,200 messages before a single marketing broadcast. On Thailand Free (300) the job dies in the first week. On Japan Light (5,000, no overage) a 2,000-friend weekend blast plus reminders will 429 with no purchase path except an upgrade to Standard.

5. The primary path is a URI cell into LIFF, not a chat script

Product pages love a six-cell rich menu with Reserve, Menu, Map, Coupon, Jobs, and Call. Only one cell should own the booking job.

Rich menu cell. type: "uri" to the LIFF endpoint. Do not use type: "message" with “予約” as the text. That design looks like automation and then waits for a webhook, a reply token, and a bot that must not collide with the agency’s auto-reply. URI skips the chat transcript entirely.

LIFF container. Open inside the LIFF browser so liff.init() can read the ID token. An ordinary https://book.example.com URL opened from the rich menu often lands in LINE’s in-app browser without LIFF login, or worse, in Safari / Chrome with a “Leave LINE?” prompt. That hop is where completion falls 40% to 60% in operator retellings. Keep the guest inside LINE.

Live inventory, not a cover budget. A calendar that says “20:00 still has 8 covers” will seat two four-tops at the same four-top. The slot list must be table-aware (or room-aware) and must lock on tap. Fifteen seconds is enough for a confirm tap and short enough that an abandoned LIFF does not freeze Friday inventory.

Commit, then message. Write the row first. Then send the Flex card. If the reply token is alive, use reply (free). If the guest confirmed 40 seconds after the last webhook, use push and increment the quota counter you actually monitor.

Per-user menus for language and state. Default menu in Thai (or Japanese). On first LIFF open, persist language and lifecycle (guest, upcoming_reservation, vip). Link a per-user rich menu so a diner with tonight’s booking sees Modify / Cancel / Map instead of a second Reserve tap that double-books them. Unlink after service.

6. Implementation snippets: rich menu, webhook, lock, commit

The failure mode after a demo is not “LINE did not connect.” It is a missing lock, a spent reply token, or a second tool stealing the webhook.

const FULL_RICH_MENU = { width: 2500, height: 1686 } as const;
const COMPACT_RICH_MENU = { width: 2500, height: 843 } as const;
const REPLY_TOKEN_BUDGET_MS = 25_000;
const SLOT_LOCK_MS = 15_000;

export const reserveCell = {
  bounds: { x: 0, y: 0, width: 1250, height: 843 },
  action: {
    type: "uri" as const,
    label: "Reserve",
    uri: "https://liff.line.me/2001948572-rezabo",
  },
};

export function mustUsePush(webhookReceivedAt: number): boolean {
  return Date.now() - webhookReceivedAt > REPLY_TOKEN_BUDGET_MS;
}

export type SlotLock = {
  shopId: string;
  tableId: string;
  serviceAt: string; // ISO-8601
  holderLineUserId: string;
  leaseUntil: string;
};

Webhook body when a leftover postback cell is still on an old menu (abbreviated). Verify x-line-signature before you parse. Return HTTP 200 fast; do the book work off-thread.

{
  "destination": "Uxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
  "events": [
    {
      "type": "postback",
      "timestamp": 1776643200000,
      "source": { "type": "user", "userId": "Uaaaabbbbccccddddeeeeffff11112222" },
      "replyToken": "b60d432864f44d079f6d8efe86cf404b",
      "postback": {
        "data": "action=open_reserve&shop=suk13",
        "params": {}
      },
      "mode": "active"
    }
  ]
}

Prefer not to receive that event at all. The production path is LIFF calling your booking API with the ID token, not a postback. The reservation write still needs a mutex the floor iPad respects.

BEGIN;

INSERT INTO slot_locks (shop_id, table_id, service_at, line_user_id, lease_until)
VALUES (
  'suk13',
  'T12',
  TIMESTAMPTZ '2026-08-21 20:00+07',
  'Uaaaabbbbccccddddeeeeffff11112222',
  now() + interval '15 seconds'
)
ON CONFLICT (shop_id, table_id, service_at)
DO UPDATE SET
  line_user_id = EXCLUDED.line_user_id,
  lease_until = EXCLUDED.lease_until
WHERE slot_locks.lease_until < now();

INSERT INTO reservations (
  id, shop_id, table_id, service_at, party_size, line_user_id, status
)
SELECT
  'rsv_suk13_20260821_2000_t12',
  'suk13',
  'T12',
  TIMESTAMPTZ '2026-08-21 20:00+07',
  4,
  'Uaaaabbbbccccddddeeeeffff11112222',
  'confirmed'
WHERE EXISTS (
  SELECT 1 FROM slot_locks
  WHERE shop_id = 'suk13'
    AND table_id = 'T12'
    AND service_at = TIMESTAMPTZ '2026-08-21 20:00+07'
    AND line_user_id = 'Uaaaabbbbccccddddeeeeffff11112222'
    AND lease_until >= now()
);

COMMIT;

If the INSERT INTO reservations writes 0 rows, the LIFF must refresh the slot grid. Do not show a fake success toast. That toast is how a guest arrives to a sat table.

Issue the rich menu and the booking session from the same service:

mutation OpenReserveSession($input: OpenReserveInput!) {
  openReserveSession(input: $input) {
    liffEndpoint
    shopId
    defaultPartySize
    lockedTableId
    leaseUntil
    remainingPushQuota
  }
}

query MessageQuota {
  lineQuota {
    type
    value
    totalUsage
  }
}

Poll GET /v2/bot/message/quota and .../quota/consumption on a 15-minute cadence, not per request. Those insight-adjacent habits are how shops discover they are at 29,400 / 30,000 on the last Friday of the month, before the 19:00 reminder job starts.

7. Operational traps that keep Friday chats unread

Rich menu design has a few mechanical rules that designers skip. Export at exactly 2500×1686 or 2500×843. Keep the Reserve cell on the left, largest, high contrast, with a thumb-sized target. Put Call and Jobs on a second “More” menu if you need them. The chat bar label is 14 characters; test Thai and Japanese glyphs, not only English. selected: true opens the menu expanded, which is what you want at a restaurant OA. A collapsed bar that says “メニュー” hides the only conversion control you paid to draw.

8. Pricing pitfalls and first-year TCO

Assume a 48-seat Sukhumvit izakaya. Average check 2,800 THB. LINE chat inquiries 120 per month. Under a five-minute reply, about 45% convert (54 covers). After a 30-minute silence, conversion falls near 18%. Forty threads go dead. Hosts spend about 5 minutes on each inquiry that they do answer.

• Abandoned high-intent threads: 40 / month
• Conservative capture if a 3-tap LIFF is always on: 60% of those 40 = 24 covers
• Recovered contribution at 65% after food cost: 24 × 2,800 × 0.65 = 43,680 THB / month, 524,160 THB / year
• Host minutes returned: 80 handled threads × 4 minutes saved ≈ 5.3 hours / month (the LIFF still needs exception handling)

That recovered top line is the real budget. LINE plan fees are not.

Three procurement mistakes repeat.

1. Buying a rich menu design and calling it a booking system. A 1 MB JPEG does not lock table 12.
2. Signing Japan Light or Thailand Free for a shop that sends confirm + two reminders. Reply is free. The reminders are not. Upgrade the plan before the first Friday blast, or the API will upgrade it for you with 429s.
3. Per-cover reservation software plus an agency LINE retainer. Volume is punished twice. Rezabo’s 1,900 THB/month is the unlimited reservation ledger, not a booking commission. LINE message fees stay on LY’s / LINE TH’s invoice. Do not mix those lines.

Re-quote Japan accounts before 1 October 2026. LY’s announced structure change will move the Standard overage math. Thailand Pro at 1,780 THB with 35,000 messages remains the working default for a single Bangkok shop that also broadcasts twice a week.

9. Roll out the three-tap path in three weeks

• Week 1. Freeze the rich menu to six or fewer cells. Left-most cell is Reserve, URI to LIFF. Turn off OA Manager auto-reply on the keywords “book,” “จอง,” and “予約.” Point the webhook at one owner. Photograph every current menu (API and Manager) before you delete anything.
• Week 2. Dual-run. LIFF writes the live grid. Chat reservations are re-keyed by the host into the same grid within two minutes, then the host pastes the LIFF link back. Measure time-to-confirm and abandoned LIFF sessions. Fix cache-busting on the LIFF bundle.
• Week 3. Remove “book via chat” from the menu. Per-user menus for guests with an upcoming reservation. Quota alert at 80% of monthly messages. Drill an offline seating path on the iPad. Add deposit QR on the confirm card only for Friday-Saturday high-check inventory.

Do not launch a new six-message onboarding carousel in the same week. You will spend the month’s quota teaching people to tap a button that is already at the bottom of the screen.

10. Questions owners ask before they swap the cell

Q1. Will we lose existing friends? No. The Messaging API attaches to the current Official Account. Followers, chat history, and the LINE ID stay. You are changing the menu object and the webhook, not the account.

Q2. What happens to phone and walk-in? They must write the same table grid. If they do not, the LIFF is a second book and you have rebuilt the collision you had with paper.

Q3. Can we keep chat for allergy and banquet notes? Yes. After tap 3, a “Add a note” postback or a free-text field on the LIFF is enough. Do not block the commit on a human reading the note.

Q4. How do we handle Japanese, Thai, and English on one OA? Detect from LINE profile / LIFF locale on first open. Link a per-user rich menu. Do not put three Reserve buttons on one image.

Q5. Does LIFF work if the guest has not added the OA as a friend? They can open a LIFF URL, but login and push become messy, and the rich menu itself is a friend-chat object. Put Add Friend on the door QR, then the menu.

Q6. What if LINE is down during service? Seat from the local iPad cache. Take names. Sync when the platform returns. Do not invent a paper side book that never gets typed in.

11. Metrics that prove the rich menu is actually selling seats

Closing

Restaurant Official Accounts do not leak Friday covers because the logo on the rich menu is wrong. They leak because the Reserve cell still opens a conversation that nobody can answer at 17:20. The fix is narrow. Point the cell at a LIFF booking surface, prefill identity from LINE, lock the same table the iPad uses, commit in three taps, and send the confirm as a reply when the token is still valid. Price the LINE plan for transactional push plus a small broadcast, not for a demo week on the Free tier. Keep one webhook, one ledger, and a local floor cache for the next platform incident.

What to refuse is equally specific: message-action cells, external signup pages, keyword bots with no table map, Japan Light or Thailand Free as a production quota, and a second calendar that the host re-types at 18:00. Agency retainers of 15,000 to 50,000 THB a month that deliver a JPEG and a chatbot script do not buy you a lock on table 12. A 1,900 THB ledger that does, plus 1,780 THB of Thailand Pro (or Japan Standard after you re-quote October), sits an order of magnitude below the contribution you are already losing to silent chats.

If the next guest who taps your Official Account at 17:12 can hold a real 20:00 four-top without a human seeing the thread, the flow is finished. If they still type “are you open?” into the chat, the menu is decoration.

To map rich menu cells, LIFF locale, and table locks onto your actual floor mix, talk to the local team from the button below.