香港
AI agent development:Amazon 短訊購物對企業有何啟示

AI agent development:Amazon 短訊購物對企業有何啟示

截至 2026 年 11 月,Amazon 已確認開始讓客戶用短訊與 Alexa 對話購物,但這不是一個人人可用的新渠道。按 Amazon 自己發布的說明頁,短訊購物現時屬邀請制、僅限美國,客戶要有已驗證的手機號碼、開啟 RCS 對話的手機,以及支援 RCS 商業訊息的電訊商。如果你正在考慮開一條對話式銷售渠道,或者正為 ai agent development 排預算,要先分清楚兩件事:開通一個文字代理,同把它接到你自己的訂單與客戶系統,是兩項完全不同難度的工作。

重點摘要

  • Amazon 的短訊購物是邀請制、僅限美國,並非開放註冊的新銷售渠道。
  • 開通條件卡在手機與電訊商,不是卡在網店功能。
  • 代理會記住一次性偏好,但記憶只停留在對話層,不代表你的系統收得到。
  • DoorDash 披露第三方代理在其平台至今只落過數百張訂單,說明這條路仍屬早期。
  • 香港企業今天就能動手的一步,是把 WhatsApp 或網頁對話接上 CRM 與 ERP,不用等短訊功能。

Amazon 到底開放了什麼

TechCrunch 在 2026-11-06 報道,Amazon 表示會向部分美國客戶發出短訊,邀請他們啟用購物功能;有權限的客戶可以用自然語言向 Alexa 搜尋商品、加入購物車以至完成購買。報道亦指出,這個文字代理建基於近期一批購物導向的 Alexa 升級,因此可以管理清單、追蹤價格、跨網站搜尋商品、比較產品以及查詢訂單狀態。

換句話說,它把原本分散在語音與 App 的能力,搬到一個最普及的介面:短訊。Amazon 的官方說明頁把用途寫得更具體,可以一次過把整張購物清單傳過去、上載相片找相似的貨品、傳一份食譜讓代理把材料加進購物車。

讀者第一個要問的問題因此很簡單:這是一個我可以報名用的渠道,還是 Amazon 自己的客戶服務升級?答案是後者。

開通條件:為什麼卡在手機與電訊商

這是本文最值得企業留意的一段,因為它揭示「文字代理」在香港落地的實際門檻。按 Amazon 的說明頁,現時需要四樣東西同時成立:個人 Amazon 帳戶、已驗證的手機號碼、已開啟 RCS 對話的手機,以及支援 RCS 商業訊息的電訊商。

Amazon 亦列明,多數安裝 Google Messages 的 Android 手機,以及運行 iOS 18 或以上版本的 iPhone 都支援 RCS 對話;但 Google Fi 的 iPhone 用戶暫不支援。這一句看似技術細節,其實是整個渠道的分水嶺:RCS 商業訊息不是單純開一個 SMS 號碼就成事,它需要電訊商一側配合,而不同市場的電訊商支援程度並不一樣。

所以如果你的判斷是「香港企業應該立即開一條短訊購物線」,這個前提先要被打問號。短訊渠道的開通速度,取決於電訊商而不是你的網店。

桌上智能手機亮著短訊對話畫面,窗外遠處有城市天際線與訊號基站。

代理記得你一次,然後呢

Amazon 說明頁談到記憶時舉了兩個例子:告訴它「我們只喝燕麥奶」,或者「我兒子現在穿 youth size 12」,下次購物時它會記得。這個設計的商業意義值得拆開看。

它記住的是「你這次買給誰、買什麼尺碼」這一類一次性偏好,用途是減少重複輸入。但記憶存放在代理這一層,並不等於你的品牌系統拿得到。如果客戶是在 Amazon 上完成對話,商家看到的是一張訂單;如果客戶是在你自己的 WhatsApp 或網站上完成對話,你要自己決定這些偏好寫進哪裡、由誰讀取、下次由哪個系統拿出來用。

這正是很多企業在導入 ai 代理 時低估的一步:聊天記錄留得下來,偏好卻沒有變成客戶檔案的一部分。代理下一季換了版本,客人又要重講一次。做 ai agent development 規劃時,這一項要寫進需求書,否則上線後才發現沒有欄位可存。

「幫人買」不等於「幫你賣」:訂單量的現實

TechCrunch 同篇報道引述外賣平台 DoorDash 在上個月表示,第三方代理在其平台至今只落過數百張訂單,並指該公司打算集中發展自己的文字代理。這個數字是整篇報道最應該被放大的一句。

