跳至正文

寫字樓外賣配送服務方案

騎手止步接駁點。餐送到樓層附近。

午高峰,騎手在固定接駁點完成投遞。機器人承擔樓內運輸,員工在樓層附近驗證取餐。物業在管理端檢視每一單的狀態。

騎手在寫字樓大堂接駁點持餐袋站在 KAGO 旁,準備交接。
  1. 騎手

    接駁點放餐

    在機器人螢幕或小程式錄入樓宇、樓層和手機尾號,把餐放進指定倉。

  2. 機器人

    樓內配送

    沿已授權路線通過閘機與電梯,前往目標樓層。

  3. 員工

    樓層附近取餐

    收到到達通知後,用手機尾號或取餐碼開倉領取。

接駁點不設中轉架,也不安排專人值守。取餐點、通行權限與核驗方式按專案配置。

服務如何運轉

每一單都留在同一條狀態上。

放入、配送、到達、取餐和返回都有記錄。管理端和員工手機看的是同一張訂單。

跟著一份外賣,走完樓內這一程。

1F 接駁 → 8F 取餐 → 1F 待命。進入後自動播放,也可點選步驟重放動作。

8F1F省略 2–7F電梯閘機接駁點樓層取餐點辦公區
1F · 接駁點輸入收餐人手機尾號 4 位

概念佈局與模擬訂單:省略中間樓層,樓層間距已壓縮。倉門運動為流程示意,未連線設備或業務系統。

  1. 騎手

    已放入

    餐品進入指定倉,任務已經生成。

  2. 機器人

    配送中

    機器人正在前往樓層,位置可以沿路線檢視。

  3. 機器人

    已到達

    機器人到達樓層,並通知員工。

  4. 員工

    已取餐

    員工核驗後取走餐品。

  5. 機器人

    已返回

    機器人回到待命位置。

通知渠道和允許等待的時長按專案設定。取餐完成後,機器人返回為它配置的待命位置。

騎手、員工、物業,各做一段。

  • 騎手

    找到機器人,錄入訂單,把餐放進指定倉。交接在這裡完成。

  • 員工

    登記樓層和取餐資訊,收到通知後核驗領取。

  • 物業

    配置接駁點、路線和已接入的設備。管理端檢視任務、設備、異常和當天訂單。超時未取或路線受阻時,由現場處理。

三種方式發起,送的是同一趟。

訂單可以從員工、騎手或機器人螢幕開始。按樓宇把它們組合起來。

使用者預約送

大型樓宇,午高峰需要錯開

運力更好安排

  1. 預約先選時間和地點
  2. 接單系統分配任務
  3. 送達機器人送到該樓層

騎手預約送

標準寫字樓

員工操作少,交接有記錄

  1. 掃碼錄入樓宇、樓層和取餐資訊
  2. 接單系統生成任務
  3. 送達機器人送到該樓層

螢幕下單

先跑通一條路線

互動最快,使用門檻最低

  1. 錄入在螢幕輸入樓宇、樓層和取餐資訊
  2. 接單任務立即生成
  3. 送達機器人送到該樓層

標準寫字樓以騎手預約送和螢幕下單為主。樓宇大,或午高峰訂單擠在短時間裡,再疊加使用者預約送。

倉是這次交接的介面。

從放餐到取餐,這個倉一直對應這一單。其餘倉門保持關閉。

KAGO 位於接駁臺旁,臺上放著封裝餐袋和固定在杯託中的飲品。
餐品包裝與倉格配置需按專案核對。
  • 分開裝載

    一趟可以帶多單。餐和飲品也可以分倉放置。

  • 指定開倉

    原方案要求獨立電控倉門和核驗取餐。採購前需確認機器人版本、倉門硬體及軟體接入,不能僅憑型號預設具備。投遞時明確顯示指定倉編號,其餘倉保持鎖閉。

  • 尾號或取餐碼

    通知裡帶上倉編號。手機尾號或取餐碼都可以開啟對應的倉。

  • 狀態留在訂單上

    開倉、取餐和異常都可以回看。

  • 超時未取

    系統提醒。仍未取走時,按現場規則遠端召回,或由人員協助處理。

哪些樓宇適用

先確認樓宇是否適合,再決定配幾臺。

