第零天：委託信裡最關鍵的一句話
一次性情報報告要在下週就能使用，設計重點不在分析深度，而在於每個結論都綁定一個負責人、一個動作與一個期限。某連鎖教育品牌的營運主管在委託信裡寫道：「上一份報告寫得很好，但放在雲端資料夾裡三個月沒人打開。」這句話定義了整個案子的驗收標準：不是報告好不好看，而是下週會議後有沒有人動起來。
我們在回信中先確認了三件事：下週一的會議有哪些部門出席、每個部門主管的決策權限到哪裡、以及公司目前手上已經在執行的專案有哪些。第三件事特別重要，因為一份報告如果建議的動作和現有專案衝突，通常會被默默忽略。這些資訊都以文字往返確認，沒有安排任何會議。
第一到三天：先蒐集，再決定不寫什麼
前三天的工作是蒐集與篩選，而篩選比蒐集更花時間。我們鎖定委託方在同一商圈的四家主要對手，蒐集範圍包括公開課程方案與價格、招生活動頁面、社群貼文節奏、職缺公告、以及家長社群中的公開討論。資料量在第三天結束時累積到大約一百二十條紀錄。
篩選時我們用一個問題過濾每一條紀錄：「這條資訊能不能讓某個部門在兩週內做出不同的動作？」如果不能，即使它很有意思，也只放進附錄。例如某對手換了新的品牌色，這對行銷部門或許有參考價值，但無法導出兩週內的具體動作，因此不進正文。最後進入正文的紀錄大約二十條。
蒐集過程中我們也刻意記錄了「找不到的資訊」。例如某對手的團報優惠條件在官網上查不到，只在家長社群裡有零星描述，這類資訊我們會標註為低可信度，並在報告裡寫明需要委託方透過自己的管道確認，而不是當作事實寫進建議。把資訊缺口寫出來，是為了避免部門主管在不知情的情況下根據一條傳聞做決定，也讓委託方知道下一次情報可以補強哪些來源。
第四到五天：初稿長得像一般報告，這是問題所在
第五天完成的初稿結構很傳統：市場概況、對手逐一分析、比較總結、建議事項。內容本身沒有錯，但我們自己做了一次模擬閱讀，假設自己是教務主管，讀完後發現要自己從十二頁中挑出與教務相關的段落，再自己推論該做什麼。這正是上一份報告失敗的原因，只是我們差點重蹈覆轍。
這一天我們決定把整份報告的結構翻過來：不再依照對手分章，而是依照部門分章。每個部門一頁，頁首就寫這個部門下週該做的動作，後面才附上支撐的證據。對手分析的內容沒有消失，只是被拆散到各部門頁面裡，作為動作的理由。
第六到七天：把建議改寫成動作卡
第六天開始，我們把每一條建議改寫成固定格式的動作卡。動作卡的設計原則是：任何一位部門主管拿到後，不需要讀其他頁面也能理解並執行。
- 動作：用動詞開頭，具體到可以驗收，例如「在暑期招生頁新增試聽後七日內報名的方案說明」，而不是「強化招生策略」。
- 負責部門與建議負責人職位：寫職位不寫人名，由委託方自行指派。
- 期限：分成「一週內」「一個月內」「一季內」三級，下週會議只討論一週內的動作。
- 依據：用兩到三句話交代這個動作來自哪個觀察，附上附錄編號。
- 放棄條件：如果某個情況發生，這個動作就不必做了，例如「若對手在兩週內撤下該優惠則暫緩」。
放棄條件是這次新增的欄位，也是事後回饋最好的一項。營運主管說，過去報告最讓人困擾的是建議只會增加，不會減少，每個部門都覺得工作量被無限放大。有了放棄條件，部門主管知道哪些動作是有前提的，比較願意接受。
第八天：交付物的最終形狀
最終交付的報告共九頁：第一頁是一頁摘要，列出全部十一張動作卡的標題與負責部門；第二到六頁是五個部門各一頁；第七頁是需要跨部門協作的兩個動作；第八到九頁是方法說明與附錄索引。完整的一百二十條紀錄另外以試算表交付，每一條都有來源網址與取得日期。
- 一頁摘要：給營運主管在會議開場用，五分鐘內可以講完。
- 部門頁：各部門主管在會議前自行閱讀，會議中只討論有疑問的動作卡。
- 跨部門頁：會議中花最多時間的部分，因為需要當場協調資源。
- 附錄試算表：給想要驗證或延伸研究的同仁使用，不要求所有人閱讀。
交付時我們還附了一份會議議程建議，把六十分鐘會議切成開場摘要、部門確認、跨部門協調、指派與期限確認四段。議程不是必要的，但委託方後來說，這份議程讓會議比預期提早結束。銘望顧問所的逆向破解競業情報書現在也會視情況附上類似的使用建議。
交付前的最後一步，是我們自己扮演五個部門主管各讀一次自己的那一頁，只檢查一個問題：讀完之後能不能在週一早上開始做第一件事。有兩張動作卡在這一步被退回重寫，原因是動作描述仍然太抽象，例如「調整社群貼文方向」被改寫成「每週固定一篇試聽課實況貼文，連續四週」。
第十五天與第四十五天：兩次回頭檢查
交付後第十五天，我們以文字詢問委託方十一張動作卡的狀態。結果是七張已經開始執行，兩張因為放棄條件成立而暫緩，兩張被指派後還沒動。未動的兩張都屬於跨部門動作，原因是負責人雖然指派了，但另一個部門的配合時程沒有確定。
第四十五天的第二次檢查中，我們請委託方回報已執行動作的初步觀察，例如試聽後報名說明上線後，詢問內容是否改變。這些回報不用來證明報告有效，而是用來判斷哪些觀察值得在下一次情報中持續追蹤。這次復盤也讓我們承認一個失誤：跨部門動作卡應該在交付時就寫明需要哪個部門在哪一天前給出什麼，而不是只寫「需要協調」。
不適合這種設計的委託
把報告設計成下週就能用的版本，並不適合所有情報需求。如果委託方的目的是長期策略規劃，例如三年後是否進入新市場，那麼強迫每個結論都變成一週內的動作，反而會讓分析變淺。另外，如果組織內部門權責不清，動作卡寫得再清楚也沒有人能接，這時問題不在報告，而在組織本身。
還有一種情況是委託方其實只需要一個答案，例如某對手是否即將降價。這種單一問題的委託，一頁判斷加證據就足夠，硬套部門分章的結構只會增加閱讀負擔。報告的形狀應該跟著使用者的下一步走，而不是反過來。
最後要提醒的是，動作卡的品質高度依賴委託方提供的內部資訊。如果委託方不願意透露現有專案與部門權限，我們只能根據公開資料推論，動作卡就容易和內部實況脫節。因此開工前的資訊確認不是形式，而是這種設計能否成立的前提。