科技執法罰單被申訴時系統要提供什麼？
調閱影像、稽核軌跡與回覆時效的作業流程

科技執法罰單被申訴時，舉發機關要在期限內回答三件事：違規事實是否成立、設備與程序是否合規、這筆案件從拍攝到寄出有沒有被改動過。系統要做的，是讓承辦人輸入一個案號，就能在一個工作天內調齊六類資料、打包成回覆附件，同時把回覆期限、暫停刪除與最後的處理結果留下紀錄。做不到這一點，每一件申訴都會變成承辦人四處打電話、翻資料夾、向廠商要截圖的手工作業。

先講清楚範圍：這篇寫給承辦資訊系統的機關人員與廠商，談的是申訴進來之後，系統怎麼接、怎麼調、怎麼回。民眾視角的申訴依據（罰單上怎麼看舉發來源、可以從哪些點提出異議）已整理在逕行舉發是什麼意思；違規證據平時要怎麼保存才站得住，見交通違規證據鏈要保存什麼。本文列的流程與欄位都是方法論，不引用、也不描述任何實際案件。

科技執法罰單申訴從哪裡進來？三種管道與期限來源

受處分人對罰單有異議，不一定直接找舉發的警察機關。實務上常見的是向處罰機關（監理機關）陳述意見，再由處罰機關把陳述內容轉給舉發機關查明；也有人直接向舉發機關陳情；若對裁決不服，則進入行政訴訟。三種管道的入口不同、期限來源不同，但最後都要回到系統裡的同一筆案件。

管道	通常怎麼進到舉發機關	回覆期限從哪裡來	系統要接住的動作
向處罰機關陳述意見	處罰機關來函，請舉發機關查明並回覆	來函所定的回覆日期	收文當日登錄案號、來文字號、收件日與回覆期限
直接向舉發機關陳情	電話、書面、機關的陳情信箱或首長信箱	機關陳情案件處理規定	同上，另標記進件管道，避免同一人多管道重複處理
行政訴訟	法院或處罰機關要求提出證據與說明資料	法院通知或處罰機關所定日期	標記「訴訟中」，暫停該案的到期刪除排程

各管道的法定期限與程序，以現行道路交通管理處罰條例、相關處理細則與行政訴訟法的條文為準；本表只示範系統要記錄的欄位。

最常見的斷點在第一列：申訴以公文形式進來，在公文系統裡流轉，跟案件系統完全沒有連結。承辦人拿著公文上的違規車號回頭查案件，回覆期限也只存在公文系統裡，案件那一端看不出「這筆正在被申訴」。建議在案件系統裡為每一件申訴建立一筆申訴子紀錄，至少包含：進件管道、來文字號、收件日、回覆期限、承辦人、目前狀態與處理結果。能和公文系統介接自動帶入最好，做不到也要能手動登錄；介接的範圍怎麼盤，見科技執法系統要介接哪些系統。

申訴來了，系統要能調出哪六類資料？

受處分人提出的異議五花八門，但回到舉發機關要查證的，幾乎都落在下面六類。每一類都要能用案號直接調出，而且調出來的是違規當下的狀態，不是現在的狀態。舉例來說，設備現在的檢定證書是有效的，不代表違規那一天也有效；系統要能依違規時間反查。

資料類別	申訴常見的爭點	系統要做到
一、原始影像與連拍	車牌是否清楚、是否為同一輛車、畫面能否呈現違規事實	調出原始母檔與判讀用副本，並附上建檔時的完整性驗證值，證明檔案未被更動
二、設備身分與檢定狀態	違規當下設備是否在檢定合格期內、告示是否依規定設置	依違規時間反查當時的檢定證書編號與有效期間；點位告示的設置日期與現場照片
三、時間來源與校時紀錄	違規時間是否正確；闖紅燈類案件的號誌時相	違規前後最近兩次校時紀錄與當時的時間偏差；需要時一併調出號誌時相資料
四、辨識結果與人工複核	是否誤判、由誰確認成立	辨識結果與信心值、複核帳號、複核時間與複核判定，三者分開顯示
五、舉發製單與送達	是否逾期舉發、送達程序是否完備	違規日、製單日、移送監理端的日期、寄送與送達紀錄，自動算出各段間隔天數
六、稽核軌跡	案件資料是否被修改過、改了什麼	這筆案件所有操作紀錄：帳號、時間、動作、異動欄位與前後值

