構建自助管理區域的藝術

已發表: 2022-03-11

一旦你啟動了你的被動收入網站,你應該慶祝一下,對吧?

不幸的是,生活並不總是應有的樣子,你通常不得不推遲慶祝活動來迎合你的客戶——除非你有正確的系統。

我管理一個被動收入網站已經六年多了。 對我來說,重點一直是“被動”。 因此,盡可能精簡我的業務一直是我的首要任務。

有效地簡化在線業務歸結為在您的管理面板中具有正確的特性和功能。

在本文中,我將詳細介紹管理儀表板的常見問題,並為每個問題提供解決方案。 在本文結束時,您將獲得一本強大的最佳實踐手冊,為您的自動化業務開發高效的管理面板。

考慮用戶錯誤

用戶會犯錯誤,這意味著我們需要一個管理面板來修復這些錯誤。 這裡有幾個例子。

您的一個供應商不小心將錯誤的產品發給了客戶。
客戶訂購了錯誤的產品或訂購了兩次相同的產品。
您的樂譜列表網站上的音樂家創建了幾乎相同的分類法,這些分類法已經存在於您的數據庫中。 例如,您網站的用戶被視為一個集體,將電吉他指法分散在三個類別中:“電吉他”、“電吉他”和“電吉他”。 這些確實應該是一個,否則您的前端導航和可用性會受到影響。

優化您的管理面板以解決用戶錯誤:

允許最終用戶糾正他們的錯誤。 例如,亞馬遜在其用戶的儀表板中有表格,允許客戶在其倉庫處理訂單之前的任何時間點更改訂單。 此功能使亞馬遜客戶能夠在不尋求客戶支持的情況下糾正錯誤。
將一部分用戶提升為主持人狀態。 Reddit 和 StackOverflow 等論壇有一個特殊的用戶類別,稱為版主。 版主刪除垃圾郵件、編輯拼寫錯誤、清除網站上的攻擊性或自我宣傳信息,並對內容進行正確分類。 在許多情況下,版主是志願者,他們只是對社區感到忠誠。

考慮用戶缺乏經驗

不要期望您的用戶精通您的業務。 這裡有幾個例子來說明我的意思。

例如,您的普通用戶是一個糟糕的攝影師,但您希望在您的平台上列出同一用戶的度假出租物業的精美照片。

也許普通用戶是一個糟糕的銷售人員,但你想要那些用戶通過你的平台銷售的小飾品的誘人的、SEO 優化的描述。

或者,也許您經營一家在線銷售鞋子的電子商務商店,但您的普通網站訪問者不知道如何測量他們的腳,這導致大部分客戶訂購了錯誤的尺碼,然後想稍後退回他們的鞋子。

導致用戶缺乏經驗的管理區域:

創建內聯文檔。 就如何充分利用他們對您網站的體驗向用戶提供建議。 例如,您可以寫一篇文章,如“5 個可以增加銷售額的文案寫作技巧”。 通過為用戶提供可靠的參考資料,您將大大減少他們對人工幫助的需求。
半自動輔助。 通過連接外部軟件 API,您的網站可以做一些事情,例如自動建議元描述的最佳關鍵字,並鼓勵用戶將某些關鍵字合併到他們的副本中。
自己做。 發送您自己的照片或編寫您自己的產品說明。 當然,這需要最終用戶以某種方式向您組織中的合適人員表明他們已準備好使用此服務。 在這裡,您的管理系統需要簡化這種溝通以及專家稍後交付的工作。

未決業務決策的會計處理

不幸的是,一切都不能自動化。 在進行判斷時,通常需要人工。

例如,當您需要在您的高信任平台上驗證您最新的保姆申請人的身份時會發生什麼?

或者,當您是唯一可以為平台作者提交的最新數字產品定價的人時會發生什麼?

因未決業務決策而為管理員節省時間的示例:

利用現有的用戶組。 約會網站 Plenty Of Fish 將可能令人反感的個人資料照片的審核外包給志願者用戶,這些用戶花費無數小時檢查這些照片,而無需支付任何報酬。 與傳統的論壇版主不同,他們不會在內容髮布後對其進行審核。 相反,他們會在發布前審查用戶提交的照片,從而確保不適當的個人資料照片永遠不會被發布。
連接到人類即服務 API。 例如,Facebook 將其管理面板連接到雲 API,例如 Amazon Turk(或內部同類產品),並將審核大量外包給更便宜的工人。 就 Facebook 而言,專業版主佔其員工總數的三分之一。 確實,與相對未經審核的網站上出現的駭人聽聞的言論相比,適度的存在有助於確保 Facebook 的評論相對溫和。

會計用戶需要與網站的管理溝通

當您經營企業時,會出現問題。 通過有效地提前計劃,您可以顯著縮短響應時間,並可能首先減少您收到的客戶請求的數量。

滿足用戶通信需求的管理區域:

未雨綢繆。 通過分析過去的客戶服務問題,您可以發現常見主題並提前回答。 一個典型的例子是設計一個包含這些問題和答案列表的常見問題解答頁面。
快速退款給客戶。 針對客戶投訴提供快速退款是滿足失望客戶的一種非常有效的方式。 別擔心——這不會導致利潤減少; 事實上,它甚至可能導致更多。
為困惑的訪客創建論壇。 谷歌因其幾乎不存在的客戶服務而臭名昭著。 代替人工,谷歌創建了產品論壇,困惑的用戶可以從其他用戶那裡獲得幫助。 在極少數情況下,當 Google 員工在其中一個論壇上回答問題時,他們的答案會被保存,很容易被 Google 索引,並可供未來遇到相同問題的用戶使用。 雖然這對最終用戶來說可能看起來很殘酷,但當您考慮到大多數 Google 不受支持的產品都是免費的時,這是非常合理的。
利用預設響應和虛擬助手 (VA)。 查看過去一年的客戶服務單,並提取一致提出的問題。 通過為每個人製作模板回复,您將為自己節省大量時間。 在易於訪問的 Google Doc 中寫下您的答案,或者更好的是,使用電子郵件插件,例如 Canned Responses。 然後聘請 VA 在出現問題時將這些模板轉發給客戶。

考慮用戶改變主意

一位智者曾經說過:“變化是生命中唯一不變的。” 他是對的。 事情會改變的。

也許用戶結婚了,他們不再有相同的姓氏。

或者,可能是訂閱了您的每月送貨箱服務的客戶搬家並需要更新他們的地址。

這些只是不可避免的變化的兩個例子,您必須提前計劃。

由於用戶的情況/思想變化而為管理員節省時間的示例:

您的用戶需要編輯能力。 如果您沒有在用戶儀表板中提供編輯功能,那麼遲早您的客戶支持團隊 - 以及您的數據庫程序員 - 將不得不手動進行更改,就像上面提到的那樣。
不要凍結編輯功能。 對於有評論的論壇或網站,您必須考慮凍結帖子以進行刪除的政策,或者放置一個按鈕,請求對正常政策進行例外處理。 此解決方案通過減少支持團隊和最終用戶之間來回消息的數量來節省時間。

歸因於用戶擔憂的行動

與實體店不同,在線業務缺乏從真人那裡購買的保證。

想想看。 當你在百思買買東西時,你感覺如何? 可能很有信心,因為您知道明天早上,如果您返回投訴或退款,百思買仍然會在那裡。

由於顯而易見的原因,這種確定性的感覺在網上消失了。 人們很容易忽略在線交流,這讓潛在客戶想知道是否有人會回复他們。 只有當網站是一些沒有品牌資產的不知名的初創公司時,這種懷疑的感覺才會增加。

管理員因用戶擔心而節省時間的示例:

先發製人地解決問題。 一旦有人向您購買商品,請發送一兩封電子郵件以增加信心。 例如,亞馬遜以及幾乎所有電子商務企業,都會在訂單發貨後立即發送電子郵件。 其他人還提供一系列電子郵件,在產品交付之前更新用戶。

解決潛在的歧義

推出一年後,由於收入可觀,您現在將網站的管理委派給專門的團隊成員。

然而,有一天,這位管理員意外地生病了,現在需要恢復他們的管理工作,而沒有任何關於該管理員上週所做的事情的簡報。

