三步驟取代人工審核
加油快速通申請更輕鬆
三步驟取代人工審核
加油快速通申請更輕鬆
三步驟取代人工審核
加油快速通申請更輕鬆
角色
角色
產品設計
產品設計
協作對象
協作對象
產品經理*2
軟體工程師*2（前端、後端）
產品經理*2
軟體工程師*2（前端、後端）
專案期間
專案期間
2022/11-2023/2
2022/11-2023/2
平台
平台
Mobile Web (In-App Webview)
Mobile Web (In-App Webview)
Background
Background
「加油快速通」是 Autopass 自 2021 年起推出的加油付款模式。目的是為了快速導入大型加油業者的同時，提供用戶更省力的付款體驗。
用戶只需說出「我要用快速通加油」，無需掏卡、掏手機，由加油員操作後完成加油，App 隔日自動扣款。
在使用前，用戶須先登記車牌，由我們匯入油站系統。
Problem
Problem
人工審核撐不住成長
營運每日審核，用戶等不到結果
初期為了快速上線，公司採用表單加人工審核的暫時性做法：用戶填表單申請，由營運人員每日審核、手動開通。
然而這樣的做法也開始產生以下問題：
初期為了快速上線，公司採用表單加人工審核的暫時性做法：用戶填表單申請，由營運人員每日審核、手動開通。
然而這樣的做法也開始產生以下問題：
營運痛點
隨著申請人數成長，每日審核成為營運人力負擔。
團隊每月約花 9 小時處理名單、審核與通知，逐筆確認車牌是否符合開通資格，量能已接近滿載。
隨著申請人數成長，每日審核成為營運人力負擔。
團隊每月約花 9 小時處理名單、審核與通知，逐筆確認車牌是否符合開通資格，量能已接近滿載。
使用者痛點
由於流程繁瑣、非即時，且缺乏申請流程進度回饋，導致用戶體驗感受不佳，客服也常收到相關詢問。
由於流程繁瑣、非即時，且缺乏申請流程進度回饋，導致用戶體驗感受不佳，客服也常收到相關詢問。
Goal
Goal
建立自動化申請開通的服務
因此本次的專案，我們目標很明確，即是要取代原先的「表單＋人工審核」，建立一個能自動化申請開通的服務，以減輕營運的人力負擔。
因此本次的專案，我們目標很明確，即是要取代原先的「表單＋人工審核」，建立一個能自動化申請開通的服務，以減輕營運的人力負擔。
Challenge
Challenge
從使用者角度切入專案
提出設計觀點
專案由後端 PM 主導，初始聚焦於「營運負擔解決」；
而我在此專案中切入，從「使用者體驗」的角度補上設計端觀點，聚焦兩大任務：
專案由後端 PM 主導，初始聚焦於「營運負擔解決」；
而我在此專案中切入，從「使用者體驗」的角度補上設計端觀點，聚焦兩大任務：
1
定義用戶端的申請流程痛點與服務空缺
2
提出能兼顧自動化與用戶體驗的設計解法
此外，前端開發資源有限，服務需以 In-App Webview 實作，同一套流程要同時相容車麻吉 App 與授權合作平台。
此外，前端開發資源有限，服務需以 In-App Webview 實作，同一套流程要同時相容車麻吉 App 與授權合作平台。
Process
Process
了解使用者旅程
了解使用者旅程
首先，我與設計主管規劃內部訪談與現場體驗：由 1 位公司內部車主完整走過一次申請與加油流程，並實地走訪 2 間加油站，觀察加油員的操作。再從客服管道整理用戶反饋與常見抱怨類型，與訪談交叉比對，彙整出用戶旅程圖。
旅程圖顯示，申請流程在三個階段各有斷點：
首先，我先徵集公司內部車主，實際體驗服務並進行訪談；
再者，從客服管道收集用戶反饋與常抱怨的類型，彙整出用戶旅程圖。
申請前
不理解與原先麻吉付加油的差異，也不明白為何要先申請
不理解與原先麻吉付加油的差異，也不明白為何要先申請
申請時
一次僅能申請一張車牌、步驟多，且需重填 App 內已有的資料
一次僅能申請一張車牌、步驟多，且需重填 App 內已有的資料
申請後
App 內看不到開通狀態，失敗也不另行通知
App 內看不到開通狀態，失敗也不另行通知
定義痛點
定義痛點
攤開原本的用戶流程，能發現用戶在不同節點遇到的困難：
攤開原本的用戶流程，能發現用戶在不同節點遇到的困難：
我們根據觀察到的三大痛點，定義出自動化申請服務的關鍵設計原則，並以此作為此次設計策略的核心。
我們根據觀察到的三大痛點，定義出自動化申請服務的關鍵設計原則，並以此作為此次設計策略的核心。
設計發想與挑戰
設計發想與挑戰
考量「快速通加油」需支援多個平台，產品團隊自設計初期便有共識採用 In-App Webview 實作，確保能以最低開發成本，快速接入各授權產品。
此策略也同步影響流程設計方向，在設計申請流程初期，我們曾考慮提供「即時新增車牌／信用卡」的流程，讓使用者在申請時一併補齊資料。
考量「快速通加油」需支援多個平台，產品團隊自設計初期便有共識採用 In-App Webview 實作，確保能以最低開發成本，快速接入各授權產品。
此策略也同步影響流程設計方向，在設計申請流程初期，我們曾考慮提供「即時新增車牌／信用卡」的流程，讓使用者在申請時一併補齊資料。
然而，在與工程端確認 Webview 行為後，發現系統無法在頁面間即時同步更新資料。因此我們調整策略，讓使用者於申請前就完成車牌與付款方式設定，以確保流程穩定。
然而，在與工程端確認 Webview 行為後，發現系統無法在頁面間即時同步更新資料。因此我們調整策略，讓使用者於申請前就完成車牌與付款方式設定，以確保流程穩定。
Final Design
Final Design
1
簡化申請步驟
簡化申請步驟
直接顯示用戶已設定的車牌，預設一次開通符合資格者，油種於同頁勾選，不再重填會員帳號內已有的資料。最少只要 3 步驟，即可完成申請。
直接顯示用戶已設定的車牌，預設一次開通符合資格者，油種於同頁勾選，不再重填會員帳號內已有的資料。最少只要 3 步驟，即可完成申請。
2
申請資格檢核點
申請資格檢核點
在入口處增加「車牌、付款方式」是否綁定的檢核點，清單內不符資格的車牌（如電動車）也會直接標示「無法申請」與原因。
讓大部分用戶在進入申請流程後，都是在低摩擦力的體驗下完成申請。
在入口處增加「車牌、付款方式」是否綁定的檢核點，清單內不符資格的車牌（如電動車）也會直接標示「無法申請」與原因。
讓大部分用戶在進入申請流程後，都是在低摩擦力的體驗下完成申請。
3
明確的開通結果提示
明確的開通結果提示
無需透過客服，用戶可自行在產品內查看「開通狀態」；系統會每日排程，簡訊通知用戶開通結果。
無需透過客服，用戶可自行在產品內查看「開通狀態」；系統會每日排程，簡訊通知用戶開通結果。
Outcome
Outcome
Saved 9hrs+
Saved 9hrs+
每月營運人力
每月營運人力
每月營運人力
Increased 54%
Increased 54%
快速通申請完成率
快速通申請完成率
快速通申請完成率
（49.7% → 76.5%）
（49.7% → 76.5%）
（49.7% → 76.5%）
專案上線後，營運每月約 9 小時的名單下載、審核與通知作業，全數改由系統處理，解放人力量能。
另一方面，流程簡化後降低了用戶使用阻力，申請完成率由 49.7% 提升至 76.5%；新版上線 41 天內，共 334 位用戶完成開通。
專案上線後，營運每月約 9 小時的名單下載、審核與通知作業，全數改由系統處理，解放人力量能。
另一方面，流程簡化後降低了用戶使用阻力，申請完成率由 49.7% 提升至 76.5%；新版上線 41 天內，共 334 位用戶完成開通。
後續，在用戶服務滿意度調查（2023 年 Q3）中，我們發現 67 位使用過加油快速通的受訪者裡，僅 1 位反饋「第一次較難了解怎麼使用」；申請相關的客服詢問，也很少再出現。
由此可以看見用戶對服務的體驗感受更加順暢。
後續，在用戶服務滿意度調查（2023 年 Q3）中，我們發現 67 位使用過加油快速通的受訪者裡，僅 1 位反饋「第一次較難了解怎麼使用」；申請相關的客服詢問，也很少再出現。
由此可以看見用戶對服務的體驗感受更加順暢。
Takeaways
Takeaways
這次的設計挑戰，在於如何兼顧使用者需求與既有技術限制。
原先希望讓用戶在申請過程中補齊資料，但考量 Webview 無法即時同步，最終將資料檢核提前至申請前，讓使用者先確認資料是否完整，再進入申請流程。這讓我更重視設計方案的可行性，並在使用者體驗與開發資源之間找到合適的平衡。
這次的設計挑戰，在於如何兼顧使用者需求與既有技術限制。
原先希望讓用戶在申請過程中補齊資料，但考量 Webview 無法即時同步，最終將資料檢核提前至申請前，讓使用者先確認資料是否完整，再進入申請流程。這讓我更重視設計方案的可行性，並在使用者體驗與開發資源之間找到合適的平衡。
© Yuan Chiu 2026 Copyright. All Rights Reserved.