Every function the system offers, in pictures — following one real order from start to finish.以图解说明系统的每一项功能 — 跟着一张真实订单，从头走到尾。
Four parts. Everything else is detail.四个部分，其余都是细节。
Your team watches over all of it — every order leaves a note to check. 您的团队全程掌握——每张订单都会留下一则可供核对的备注。
Reply in the chat and the assistant stands down immediately.只要在对话中回复，助手会立即停止回应。
Numbers not on your list get no automated reply at all.名单以外的号码不会收到任何自动回复。
It can record a payment receipt, nothing more.仅能记录付款收据，不做其他处理。
Delivery requests are written down and passed to your team.送货要求会记录下来并转交团队。
Every request the assistant can handle. Anything not on this list goes to a person.助手能处理的所有请求。清单以外的一切，都会转交人员。
Anything else is handed to a person. Complaints, negotiations, unusual requests — the assistant stops replying and leaves the conversation in your inbox. That is a designed outcome, not a failure. 其余一切都交由人员处理。投诉、议价、特殊要求——助手会停止回覆，并把对话留在收件箱。这是刻意设计的结果，而非故障。
A real customer message, and what happens to it.一则真实的客户讯息，以及它的完整旅程。
Usually several, not one.通常是好几则，而不是一则。
叉烧 2 · 豆包 3 · 还有那个鱼丸 · 5 包
So it can read all four lines together. On their own, “5 包” means nothing.以便把四行一起阅读。单看「5 包」毫无意义。
Phone number → customer account → which outlet.电话号码 → 客户账号 → 哪一间门市。
016-778xxxx → K100
· Puchong outlet· 蒲种门市
The hardest step, and where nearly every mistake starts. Section 4.最困难的一步，也是几乎所有错误的起点。详见第 4 节。
叉烧 2 → 鸿缘-叉烧(切) → 0001H11004
1 箱 is not 1 piece. Each product has its own pack size.1 箱不等于 1 件，每项产品的包装数量各不相同。
1 箱 → 10 PKT
· using that product’s own pack rate· 依该产品自身的包装比率
Only the product code and quantity are sent. SQL Account fills in the name and price.只送出产品代号与数量，名称与价格由 SQL Account 自行填入。
0001H11004 + qty 2 → SO-01234
A confirmation to the customer, and an internal note to your team listing exactly what was booked.一则确认讯息给客户，一则内部备注给团队，列明实际下单内容。
The internal note is your safety net. It shows what was actually booked — not what the customer wrote. Reading the two side by side is how a wrong product gets caught. It takes seconds. 内部备注就是您的安全网。它显示的是实际下单的内容，而非客户所写的文字。把两者并排对照，就能发现下错的产品，只需几秒钟。
The hardest step in the system. Customers don’t use catalogue names.系统中最困难的一步。客户不会使用目录上的正式名称。
Brand, product, size and quantity are separated — 叉烧 2 becomes product 叉烧, quantity 2.将品牌、产品、规格与数量分开——叉烧 2 拆成产品「叉烧」、数量 2。
If a nickname matches, it takes over the search — the catalogue name replaces what the customer typed. This is why teaching a nickname is the strongest fix available to you.一旦命中别名，它会主导整个搜寻——以目录名称取代客户输入的文字。这也是新增别名之所以是最有效解法的原因。
By meaning (products that are similar to the words) and by text (products whose names contain the words). Both sets of candidates are pooled.一是依语意（与用词相近的产品），二是依文字（名称包含该用词的产品），两组候选结果合併处理。
Closeness of match, whether the brand matches, whether the size matches, and how often this customer buys each candidate.依相符程度、品牌是否吻合、规格是否吻合，以及该客户购买各候选产品的频率来排序。
If nothing scores well enough, it does not guess. The request goes to your team.若没有任何结果分数足够，系统不会猜测，该请求会转交团队。
You control the first four.前四项由您掌控。
What everyone calls it.大家惯用的叫法。
What one customer calls it.某位客户专属的叫法。
Chinese, English, abbreviations.中文、英文、缩写。
烧麦 → 烧卖, and similar.如「烧麦」→「烧卖」。
Automatic. What they usually buy.自动套用，即客户惯常购买的品项。
The customer wrote a four-character shorthand that appears nowhere in the catalogue.客户写了一个四字简称，而目录中并不存在这种写法。
Three characters matched a real supplier name — leaving only 「鱼」 to search on.其中三个字与真实供应商同名，结果只剩下「鱼」可供搜寻。
With little left to go on, it chose the fish this customer buys most. Both lines became the same product — one item never made the order.在线索不足的情况下，系统选了该客户最常买的鱼。两行变成同一项产品，另一项完全没进订单。
The fix took one row in a spreadsheet — teaching it that customer’s private nickname. That is the usual pattern: most repeat mistakes are yours to fix, in a sheet, without a developer. Section 12. 解决方法只是在试算表新增一行——把该客户的专属叫法教给系统。这也是通则：多数重覆出现的错误，您都能自行在试算表中解决，无需工程人员。详见第 12 节。
Worth accepting: this step will never be perfect. Nicknames, mixed languages and near-identical product names make it genuinely hard. That is exactly why every order produces an internal note for your team to glance at. 需要接受的事实：这一步永远不会百分之百准确。别名、混合语言与极为相似的产品名称，使它本质上就很困难。这正是每张订单都会产生内部备注、供团队过目的原因。
Customers photograph the packet instead of typing the name.客户直接拍下包装，而不是打字输入名称。
Every incoming image is sorted first — a product photo, or a payment receipt. They go down completely different paths.每张收到的图片会先被分类：产品照片，还是付款收据。两者走的是完全不同的流程。
The photo is converted into a numeric fingerprint and compared against a fingerprint stored for every product in the catalogue. The closest match wins a score.照片会被转换成一组数值指纹，并与目录中每项产品预存的指纹比对，最接近者取得一个分数。
Two tests must both pass — a high score, and a clear gap over the runner-up.必须同时通过两项检验——分数够高，而且与第二名拉开明显差距。
score ≥ 0.90 and且 gap ≥ 0.03
Genuine matches usually score 0.93–0.99. The product joins the order like any typed item.真正相符的比对通常落在 0.93–0.99，该产品便如同文字下单一样进入订单。
It does not guess, and it does not ask the customer to send a clearer photo. The conversation goes to customer service.系统不会猜测，也不会要求客户重拍。该对话会转交客服处理。
Why the bar is set so high. Any two packets of the same brand score around 0.80–0.82 simply because they look alike — the packaging, not the product. A gate set at 0.80 would confidently match products the catalogue does not even carry. Real matches sit far above that, so 0.90 with a clear gap separates a true match from a lookalike. 门槛为何订得这么高。同一品牌的任意两包产品，光是外观相似就能得到约 0.80–0.82 分——相似的是包装，而非产品。若把门槛设在 0.80，系统会「很有信心」地比对到目录中根本没有的产品。真正相符者的分数远高于此，因此 0.90 加上明显差距，才能区分真正相符与外观相似。
What this means for your team: an unmatched photo is not a fault — it is the system refusing to guess. It arrives in your inbox with the photo attached, ready for someone to identify in a few seconds. 对团队的意义：照片比对不到并非故障，而是系统拒绝猜测。该对话会连同照片一起出现在收件箱，让人员几秒内就能辨识。
What happens the moment the customer confirms.客户确认下单当下发生的事。
Lines are read in the sequence the customer wrote them, so the Sales Order reads the same way as the conversation.依客户书写的顺序读取行项，使销售订单的排列与对话一致。
The product name is never sent. SQL Account fills in the name, unit and price itself, from the code.产品名称绝不送出。SQL Account 会依代号自行填入名称、单位与价格。
0001H11004 + qty 2
→ SQL Account adds 鸿缘-叉烧(切) · PKT · priceSQL Account 补上 鸿缘-叉烧(切) · PKT · 价格
Taken from the outlet identified in step 3 of section 3. Split orders are labelled so the office can tell them apart.取自第 3 节步骤 3 所判定的门市。拆单会加上标记，方便办公室区分。
Plus the internal note to your team listing exactly what was booked.同时向团队发出内部备注，列明实际下单内容。
Because only the code travels, SQL Account cannot check the name. A wrong code produces a line that looks perfectly correct — right description, right price, wrong product. Nothing downstream re-examines it. This is why the internal note matters: it is the last point where a human sees the product name beside what the customer actually asked for. 由于只传送代号，SQL Account 无法核对名称。错误的代号会产生一行看起来完全正确的资料——品名对、价格对，但产品错。后续没有任何步骤会再作检查。这正是内部备注的价值所在：那是最后一个由人看到「产品名称」与「客户要求」并列的环节。
If a product code is changed or retired in SQL Account, the order is still accepted — but that line comes back blank: no description, no unit, price zero, and excluded from the total. The system spots this and notifies your team, but it still needs fixing by hand. 若产品代号在 SQL Account 中被更改或停用，订单仍会被接受——但该行会是空白的：没有品名、没有单位、价格为零，且不计入总额。系统会侦测并通知团队，但仍需人工更正。
The connection runs through a computer at the office. Overnight it may be off. The order is marked pending and retried automatically every 5 minutes between 08:00 and 12:00 the next morning. Orders are delayed, not lost. 该连线需经办公室的一台主机，夜间可能关机。订单会被标记为待处理，并于隔日 08:00 至 12:00 之间每 5 分钟自动重试。订单只是延后，并未遗失。
The retry does not cover everything. It only rescues orders that failed at this final step. If something failed earlier, the order is never marked pending and will not be retried — even though the customer may already have been told it was going through. If a customer says they ordered and no Sales Order exists, check rather than wait. 重试机制并非万能。它只能挽救在最后这一步失败的订单。若失败发生在更早的阶段，订单不会被标记为待处理，也不会重试——即使客户可能已被告知订单正在处理。若客户表示已下单却查无销售订单，请主动查核，不要等待。
Its replies are not scripted word for word — but what it may say, and when, is tightly controlled.助手的回覆并非逐字写死——但它可以说什么、什么时候说，都受到严格限制。
Tone, set once and applied everywhere: professional, concise, transactional, polite. Avoid unnecessary confirmations. Avoid repetitive questions. Move the transaction forward. 语气基调，一次设定、全域适用：专业、简洁、以交易为导向、有礼。避免不必要的确认，避免重覆提问，让交易顺畅推进。
The assistant greets the customer only when the conversation is new. If a conversation is already running, it answers straight away with no greeting — which is why a regular placing a second order in the same session is not greeted twice.
助手只在对话是全新的时候问候客户。若对话已在进行中， 它会直接回答、不再问候——这也是熟客在同一段对话中再下一张订单时， 不会被重覆问候的原因。
If the product is identified with high confidence, it is added with no confirmation question. Asking “did you mean X?” on every line would make ordering slower than typing it into SQL Account by hand.若产品以高信心辨识出来，会不经确认直接加入。若每一行都问「您是指 X 吗？」，下单会比人手输入 SQL Account 还慢。
Several low-confidence candidates means it asks the customer to clarify before touching the cart.若出现多个低信心候选，会先请客户厘清，之后才动购物车。
A missing detail is a question, not a handover. These are the actual phrasings it uses:缺少细节属于提问，而非交接。以下是它实际使用的说法：
请问您要多少数量？请问您要哪一种包装规格？请提供数量后我可以帮您加入购物车。
When the customer clearly confirms — 下单, confirm,
ok proceed or similar — the assistant creates the order
immediately. It does not re-read the cart back, does not ask “are you sure?”,
and does not ask for the address again.
After the Sales Order number is returned, it shows the order detail, address, product list, subtotal and total. The cart is then closed — further edits are not accepted, and a change needs a new order or your team.
当客户明确确认——下单、confirm、ok proceed
或类似说法——助手会立即建立订单。它不会再读一次购物车、
不会问「您确定吗？」，也不会再要一次地址。
销售订单号码回传后，它会显示订单明细、地址、产品清单、小计与总额。 此时购物车即关闭，不再接受修改；若需变更，须另建新订单或由团队处理。
A customer with several branches can order for more than one in a single message. The message is split by outlet, and each outlet becomes its own order with its own delivery address.
Two details matter for how it reads to the customer:
The same applies when a customer asks for separate bills — 单1 /
单2, bill 1 / bill 2 — each group becomes its
own Sales Order, labelled so the office can match them up.
拥有多间分店的客户，可以在同一则讯息中为不止一间下单。 该讯息会依门市拆分，每一间门市各自成为一张订单，各用自己的送货地址。
其中有两点会影响客户看到的样子：
客户要求分开开单时亦同——单1／单2、
bill 1／bill 2——每一组各自成为一张销售订单，
并加上标记以便办公室对应。
It must not say 已收到 / received for a payment slip — your team verifies the money first.
收到付款截图时，不得说 已收到 或 received——须由团队先核实款项。
Product images only when the customer explicitly asks for one. 只有客户明确要求时，才会发送产品图片。
No price available → it says customer service will quote, rather than inventing a figure. Where several price tiers exist, it states the tier. 没有价格时，会说由客服报价，而不会编造金额。若有多个价格等级，会说明适用等级。
Image links must be real ones supplied by the system — it may not build a URL out of a product name. 图片连结必须是系统提供的真实连结，不得以产品名称自行拼凑网址。
Long replies are split into separate messages — a greeting and a product list arrive as two WhatsApp messages rather than one wall of text. That is deliberate, and it is why the assistant sometimes sends two or three messages in a row. 较长的回覆会拆成多则讯息——问候与产品清单会分成两则 WhatsApp 讯息，而非一大段文字。这是刻意设计的，也是助手有时会连续发出两三则讯息的原因。
Only one of them answers at a time. This is how that is decided.同一时间只有一方会回覆。以下是判定方式。
From your side there is nothing to switch off. Reply in the conversation and the assistant stops. That is the whole procedure. 就您而言，无需关闭任何开关。只要在对话中回覆，助手便会停止。整个操作就是这样。
Before the assistant replies to anything, it asks one question: has a human already taken this conversation? Four rules answer it, in order.
助手在回覆任何内容之前，都会先问一个问题：这段对话是否已由人员接手？ 以下四条规则会依序作答。
If the customer sent it before your team closed the conversation, CS has already dealt with it. The assistant stays quiet.若客户是在团队关闭对话之前发送的，代表客服已处理过，助手保持沉默。
If so, the assistant replies — regardless of anything that happened in earlier, closed conversations. A reopened chat starts clean.若是，助手会回覆——与先前已关闭对话中发生过什么无关。重新开启的对话会重新开始。
This is the main rule. The system looks back at the most recent message sent out to the customer. If a person sent it, CS has the conversation and the assistant stands down.这是主要规则。系统会回看最近一则发送给客户的讯息。若是人员发的，代表对话由客服掌握，助手即退场。
Messages from a closed conversation do not count. Without this, a CS reply from days ago would keep the assistant permanently silent for that customer.已关闭对话中的讯息不列入计算。若无此规则，几天前的一则客服回覆，会让助手对该客户永久静默。
“Any colleague”, not “the assigned one”. A reply from any human agent hands the conversation over — the assistant does not check who it was assigned to. 是「任何同事」，而非「被指派的那位」。任何一位人员回覆，对话即转由人员处理，助手不会检查该对话指派给谁。
Closing ends the session. The next message from that customer starts fresh and the assistant answers again. 关闭即结束该次工作阶段。该客户的下一则讯息会重新开始，助手会再次回覆。
While a conversation stays open with your reply as the last outgoing message, the assistant will not answer — however long that lasts. 只要对话保持开启，且最后一则对外讯息是您的回覆，助手就不会回答——无论持续多久。
Keeping a customer off the assistant entirely is an access-list change, not a per-conversation one. Section 12. 若要让某客户完全不由助手服务，应从存取名单调整，而非逐段对话处理。见第 12 节。
A missing quantity is not a handover. If the assistant only needs the quantity or the packing size, it asks the customer directly and stays in the order flow. Handing those to CS would defeat the point of the assistant. 缺少数量并不构成交接。若助手只是需要数量或包装规格，它会直接询问客户，并留在下单流程中。若把这些也交给客服，就失去了使用助手的意义。
The internal note is still written even when CS has taken over. If an order was created, your team gets the record of what was booked either way. 即使客服已接手，内部备注仍会写入。只要订单已建立，团队都会收到实际下单内容的记录。
Not every message is an order. These are handled automatically too.并非每则讯息都是订单，以下请求同样会自动处理。
Looks up an invoice and which payments have been applied against it — so “已经付了吗？” can be answered without anyone opening SQL Account. 查询发票及已冲销的款项，因此「已经付了吗？」无需有人开启 SQL Account 即可回答。
How much the customer owes. Read live from SQL Account at the moment of asking, not from a stored copy — so it is never out of date. 客户的应付金额。于询问当下即时读取自 SQL Account，而非使用已储存的副本，因此不会过时。
Returns and credits raised against the account. 账户下的退货与贷项记录。
Bank details, which areas are delivered to, and the minimum order for a given postcode. 银行资料、送货涵盖区域，以及各邮区的最低消费金额。
Reads back the current order before it is confirmed. Useful for the customer to check themselves — and it is the same list your team sees in the internal note. 在确认前列出目前的订单内容，方便客户自行核对——这份清单与团队在内部备注看到的一致。
Rebuilds an order from a previous invoice, so a regular customer does not have to list everything again. 依过往发票重建订单，让熟客无需重新列出所有品项。
Reads back the address on file, and can update it. Multi-outlet customers get the address of whichever outlet the order was for. 读取现有地址，亦可更新。多门市客户会取得该订单所属门市的地址。
Records a restock request for that product, using the supplier’s delivery schedule to work out when stock is next expected. 为该产品登记补货通知，并依供应商的送货排程推算下次到货时间。
Restock notifications depend on the supplier schedule sheet. If a product’s supplier has no delivery schedule recorded, the assistant says so plainly rather than inventing a date — and the request goes to your team instead. 补货通知取决于供应商排程表。若某产品的供应商没有登记送货排程，助手会如实说明，而不会编造日期，该请求会改由团队处理。
Customers send a bank transfer screenshot. The assistant reads it and logs it.客户传来转账截图，助手会读取内容并加以记录。
Same first step as a product photo — every image is sorted before anything else happens. Receipts and PDFs both work.与产品照片的第一步相同——所有图片都会先分类。收据图片与 PDF 皆可处理。
Amount, payment date, reference number, and the invoice number if it appears on the slip.金额、付款日期、参考编号，以及收据上若有出现的发票号码。
MYR 174.20 · 2026-04-14 · ref 52119 · IV-341462
One row per receipt, with the customer code, a link back to the original image, and a link to the conversation — so back-office can always see the source.每张收据一行，包含客户代号、原始图片连结与对话连结，方便后台随时查看来源。
Payment_Receipt_Recorder
This records only — it does not reconcile. Nothing is matched against open invoices, and nothing is knocked off in SQL Account. The row is a log entry for your back-office to work from; the actual accounting is still done by a person. 此功能仅作记录，不作核销。系统不会比对未结发票，也不会在 SQL Account 中冲销任何款项。该笔资料只是供后台作业的记录，实际账务仍由人员处理。
The sheet has a “Verified” column for back-office to tick once a receipt has been checked and applied. Treating that column as the working queue is the simplest way to make sure nothing sits unprocessed. 该试算表设有「Verified」栏位，供后台在核对并冲销后勾选。把这一栏当作待办清单，是确保没有收据被遗漏最简单的做法。
If a field cannot be read it is left blank rather than guessed — most often the invoice number, which many transfer slips simply do not show. 若某个栏位无法读取，系统会留空而非猜测——最常见的是发票号码，因为许多转账收据本来就没有。
Reading numbers off a photo is not perfect. The amount and date should be checked against the bank record before anything is applied. 从图片读取数字并非百分之百准确。冲销前应先与银行记录核对金额与日期。
The assistant works from its own copy of your data, refreshed on a schedule.助手使用的是您资料的副本，并依排程定期更新。
SQL Account is always the master. Change something there and the assistant picks it up automatically. Change it in the assistant’s copy and the next sync wipes it. SQL Account 永远是主资料源。在该处修改，助手会自动取得；在助手的副本中修改，下一次同步就会覆盖掉。
During business hours. Customers, invoices and payments refresh on the same tick. 营业时段内。客户、发票与付款也在同一节奏更新。
Re-reads the whole catalogue, repairing anything the quick sync missed. Worst case, a change is live within 2 hours. 重新读取整个目录，补齐快速同步遗漏的部分。最坏情况下，变更也会在 2 小时内生效。
Every 5 minutes between 08:00 and 12:00, when the office computer is back on. This is what rescues overnight orders. 08:00 至 12:00 之间每 5 分钟一次，即办公室主机重新开启时。夜间订单便是由此挽救。
All times are Malaysia time. Every scheduled job in the system runs on the same clock, so there is no timezone conversion to think about. 所有时间皆为马来西亚时间。系统中每一项排程作业都使用同一时钟，无需换算时区。
Read directly from the live system each time this guide is rebuilt, so it cannot fall out of date.每次重建本指南时，皆直接读取线上系统，因此不会过时。
| Sync | What it keeps up to date | How often |
|---|---|---|
| Customer | Customer accounts, codes and contact details | Every 10 minutes, 08:00-23:59 |
| Customer Area Sync | Which outlet an order belongs to, for customers with several branches | Every 30 minutes |
| Customer Invoice | Which invoices belong to which customer | Every 10 minutes, 08:00-23:59 |
| Frequent Purchase | Each customer’s buying history, used to help identify products | Weekly |
| Google Sync Workflow | Your Google Sheets settings — access list, nicknames, typo list, delivery areas | Access list every 5 minutes; all other sheets hourly |
| Invoice | Invoice records, so invoice enquiries can be answered | Every 10 minutes, 08:00-23:59 |
| Outstanding Full Sweep | A full refresh of every customer’s outstanding balance | Daily 13:00 |
| Payment | Payments received, so balances stay correct | Every 10 minutes, 08:00-23:59 |
| Retry Pending SOs | Retries orders that failed overnight while SQL Account was offline | Every 5 minutes, 08:00-11:59 |
| Sales Order | Sales Orders — including ones created outside the chatbot | Every 10 minutes, 08:00-23:59 |
| Stock Item | Product names, codes, prices and stock levels | Every 10 minutes, 08:00-23:59 |
| Stock Item Embedding | The product “fingerprints” used to match words and photos to products | Every 10 minutes, 08:00-23:59 |
| Stock Item Full Sync | A complete catalogue rebuild — repairs anything the 10-minute sync missed | Every 2 hours, 08:00-22:00 |
| Stock Item UOM Weekly Refresh | Packaging sizes — how many packets are in a carton, used for 箱 → 包 | Sundays 23:00 |
| 同步项目 | 更新什么资料 | 更新频率 |
|---|---|---|
| Customer | 客户账号、代号与联络资料 | 每 10 分钟（08:00-23:59） |
| Customer Area Sync | 订单所属门市，适用于拥有多间分店的客户 | 每 30 分钟 |
| Customer Invoice | 各张发票所属的客户 | 每 10 分钟（08:00-23:59） |
| Frequent Purchase | 各客户的购买记录，用于协助辨识产品 | 每周 |
| Google Sync Workflow | 您的 Google 试算表设定——存取名单、别名、错别字对照、送货区域 | 存取名单每 5 分钟；其余试算表每小时 |
| Invoice | 发票记录，供回答发票查询 | 每 10 分钟（08:00-23:59） |
| Outstanding Full Sweep | 完整更新每位客户的未结余额 | 每天 13:00 |
| Payment | 已收款项，使余额保持正确 | 每 10 分钟（08:00-23:59） |
| Retry Pending SOs | 重试因 SQL Account 离线而在夜间失败的订单 | 每 5 分钟（08:00-11:59） |
| Sales Order | 销售订单——包含非经机器人建立的订单 | 每 10 分钟（08:00-23:59） |
| Stock Item | 产品名称、代号、价格与库存 | 每 10 分钟（08:00-23:59） |
| Stock Item Embedding | 用于比对文字与照片的产品「指纹」 | 每 10 分钟（08:00-23:59） |
| Stock Item Full Sync | 完整重建产品目录——补齐 10 分钟同步遗漏的部分 | 每 2 小时（08:00-22:00） |
| Stock Item UOM Weekly Refresh | 包装规格——一箱有几包，用于「箱 → 包」换算 | 每周日 23:00 |
Wait for the 2-hourly rebuild before investigating. Most “stale data” reports resolve themselves. 请先等待每 2 小时的重建再追查。多数「资料过时」的回报都会自行解决。
That is the connection to SQL Account, not the assistant. Check the office computer and its antivirus. 这是与 SQL Account 的连线问题，而非助手。请检查办公室主机及其防毒软件。
Google Sheets. No developer needed.透过 Google 试算表，无需工程人员。
One rule: the sheet is the real record. Anything changed elsewhere is wiped by the next sync. 一条规则：试算表才是正本。在别处修改的内容，会被下一次同步清除。
Only the access list is fast. Everything else takes up to an hour — so don’t decide a nickname “didn’t work” after ten minutes. 只有存取名单是即时的。其余最长需要一小时——因此别在十分钟后就断定别名「没生效」。
Add a row to Chatbot_Controller: customer code + phone with no “+”. Live in 5 minutes. Then ask for the branch check to be run — it does not run by itself. 在 Chatbot_Controller 新增一行：客户代号 + 不含「+」的电话号码，5 分钟内生效。接着请人执行分店核对——它不会自动执行。
Add a row to Stock_Personalize_Term: customer code, the exact catalogue name, and their word for it. If the catalogue name isn’t exact, nothing happens and nothing warns you. 在 Stock_Personalize_Term 新增一行：客户代号、完全正确的目录名称，以及客户的叫法。若目录名称不完全一致，该行不会生效，也不会有任何提示。
Don’t skip the branch check after adding a customer. Without it, a stale record can send the new customer’s orders to the wrong account. This has happened. 新增客户后请勿略过分店核对。否则过时的资料可能把新客户的订单送往错误的账户。此情况确实发生过。
Where to look first, before escalating.在提报之前，先从这里查起。
Usually the message never reached the assistant. Check the customer is on the access list, and check respond.io’s routing rules. Often not the assistant’s fault. 多半是讯息根本没送到助手。请确认该客户在存取名单内，并检查 respond.io 的路由规则。通常不是助手的问题。
A respond.io rule can hold order-style messages for an hour or more before passing them on. The orders are late, not lost. respond.io 的规则可能把订单类讯息拦截一小时以上才转交。订单只是迟到，并未遗失。
That points at the SQL Account connection, not the assistant. Check the office computer and its antivirus. 这指向 SQL Account 的连线，而非助手。请检查办公室主机及其防毒软件。
Correct the order, then teach the nickname so it doesn’t repeat. Section 12. 先更正订单，再新增别名以免重覆发生。详见第 12 节。
Normal. The office computer is off overnight; orders retry automatically in the morning. 属正常现象。办公室主机夜间关机，订单会在早上自动重试。
Check, don’t wait. The automatic retry does not cover every case. 请主动查核，不要等待。自动重试无法涵盖所有情况。
Before asking for help, gather three things: the customer’s phone number and roughly when, what they actually wrote, and what the assistant replied plus the internal note. Almost every diagnosis starts by comparing those three. 寻求协助前，请先收集三项资讯：客户电话与大约时间、客户实际写了什么，以及助手的回复与内部备注。几乎所有诊断都是从比对这三者开始。
Stated plainly, so nothing is a surprise later.如实说明，以免日后措手不及。
The biggest source of error. Reduced by teaching nicknames; never eliminated. 最大的错误来源。可透过新增别名减少，但无法完全消除。
Messages sent within a second or two can be read out of order, detaching a quantity from its product. Fix identified, not yet applied. 在一两秒内连发的讯息可能被读成错误顺序，导致数量与产品脱钩。修正方式已确认，尚未套用。
Until 6 Aug 2026 the assistant confirmed removals that never happened — the line still ordered. Orders before that date where a customer cancelled a line are worth checking. 在 2026 年 8 月 6 日之前，助手会确认「已删除」，但实际并未删除，该行仍会下单。该日期之前客户曾要求取消某行的订单，值得逐一查核。
Pre-order items and products without a price tier get “customer service will quote”. 预订品项与未设定价格等级的产品，只会回覆「由客服报价」。
If a code changes in SQL Account, an order can book a blank line. Your team is notified, but it needs fixing by hand. 若 SQL Account 中的代号变更，订单可能产生空白行。系统会通知团队，但仍需人工更正。
Complaints, negotiations, special requests — it stops replying and waits for a person, by design. 投诉、议价、特殊要求——系统会停止回覆并等待人员处理，这是刻意的设计。
Everything above is already handled the same way: the assistant hands over rather than guessing, and every order leaves a note for your team. The system is built to fail visibly, not silently. 以上情况的处理方式一致：助手会交由人员处理，而不是猜测，且每张订单都会留下备注给团队。整个系统的设计原则，是让问题显现出来，而不是悄悄发生。