六類資料裡，第二類最容易調不出來。設備的檢定證書與告示照片，很多時候存在維運廠商的文件夾或承辦人的電腦裡，而不在系統中。建議把檢定證書編號、有效期間與告示設置紀錄登錄成設備主檔的欄位，有效期屆滿前（例如 60 天）自動提醒；更進一步的做法，是讓系統在設備檢定逾期期間不產生待舉發案件，從源頭避免最難辯護的那一類申訴。第三、第六類的欄位設計，與證據鏈那篇的三種時間戳與七個稽核欄位是同一套，平時存得完整，申訴時才調得出來。

調得出來之後，還要能打包。理想的做法是系統依範本產出一份「申訴案件包」：一頁摘要（案號、違規時間地點、設備、複核者、送達日期）加上六類附件，每個附件有編號，摘要裡引用的就是這些編號。案件包要有兩個預設：

1. 不含檢舉人資料。民眾檢舉來源的案件，案件包範本裡就不應該有檢舉人姓名與聯絡方式的欄位，理由與做法見民眾檢舉平台個資怎麼保護。
2. 產出本身留紀錄。誰在什麼時間、為了哪一件申訴產出了案件包，寫進稽核軌跡。案件包離開系統之後就無法收回，這筆紀錄是事後釐清的依據。

回覆時效怎麼管？從收件到結案的五個節點

回覆期限不是系統能決定的，它來自處罰機關的來函或法院的通知。系統要做的是把這個日期變成案件上看得到、會倒數、會提醒的欄位，而不是讓它停留在公文的某一行字裡。下面五個節點，每一個都要在申訴子紀錄裡留下時間與經手人。

期限提醒建議設兩段，例如期限前 5 個工作天與前 2 個工作天各提醒一次；已逾期或當天到期的申訴，集中顯示在主管的待辦清單。這些天數是示範值，實際要依機關的作業量與來函慣例調整，重點是系統不要自己預設一個天數去覆寫來函上的日期，期限一律以登錄的那個日期為準。

系統跑一段時間之後，還可以回頭看兩個數字：從收件到案件包產出的平均時間，以及因資料缺漏而延後回覆的件數。前者反映系統調閱效率，後者反映平時的資料管理有沒有漏洞，兩者都比「申訴件數」本身更能指出要改哪裡。

申訴結果要回到系統：撤銷原因代碼與規格書檢查

一件申訴處理完就結案，是浪費。撤銷的原因如果集中在某個點位、某段時間或某一種辨識錯誤，代表問題在設備設定或判定規則，下個月還會再發生。節點 3 用代碼記錄理由，就是為了這一步。下表是撤銷原因代碼的分類範例，以及各類原因要回饋到哪裡：

撤銷原因類別	可能指向的問題	回饋動作
影像不足以辨識違規事實	點位角度、夜間補光、影像壓縮設定	檢討該點位的設備設定，必要時重新評估點位，見科技執法點位怎麼挑
車牌或違規態樣誤判	辨識模型的弱點，或人工複核漏看	把同類案件加進複核抽查樣本，見誤判率門檻與人工複核抽查設計
設備檢定或告示瑕疵	設備主檔與到期管理	查同一設備同一期間的其他案件，補強到期提醒
逾期舉發	流程中某一段停留過久	從製單與移送日期找出卡住的環節
送達程序瑕疵	寄送地址資料或送達紀錄不完整	與監理端核對送達資料的介接欄位
時間或地點誤繕	路口主檔或設備主檔資料錯誤	修正主檔，並查詢引用同一筆主檔的案件

這些數字最後要進到月報：申訴件數、撤銷件數、撤銷率，再依原因與點位拆開。單看撤銷率會誤導，因為申訴件數本身會隨宣導、媒體報導與新點位啟用而波動；月報裡哪些數字該放、怎麼避免誤讀，見科技執法成效怎麼報。

七項都能在驗收當天實際操作：建一筆測試申訴、看暫停刪除的標記是否出現、產出一份案件包確認附件與摘要對得上、把期限改到明天看提醒是否跳出。驗收腳本的寫法見科技執法系統驗收怎麼驗，規格條文怎麼寫得驗得到又不綁標，見科技執法標案規格書怎麼寫。

瑪尼國際成立於 2004 年，深耕資訊服務逾 20 年、服務逾 500 家企業，並以協力廠商身分參與全台多個縣市警察局交通隊的入案系統建置與維運。建置科技執法系統時，我們把「申訴來了調不調得出來」當成資料結構的驗收題，在建置期就決定欄位與範本，而不是等第一件申訴進來才補。系統主機放在中華電信光纖機房，由我們負責網站代管與維運，前台與民眾檢舉平台的網頁設計也可以一併規劃。從前台、資料庫到主機由同一組人負責的一條龍服務，好處是申訴要的六類資料，每一類都找得到負責保存的人。

常見問題