原因很直接:如果連 DoorDash 這種訂單密度高、決策成本低的場景,第三方代理的訂單量仍然停留在數百張,那麼百貨、家品、禮品這類需要比較與信任的品類,短期內更不可能靠代理帶來可觀的成交。趨勢不必否定,預算要投在正確的位置。

對香港中小企而言,把代理當成「新流量入口」去追逐,與把它當成「對話沉澱與轉化工具」去建設,是兩種完全不同的投資。前者賭平台開放,後者改善自己的轉化率,而後者今天就能做。這也是 ai 代理 值得先做的一邊。

香港企業真正要接的是哪一層系統

從 Amazon 的案例抽出來看,一個可以做生意的文字代理至少牽涉四層,缺一層就接不到訂單。

第一層是對話入口:WhatsApp、Messenger、網頁聊天或短訊。這一層最容易買,市場上的工具也最多。第二層是對話內容的結構化:把客戶講的尺碼、預算、交貨期變成欄位,而不是留在一段自由文字裡。第三層是交易與客戶資料:商品、訂單、購買紀錄要能與對話對上。第四層是歸因:哪一段對話最後帶來收入,要能回到廣告與渠道。

Amazon 的優勢落在第三層與第四層,這兩層它本來就有。這也是為何它可以讓代理「幫人買」:商品目錄、訂單系統與客戶帳戶都在同一個屋簷下。大部分企業沒有這個條件。

要補第三層,就繞不開 erp 系統 整合:關鍵在讓對話產生的商機欄位與訂單資料寫回企業既有的客戶與交易系統,接一個聊天窗並不足夠。這一層做不好,前面的對話再多,也只是散落在幾個後台裡的訊息。

職員在辦公室同時查看手機對話與電腦訂單表格,兩者之間以光線相連。

這個建議不適合哪類公司

這裡也講清楚邊界。以下三類公司,現階段不必急著投資對話式代理。

第一類是單價極高、決策週期長的 B2B 供應商,例如大型設備或工程項目。這類交易的談判發生在會議與報價單,不在短訊裡;把資源放在報價流程與 CRM 記錄更實際。第二類是產品線極窄、回購週期極短的零售商:如果九成生意來自同一個爆款,對話代理帶來的邊際效益有限。第三類是資料尚未整理的企業,商品資料不齊、訂單系統與客戶名單各據一方,先整理資料,再談代理,否則代理只會把混亂自動化。

反過來說,最適合先做的一類是:已有穩定詢盤量、產品有選項需要引導、並且願意讓人工接手完成成交的企業。

從「寫一個代理」到「開一條購物對話渠道」:兩件不同的事

開發者教程那一類搜尋結果,教的是用程式碼把一個代理搭出來:選模型、寫工具、測回應。那條路解決的是「代理會不會答」。

Does Boot dev use generative AI:一個與購物渠道無關的搜尋結果

Boot dev 一類的教學把重點放在「用 Python 寫一個代理」,它回答的是程式碼層面的問題。這類內容對開發者有用,但它處理不到本文的問題:一條可以收單的購物對話渠道,卡住的地方通常不在程式碼,而在手機與電訊商是否支援 RCS、企業的訂單系統是否接得上、對話產生的欄位有沒有人接收。寫完一個能跑的代理,同開完一條渠道之間,隔住的是營運與系統整合的工作。Amazon 這次披露的動作考驗的是另一件事:一條渠道能不能接住真金白銀的交易。前者的瓶頸在工程能力,後者的瓶頸在手機、電訊商、訂單系統與客戶資料。兩件事都要做,次序與負責人卻完全不同,把兩者混為一談,結果往往是代理跑得通,訂單進不來。

這個分野對香港企業的直接含義是:如果你找的是寫程式的人,你要先講清楚終點是示範還是營運;如果終點是營運,需求書裡就一定要有渠道開通條件、資料欄位與系統寫回這幾項。

會議室長桌兩端,一人對著電腦寫程式,另一人翻閱營運流程文件。

Topkee 的看法:對話商務的難點在交易系統,不在聊天窗

Topkee 在這個題目上的立場很明確:真正要處理的是把對話沉澱成可追蹤的線索,聊天視窗本身解決不了這一半。其 YME 對話營銷把 WhatsApp、Messenger 與網頁聊天的客戶對話集中到同一個結構化系統,由人工智能與人工協同回應,支援多語言、意圖識別與合適時機轉人工,並與線索系統同步;定位是全渠道詢盤捕獲,目標是把對話轉化為可追蹤的增長線索。

