Otter Beam / 指南
Otter Beam Workspace 中的資料流動
Otter Digital Pte. Ltd. · 2026 年 10 月 17 日更新
Otter Beam Workspace 把 Sales & CRM、採購與專案管理放在公司自己電腦上的同一個公司資料庫裡。當一個模組發生的事情需要讓另一個模組知道時，Otter Beam 會自動傳遞過去。我們把每一次這樣的傳遞稱為交接。本頁列出每一次交接：由什麼觸發、建立或修改什麼、什麼時候什麼都不做，以及無法完成時會怎樣。
每次交接的行為
- 同一時刻，同一個資料庫。交接與觸發它的操作在同一個資料庫交易中執行。要嘛兩者都儲存，要嘛都不儲存，任何人都不會看到只完成一半的狀態。
- 你的操作一定有效。即使交接本身無法完成（例如供應商被暫停），觸發它的操作仍會儲存。接受報價單後，即使後續步驟失敗，報價單依然是已接受狀態。失敗的交接會單獨回復並回報。
- 記錄者為 "Otter Beam"。交接建立或修改的紀錄由系統寫入，而不是由真人或代理寫入；每一項變更都會進入稽核紀錄，附有變更前後的值，並以交接編號（F1–F8）作為備註。
- 可在 Data health 中查看。每次執行都會記錄為 OK、Skipped（無事可做）或 Failed，並附上確切原因。失敗的執行還會產生一筆錯誤。排除原因後，可以在 Data health 中重試；重試只會處理尚未完成的部分。錯誤可以標記為已解決。
- 連鎖觸發有上限。一次交接可以觸發下一次（已接受的報價單建立銷售訂單，銷售訂單再建立專案）。連鎖最多四步，因此設定失誤也不會造成無限迴圈。
- 不必重複輸入。每一筆建立出來的明細都指回它的來源明細，所以數量、價格與進度可以從報價單一路追溯到最後一筆付款。
銷售流程
| # | 觸發條件 | 執行內容 | 什麼都不做的情況 | 失敗的情況 |
|---|---|---|---|---|
| F1 | 潛在客戶被轉換 | 如果潛在客戶沒有對應的客戶，則建立客戶（公司或個人）；如果潛在客戶寫明了聯絡人，則建立主要聯絡人；再建立一筆同時連結兩者的商機。潛在客戶標記為已轉換。 | — | 無法建立這些紀錄（原因顯示在 Data health 中）。 |
| F2 | 報價單被接受 | 用下一個訂單編號建立一張已確認的銷售訂單，複製報價單的所有明細與現場地址；報價單標記為已轉換，商機標記為成交。變更報價單則不建立新訂單，而是把它的明細加到原訂單上並更新合計。 | — | 無法建立訂單。報價單維持已接受狀態。 |
| F3 | 銷售訂單被確認（包括由 F2 確認） | 如果訂單中有需要啟動專案的品項，則建立專案（預算為這些品項的小計），並依專案範本建立任務，日期依序排開，任務之間是完成後才能開始的相依關係。 | 訂單中沒有會啟動專案的品項，或已經有專案。 | 沒有可用的專案範本。訂單維持已確認狀態。 |
| F8 | 付款被確認、分配或作廢，或發票被開立或作廢 | 重新計算每張受影響發票與供應商帳單的已付與應付金額，並更新為部分已付／已付清；同時更新銷售訂單的 "Invoiced x% · Paid y%" 與採購單的付款狀態。只計入已確認的付款。 | 這筆付款尚未分配給任何單據。 | — |
| — | 從還沒有任何明細的銷售訂單建立了發票 | 預先填入內容：標準發票複製尚未開票的數量；訂金發票或進度請款發票則新增一行約定比例的金額，並扣除先前已開的款項。 | — | — |
採購流程
| # | 觸發條件 | 執行內容 | 什麼都不做的情況 | 失敗的情況 |
|---|---|---|---|---|
| F4 | 為某個專案建立了請購單 | 把請購單連結到專案。未填價格的品項會依慣用供應商的上次價格預先填入（沒有慣用供應商時，採用已知的最低價）。 | — | — |
| F5 | 請購單被確認 | 依供應商把請購單拆成多張採購單草稿，價格取各供應商的上次採購價。所有品項都進入訂單後，請購單標記為已下單。 | — | 供應商被暫停或被封鎖，或某一行沒有供應商（"Vendor Tampines Paint & Coatings is on hold."）。其他供應商的訂單仍會建立；"Retry later" 只會補建缺少的訂單。 |
| F6 | 收貨單被過帳 | 把收到的數量加到採購單的明細上，並把訂單更新為部分收貨／已收貨（"Received 90%"）。 | — | — |
| F7 | 從採購單建立了供應商帳單，其明細發生變更，或帳單被確認 | 依採購單預先填入供應商帳單，並把帳單上的數量與單價和實際收貨情況比對（三方比對）：相符、數量不符（"Qty mismatch: billed 40, received 38"）、單價不符，或尚未收貨。確認後，會在採購單上記錄已開帳單的內容。 | — | — |
專案
| 觸發條件 | 執行內容 |
|---|---|
| 任務被啟動 | 所相依的任務尚未完成時會被拒絕（"Waits for: Site survey"）。 |
| 新增了一項相依關係 | 如果會形成迴圈，則會被拒絕。 |
| 任務、指派、預估或已記錄工時發生變更，或 F3 建立了任務 | 重新計算每位受影響成員未來幾週的每週工作量；Workload 檢視會用紅色標出分配過多。 |
AI 代理能做什麼、不能做什麼
代理從不直接寫入資料庫。它送出結構化請求，這些請求與真人走同樣的規則：同樣的驗證、同樣的交接、同樣的稽核紀錄。它建立的草稿在獲得核准前不會產生任何業務影響；凡是會對公司產生約束力的操作（確認、寄送、付款），都會停在核准卡片上，由負責人核准或駁回，通常在手機上完成。代理的讀取權限僅限於結構化的唯讀查詢。凡是包含個人資料（聯絡人與員工的姓名、電子郵件、電話）的回答都會被標記出來，並且代理被要求只在當前任務中使用這些資料。