適合騎手止步樓下、午高峰訂單集中,且員工可以在約定樓層取餐點及時領取的辦公樓。判斷依據是服務路徑與實際單量,而不只是樓宇面積。

  • 適合優先試點

    單棟寫字樓或已獲授權的多樓棟;有騎手容易找到的接駁點、可通行的樓層取餐點,且物業能夠負責服務規則與異常響應。

  • 需要現場驗證

    電梯與門禁能否聯動、通訊是否覆蓋全程、通道是否暢通、餐袋是否裝得下,以及高峰單量和使用者取餐等待。勘察與實測後再確定運力。

  • 先補齊條件再上線

    路線存在臺階或無法通過的門檻,缺少通行授權,沒有安全接駁空間,或無人響應異常。送到工位、無人領取等要求需另行評估。

午高峰卡在大堂。

騎手止步樓外之後,壓力集中到樓下的堆放,和樓上等待取餐的人。

現場問題直接影響
騎手無法入樓外賣集中堆在樓下。
員工下樓取餐午高峰大堂人流增加。
餐品散開擺放找餐、錯拿和丟餐的可能變高。
配送狀態看不見員工不知道餐品到了哪裡。
物業缺少管理工具現場人員只能守在大堂維持秩序。
同一條接駁,各方看到的變化不同。
  • 業主

    租戶能感知這項樓內服務,大堂不再堆著外賣。

  • 物業

    外賣管理從守在大堂,轉到管理端檢視任務、設備和異常。

  • 企業租戶

    員工少在午休時間集中下樓。

  • 員工

    在樓層附近取餐,少下樓,也少等待。

  • 騎手

    在接駁點完成交付,少等候,也少找人。

樓內路線與通行

接駁點避開主通道。

騎手要找得到放餐的地方,員工要說得出取餐的位置。電梯、閘機和門禁按現場接入。

  1. 樓宇入口

    騎手到達

  2. 接駁點

    錄入資訊並放餐

  3. 閘機

    沿授權路徑通過

  4. 電梯

    前往目標樓層

  5. 取餐點

    通知、核驗、領取

路線示意,點位與通行設備按專案配置。
KAGO 在平整的寫字樓梯廳內,停在開啟的電梯門前。
員工在 KAGO 旁持已領取的餐袋和手機。

接駁點可以放在

  • 大堂側邊服務區
  • 閘機外側
  • 貨梯廳或服務入口附近
  • 靠近電梯、不佔主通道的位置

在接駁點完成的事

騎手掃碼或輸入取餐資訊完成識別,把餐放進指定倉。機器人接單後上樓,投遞記錄留在這一單上。固定入口把排隊從主通道引開。

配送終點是專案配置的樓層取餐點。是否送到辦公室門口,以已建路線為準。

機器人接入這棟樓的通行體系。

呼梯、選層、上下樓,以及通過閘機和門禁,都按這棟樓已經授權的路徑工作。

  • 電梯

    呼梯、選層,並完成上樓和下樓。

  • 閘機

    只在已授權的路徑裡通過。

  • 門禁

    按專案配置的樓層或區域權限開門。

原方案採用自帶 4G 通訊,樓內 Wi-Fi 不是核心部署前提;仍需測試電梯轎廂、梯廳和充電點的訊號覆蓋。電梯、閘機和門禁需完成相容性確認、授權與現場聯調。

現場需要具備的條件

左右滑動檢視完整表格。

核對項部署前確認什麼需要誰參與
服務範圍明確服務樓棟、樓層、時段和取餐點。終點是電梯廳、企業櫃檯還是辦公室門口,需事先說清。物業、企業租戶
電梯與通行核對設備型號、可用介面、接入許可與授權路線;在高峰測試進梯、選層、出梯和返回全過程。物業、設備服務方、實施團隊
路線與充電按選定機型核對淨寬、轉彎空間、門檻、坡度和電梯間隙;預留有電源、不擋通行的安全充電點。物業、實施團隊
通訊與通知測試全路線 4G 覆蓋;明確到達通知渠道、收件資訊和通知未收到時的聯絡辦法。實施團隊、運營負責人
餐品與倉格用真實餐袋、飲品和大份訂單試裝,確認倉格尺寸、載重、防灑漏要求,以及可區分交付的實際裝載單量。運營負責人、騎手、實施團隊

排班與運力

先選一檔規模,再按這棟樓測算。

建議臺數 = 午高峰目標配送單量 ÷ 單臺機器人在該視窗內的有效配送單量,結果向上取整。有效單量需同時計入往返趟數與每趟實際裝載單量。以下三檔來自原方案的推薦配置,不代表固定承載保證。

單棟標準寫字樓

2–4 臺機器人,1–2 部電梯,1 組閘機,1 個接駁點。配置使用者端、管理端和排程。發起方式用騎手預約送和螢幕下單。

中大型寫字樓

4–8 臺機器人,2–4 部電梯,1–2 組閘機,1–2 個接駁點。增加騎手端。三種發起方式一起用。

