The skeleton of a LINE auto-reply system

Plenty of shops run a LINE Official Account that stops at auto-reply equals keyword matched to a canned message.
One extra question from a customer and nothing comes back, so in the end a human watches all of it anyway.

This guide walks you through turning auto-reply into a system you can actually rely on:
Answers that have to be word for word go to rules.
Fuzzy natural language goes to AI.
Both sides get a safety net, and anything neither one catches goes to a human.

By the end you will have three things:
First, the skeleton of the whole message pipeline, from signature checks and deduplication to member state and sending the reply.
Second, where AI is actually worth putting, instead of letting it answer at random.
Third, the quality design that keeps the system out of trouble after launch.

Every node in the flow chart below opens up, showing what it does, how to design it, and how to test it.
The three views are: the full skeleton, where AI belongs, and how to build it well.

Why this order

Put AI at the front and the usual result is a customer asking your opening hours and getting a beautiful wrong answer. Rules run first so the answers that have to be word for word stay consistent, though consistent is not the same as true, and someone still has to maintain the data behind the rules. AI runs second, to catch the phrasings the rules miss. The gate sits last, because even when both earlier layers are sure they are right, something still has to ask whether this message is really safe to send. One exception worth remembering: payments, cancellations and anything else that changes real data needs its confirmation and authorization before it runs, not a check after the fact.

Three shared foundations get overlooked. With no versioning on the knowledge base, answers stay stuck on a policy from six months ago. With no timeout on session state, a user who comes back the next day gets yesterday's follow-up question. With no logs, the only way you ever learn the system broke is a complaint.

One more layer: this page is an intro, not a launch blueprint

This page covers the skeleton and the thinking behind it. To actually run the system in production, with real customers and real money, there is a reliability layer I have not opened up here:

Queue depth and retry monitoring, accuracy tracking per intent, citation checks on AI answers, conversation-level traces, reproducible model and knowledge base versions, an emergency kill switch and an event replay tool.

Do not let that list scare you at the start. Build the rule layer solidly along the skeleton above, send everything high-risk to a human, and you can start safely. Once volume grows and money is involved, come back and fill this layer in, or find someone who has done it to check your work.