相信大家出門在外工作打拼，多少會遇到喜歡請你 "順便" 幫忙開發什麼，或是會在合約的模糊地帶多凹你一點的客戶，軟體機器人不會說話，所以常常受這樣的悶氣，硬是被塞了不適合他的工作
之前有提到要有明確的 business logic, 加上它不會隨意變動和被人為干擾，才比較適合用 RPA 開發。台灣的客戶常常很喜歡用第一項商業邏輯去跟乙方顧問要求多開發一點: 不是說有邏輯機器人就有辦法嗎？即使你跟他分析後續維護成本和出錯率的 issue，常常還是會得到: "你們就試試看吧，又不是不能做，不行之後再停就好了。" 之結論，就連非常雞毛蒜皮，他們也會不足惜去花開發者的時間和改變整體的schedule, 時間還不一點節省的到作開發，完全符合80/20定律啊，花了80%的時間做了僅20%的工作。

萬物都有其特性，照理說這種情況要在 PAA(process automation assessment)階段就被屏除掉了，問題是談案子scope,決定要不要做PAA,跟客戶的談判...這些是最懂得的開發人員頂多能善盡告知分析利弊的責任，剩下的就不是我們可以插手的事了。 也只能眼睜睜的看著案子在還沒導入前就被談壞了，完全可以預知未來的悲戚狀況，這也難怪許多科技公司的sale要相關背景甚至工程師去擔任，只有他們會客觀中允的分析，並不是為了賣案子什麼原則都只是參考用的狀況了。

RPA案子不常失敗，一旦失敗那十之八九的問題就是專案內容被 overpromise 了，Robot被硬塞不適合他的食物，呈現暴走型態指日可待，到時也不用說到底能多省時多有效益，恐怕後續 maintain 的時間都要比機器人幫你省的時間多。