根據管理面板中的信息,您需要知道管理員在哪裡停止 - 他們處理了哪些任務以及他們未完成的任務。

這並不總是可能的,因為設計不良的狀態機不能可靠地區分未見(或未處理)和已考慮(或已處理)。 例如,想像一個管理狀態機如下:

發生什麼了狀態變化
藝術家申請在您的藝術品銷售平台上出售他們的藝術品藝術家條目出現在管理面板中,起始狀態為“已應用”
您的管理團隊中的某個人接受了該藝術家,允許他們出售他們的藝術作品管理員將狀態更改為“已接受”
你的團隊拒絕了這個藝術家,因為它知道,它肯定永遠不會想要那個藝術家管理員將狀態更改為“拒絕”
您的團隊對這位藝術家持觀望態度,希望推遲決定沒做什麼


從系統管理員的角度來看,這個管理流程的問題在於,管理面闆對看不見的新藝術家已經看過/考慮但被推遲但沒有被徹底拒絕的藝術家都說“接受”。

考慮(或處理)該藝術家僅存在於缺席管理員的腦海中的事實,並且沒有任何方式將潛在客戶標記為“推遲”,此信息丟失,因此接管工作的人必須重複工作已經完成。

一個好的活動提要可以解決這種類型的歧義。

最大化透明度

許多管理小組行動在幕後執行一系列步驟。

例如,在按下“接受申請人”按鈕後,相關申請人會收到一封接受電子郵件,他們的帳戶會獲得 100 美元的開卡獎金,並且他們在數據庫中的狀態會從“已申請”更改為“已接受”。 在軟件工程術語中,這些都是副作用

鑑於您(程序員)開發了這些功能,您可能已經意識到點擊“接受申請人”的後果。

至少,您可以打開一個源代碼編輯器或您最喜歡的 IDE,然後參考代碼以獲得答案。

但是,您的客戶服務代表沒有這種奢侈。 所以他們很可能不確定當他們按下按鈕時會發生什麼。 此外,他們可能會想知道申請人是否會被告知他們已被接受,或者他們是否應該在按下按鈕後發送手動電子郵件以提醒申請人。

這種不確定性減慢了整個過程,因為現在,管理員需要詢問管理和/或工程問題並等待他們的答复。 更不用說這很容易導致重複工作並將錯誤引入原本平穩運行的業務。

理想情況下,在這個例子中,帶有“接受申請人”按鈕的管理頁面應該有一個內嵌的描述性段落,準確地解釋當他們按下按鈕時會發生什麼。

或者或另外,在按下按鈕後可能會出現一條消息,解釋接下來會發生什麼。

到目前為止,我們已經看到了快樂的情況,即當一切正常運行時發生的後台操作。 更棘手的情況是在出現問題後處理不透明性。 哪些副作用已完成,哪些未完成? 在一個完美設計的系統中,如果失敗,“接受申請人”按鈕會通知管理員(以及進行清理的技術團隊)接受電子郵件已送達,但 100 美元的註冊獎金並未發送到該用戶的 Paypal 帳戶。 該信息使公司能夠糾正部分交易。 至於實現細節,這種反饋可以通過跟踪每一個微小步驟的詳細狀態機來完成,或者通過將管理操作包裝在服務對像中,這些服務對象的返回值列出了成功運行的命令和未能運行的命令。

以我的經驗,信息呈現給管理員的方式與呈現給最終用戶的方式之間的差距可能令人沮喪地不透明。

有時,回复客戶電子郵件或錯誤報告需要您的管理團隊了解客戶登錄儀表板的外觀、特定自動電子郵件的內容,或者面向用戶的儀表板所說的欠用戶的版稅。

訪問此信息有助於您的團隊在用戶遇到問題時了解問題。

實現此功能的一種方法是構建“以用戶身份查看”管理功能。

這將代替創建單獨的管理屏幕來重新實現已為普通用戶提供的功能,從而為您提供重用大量現有代碼的額外獎勵。

至於自動電子郵件,請考慮構建一個輕量級的管理區域電子郵件渲染器,以便您的員工可以閱讀將要或已經發送給用戶的消息。

