在Slack、微信之類聊天工具中如何管理批准工作流? - wrangle

banq發表於2020-08-02

對於我們大多數人來說,Slack是我們交流的預設方式,它取代了電子郵件收件箱。隨著我們將更多的工作投入到Slack中,您的團隊可能已開始嘗試讓訊息傳遞同事批准這些事情以進行簽名。這些決定中的一些對於正確做出決定非常重要。

Slack使我們在建立對話時具有很大的靈活性,但是這種隨心所欲的方法在您需要進行結構化決策時會造成混亂。由於Slack沒有內建的批准工作流程,因此在使用聊天進行批准時遇到了以下幾個問題:
  • 如何讓人們批准?您向某人傳送訊息以供批准,他們正在開會,但他們忘記將其標記為未讀。幾天後,您便要提醒他們需要做出決定。這會很困難。
  • 在繁忙的頻道中迷路。或者,您在訊息中傳送了一個小組反饋的頻道,突然之間,您的討論變得很漫長,同時又混入了其他六個討論。在其他時區的員工使用數百個未讀的Slack開始新一天時,可能會完全錯過該請求。另外,在繁忙的渠道中,不可能快速檢視誰真正批准了。他們的表情符號反應是否表示他們同意這個決定?他們有保留嗎?或者他們同意人群嗎?
  • 必須回去詢問更多資訊。當人們要求使用自由格式的文字進行批准時,他們通常會忘記包含重要資訊。因此,您必須答覆並概述所有需要了解的事情-例如,需要在購買請求中澄清有多少使用者將使用某些新軟體。如果您可以將它們組織成一種形式,那麼生活會容易得多。
  • 沒有記錄決定。許多決定需要稍後進行稽核。如果有人要為其團隊購買某些軟體,那麼當財務副總裁敲門問問誰批准該軟體時,您會怎麼做?如果與該人一起在DM中待了3個月,那麼以後很難追究責任。
  • 沒有結束迴圈。除了決策迷失之外,對決策採取行動還存在一些問題。在您批准聘用某人後,需要發出要約,通知人力資源,簽署他們的合同等。有人必須手動啟動所有這些操作,但是我們忘記了過程中的所有步驟,因此迴圈永遠不會結束。


理想的Slack等聊天工具中批准流程是什麼
如果我們要使Slack批准生效,就必須克服自由格式聊天的一些限制。理想情況下,我們為這些決策引入一些結構和文件,同時仍然使批准變得非常簡單。
以下是一些有幫助的事情:

  • 批准或拒絕的按鈕。如果您是開發人員,那麼Slack為您提供了許多向訊息新增按鈕的方法。如果我們可以使機器人透過一鍵式按鈕向批准者傳送訊息以批准或拒絕該怎麼辦?現在,我們不必嘗試解釋他們的表情符號或模糊的響應-我們有了明確的決定。[顯示Wrangle批准的螢幕截圖]
  • 請求更改的方式。在大多數情況下,當我們不準備批准時,我們希望此人進行一些更改。因此,如果我們要使用這些明確的方法來批准或拒絕,則在最終批准之前,我們可能需要一種與請求者進行迭代的方法。
  • 批准檔案。Slack在我們所有的對話中都有很長的歷史,但是有時候很難在大海撈針上找到針頭。在某個地方記錄我們給予的批准將是一個很棒的記錄系統。
  • 多級批准。通常,我們需要讓來自不同團隊的多個人參與批准。如果Slack有辦法將這些單獨的批准分組為一個大決策,那麼我們就可以完成更復雜的決策,而不必為我們的所有決策設定一千個DM。另外,我們可能需要根據請求以一種或另一種方式路由批准。例如,如果有要審查的自定義合同,則獲得合法簽字。
  • 結束迴圈。在大多數情況下,批准會導致採取後續行動。如果我們的Slack工作流程還可以處理向某人分配任務,那將是很好的。在員工入職情況下,我們可能會批准僱用某人,但隨後需要指派某人將要約詳細資訊傳送給候選人。


批准形式
由於Slack會將收件箱替換為我們收到通知的地方,因此成為我們所有批准的中心是有道理的。以下是我們希望使用Slack進行的一些操作:

  • 銷售報價和合同。有很多人參與複雜的交易,例如財務,法律,交付團隊,工程和銷售管理。使此過程更簡單將是理想的。
  • 購買請求。絕對是最常見的批准請求之一。似乎是Slack的理想之選,但我們需要記錄誰獲得批准以及花費了多少。
  • 新員工:許多人參與其中的另一個過程,因此決定是結果。
  • 人力資源要求,如PTO或時間表。我們需要處理涉及團隊的許多不同流程。他們已經在Slack中了,因此這似乎是處理諸如請假的理想場所。
  • 客戶入職。當我們簽約新客戶時,當我們為客戶提供服務時,我們需要混合分配任務和批准工作專案。為了確保我們交付成功的實施,多個團隊必須做很多事情。


在Slack中進行更復雜的批准的方法
1)使用具有Slack通知的工具
許多工具(尤其是Figma等設計工具或Github等工程工具)都有Slack通知。很多時候,這些通知是關於正在評論或審查的工作的。因此,對於有限的用例,這些可以處理我們一些理想的批准工作流功能。
優點:內建的Slack通知
缺點:不靈活,僅適用於特定用例,通常僅限於一個團隊的工作

2)讓開發人員構建一個Slack機器人
開發人員可以編寫程式碼,以向其建立的漫遊器中的訊息新增按鈕。因此,我們可以讓開發人員為我們在Slack中構建批准工作流。然後,當我們想要進行某種批准(例如購買請求)時,可以讓他們對我們的機器人進行程式設計,以透過批准或拒絕的按鈕向合適的人傳送訊息。然後,他們可以將該決定儲存在資料庫或電子表格中,以便我們稍後進行檢查。
優點:將為我們提供批准按鈕和可稽核性
缺點:需要編寫程式碼,可能只需要關注一種批准即可。需要更多自定義程式碼來通知工作流中的下一個人以結束迴圈並對批准採取行動。

3)在無程式碼工具中構建Slack機器人
像上面的#2一樣,我們也可以使用“無程式碼”工具(視覺化拖放式程式設計和自動化工具)來構建我們自己的批准Slack機器人。例如,我們可以使用Zapier或tray.io之類的自動化平臺。我們可以建立一個自動流程,該流程傳送帶有批准和拒絕按鈕的訊息,然後再構建兩個流程:一個流程用於處理批准,另一個流程用於處理拒絕。後兩個流程可以關閉迴圈,並在批准決策後使用任務跟蹤工具將某些任務分配給某人。這是一篇有關如何在tray.io中構建這些機器人之一的文章
優點:獲得批准後,會給我們批准按鈕並觸發任務分配
缺點:可能非常複雜,因為我們需要對多個流程進行視覺化程式設計才能進行批准工作。與編寫自定義程式碼相似,我們需要做更多的工作來支援許多不同種類的批准。我們還需要將決策自動記錄到資料庫或電子表格中。



 

相關文章