跨職能流程圖範本（內容審閱與發布）
以一條內容審閱與發布流程建構的跨職能流程圖範本：撰稿人、編輯、法律及合規與網站團隊四條泳道，橫跨由內容綱要到發布後檢視的五個階段。
運作方式
先判斷泳道值不值它所佔的位置
在改動任何東西之前，先確認你們的失敗真的落在交接上。如果你們的問題是稿件本身寫得差，泳道圖幫不了忙，一條直線反而更易讀。只把泳道給那些會作判斷、或者會在等待期間拿住工作的團隊，絕不要一個人一條：以個人命名的泳道，第一次有人調職就不再描述那條流程。
把泳道改成你們真正有的職能
把撰稿人、編輯、法律及合規與網站團隊換成你們自己的。如果你們沒有內部法律審閱人，不要把檢查連同泳道一併刪掉：把「逐項核對聲稱與其證據」移入編輯的泳道，並指名為它簽署的外部律師或合規負責人。只有在確實由同一個人兼任時才合併撰稿人與編輯泳道，而那正是這張圖不再算是跨職能的那一刻。
把聲稱觸發清單寫下來
「內容是否涉及受規管或比較性聲稱？」的好壞，完全取決於背後那份清單。把你們的記在該步驟上：點名的競爭對手、價格或節省金額、效能或安全聲稱、客戶名稱與標誌、醫療、財務或法律意見，以及任何受規管的用詞。把這個判斷留在編輯的泳道。趕交稿期的撰稿人會繞過一道由自己負責的檢查，而這個交叉點存在的目的正是防止這件事。
訂下法律部的處理時限並指名一位審閱人
本範本假設有一個明確的處理時限，三個工作天是常見的做法，並為每篇稿件指定一位具名審閱人。把你們真實的數字寫在該步驟上。保留「法律部是否按原文放行各項聲稱？」的第三條分支：背後沒有註明日期的證據支持的聲稱，並不屬於修改的情況，而把它併入修改分支，正是無法舉證的聲稱被改寫措辭而不是被剔除的方式。
把發布前檢查改成你們的，並在預覽頁面上執行
把你們的檢查項目列在判斷步驟上：已批准的文稿是否已就位、標題與元描述、各級標題與替代文字、連結是否可用、手機版面、任何嵌入媒體的同意機制。有兩件事比清單本身更要緊。檢查是對著預覽頁面而不是對著文件執行，而不通過的項目回到網站團隊，所以那條分支要繼續指向「製作頁面並上載至預覽環境」。
在簽署時就訂下檢視日期，不要拖
「簽署文稿並訂下發布日期」也是檢視日期應該落腳的地方，一般是 30 天或 90 天之後，並對照內容綱要裡寫明的目標來判斷，而不是只看流量。把須更新分支繼續接回修改步驟：改動過的聲稱需要再次放行。如果你們團隊確實從不回頭處理已發布的頁面，就刪掉最後一個階段，而不是留下一個沒有人執行的步驟。
常見問題
甚麼時候需要跨職能流程圖，而不是普通流程圖？
當失敗落在交接上的時候。把流程畫成一條直線，然後看最近實際上出了甚麼問題。如果是步驟做得差，泳道只會加闊圖面，甚麼新東西都告訴不了你。如果工作停住是因為沒有人知道它已經到了，或者被做了兩次是因為兩個團隊各自以為那是自己的事，那麼歸屬就是你缺少的那項資料，而泳道就是把它顯示出來的方法。這裡的發布流程通得過這個測試：一項需要法律放行的聲稱，以及一個由網站團隊上載至預覽環境卻由編輯簽署的頁面，兩者都是交叉點，也都是稿件失落的地方。
內容審閱與發布流程有哪些階段？
五個，而它們對應這張圖的階段。草擬：按一份寫明對象讀者、目標、目標網址與預定日期的內容綱要撰寫，然後附上資料來源、圖片與替代文字。審閱：校訂準確性與文風規範，然後由編輯作判斷，並帶一條修改迴路。審批：判斷這篇稿件是否涉及受規管或比較性聲稱，逐項核對這些聲稱與其證據，然後簽署文稿並訂下發布日期。發布：製作頁面並上載至預覽環境，在頁面上執行發布前檢查，發布並申請搜尋引擎收錄。發布之後：檢查收錄、轉址與錯誤，然後在一個訂好的檢視日期對照目標評價這一頁。
內容審閱與發布流程由誰負責？
編輯負責流程；沒有其他角色處於能負責的位置。撰稿人負責稿件與修改，法律及合規負責一項聲稱能否按原文成立，網站團隊負責已製作的頁面與部署。但編輯是唯一在五個階段之中出現於四個的角色，這也是為甚麼聲稱觸發點、文稿簽署、發布前判斷與發布後檢視全部落在那條泳道。如果你們的流程一直停滯，先看看那位端到端的負責人到底存不存在，還是每個團隊只是在做自己那一份然後盼望。
這與 Visio 裡的跨職能流程圖相比如何？
Visio 的桌面版範本叫 Cross Functional Flowchart，而 Microsoft 自己在不同文件裡對這個名稱的連字號用法並不一致，所以不要從中讀出分別。那邊有兩件事會令人意外。階段並不是泳道的一項屬性，而是另外放到泳道上的 Separator 形狀；而刪除一條泳道會把裡面所有形狀一併刪除，Microsoft 有文件記錄的變通做法是先把那些形狀完全移到圖表之外。在網頁版上，跨職能流程圖需要 Visio Plan 1 或 Plan 2；Microsoft 365 內附的那一檔 Visio 並不提供。在這裡，泳道是步驟本身的一個值，所以重新指派一個步驟，就是編輯那一行。