Nothing held back: 15 pitfalls of AI customer service on LINE

The short version:The hard part of adding AI customer service to LINE isn't getting the AI to answer questions. It's everything around the AI: who owns the account, who pays the message fees, how customers actually type, and whether anyone notices when the system breaks.

This piece is drawn from real records of our four in-house LINE bots and several client projects. Every pitfall either actually happened or was a question a client actually asked. No client names are included.

Our earlier piece, 4 pitfalls of adding AI customer service to a LINE Official Account(entry-point design, conflicting keyword rules, broken handoffs to humans, broadcasts hijacking the account), isn't repeated here.

TL;DR

Before you start 1. Your customers may not be on LINE 2. Whose name the official account is under decides whether your list goes with you 3. Push messages cost money, so the AI can't casually say "one moment" 4. Settle who pays for AI usage before signing

At launch

1. Official accounts have auto-response on by default
2. Customers split one sentence into several messages
3. Returning customers scan the QR code and nothing happens
4. The AI slips in Simplified characters, and blanket conversion gets it wrong

How far the AI should go

1. "Hand off to a human when unsure" gets rejected by clients
2. Conversation memory has no expiry
3. Slow replies, or no reply at all

After launch

1. The system is down, but everything looks fine

Engineering

1. Don't make LINE wait on your webhook
2. A fallback with no traffic isn't useless
3. The same job gets processed twice

1. What to know before you start

Pitfall 1: Your customers may not be on LINE

A coach asked us to build LINE AI customer service. When we took stock, their official account had just 5 friends. All their customers were in Instagram DMs.

So the brief became "start with IG." But IG has two limits LINE doesn't:

• You can't message customers first. A follow-up reminder three days later isn't possible on IG.
• You can only reply within 24 hours of the customer's last message. After that, the window closes.

How to avoid it: Before building anything, count where your customers actually come from. Don't assume "Taiwan means LINE."

Pitfall 2: Whose name the official account is under decides whether your list goes with you

The ID LINE assigns to each friend (userId)is tied to the Provider. The same person has a different ID under a different provider.

So if the official account's API was set up by the vendor undertheir ownprovider, then when you switch vendors later:

• Friend IDs in the new system won't match the old data
• Tags and chat history stay in the old vendor's database

We once took over a project migrating off a SaaS platform, and wrote this into the contract before signing: if the original account can't be transferred, rebuilding the list is quoted separately; tag data must be fully exported as CSV before the old contract ends; and at launch, existing friends will be asked to go through the flow again.

How to avoid it: - Create the official account and Messaging API underyour own company'sprovider, and give the vendor admin access only - Before switching vendors, transfer permissions and export your list first

Pitfall 3: Push messages cost money, so the AI can't casually say "one moment"

LINE has two kinds of messages:

• Reply messages: sent in response to a customer, using that message's reply token.Free。
• Push messages: the system reaches out to the customer on its own.Billed per message; once your plan's free quota runs out, you pay.

This shapes the design. If the AI needs over ten seconds to answer, you can't first reply "Hold on, let me check," because that uses up the reply token. The real answer then has to go out as a push message, meaning every conversation costs money.

How to avoid it: - Use LINE's free "typing" indicator to cover the wait instead of sending text first - State clearly in the quote:message fees are paid through the client's official account plan - With multiple stores or events, "one account per event" and "one shared account" each have trade-offs. Every account gets its own free quota, but your list gets split up. It's a trade-off with no single right answer

Pitfall 4: Settle who pays for AI usage before signing

This is a question visitors to our website have actually asked. The same visitor asked it three different ways:

"Do I need to apply for an OpenAI API myself?" "Do I pay for the tokens, or do you?"

Every time the AI replies, someone pays the model provider, billed by "token" (think of it as billing by word count). There are two common approaches:

We default to the first.

How to avoid it: Whichever you choose, the quote should state who pays, what the cap is, and what happens if it's exceeded.

2. Where launches get stuck most

Pitfall 5: Official accounts have auto-response on by default

The code is clearly running, yet customers receive canned messages from the official account dashboard.

The reason: free official accountshave "Auto-response" and "Greeting message" turned on by default, and they compete with your AI to reply. Another small catch: the webhook toggle only becomes clickable after you've entered the URL.

How to avoid it: Make the first line of your launch checklist "Dashboard auto-response: off."

Pitfall 6: Customers split one sentence into several messages

A real example:

"Planning on around 1 p.m." (7 seconds later) "Does that work"

If each message is treated as a separate question, the AI first responds to "around 1 p.m.," then to a context-free "does that work."

It's worse with keyword rules. A customer types "pricing / I want to book," the first half triggers the price list, and the booking request gets ignored.

How to avoid it: Wait for the customer to pause, merge the messages, then process them as one. Our settings:

