逃されたリクエストのほとんどは、1 回の劇的な失敗では消えません。彼らは静かに消えていきます。
顧客が 1 つのチャネルでアップデートを要求しました。パートナーが古い電子メール スレッドに返信します。忙しい一日の中で、チームメイトがブロッカーについて言及しました。マネージャーがそれを見て、後で処理する予定ですが、その後、新しいメッセージによってそのメッセージが表示されなくなります。
創業者、オーナー、CEO、COO、マネージャーにとって、これは不快な運営上の問題を引き起こします。ビジネスは助けようとする人々でいっぱいかもしれませんが、どのリクエストがまだ未処理で、誰がそのリクエストを所有しており、どのリクエストにエスカレーションが必要かを確実に言う人は誰もいません。
そこで、検証済みのフォローアップ キューが役立ちます。これは単なる共有受信トレイではありません。これは、承認されたコミュニケーション ソースをチェックし、未解決の項目を分類し、所有権を割り当て、顧客の不満、社内の遅延、または幹部の消火活動に発展する前に、未解決のリクエストを繰り返し確認できるビューを経営陣に提供する、管理されたリクエスト管理プロセスです。
受信トレイのチェックを増やしても問題がほとんど解決しない理由
リクエストが無視された場合、最初の反応は、メッセージをもっと頻繁にチェックするよう人々に求めることです。それは一週間は役立つかもしれない。耐久性のあるオペレーティング システムになることはほとんどありません。
問題は量だけではありません。それはあいまいさです。
一部のメッセージは質問です。一部は課題です。一部はFYIであり、後に約束に変わります。一部は別のスレッドですでに解決されています。緊急を要するものもありますが、カジュアルな表現になっています。一部の機能は非常に敏感であるため、自動化ではそれらを処理しようとするのではなく、人間に対してのみ表面に表示する必要があります。
これが、受信トレイ管理だけでは十分ではない理由です。ビジネスには、すべてのメッセージを同じ方法で処理できるかのように振る舞うことなく、ノイズと仕事を分離する方法が必要です。
反復可能なフォローアップ プロセスにより、実際的な質問に答えられるはずです。
- どの承認された情報源がレビューされますか?
- リクエスト、割り当て、ブロッカー、またはフォローアップとして何が考慮されますか?
- 項目がすでに解決されていることを示すシグナルは何ですか?
- 次のアクションの所有者は誰ですか?
- 項目がいつ緊急または期限切れになるべきですか?
- 返信やエスカレーションの前に人間の判断が必要な項目はどれですか?
- リーダーは何を毎日レビューする必要がありますか?毎週ですか、それとも経営会議の前ですか？
これらのルールがなければ、会社は記憶、善意、散在する通知に依存することになります。
検証済みのフォローアップ キューに含めるべき内容
検証済みキューは、利用可能なコンテキストに対してチェックされた、未解決の作業の構造化されたリストです。あらゆるメッセージの捨て場になってはいけません。その価値は、分類、所有権、レビューによって決まります。
KeepSolid Automations などのマネージド オートメーション サービスの場合、承認されたソースと明示的なビジネス ルールに基づいてプロセスを設計できます。検出と権限に応じて、ワークフローは受信トレイとチームのコミュニケーションを分類し、緊急アイテムを表示し、フォローアップ キューを維持し、タスクをルーティングし、ステータスを収集し、人間による決定のためのエグゼクティブ ブリーフィングを準備します。
実際には、通常、有用なキューには次のものが含まれます。
- 元のソース参照、
- リクエストまたはコミットメントの概要、
- 責任のある所有者、
- 現在のステータスまたは最新の既知の応答、
- 緊急性または期限の合図（利用可能な場合）、
- アイテムがまだ未解決であるとみなされる理由、
- 期限を過ぎたアイテム、ブロックされているアイテム、曖昧なアイテム、または機密アイテムのエスカレーション パス
「検証済み」という言葉が重要です。このプロセスでは、古いメッセージに質問が含まれているという理由だけで、明確に解決された作業を追加することは避けるべきです。マネージャーに介入を依頼する前に、返信、ステータス信号、所有者の更新を確認する必要があります。
所有権が運用リズムをどのように変えるか
各アイテムに所有者とレビュー パスがあると、未解決のリクエストを無視することが難しくなります。
それは、すべての項目に管理者の注意が必要であるという意味ではありません。健全なワークフローでは、明確なルールに基づいて、多くのリクエストを適切な担当者またはチームにルーティングできます。管理者は主に、期限切れ、ブロックされている、あいまいな、優先度の高い、または明確な所有者が不明のアイテムなどの例外を確認する必要があります。
これにより、リーダーの評価は「すべてに答えたことを覚えている人はいますか?」から変わります。より役立つ質問セットへ:
- どのリクエストが私たちを待っていますか?
- どのリクエストが顧客、パートナー、または内部関係者を待っていますか?
- どの所有者が過負荷またはブロックされていますか?
- 別のリマインダーではなく、どの問題が決定を必要としていますか?
- どのソースが繰り返し混乱を引き起こしていますか?
この種のレビューは、電子メール、チャット、スプレッドシート、タスク ツール、非公式のフォローアップを組み合わせて作業を進めるオーナー主導の企業やチームに特に役立ちます。目標は、自動化の背後に説明責任を隠すことではありません。目標は、説明責任を可視化することです。
自動化が役立つ場所と人間が制御を維持できる場所
ワークフロー自動化サービスは、人間が判断に責任を持ちながら、繰り返し可能な監視と準備作業を処理する場合に最も役立ちます。
たとえば、管理ワークフローは次のように設計できます。
- 承認されたコミュニケーション ソースのみをチェックします。
- 可能性のある質問、リクエスト、割り当て、未解決のフォローアップを分類します。
- 解決の兆候があるかどうかを特定します。
- 日常的な項目を予想される所有者にルーティングします。
- 責任者から状況を収集します。
- 期限を過ぎた作業やブロックされた作業を強調します。
- 出典参照を含む簡潔な役員概要を作成します。
しかし、プロセスでは限界も定義する必要があります。あいまいなコミュニケーション、デリケートなコミュニケーション、または影響の大きいコミュニケーションは、担当者にエスカレーションする必要があります。ワークフローでアイテムを自信を持って分類できない場合は、不確実性を埋めるのではなく、明らかにする必要があります。アクションが外部的、破壊的、管理的、財務的、またはその他の結果的なものである場合、クライアントのルールに基づいて明示的な承認を必要とする必要があります。
これが、マネージド サービスのアプローチが、単に別の自動化ツールを追加することとは異なる理由の 1 つです。実装は実際のビジネス プロセス、つまりトリガー、入力、所有者、承認、例外、必要な出力、レビュー責任から始まります。
ビジネス オーナー向けの実践的な評価チェックリスト
検証済みキューを構築する前に、所有者とオペレーターはプロセスを自動化する準備ができているかどうかを評価できます。
ソースから始めます。現在リクエストが発生している通信チャネルをリストします。企業が承認、アクセス、管理できるソースのみを含めます。チャネルに機密データまたは制限されたデータが含まれている場合、それは最初から設計上の制約として処理する必要があります。
次に、何が未解決としてカウントされるかを定義します。誰も返信しなかったり、所有者がステータスを更新していないため、返信には承認が必要であるため、または次のステップが別のチームに依存しているため、リクエストがオープンになっている可能性があります。これらのケースを同一のものとして扱うべきではありません。
次に、所有者の名前を指定します。明確なルールによってリクエストを割り当てることができない場合、ワークフローは推測ではなく人間のレビュー担当者にリクエストをルーティングする必要があります。所有権ルールは、職務、顧客、取引、プロジェクト、トピック、緊急性、または別の承認された運用ルールに基づくことができます。
最後に、管理者がキューをどのようにレビューするかを決定します。一部のチームでは、毎日の管理概要が必要です。項目がしきい値を超えた場合にのみエスカレーションが必要な場合もあります。形式は使用するのに十分短く、実行するのに十分具体的である必要があります。
通常、最良の最初のバージョンは、少数の承認されたソース、明確なリクエスト タイプ、指定された所有者、およびシンプルなエスカレーション リズムという範囲が狭いものです。企業がルールをテストし、実際の例外を確認した後、より広範な適用範囲を検討できます。
プロセスを設定するときに避けるべきこと
フォローアップ キューが急速に広くなりすぎると、失敗する可能性があります。
すべてのメッセージをタスクとして扱うことは避けてください。それは騒音を生み、列を無視するように人々を訓練します。レビューせずに自動化に機密性の高い意図を推測させることは避けてください。実際の問題として責任を負う人がいない場合は、作業を一般的なチームの所有権にルーティングすることは避けてください。合計のみを報告することは避けてください。リーダーには単にカウントするだけではなく、コンテキストが必要です。
ツールや統合についてサポートされていない仮定を避けることも重要です。実現可能性は、クライアントのシステム、権限、データ品質、リスク レベル、要件によって異なります。責任ある実装では、アクセスを検証し、通常のケースと特殊なケースをテストし、レビュー担当者がソース証拠を利用できるようにし、例外に対する手動フォールバックを維持する必要があります。
KeepSolid Automation がワークフローをサポートする方法
KeepSolid Automations は、企業が反復的な運用作業を管理されたカスタム自動化システムに変えるのに役立ちます。コミュニケーション制御と未回答リクエストの追跡の場合、これは、承認された受信トレイとチームのコミュニケーションを分類し、緊急アイテムを表示し、フォローアップキューを維持し、明確なルールに基づいてタスクをルーティングし、ステータスを収集し、人間の決定のための役員ブリーフを準備する、管理されたプロセスを設計および維持することを意味します。
このサービスは、DIY 受信ボックス プラグインとしては位置付けられていません。これは、クライアントの実際のプロセスを中心に構築されています。つまり、何を監視する必要があるか、どのルールが信頼できるか、各カテゴリの作業の所有者は誰か、どこで人間の承認が必要か、例外をどのようにレビューするかなどです。
未処理のメッセージを理解するためにメッセージを検索することにうんざりしているリーダーにとって、正しい質問は単に「どの受信トレイを見逃したか?」ということではありません。より良い質問は、「未解決の作業を表示、所有、レビュー可能にする検証済みのフォローアップ プロセスはありますか?」です。
答えが「いいえ」の場合、それが自動化検出に関する会話の良い出発点になる可能性があります。
よくある質問
リクエスト管理は共有受信トレイと同じですか?
必ずしもそうとは限りません。共有受信箱ではメッセージを収集できますが、リクエスト管理には分類、所有権、ステータス、エスカレーション、レビューのルールが必要です。検証済みのフォローアップ キューでは、判断が必要なケースに対する人間の責任を維持しながら、承認されたコミュニケーション ソースを使用できます。
自動化はすべての未解決リクエストに応答できますか?
それが目標であってはなりません。一部の日常的なフォローアップは、承認された草案やルーティングをサポートする場合がありますが、あいまいな、機密性の高い、影響の大きい、または重大なコミュニケーションは担当者がレビューする必要があります。より安全な運用モデルは、未解決のリクエストをコンテキストと明確な所有権とともに表面化し、責任ある担当者に最終決定を委ねることです。
フォローアップ プロセスを繰り返し可能にするものは何ですか?
反復可能なプロセスでは、ソース、リクエスト タイプ、所有者、ステータス シグナル、エスカレーション ルール、レビュー頻度、および例外処理を定義します。また、管理者が概要だけに依存するのではなくコンテキストを確認できるように、ソース参照も保持する必要があります。
企業はこの問題に対してワークフロー自動化サービスをいつ検討すべきですか?
フォローアップの欠落が繰り返し発生する場合、作業が承認された複数のコミュニケーション ソースに分散している場合、マネージャーが状況を尋ねるのに時間がかかりすぎる場合、または所有権が不明瞭な場合に検討してください。検出では、実装前にプロセス、アクセス、データ、リスク レベルが適切かどうかを確認する必要があります。
