應用開始有人使用，往往被當成落地的證明。真正要問的是：誰在審核輸出、誰在改流程、模型與人工成本如何隨用量上升，以及對方停止使用時如何交接。沒有這筆帳，試用很容易被誤認作成熟服務，後續預算也無從談起。
試用提供線索，持續服務仍需驗證
使用記錄能提供需求線索，但還要看輸出是否被採用、任務是否完成，以及過程投入了多少人工。主管覆核、前線改寫和再次向客戶確認，都應計入交付成本。評估時可同時記錄使用頻率、採用情況、處理工時和責任分工，避免只以試用人數判斷服務是否成熟。
反過來看，暫時無人使用也不必然代表方向錯誤，可能只是入口、權限或培訓尚未到位。但有人使用同樣不能推出維護成本可控。設想一個銷售團隊每天把客戶跟進交給應用草擬，表面省下寫作時間，實際卻新增抽查、改錯和例外上報。用量上升時，省下的時間可能被審核重新喫掉。成本要按完整動作計算，而不是按功能清單計算。
從自用到對外，範圍會重新打開
一套自己用得順的流程，轉給外部客戶時往往要重做邊界。現場資料的格式、審批層級、例外口徑和責任歸屬都可能不同。原本由創建者默認知道的規則，必須寫成可執行的步驟，否則每次交付都靠臨場解釋。這不是把原應用複製一次，而是為新的資料和流程做適配。適配工時應在承諾之前單獨估算，以免上線後才發現主路徑並未跑通。
例如一家門店把內部排班建議做成對外服務，就要處理各店班次、人力上限和臨時請假，而不是隻保留原來的提示。若這些差異留到上線後才發現，開發、模型調用和返工會疊在同一週。較穩妥的做法，是先用一小段真實流程核對輸入、輸出和人工覆核點，再決定是否擴大。小範圍跑通，比一次承諾整套系統更容易看清負擔。
持續服務裏的人工並沒有消失
代客戶維持一個應用，通常伴隨帳戶、權限、例會和匯報。這些工作不產生新功能，卻佔用固定時間。模型消耗會隨調用增加，人工消耗則隨例外和溝通增加，兩者都要入帳。若只報一個開發價，其後的週會、月報和故障説明就會變成無形加班。對購買方而言，這也是難以驗收的灰色地帶，因為看不到時間花在協調還是花在結果上。
培訓投入可能延伸到課後：崗位換人、流程改版或輸出不穩定，都可能需要補充練習與答疑。設想學員完成通用課程後，仍難以處理自己的表格和審批任務，此時可以評估增加場景工作坊，另計案例準備、現場調整及跟進時間。一次講解與持續支持應分別約定，讓雙方清楚服務內容與費用。
既有信任不能代替成本覈算
客戶願意開會、內部也有技術人員，只説明合作有起點。它不説明需求已經對準某個可交付結果，更不説明模型、審核和維護的開支能夠被收入覆蓋。信任可以降低溝通摩擦，技術資源可以縮短實現時間，兩者都不能取代範圍和驗收。項目仍要回答：完成什麼、不包含什麼、誰確認、何時停止。關係順暢，只是把這些問題問得更早的條件。
設想雙方已有穩定合作，演示也符合預期，進入現場後卻發現資料分散、口徑衝突和負責人不明。新增投入可能集中在訪談、清洗、返工及等待規則確認，而非模型調用。覈算時應評估這些條件，指定能確認業務規則的人員，並約定資料或決策延遲時如何調整排期。
按實際範圍列帳，而不是按熱門功能報價
可按實際範圍列出調研、開發或配置、模型調用、審核返工、培訓與維護。模型成本除調用次數，還取決於計費方式、輸入輸出長度、重試及工具費用。建議約定觀察週期、預算提醒和超支處理，並把人工覆核時間一併記錄，才能比較新增開支與節省投入。
返工需要定義次數和觸發條件。例如因輸入資料缺失而重做，與因需求臨時改口而重做，責任並不相同。培訓則要區分一次講解、崗位練習和上線後答疑。維護要寫清故障回應、規則更新和版本交接，而不是用持續優化概括。清單的作用不是製造文件，而是讓日後每一筆時間都能對回當初約定。算不清的項目，往往輸在動詞含混。
驗收、變更與退出要同時約定
驗收看的是雙方事先同意的結果，不是演示當天的氣氛。可以採用小範圍試運行，記錄哪些輸出被採用、哪些被退回、退回後由誰修改。變更則要有入口：新需求如何提出、是否影響工期和費用、何時重新評估。沒有變更機制，範圍會在使用中悄悄擴大，最後誰也説不清原約定還剩什麼。使用越頻繁，這道入口越要提前設好。
退出同樣屬於成本。停止使用時，帳戶、提示規則、資料副本、未完成工單和內部接手人要有交接清單。設想合作數月後企業決定改回人工流程，若沒有退出約定，服務方仍可能被臨時質問，購買方也可能失去自己的資料和操作説明。把結束寫清楚，不是預設失敗，而是讓繼續或停止都不必靠關係臨時談判。
應用有人用，只是把真實成本從隱性變成可見。企業應按調研、實現、模型消耗、審核返工、培訓和維護逐項核對，並同時寫明驗收、變更與退出。算清之後，縮小範圍、繼續深化或果斷停止，都是負責任的決定，而不是對技術的否定。