系統外的事件是一種責任

可管理的管理是獨立的。

它被裝在一個封閉的系統中,而不是分散的碎片中。

例如,如果有關您提供的退款的信息分散在 Excel 電子表格、桌子上的一些黃色便利貼以及發給您會計師的電子郵件中,那麼您的手上就會一團糟。

正確的解決方案是在您的管理儀表板的數據庫表中列出完整的退款列表。 當您擁有一個單一的真理神諭時,您可以放心,您製作的任何報告都是權威且值得信賴的。

雖然這看起來很明顯,但在管理企業的過程中經常被忽視。

我會知道,因為它發生在我身上。

當我最初設計我的電子商務訂購系統管理面板時,我只准備它來記錄銷售額並且只記錄銷售額。

推出幾個月後,我意識到所有我沒有考慮到的額外交易,例如退款、拒付、免費贈品、折扣和付款調整。

因為我在最初的設計中沒有預見到這些交易,所以我的管理面板中沒有用於履行或報告它們的代碼。

每當我必須退款時,我通常時間緊迫,以至於我以當時最簡單的方式進行 - 通常通過 Paypal 的網絡界面(跳過我網站的訂單數據庫) - 但有時通過第三方 iPhone與 Paypal 的 API 通信的應用程序。

由於我的行動和數據分散,我的所有會計都在各種外部來源中隨意報告。 更糟糕的是,我的生產數據庫記錄與我的完整訂單歷史記錄並不一致。

不可避免地,問題出現了。 收入和佣金的管理報告並未反映經濟現實。 我的一些作者收到了帶有錯誤財務報告的財務報告。 最糟糕的是,我高估了我的稅務報告,導致繳納了超額稅款。

所有這一切都是因為我沒有打折所有退款。

通過將訂單和會計信息部分存儲在我的主要軟件系統內部和部分存儲在我的主要軟件系統之外,我首先剝奪了自己軟件的許多優勢——它的準確性和精確性。 我不再信任它,這意味著我不能再自動化它。

針對這些問題,我開始厭惡將任何公司數據保留在我的核心軟件系統之外。

即使最初將所有必要的信息集成到核心中的成本很高,但從長遠來看,其收益遠遠超過半成品黑客的成本。

也就是說,儘管我的最佳意圖是自動化,但有時它就是不可能發生的。

許多軟件公司都有自動銷售電子郵件,將用戶逐英寸傳送到他們將激活帳戶或進行購買的點——理想情況下,所有這些都不需要任何人工幫助。

當潛在客戶在其中一項滴灌活動中途向您的員工發送特殊要求時,就會出現並發症。

假設領導回應說他們將休假兩週,但請在之後與他們聯繫以達成交易。

如果我們的系統被編程為僅在五天后發送一封自動提醒電子郵件,那麼我們就忽略了領導的意願,並且可能通過給人一種咄咄逼人、不專心和機器人的印象而使關係惡化。

那麼在這種情況下該怎麼辦呢?

一種答案是半自動的。

管理界面可能會詢問您應該發送哪些電子郵件,您可以勾選一個框以根據需要取消安排它們。

誠然,這可能是工程上的矯枉過正,所以有時唯一現實的選擇是接受自動電子郵件有時會出錯。

顯示最相關的管理員信息和操作

當客戶聯繫您的業務時,通常與訂單、帳戶或產品有關。

憑藉存儲的數據、登錄 cookie 和來自跟踪層的數據,您的應用程序可能對其客戶及其交互歷史了解很多。

您可以通過算法提取這些信息源並提取相關數據位以促進管理員的響應,從而節省大量響應客戶服務請求的時間。

例如,聯繫表單消息在轉換為發送到收件箱的電子郵件之前,可能會自動附加一個信息框,其中包括訂單的付款狀態、運輸狀態、行項目等。

此外,這些強化電子郵件還可以包含指向管理區域最常用(和相關)部分的便捷鏈接,例如退款儀表板或運輸跟踪器。

預測、緩解和從管理員錯誤中恢復

