先看顧客正在做甚麼
瀏覽器通知權限意味商店日後可在網頁以外打擾顧客。是否要求這項權限，應從顧客自選的具體用途出發，而非從推廣目標或試用新功能的意願出發。先說清楚顧客希望知道甚麼事件：訂單可供自取，與每次推出新品，性質並不相同。列明事件何時發生、通知會帶來甚麼行動，以及顧客接到通知後可以在哪裏處理。若帳戶或訂單頁已提供同一資訊，瀏覽器提示可作額外便利，毋須變成取得重要資訊的唯一渠道。
Chrome 的 Lighthouse 文件會指出網頁一載入就要求通知權限的做法，並建議先讓用戶選擇特定通知類別，之後才提出瀏覽器要求。這既是產品設計，也是技術安排。尚未購物的訪客難以判斷籠統的「允許更新」有甚麼價值。完成訂單後，使用「自取貨品備妥時在此瀏覽器通知我」之類的選項，才能交代用途和範圍。頁面也要說明忽略選項後會怎樣；付款流程應先完成，才進入權限步驟，避免顧客誤以為允許通知是結帳條件。
加入瀏覽器通知前，先比較商店已有而干擾較少的渠道。訂單狀態頁讓顧客按需要自行查閱；電郵可保留較完整細節，但亦受派遞和收件匣使用習慣影響；站內訊息適合仍在網站上的顧客。當時效重要，而顧客明確選擇在該裝置接收時，瀏覽器通知才較有價值。各渠道資料若不一致，應事先決定哪個紀錄作準。例如是否可取貨，應以訂單紀錄為準，不應由通知是否送達來判斷。這樣即使提示遺漏，也不會令業務狀態跟着消失。
設計一次清楚的自願流程
頁面可先以一般用語提供某一類提示的自願選項。顧客按下後，程式才檢查瀏覽器是否支援通知功能，並讀取現有權限。MDN 說明權限可為 default、granted 或 denied。default 表示尚未有確定選擇，不能當作同意；granted 可繼續使用功能；denied 則要提供可用的替代途徑，並在顧客有需要時簡潔說明可到瀏覽器設定更改。遭拒絕後不要不停強迫再次彈出要求，也不要暗示網站內的開關能推翻瀏覽器層級的拒絕。
MDN 指出通知權限要求應回應用戶動作，例如按鈕點擊；支援的瀏覽器亦要求安全連線，跨來源嵌入框架另有限制。因此，真正的瀏覽器要求應放在商店自身的安全頁面，由顧客主動操作觸發。要在顧客實際使用的瀏覽器及裝置上測試，不能以一次桌面示範概括手機體驗。MDN 亦提醒，大部分手機瀏覽器不適合直接建立 Notification，開發者應考慮 service worker 的相關方法。本文處理的是權限與顧客決策；推送派遞的技術設計仍須獨立檢查。
網站內的接收偏好，與瀏覽器權限，是兩個獨立事實。顧客以前可能允許瀏覽器通知，其後卻在帳戶內關閉取貨提示；商店仍須尊重較窄的選擇。相反，顧客在網站勾選取貨提示，但瀏覽器權限是 denied，介面就不能承諾一定送達。只儲存營運選項所需的偏好資料，並提供容易找到的更改位置。還要說明選項只適用於目前瀏覽器、整個帳戶，還是所有裝置；三者的顧客期望及技術安排都不相同。
以自取訂單作例子
假設商店提供翌日櫃檯自取。付款完成後，確認頁先顯示訂單編號及正式狀態頁連結，再提供「備妥可取貨時通知我」的可選瀏覽器提示。顧客按下自願接收按鈕，頁面檢查權限；若是 default，才因應該次按鍵提出瀏覽器要求；若已是 granted，便可記錄偏好。若權限是 denied，或要求後仍回傳 default，頁面回復中性狀態，並引導顧客查看訂單狀態。整段流程中，訂單確認不受通知選項影響。
接着要決定訊息內容。「訂單可供自取」及返回相應訂單的途徑，比空泛的推廣句子實用；但鎖定畫面通知可能被旁人看見。除非商店已評估這種暴露，否則不要在提示中放入敏感貨品或個人資料。通知應與更新訂單狀態頁的同一業務事件相連。若事件延遲或重複，也不應造成誤導性的連續提醒。網站可以把重複變動合併為一次有用更新，但伺服器嘗試發送，不等於可以聲稱顧客已收到。
再看顧客拒絕的情況。封鎖通知後，確認頁仍須正常顯示，顧客日後也能找到訂單。商店可按顧客原有選擇提供電郵或帳戶頁，但不可悄悄把顧客加入另一類提示。員工回應取貨查詢時，應查看訂單紀錄並告知可用的狀態查閱途徑。這說明瀏覽器權限只應疊加在本已完整的服務之上。團隊亦可明確驗收：購買完成、提示偏好記錄準確，而不論權限如何，顧客均可查閱當前狀態。
測試拒絕、更改與訊息是否有用
首次造訪路徑應用全新的瀏覽器設定檔測試，因為既有權限會遮蓋要求畫面。分別測試 default、granted、denied，以及顧客關閉提示而未選擇的情況。檢查網頁載入時不會立即要求權限，按鈕文字亦須在瀏覽器彈窗前說明提示用途。再以支援的手機瀏覽器和純鍵盤操作重試，確保英文及繁體中文的按鈕與狀態訊息都清楚。這是功能測試，不能據此聲稱顧客喜歡此功能；那要靠真實顧客研究及實際使用數據支持。
覆核偏好的整個生命週期，不只看首次允許。讓顧客關閉某類提示、登出、換裝置，再重訪訂單頁。若帳戶偏好已存在，但新裝置尚未允許瀏覽器通知，介面應顯示甚麼狀態，要先決定。顧客在網站仍開啟時改動瀏覽器設定，也要檢查介面反應。不同瀏覽器的實際操作不盡相同，因此使用說明應根據已測試的介面編寫，不要假設所有裝置的設定路徑一樣。denied 狀態亦不能留下看似已啟用、卻不可能顯示提示的開關。
最後，在定期產品會議檢視提示種類。刪去已不再服務於有時效顧客需要的類別，並確認選項文字與系統實際發送的內容一致。商店可能發現改善訂單狀態頁已能解答大部分查詢，瀏覽器提示增益有限；沒有可靠量度前，這只是待驗證假設，不是已得出的成效結論。務實的驗收標準是：顧客在被要求前明白具體好處，拒絕後仍可使用服務，日後可更改網站內偏好，而且始終找得到訂單的正式資訊。
進行前先確認
- 提示是否對應顧客自選的具體事件，並有清楚的替代途徑？
- 瀏覽器要求是否由安全頁面的主動操作觸發，而各權限狀態均可正常處理？
- 顧客能否拒絕或更改網站偏好，而不影響訂單流程？
