使用者預約送
大型樓宇,午高峰需要錯開
運力更好安排
- 預約先選時間和地點
- 接單系統分配任務
- 送達機器人送到該樓層

騎手
在機器人螢幕或小程式錄入樓宇、樓層和手機尾號,把餐放進指定倉。
機器人
沿已授權路線通過閘機與電梯,前往目標樓層。
員工
收到到達通知後,用手機尾號或取餐碼開倉領取。
接駁點不設中轉架,也不安排專人值守。取餐點、通行權限與核驗方式按專案配置。
服務如何運轉
放入、配送、到達、取餐和返回都有記錄。管理端和員工手機看的是同一張訂單。
1F 接駁 → 8F 取餐 → 1F 待命。進入後自動播放,也可點選步驟重放動作。
概念佈局與模擬訂單:省略中間樓層,樓層間距已壓縮。倉門運動為流程示意,未連線設備或業務系統。
騎手
餐品進入指定倉,任務已經生成。
機器人
機器人正在前往樓層,位置可以沿路線檢視。
機器人
機器人到達樓層,並通知員工。
員工
員工核驗後取走餐品。
機器人
機器人回到待命位置。
通知渠道和允許等待的時長按專案設定。取餐完成後,機器人返回為它配置的待命位置。
找到機器人,錄入訂單,把餐放進指定倉。交接在這裡完成。
登記樓層和取餐資訊,收到通知後核驗領取。
配置接駁點、路線和已接入的設備。管理端檢視任務、設備、異常和當天訂單。超時未取或路線受阻時,由現場處理。
訂單可以從員工、騎手或機器人螢幕開始。按樓宇把它們組合起來。
使用者預約送
大型樓宇,午高峰需要錯開
運力更好安排
騎手預約送
標準寫字樓
員工操作少,交接有記錄
螢幕下單
先跑通一條路線
互動最快,使用門檻最低
標準寫字樓以騎手預約送和螢幕下單為主。樓宇大,或午高峰訂單擠在短時間裡,再疊加使用者預約送。
從放餐到取餐,這個倉一直對應這一單。其餘倉門保持關閉。

一趟可以帶多單。餐和飲品也可以分倉放置。
原方案要求獨立電控倉門和核驗取餐。採購前需確認機器人版本、倉門硬體及軟體接入,不能僅憑型號預設具備。投遞時明確顯示指定倉編號,其餘倉保持鎖閉。
通知裡帶上倉編號。手機尾號或取餐碼都可以開啟對應的倉。
開倉、取餐和異常都可以回看。
系統提醒。仍未取走時,按現場規則遠端召回,或由人員協助處理。
哪些樓宇適用
適合騎手止步樓下、午高峰訂單集中,且員工可以在約定樓層取餐點及時領取的辦公樓。判斷依據是服務路徑與實際單量,而不只是樓宇面積。
單棟寫字樓或已獲授權的多樓棟;有騎手容易找到的接駁點、可通行的樓層取餐點,且物業能夠負責服務規則與異常響應。
電梯與門禁能否聯動、通訊是否覆蓋全程、通道是否暢通、餐袋是否裝得下,以及高峰單量和使用者取餐等待。勘察與實測後再確定運力。
路線存在臺階或無法通過的門檻,缺少通行授權,沒有安全接駁空間,或無人響應異常。送到工位、無人領取等要求需另行評估。
騎手止步樓外之後,壓力集中到樓下的堆放,和樓上等待取餐的人。
| 現場問題 | 直接影響 |
|---|---|
| 騎手無法入樓 | 外賣集中堆在樓下。 |
| 員工下樓取餐 | 午高峰大堂人流增加。 |
| 餐品散開擺放 | 找餐、錯拿和丟餐的可能變高。 |
| 配送狀態看不見 | 員工不知道餐品到了哪裡。 |
| 物業缺少管理工具 | 現場人員只能守在大堂維持秩序。 |
租戶能感知這項樓內服務,大堂不再堆著外賣。
外賣管理從守在大堂,轉到管理端檢視任務、設備和異常。
員工少在午休時間集中下樓。
在樓層附近取餐,少下樓,也少等待。
在接駁點完成交付,少等候,也少找人。
樓內路線與通行
騎手要找得到放餐的地方,員工要說得出取餐的位置。電梯、閘機和門禁按現場接入。
騎手到達
錄入資訊並放餐
沿授權路徑通過
前往目標樓層
通知、核驗、領取