和其他人一樣,管理員也是人,偶爾也會犯錯。

鑑於他們對您的數據擁有控制權,他們的錯誤可能會造成無法彌補的損失。

為了防止災難,這裡有一些措施:

自動安排一致的備份:這是所有可想像的盡職調查措施中最粗略、最瑣碎但最重要的。 但是,即使您有良好的備份,如果您需要修改 SQL 轉儲,您也已經陷入了痛苦的境地。 因此,計劃的備份不應該是您唯一的恢復來源。
旨在恐嚇用戶的按鈕:對於具有潛在不可挽回後果的操作,將其塗成鮮紅色,在其上貼上放射性圖標,並用標題標記它們,例如“警告:硬刪除是核選項:如果不確定,請勿使用結果。” (顯然,您應該在此按鈕旁邊顯示這些後果。)
使用 JavaScript 確認彈出窗口:有時管理員的手指滑落,而不是按下“返回”按鈕,他們不小心按下了位於下方兩個像素的“永久刪除所有內容”按鈕。 倒霉的管理員可能對這次事故完全沒有過錯,最終歸咎於笨拙的 UI 設計或渲染 CSS 時令人討厭的瀏覽器怪癖。 如果你認為這是一個荒謬且過於戲劇化的例子,那你就錯了。 金融服務業因他們所謂的胖手指錯誤而損失了數百萬美元。 因此,他們設計軟件來防止這些類型的錯誤。 一個非常簡單的解決方法是“您確定要刪除所有訂單歷史記錄嗎?” Javascript 彈出窗口。 請注意我如何在 Javascript 確認中包含特定於實體的數據——“所有訂單歷史記錄”? 這比僅僅問“你確定嗎?”要好。 如果管理員打算刪除訂單歷史記錄中的單個條目,但不小心點擊了刪除所有訂單歷史記錄的按鈕,那麼在 Javascript 確認彈出窗口中明確說明這一點有助於避免“OMG”時刻,當管理員意識到 [s]he做錯了。
利用數據版本控制和修訂控制:在標準 SQL 數據庫技術中,對數據的編輯會覆蓋舊值。 當編輯錯誤時,這是有問題的,當原始數據難以找到或再次創建時,雙重問題 - 例如,需要花費數小時編寫的長描述字段,或者再次詢問會令人尷尬的客戶信息。 修訂控制庫(如 Wikipedia 中的)是解決這些情況的首選方法。 它們使您可以根據需要輕鬆存儲和恢復舊版本的數據。 這些庫通常通過跟踪數據庫中的更改並保留以前值的時間戳版本來工作。 不幸的是,修訂控制庫通常無法處理大的二進製文件,例如照片和 pdf。 因此,對於這些數據類型,您可以保留舊版本,使用類似 Amazon 的 S3 版本控制。
考慮實施禁止刪除策略:這完全是為了防止某些表中的記錄被刪除。 這背後的原因是:鑑於現代數據存儲價格,刪除舊記錄幾乎沒有什麼好處,而在數據完整性受損、報告不完整或記錄保存不匹配方面會損失很多。 通過在每個主要表上放置一個“deleted_at”日期列來實施不刪除策略。 無論您以前在哪裡有刪除記錄的代碼,都可以替換為將該記錄的“deleted_at”列設置為當前時間的代碼。 在整個代碼的其他地方,您可以根據業務需要選擇性地顯示或隱藏“已刪除”記錄。 例如,“已刪除”的數字下載將繼續出現在管理區域中,對於在“deleted_at”日期之前購買該特定商品的過去客戶,以及“所有時間”的銷售報告中。 但是,前端商店不應再向潛在客戶展示該數字產品。

期待意外

雖然我為上述一系列問題提供了多種解決方案,但這些絕不是一成不變的規則,而是一本可供學習和參考的強大劇本。

請記住,最終目標是優化您的管理面板以簡化您的業務。 從長遠來看,留出一些時間來調整您的管理區域應該會提高盈利能力,使其成為一項值得的投資。

與生活中的任何事情一樣,規則總會有例外,因此在優化管理面板時請務必使用良好的判斷力。 然後你終於可以慶祝了。