多樓棟或園區

8 臺以上,按樓棟分組。電梯按樓棟接入。閘機按多入口、多樓棟聯動。每棟單獨設接駁點。排程覆蓋這一組樓。以使用者預約送為主,再疊加騎手預約送和螢幕下單。使用者端和管理端都配置。

這些數會改變臺數
測算因素對運力的影響
常駐人數用來估計這棟樓的基礎單量。
午高峰訂單用來看同一時段要送多少。
高峰視窗通常是 1.5–2 小時。
倉格決定一趟能分開帶幾單。倉格組合見 KAGO 產品頁。
單趟時長樓層、電梯和取餐都會改變它。
可用電梯影響機器人多久能週轉一趟。
取餐等待影響下一單什麼時候開始。

臺數、倉格、電梯聯動和午高峰排班要放在一起看。以上是推薦區間。沿實際路線測算後,再按這棟樓設計方案。

排班圍繞午高峰。

訂單擠在一起時全量配送,人少時輪流充電。

  1. 10:30 前

    準備

    檢查設備,充滿電,倉格就位。

  2. 11:00–13:30

    午高峰

    全部投入配送,儘快週轉。

  3. 13:30–16:30

    輪充接單

    輪流充電,保留少量機器人接單。

  4. 16:30–18:30

    下午與晚餐

    補上這一輪。

  5. 夜間

    回充與核對

    維護設備,並核對當天訂單。

高峰集中投入配送,低峰輪流充電,在約定服務時段內保持可用。

一套系統把人、機器人和樓宇接在一起。

管理端檢視任務、設備、異常和當天訂單。

系統層級承擔的工作
使用者互動使用者端、騎手端、機器人螢幕。
業務預約、下單、到達通知、取餐核驗。
排程任務分配、排班、路徑、狀態和異常。
樓宇通行電梯、閘機、門禁,按現場接入。
機器人接單、開倉、配送、到達、返回、充電。

試點與運營

從現場勘察,走到真實午高峰試運轉。

實施週期取決於現場準備與通行設備接入。勘察後確定各階段交付物與時間,不預設統一的上線天數。

  1. 勘察與定界

    收集高峰單量、到單分佈、樓層分佈和餐品尺寸,標定接駁點、取餐點及充電點。

    交付:服務範圍、路線勘察結果、初步運力測算。

  2. 配置與聯調

    確認機器人版本與倉門配置,聯調電梯、閘機、通知與排程,配置樓層、核驗方式和異常聯絡人。

    交付:設備清單、授權地圖、聯調檢查表。

  3. 午高峰試點

    先覆蓋一個接駁點和部分樓層,完成騎手、員工與運營人員指引,演練排隊、超時未取與通行異常。

    交付:高峰運作記錄、異常記錄、修訂後的配置建議。

  4. 驗收與擴展

    對照約定指標回顧並關閉試點問題,確認排班、清潔、回充與支援交接後,再增加樓層或樓棟。

    交付:驗收記錄、運營流程、擴展計劃。

配送暫停時,誰來接手這一單。

原方案包含超時未取預警,以及遠端回收或人工處理。下表補充建議運營流程,具體動作、超時閾值和升級聯絡人需在上線前約定並演練。

檢視異常處理清單

左右滑動檢視完整表格。

異常場景建議處置規則閉環確認
暫無空閒機器人或倉格提示下一次可用服務安排,明確騎手等待、預約其他時段或轉指定人工交接;避免把餐品臨時堆在機器人旁。記錄排隊或人工交接,告知使用者取餐方式。
資訊填錯或餐品放錯暫停受影響交接,由運營負責人核對訂單與倉號,按授權流程修正;不開啟無關訂單的倉格。目的地與收件人修正,並留存交接記錄。
電梯故障或通道受阻核查梯控、權限與障礙,僅在確認後使用已授權替代路線;無法恢復則安排人工交付或召回。明確餐品位置,記錄最終交付人及交付結果。
通知未收到或超時未取按約定渠道提醒並設定等待上限;超過上限後按規則召回或人工接管,告知使用者新的領取位置。確認已領取或已回收,餐品有明確保管人。
斷網、低電量或設備異常運營負責人核對任務和設備狀態,定位機器人並安排恢復;先確認離線可執行動作,不能假定斷網後仍可遠端操作。核對受影響訂單,設備檢查後恢復服務。
灑漏、破損或疑似錯拿暫停使用受影響倉格,核實交接記錄,並按專案規則完成清潔、客戶溝通與責任處理。記錄清潔檢查和客訴結果,依據記錄確認責任。

