@Vladislav_Vladislav 感謝你，也謝謝你公布那 65 次檢視 / 0 筆購買的數字。這比成功案例更罕見，也更有用。
我這邊也是同樣的結果：我交談過的人都沒人單獨為監控付費。我看到金錢流動的地方是在它之前的工作——有人會付錢讓工作流程被建立或修復，而之後的監控是對此的自然附加功能，而不是他們主動尋找的東西。所以我改變了策略，現在先提供建置和修復服務，交付後再包含監控。
如果這變成了付費的定期服務，我會回來這裡分享他們確切支付的費用。
Hi Stefan—你對執行錯誤和缺失業務成果之間的區分引起了我的注意，特別是對於你所提供的小型企業工作流程。你能否花20分鐘時間詳細說明你上一次真實的工作流程失敗、你如何察覺到它，以及它的影響？之後，我會向你展示一個虛構的 FlowProof 遺漏記錄警報演示以供批評。無需購買或系統訪問權限。
嘿 Lorenzo，
感謝你的聯繫！
執行錯誤和缺失業務成果之間的區別也是我覺得非常有趣的東西。
我仍在建立我的自動化業務，所以我的大部分經驗來自我自己的工作流程和測試，而不是客戶現場的生產事件。
當 n8n 報告執行成功時，它如何檢測缺失的業務成果？
它是外部監控預期結果，還是需要整合到每個工作流程中？
很樂意進一步了解你的方法。
嘿 Stefan，好問題。我不是假設 FlowProof 能單靠 n8n 的成功狀態推斷業務結果。我正在探索的第一個版本會讓使用者定義一個預期結果——例如，一個特定 ID 的潛在客戶應該出現在他們的 CRM 中——並在工作流程中新增一個輕量級檢查點。FlowProof 隨後會在設定的時間內檢查連接系統是否有該結果，如果缺少則標記。
所以這樣做需要為每個工作流程進行小的設定步驟，而不是神奇地從外部偵測每個結果。我想了解這是否有用，或者摩擦力太大。你在自己的工作流程中是否看過綠色執行但實際結果仍未發生的情況？
嗨 Stefan —
我一直在思考你在 n8n 執行緒中的評論。你指出，普通的錯誤警報可能會遺漏執行顯示「成功」但業務結果從未發生的情況，而且結果檢查需要適應每個工作流程。
你是否願意參與一個為期 14 天的付費試點，使用你控制的執行個體上的一個工作流程？我們會同意一個可觀察的結果，例如潛在客戶出現在正確的 CRM 中，然後為遺漏的結果和恢復進行安全測試，並分享一份簡短的證據報告。我們會使用測試環境或低風險工作流程，避免生產環境寫入。
我建議試點固定費用為 €250，沒有自動續約或超出範圍的承諾。FlowProof 仍處於早期階段，所以這將是實踐測試而非完成的平台。
如果這聽起來有幫助，你是否願意進行簡短通話來選擇工作流程並同意成功的標準？
謝謝，
Lorenzo