同一個邏輯也出現在其 Care 售前助手:先按客戶語言答覆並提供建議問題,再用商家自訂表單補齊商機欄位,資料收集完成後邀請人工坐席接手,交付物是客戶答覆、建議問題、線索表單與交接記錄。這正好回答 Amazon 案例裡沒有講的那一半:代理解決諮詢之後,由誰接手。

要把這一層接上交易,則要靠 TTO CDP 與工程化整合:客戶數據平台按 Server、Website、Ecommerce、Livechat、Raw Data、CRM 及 Advertising 分類組織集成,電商側可同步 Shopify、Shopline、WooCommerce、Magento 與 OpenCart 等平台的訂單與購買事件,Livechat 側可把 YME 聯絡人事件與 WhatsApp 對話接入。Topkee Cloud 的營銷整合文件亦寫明,客戶現有的 CRM、ERP、電商商城或舊數據庫會被真正接入,接入通常只需數天而不是數月,鏈路為廣告點擊、線索、對話、商機到收入。這裡的 erp 系統 整合 指的是系統之間的資料互通,並非換掉你現有的 ERP。

需要講清楚的是:Topkee 的對話渠道是 WhatsApp、Messenger 與網頁聊天,不含短訊,也沒有與 Amazon 或 Alexa 合作,更不會替客戶完成消費者下單。Amazon 的短訊代理只是這條行業趨勢的一個樣本,照搬不了。

下一步點做

如果你看完仍然不確定從哪一格開始,建議先做一次「對話到訂單」的現况盤點:抽最近一個月的二十段詢盤對話,逐段問它最後走到哪裡,成交、報價還是根本沒有記錄。盤點結果會直接告訴你缺的是入口、表單還是歸因。做法可以先看 ai agent development 的說明,再對照自己的流程。

需要一個現成的參照,可以先看 Topkee 的 TTO Funnel Tuning Agent,了解漏斗每一環的數據如何被串起來;若你的業務實際上以電話詢盤為主,Voice Agent 的說明頁會比短訊路線更貼近你的場景。

常見問題

香港企業現在可以開通 Amazon 的短訊購物功能嗎?

不可以。按 Amazon 的說明頁,這項功能現時屬邀請制、僅限美國,並要求客戶具備已驗證的手機號碼、支援 RCS 對話的手機,以及支援 RCS 商業訊息的電訊商。它是一項美國市場的客戶體驗升級,不是對外開放的工具。

香港的 iPhone 用戶能不能用 RCS 商業訊息?

Amazon 的說明只涵蓋美國情況:運行 iOS 18 或以上版本的 iPhone 支援 RCS 對話,但 Google Fi 的 iPhone 用戶暫不支援。香港實際能否使用,取決於本地電訊商是否支援 RCS 商業訊息,這一點 Amazon 的文件沒有交代。

文字代理會記住客戶偏好,是否等於品牌也拿得到?

不等於。Amazon 舉的例子是記住「我們只喝燕麥奶」或兒子的尺碼,記憶存放在代理那一層。品牌要拿到同一份偏好,必須自己設計表單、欄位與寫入系統的流程,否則對話結束就沒有留下可用的客戶資料。

第三方 AI 代理真的會帶來大量訂單嗎?

目前看不到這個證據。DoorDash 表示第三方代理在其平台至今只落過數百張訂單,並打算集中發展自家文字代理。對香港企業而言,短期內更合理的期望是改善自家渠道的對話轉化,而不是等待代理帶來流量。

我的公司需要先做 ERP 整合,還是先開對話渠道?

先做盤點,不要先買工具。如果詢盤量穩定但成交紀錄缺失,缺的多數是表單與 CRM 寫入;如果訂單與庫存資料本身分散,則要先整理系統。對話渠道可以在盤點之後再加,次序反過來只會多付一次整合成本。

Sources

  1. "After blocking Muse, Amazon now lets users text Alexa to help them shop", TechCrunch, 2026-11-06. https://techcrunch.com/2026/11/06/after-blocking-muse-amazon-now-lets-users-text-alexa-to-help-them-shop/
  2. "Shop by text with Alexa Shopping", Amazon, 無發布日期. https://www.amazon.com/text-alexa-shopping
分享到:
日期: 2026-11-11
Wing Yau

作者

Wing Yau

Marketing Manager