騎手掃碼或輸入取餐資訊完成識別,把餐放進指定倉。機器人接單後上樓,投遞記錄留在這一單上。固定入口把排隊從主通道引開。
配送終點是專案配置的樓層取餐點。是否送到辦公室門口,以已建路線為準。
呼梯、選層、上下樓,以及通過閘機和門禁,都按這棟樓已經授權的路徑工作。
呼梯、選層,並完成上樓和下樓。
只在已授權的路徑裡通過。
按專案配置的樓層或區域權限開門。
原方案採用自帶 4G 通訊,樓內 Wi-Fi 不是核心部署前提;仍需測試電梯轎廂、梯廳和充電點的訊號覆蓋。電梯、閘機和門禁需完成相容性確認、授權與現場聯調。
左右滑動檢視完整表格。
| 核對項 | 部署前確認什麼 | 需要誰參與 |
|---|---|---|
| 服務範圍 | 明確服務樓棟、樓層、時段和取餐點。終點是電梯廳、企業櫃檯還是辦公室門口,需事先說清。 | 物業、企業租戶 |
| 電梯與通行 | 核對設備型號、可用介面、接入許可與授權路線;在高峰測試進梯、選層、出梯和返回全過程。 | 物業、設備服務方、實施團隊 |
| 路線與充電 | 按選定機型核對淨寬、轉彎空間、門檻、坡度和電梯間隙;預留有電源、不擋通行的安全充電點。 | 物業、實施團隊 |
| 通訊與通知 | 測試全路線 4G 覆蓋;明確到達通知渠道、收件資訊和通知未收到時的聯絡辦法。 | 實施團隊、運營負責人 |
| 餐品與倉格 | 用真實餐袋、飲品和大份訂單試裝,確認倉格尺寸、載重、防灑漏要求,以及可區分交付的實際裝載單量。 | 運營負責人、騎手、實施團隊 |
排班與運力
建議臺數 = 午高峰目標配送單量 ÷ 單臺機器人在該視窗內的有效配送單量,結果向上取整。有效單量需同時計入往返趟數與每趟實際裝載單量。以下三檔來自原方案的推薦配置,不代表固定承載保證。
2–4 臺機器人,1–2 部電梯,1 組閘機,1 個接駁點。配置使用者端、管理端和排程。發起方式用騎手預約送和螢幕下單。
4–8 臺機器人,2–4 部電梯,1–2 組閘機,1–2 個接駁點。增加騎手端。三種發起方式一起用。
8 臺以上,按樓棟分組。電梯按樓棟接入。閘機按多入口、多樓棟聯動。每棟單獨設接駁點。排程覆蓋這一組樓。以使用者預約送為主,再疊加騎手預約送和螢幕下單。使用者端和管理端都配置。
| 測算因素 | 對運力的影響 |
|---|---|
| 常駐人數 | 用來估計這棟樓的基礎單量。 |
| 午高峰訂單 | 用來看同一時段要送多少。 |
| 高峰視窗 | 通常是 1.5–2 小時。 |
| 倉格 | 決定一趟能分開帶幾單。倉格組合見 KAGO 產品頁。 |
| 單趟時長 | 樓層、電梯和取餐都會改變它。 |
| 可用電梯 | 影響機器人多久能週轉一趟。 |
| 取餐等待 | 影響下一單什麼時候開始。 |
臺數、倉格、電梯聯動和午高峰排班要放在一起看。以上是推薦區間。沿實際路線測算後,再按這棟樓設計方案。
訂單擠在一起時全量配送,人少時輪流充電。
10:30 前
檢查設備,充滿電,倉格就位。
11:00–13:30
全部投入配送,儘快週轉。
13:30–16:30
輪流充電,保留少量機器人接單。
16:30–18:30
補上這一輪。
夜間
維護設備,並核對當天訂單。
高峰集中投入配送,低峰輪流充電,在約定服務時段內保持可用。
管理端檢視任務、設備、異常和當天訂單。
| 系統層級 | 承擔的工作 |
|---|---|
| 使用者互動 | 使用者端、騎手端、機器人螢幕。 |
| 業務 | 預約、下單、到達通知、取餐核驗。 |
| 排程 | 任務分配、排班、路徑、狀態和異常。 |
| 樓宇通行 | 電梯、閘機、門禁,按現場接入。 |
| 機器人 | 接單、開倉、配送、到達、返回、充電。 |
試點與運營
實施週期取決於現場準備與通行設備接入。勘察後確定各階段交付物與時間,不預設統一的上線天數。
收集高峰單量、到單分佈、樓層分佈和餐品尺寸,標定接駁點、取餐點及充電點。
交付:服務範圍、路線勘察結果、初步運力測算。
確認機器人版本與倉門配置,聯調電梯、閘機、通知與排程,配置樓層、核驗方式和異常聯絡人。
交付:設備清單、授權地圖、聯調檢查表。
先覆蓋一個接駁點和部分樓層,完成騎手、員工與運營人員指引,演練排隊、超時未取與通行異常。
交付:高峰運作記錄、異常記錄、修訂後的配置建議。
對照約定指標回顧並關閉試點問題,確認排班、清潔、回充與支援交接後,再增加樓層或樓棟。
交付:驗收記錄、運營流程、擴展計劃。
原方案包含超時未取預警,以及遠端回收或人工處理。下表補充建議運營流程,具體動作、超時閾值和升級聯絡人需在上線前約定並演練。
左右滑動檢視完整表格。
| 異常場景 | 建議處置規則 | 閉環確認 |
|---|---|---|
| 暫無空閒機器人或倉格 | 提示下一次可用服務安排,明確騎手等待、預約其他時段或轉指定人工交接;避免把餐品臨時堆在機器人旁。 | 記錄排隊或人工交接,告知使用者取餐方式。 |
| 資訊填錯或餐品放錯 | 暫停受影響交接,由運營負責人核對訂單與倉號,按授權流程修正;不開啟無關訂單的倉格。 | 目的地與收件人修正,並留存交接記錄。 |
| 電梯故障或通道受阻 | 核查梯控、權限與障礙,僅在確認後使用已授權替代路線;無法恢復則安排人工交付或召回。 | 明確餐品位置,記錄最終交付人及交付結果。 |
| 通知未收到或超時未取 | 按約定渠道提醒並設定等待上限;超過上限後按規則召回或人工接管,告知使用者新的領取位置。 | 確認已領取或已回收,餐品有明確保管人。 |
| 斷網、低電量或設備異常 | 運營負責人核對任務和設備狀態,定位機器人並安排恢復;先確認離線可執行動作,不能假定斷網後仍可遠端操作。 | 核對受影響訂單,設備檢查後恢復服務。 |
| 灑漏、破損或疑似錯拿 | 暫停使用受影響倉格,核實交接記錄,並按專案規則完成清潔、客戶溝通與責任處理。 | 記錄清潔檢查和客訴結果,依據記錄確認責任。 |
以下是建議驗收維度,不是已承諾的 SLA。試點前約定目標值、觀察週期、樣本量及排除條件,失敗訂單和人工接管訂單也需納入回顧。
左右滑動檢視完整表格。
| 驗收維度 | 建議如何統計或測試 | 用於判斷什麼 |
|---|---|---|
| 高峰吞吐與排隊 | 統計約定高峰視窗的接單量、已取餐量,分時段記錄最大排隊量及投遞等待。 | 臺數、接駁點與預約規則能否承接峰值。 |
| 配送與取餐時長 | 分別統計放餐確認至到達、到達至領取的時長,檢視中位數、95 分位值及超時訂單。 | 實際等待是否符合租戶預期。 |
| 完成率與人工介入 | 已取餐訂單數 ÷ 已接收訂單數;同步列出自主完成、人工介入、取消和失敗訂單及原因。 | 日常運營與人員投入是否符合預期。 |
| 通行、通知與核驗 | 逐一測試授權樓層、電梯與閘機,驗證通知可達,取餐僅能開啟指定倉格。 | 從放餐到領取的完整交接是否可用。 |
| 異常與日常運營 | 演練約定異常,核對升級響應、餐品保管、清潔、回充及當天訂單核賬。 | 現場團隊能否恢復服務,且每單去向明確。 |
提供路線與點位授權,向員工說明新的取餐方式,保持通道暢通,並指定服務時段內的運營負責人及升級聯絡人。
明確交付硬體、軟體、設備接入、培訓、維護範圍、響應時段、備用設備安排,以及路線變更的處理方式。
明確設備購置或租賃、設備接入、通訊及持續服務費用,餐損客訴處理、訂單記錄訪問權限和儲存週期。原方案未提供價格或固定響應時效。
常見問題
以上摘自原方案第 8 頁,不作為所有 KAGO 配置的統一承諾。交付前需確認具體型號、整機及單倉載重與測試條件。空載續航和最高速度不能直接換算午高峰運力;原方案也未說明餐品溫控能力。
基礎模式是在樓層附近約定點取餐。送到辦公室門口需滿足地圖路線、通行權限與約定服務範圍;原方案沒有承諾送到工位。
接駁點不設固定中轉人員和中轉貨架,但仍需有人負責異常響應、清潔、日常檢查和服務恢復。
4G 解決通訊,不等於獲得呼梯和過閘權限。需要同時驗證網路覆蓋與樓宇設備接入。
原方案提供使用者預約、騎手掃碼與螢幕錄入。與外賣平台或租戶現有系統自動同步訂單,需要另外確認介面及接入範圍。
原方案沒有說明加熱、冷藏或溫度保證。需另外確認包裝、允許運輸及等待時長,以及特殊餐品的要求。
原方案將快遞、文件、商戶商品和會議物資列為後續延展。各業務需獨立確認流程與運力,優先保障約定午高峰服務;巡檢與清潔需按其他機器人任務評估。
部署準備
快遞、商戶餐食和飲品、文件、會議物資各自有交接。巡檢和清潔是另外的樓內任務。