第23部分(第2/4 頁)

是沃爾沃讓訪客知道商家會在24小時內與其取得聯絡的方法：

很多公司好像都認為自己沒有競爭力。在B2B網站上我們看到，對消費調查的回應大部分超過了24小時。但是如果訪客被置之一邊，無人理睬，購買的可能性就大大減小，因為購買動力終止了。

提供多種選擇

RaDirect承諾“保證在一個營業日之內進行回覆（僅限北美地區）”。注意RaDirect同時也提醒人們，他們會透過公司的免費電話或者即時聊天工具與顧客取得聯絡：

設定標準

看過網上各式各樣的表格後，您會發現在必須填寫的專案前加星號（*）已成為一個網路標準。但是離線時我們填寫的表格一般只有在需要注意的事項和例外情況前加星號。離線情況下，人們認為，如果問題擺在那裡，您必須回答，除非表明回答不回答均可。因此，告訴訪客，確保他們知道星號表示的必填資訊，非選擇填寫資訊。

簡潔就是美，有時候也不完全對

人們常常想透過刪除多餘空白區域最佳化表格。最近，我們的一個客戶對錶格進行了A/B檢測。A要求訪客填寫電子郵件地址，但B不作此項要求。雖然B的完成率較A稍高，相關產品的銷售量卻非常低。自動回覆和跟蹤郵件的功能是不能忽略的。許多人沒有花時間研究電子郵件交流，研究過的人將會使顧客完成交易。

錯誤處理是另一個方面的問題

錯誤處理包含訪客和網站對訪客的回應兩個方面。網站開發者的任務經常是編寫程式處理錯誤。但很多時候，他們的指令只不過是“隨便編寫一些程式碼”來處理錯誤。沒有人能準確告訴他們網站上發生了什麼，結果網站開發者就是機械地處理錯誤：簡潔、準確、最小化，一般訪客完全不會理解是怎麼回事。

您以前已經知道：您點選按鍵上交表格，看到一個既難看又無關的網頁，顯示您操作有誤，再沒有別的附加資訊。也許實際上您犯了兩個錯誤，您只改正了其中一個，然後錯誤資訊又出來了。網站不能把所有錯誤一次性顯示出來，而是隻能一個個處理。　電子書　分享網站

第三章　交流（36）

錯誤處理可以分為兩類：處理要求和處理型別確認。第一種是關於需求的資訊或公司決定的任何必須完成的表格，比如在申請小冊中的位址列。如果顧客不提供郵寄地址，您就不能給他們傳送商品宣傳冊，對吧？

第二種要處理的是保證所提供的資訊是正確的資訊型別。比如，郵寄位址列中應該填寫地址，而不是電話號碼。

在設計網路表格時，您必須確定必須資訊和所有資訊的格式。電話號碼可以設為選填專案。如果訪客填了，網站應該可以分辨出這是電話號碼。

網站開發者傾向於把對科技的雙重體驗帶到處理網站表格錯誤中。他們分為兩大陣營：一方青睞客戶端表格錯誤處理，另一方喜歡伺服器端表格錯誤處理。換句話說，網站表格應該何時包含檢查必填區域和資料格式的編碼，在顧客上交之前還是之後？

這對您來說似乎是“半斤八兩”差不多的，人們正在熱烈爭論著哪種方法“更好”。客戶端驗證被認為更快捷（“網站更像是熟悉的桌面GUI應用程式”的委婉語），但這是典型的J*aScript編碼。J*aScript是高度依靠訪客的瀏覽器、瀏覽器版本和系統平臺，這些都有可能是阻擋購買動力的限制性因素。

伺服器端驗證允許控制處理資料的演算法，忽略瀏覽器相容問題。但是這確實需要網站伺服器進行雙向處理，先不要處理錯誤資訊，使用者點選“遞交”之後再處理。

網站開發者常常抓不住問題的要害：正確的元素是一切可以滿足訪客需求的元素，是在表格成功上交時用精準資訊造成最小動力減速路障的元素。開發者應該應用這兩種技術更好地為企業需求服務，即使要以犧牲保持編碼複雜性為代價。

提供最小的客戶端錯誤處理。這是處理必填區域和驗證路徑的非常有效的方法。使用跨平臺相容標準資料庫（如qForms，在伺服器端設定更多的錯誤處理）驗證J*aScript表格，這樣，不管訪客使用的瀏覽器的型別和版本是什麼，您都可以幫助提供資訊，減少動力減速路障。

顯示錯誤資訊

網站應該設法清晰地向訪客顯示錯誤資訊，讓他們知道該怎麼改正。Banana　Republic（香蕉共和國，經營時尚服裝）網站是一個很好的例子。如果您點選網頁底部