顧客如何繼續填寫未完成的長表格？

判斷哪些未完成資料值得保留

顧客花時間說明服務需要、查看文件，回來時卻發現表格全空。公司可能失去查詢，但自動保存每個按鍵也不是答案。先判斷哪些流程長到值得提供草稿恢復，以及哪些欄位若留在共用裝置會造成傷害。簡短聯絡表格可能只須在驗證失敗後保留輸入；需要多份文件或長篇說明的申請，則可能要明確的「儲存草稿」。記下設計要承受的中斷：誤關分頁、重開瀏覽器、網絡中斷，還是登入時段屆滿。

草稿須與已遞交申請分成兩種狀態。草稿可能未填妥、過時或未經核實，不應觸發員工處理、付款，亦不應令顧客以為申請已收妥。清楚告知已保存甚麼、何時保存、從哪裏繼續，以及仍欠哪一步才算遞交。若「已儲存在此裝置」與「已儲存至帳戶」確實採用不同機制，就應用不同字眼。儲存操作完成前，不要以轉圈或綠色剔號聲稱成功。若儲存失敗，應如實說明，同時保留畫面上的輸入以供重試。

不要預設把整張表格完整複製作草稿，應先選定最少需要保留的欄位。顧客或許願意繼續編輯服務說明，卻合理地期待身份號碼、付款資料或上載文件在離開後消失。逐欄檢視用途、敏感程度，以及顧客能否重新輸入。檔案欄位與一般文字尤其不同；網頁通常不能假裝顧客再次選了本機檔案而暗中恢復。若草稿必須包含附件，就要設計有登入保護的伺服器上載、可見狀態、保存期限和刪除途徑，或請顧客重新選檔。

讓儲存方式配合恢復承諾

瀏覽器的 sessionStorage 屬於某個來源及分頁時段，可支援該時段內部分導航或重新載入，但不應宣稱是可靠的「稍後回來」服務。localStorage 會跨瀏覽器時段保留，亦沒有內建到期日；若應用程式或瀏覽器沒有清除，遺忘的草稿可能留在家庭電腦。瀏覽器儲存亦可能因政策或配額而不可用或拋出錯誤。應把它視為經測試的便利功能，而非重要客戶申請的保證檔案庫。

若流程須在另一裝置或重新登入後繼續，與帳戶綁定的伺服器草稿通常較易界定及稽核。伺服器每次讀寫都要檢查登入身分，確保草稿屬於正確顧客與流程，並設保存規則。若匿名訪客也可儲存草稿，須設計安全的認領方法，不能假定持有網址就足以查看私人紀錄。電郵草稿連結亦有到期和洩露風險。介面和客服說明應寫出真正的恢復承諾，而非讓「自動儲存」三字暗示更強保證。

不要為方便草稿功能而把登入權杖放進 localStorage。草稿是業務資料；登入狀態是另一項安全決策。若網頁程式能讀取權杖，注入的惡意程式也可能讀取。保留既有時段設計，並明確處理時段屆滿。WCAG 的重新驗證準則描述登入時段屆滿後仍可無損地繼續活動，屬 AAA 等級；不要只因顯示提示就聲稱未經測試的設計已符合準則。實際測試是顧客重新登入後，能否查看及遞交先前輸入的內容。

讓儲存、修改和刪除清楚可見

決定何時嘗試儲存：停止輸入片刻後、切換段落時、按明確按鈕，或組合使用。延遲儲存可減少重複寫入，但最新一句在一段時間內仍未保存。顯示最後成功儲存時間或清楚的「尚未儲存」狀態，並把「遞交」另設為獨立動作。若顧客關閉分頁時寫入仍在進行，離頁事件並非可靠的最後備份。應測試真實關閉及離線情況，不要假設生命週期回呼一定救得回最後幾個字。

恢復的草稿是供顧客選擇繼續的版本，不代表可覆寫剛輸入的新內容。返回時顯示草稿日期與足夠識別資料，再按需要提供「繼續」或「重新開始」。若顧客已在另一分頁或裝置修改資料，不要暗中以舊版本覆蓋新版本。伺服器草稿可帶版本號或更新時間，讓介面發現衝突後請顧客選擇保留哪份。兩種語言的衝突選項都須容易理解；顧客作決定前，不要刪掉舊版本。

刪除規則應與儲存規則同樣仔細。成功遞交後，移除或關閉相應草稿，避免舊表格再次出現而誘發重複申請。提供看得見的「捨棄草稿」，刪除大量工作前解釋後果。帳戶關閉或公布的保存期屆滿時，處置程序亦要包括草稿及必要紀錄。若只在瀏覽器儲存，遞交或捨棄後應清除相應項目；清除一台裝置不會刪掉另一裝置的伺服器副本。客服亦須分得清已保存草稿和正式接納的申請。

演練一份較長的服務申請

以一家上門服務公司為例：表格要求地址、進入大廈的說明、希望預約時段和照片。顧客在手機填寫，停下來查大廈規則，翌晚再回來。公司決定把文字存入已登入帳戶的伺服器草稿；照片若未完成安全上載，便請顧客重新選擇。返回時首屏顯示最後儲存時間，並說明尚未提交預約。顧客須再次檢查地址及時段，因可用時間可能改變。只有最後按下「遞交」才為員工建立查詢紀錄。

用真正測試帳戶演練故障，而非只描述理想流程。輸入長段說明，在儲存前關閉網絡，再關掉及重開分頁，把恢復文字與最後成功儲存時間對照。另測登入時段屆滿、瀏覽器儲存被封鎖，以及兩個分頁同時開啟草稿。核實介面不會把失敗寫入說成成功；即使無法儲存，顧客仍可複製畫面上的文字。除觸控外，亦要以鍵盤和屏幕閱讀器測試，包括狀態更新會否打斷輸入。

亦要檢查客服後果。若顧客來電查問申請是否收到，員工應可清楚分辨未遞交草稿與已收妥查詢，同時避免全隊都能查看不必要的草稿內容。確認編號應屬於正式遞交狀態，而非自動儲存狀態。若使用第三方表格服務，作出恢復承諾前要核實其實際草稿保存期、存取控制、匯出及刪除行為。單一瀏覽器的本機測試，不能證明供應商整體服務保證。

訂立團隊能兌現的承諾

實作前先寫一段簡短產品規則：儲存哪些欄位、存在哪裏、由甚麼事件觸發、保存多久，以及歸屬哪個帳戶。補上儲存失敗、草稿到期和時段結束時，顧客會看見甚麼。設計、工程和客服應先就這些句子達成一致。這能及早揭示矛盾，例如介面承諾可在任何裝置繼續，實際卻只用了 sessionStorage；亦令品質測試有具體驗收條件，而非籠統檢查自動儲存。

首版功能應與需要相稱。若大部分查詢很快完成，可靠的遞交流程及錯誤後保留輸入，可能更值得先處理。若顧客經常需要暫停搜集文件，便在該流程試行帳戶草稿，觀察恢復失敗的位置。用真正客服個案和測試觀察改進設計；沒有量度就不要聲稱轉換率上升。成功條件雖簡單卻重要：顧客知道資料有否保存、能恢復獲准保留的部分，並且不會把草稿誤認為已接納的請求。