用哪些證據判斷試點符合預期。

以下是建議驗收維度,不是已承諾的 SLA。試點前約定目標值、觀察週期、樣本量及排除條件,失敗訂單和人工接管訂單也需納入回顧。

檢視驗收維度與責任約定

左右滑動檢視完整表格。

驗收維度建議如何統計或測試用於判斷什麼
高峰吞吐與排隊統計約定高峰視窗的接單量、已取餐量,分時段記錄最大排隊量及投遞等待。臺數、接駁點與預約規則能否承接峰值。
配送與取餐時長分別統計放餐確認至到達、到達至領取的時長,檢視中位數、95 分位值及超時訂單。實際等待是否符合租戶預期。
完成率與人工介入已取餐訂單數 ÷ 已接收訂單數;同步列出自主完成、人工介入、取消和失敗訂單及原因。日常運營與人員投入是否符合預期。
通行、通知與核驗逐一測試授權樓層、電梯與閘機,驗證通知可達,取餐僅能開啟指定倉格。從放餐到領取的完整交接是否可用。
異常與日常運營演練約定異常,核對升級響應、餐品保管、清潔、回充及當天訂單核賬。現場團隊能否恢復服務,且每單去向明確。

上線前,把服務範圍與責任寫清楚。

  • 物業與租戶

    提供路線與點位授權,向員工說明新的取餐方式,保持通道暢通,並指定服務時段內的運營負責人及升級聯絡人。

  • 實施與支援團隊

    明確交付硬體、軟體、設備接入、培訓、維護範圍、響應時段、備用設備安排,以及路線變更的處理方式。

  • 費用與資料約定

    明確設備購置或租賃、設備接入、通訊及持續服務費用,餐損客訴處理、訂單記錄訪問權限和儲存週期。原方案未提供價格或固定響應時效。

常見問題

KAGO 配送機器人

樓內這一段,由 KAGO 完成。

KAGO 提供靈活倉格組合。原方案中的電控開倉與核驗取餐還需確認具體版本及接入配置;產品頁列有 KAGO 與 KAGO MAX 的差異,以及裝載限制。

了解 KAGO

原方案中的設備參考

淨重
47.5 kg
載重
20 kg
移動速度
0–2 m/s
倉格設定
2 / 3 / 4 格
空載續航
8 小時
充電時長
3 小時
爬坡能力
≤ 7°
可通過障礙高度
< 2 cm

以上摘自原方案第 8 頁,不作為所有 KAGO 配置的統一承諾。交付前需確認具體型號、整機及單倉載重與測試條件。空載續航和最高速度不能直接換算午高峰運力;原方案也未說明餐品溫控能力。

試點前,客戶常問的幾個問題。

是否能送到每個員工的工位?

基礎模式是在樓層附近約定點取餐。送到辦公室門口需滿足地圖路線、通行權限與約定服務範圍;原方案沒有承諾送到工位。

自助投遞是否意味著完全不需要人員?

接駁點不設固定中轉人員和中轉貨架,但仍需有人負責異常響應、清潔、日常檢查和服務恢復。

有 4G 是否就不用接電梯和門禁了?

4G 解決通訊,不等於獲得呼梯和過閘權限。需要同時驗證網路覆蓋與樓宇設備接入。

是否已經打通外賣平台訂單?

原方案提供使用者預約、騎手掃碼與螢幕錄入。與外賣平台或租戶現有系統自動同步訂單,需要另外確認介面及接入範圍。

能否保溫、加熱或冷藏?

原方案沒有說明加熱、冷藏或溫度保證。需另外確認包裝、允許運輸及等待時長,以及特殊餐品的要求。

以後能否同時配送快遞或其他物品?

原方案將快遞、文件、商戶商品和會議物資列為後續延展。各業務需獨立確認流程與運力,優先保障約定午高峰服務;巡檢與清潔需按其他機器人任務評估。

部署準備

從最忙的一棟樓開始。

先定一個接駁點和一個取餐樓層。在真實的午高峰走完放餐、上樓、取餐和返回,再增加樓層和接駁點。

諮詢專案
單量與時段
常駐人數、午高峰訂單、服務視窗和預計取餐時長。
接駁與取餐點
騎手指引、放餐空間、不擋主通道的位置,以及說得清的樓層取餐點。
樓宇通行
電梯、閘機、門禁和充電位置。通行設備按現場接入。
運營規則
發起方式、核驗、通知、超時未取,以及異常由誰處理。

快遞、商戶餐食和飲品、文件、會議物資各自有交接。巡檢和清潔是另外的樓內任務。