• Message ends withnopunctuation → wait 7 seconds (they're probably not done)
• Ends with a period, question mark, or exclamation mark → wait 3 seconds
• Messages over 12 characters, or containing numbers ("how much for 2 units, 2 days"), always go to the AI, never to keyword rules

Pitfall 7: Returning customers scan the QR code and nothing happens

We often use a "scan QR code → add friend → flow starts automatically" design. Butwhen someone who's already a friend scans it, no "add friend" event fires, and nothing happens on screen.

And the people scanning a QR code printed in-store are often exactly those returning customers.

How to avoid it: Switch the QR code to a link with parameters, so existing friends can trigger the flow too.

Pitfall 8: The AI slips in Simplified characters, and blanket conversion gets it wrong

Writing "please use Traditional Chinese" in the prompt only lowers the odds; it guarantees nothing. Our bot once said to a customer:

"順著流程走会通"

The fix looks simple: run the whole sentence through a Simplified-to-Traditional converter. Instead, we got:

"預估裏程 150 公裏……大臺北"

In everyday Taiwanese writing, it's "里程" (mileage), "公里" (kilometers), and "台北" (Taipei). Whole-sentence converters "correct" these characters too.

How to avoid it: Before sending, check character by character in code, and only convert characters that can't be typed in the legacy Traditional Chinese encoding (Big5). Keep a whitelist of characters common in Taiwan that tend to be wrongly converted, and never touch them.

3. How far the AI should go

Pitfall 9: "Hand off to a human when unsure" gets rejected by clients

This is the most common conservative design, and it was our initial proposal too. A parking lot client shot it down in the meeting:

"If everything goes to a human, what's the point of AI customer service?"

Website visitors have asked the opposite: "When it can't answer, why not just say it doesn't know and hand off to a human?" Both sides have a point, so the key iswhere you draw the line。

We went back and looked at how that parking lot's human agents handled issues like "I forgot to end my session," and found they weren't verifying anything either. They were applying aleniency policy: waive it outright within a certain number of times and amount. And if it's a policy, it can be written as rules.

We mapped out all 46 scenarios:

• 27 the AI can handle directly
• 10 it can handle once given rules
• 9 stay with humans

Roughly 80% can be automated. That's a design-stage estimate, not a post-launch measurement.

How to avoid it: Don't ask "Can the AI answer this?" Ask "How do humans decide this today?" If humans are following rules too, the AI can take over.

Pitfall 10: Conversation memory has no expiry

To keep context, systems usually send "the last 10 messages" to the AI. But without looking at timestamps, something discussed three months ago gets treated as part of today's conversation.

How to avoid it: Add a time window to memory. Ours is 12 hours; anything older starts a new conversation.

The side effect: if a customer asks about "that thing earlier" the next day, the AI loses the thread, and it hands off to a human. That's a trade-off, not a bug.

Pitfall 11: Slow replies, or no reply at all

One website visitor's real feedback was just three words: "Replies are slow."

Slowness is one thing. The bigger problem isnot replying at all. Systems usually have several layers of "maximum wait time" settings:

• How long the AI itself can think
• How long to wait after switching to a backup model when the main one fails
• How long the LINE-facing layer waits

If these are set separately, you easily end up with "the LINE layer gives up at 65 seconds, but the AI layer alone takes 60 seconds to time out, so the fallback never has time to run." One of our bots had exactly this problem:the fallback never once took effect on LINE, and we only found out when we added up all three layers together.

How to avoid it: Calculate all three together. Our current settings: AI 100 seconds + fallback 100 seconds < LINE layer 230 seconds < full request 280 seconds. During the wait, the "typing" indicator from Pitfall 3 covers the gap.

4. After launch

Pitfall 12: The system is down, but everything looks fine

To avoid showing customers error messages, many systems reply with a canned line when something fails, like "Let me pass this to a team member."

The problem:customers don't report it; they just think the AI is dumb. The whole system can be down, and from the outside it looks like "the AI just couldn't answer."

We hit an even more invisible version: the background process that merges messages (Pitfall 6) stopped, and customers' texts got no response at all. Yet LINE still received "processed," and website monitoring showed all green.

How to avoid it: - Keep the canned reply, but every time it fires, alsonotify yourself(we use Telegram) - Monitoring can't just check "is the website responding." It has to check "are messages actually getting processed": is the background process running, and is the message queue piling up

5. Engineering

The last three are more technical, for anyone building it themselves or reviewing a vendor's work.

Pitfall 13: Don't make LINE wait on your webhook

When LINE sends a customer's message to your server (that entry point is called a webhook), it expects a quick response. If the webhook calls the AI directly and waits for it to finish, every message ties up one of the server's worker slots.

Our server has only 5 worker slots, shared with 6 websites. A single AI tarot reading holds a slot for 37 to 57 seconds. Five customers at once, and the websites grind to a halt.

How to avoid it: The webhook does one thing only: put the message in a queue and immediately reply "received." A separate background process works through the queue in order. (This is also why Pitfall 12 says to monitor that background process.)

Pitfall 14: A fallback with no traffic isn't useless

Our AI mainly runs on a subscription plan. When the subscription quota runs out, every service stops at once, so we built a fallback: once the quota is hit, it automatically switches to a pay-as-you-go API, with two spending caps (US$3 per day, US$15 per month). Past those, it stops and notifies us.

Once, while cleaning up our machines, we saw a fallback service that "normally gets zero traffic" and shut it down. The next day, a customer's tarot reading failed.

Fallbacks are supposed to get no traffic. It had none because the main path had been healthy all along.

How to avoid it: Before disabling any service, search the config files on every machine to see whether something else uses it as a fallback. After shutting it down, watch the next round of alerts.

Pitfall 15: The same job gets processed twice

A booking service ran a scheduled job every 5 minutes, picking up "pending" bookings and passing them to the AI to generate results. Sometimes the AI took over 5 minutes, so when the next run started, that booking was still "pending" and got picked up again.

The same customer received two different results.

How to avoid it: Before processing, change the status in the database from "pending" to "processing," and only the side whose update succeeds may continue (engineers call this an "atomic claim"). Add a file lock on top as insurance.Claim first, then do the slow work.

Final thoughts

Of these 15 pitfalls, only two or three really have to do with how smart the AI is. The rest are about accounts, billing, typing habits, and monitoring: things outside the AI.

So when choosing a vendor, rather than asking "Which model do you use?", ask:

• Whose name will the official account be under?
• Who pays the message fees and AI usage fees?
• When the system goes down, who finds out first?

Vendors who can answer these three specifically have usually fallen into the pits themselves.

Satsuma Creative builds LINE AI customer service and booking systems, with four of our own LINE bots running live. To talk through your situation, start with ourLINE AI customer service page.