払い戻し、ソフトウェアアクセス、またはコンテンツの変更に対する承認を得るために、Slackのスレッドやメールのやり取りで人を追いかける必要はありません。Zendeskの承認ワークフローは、まさにこの問題を解決するために存在します。これにより、構造化された承認プロセスをチケットに直接組み込むことができます。
マネージャーの承認が必要な顧客の払い戻しリクエスト、人事部の承認が必要な従業員の休暇リクエスト、または公開前に編集レビューが必要なヘルプセンターの記事を処理する場合でも、承認ワークフローはすべてを文書化し、スムーズに進めることができます。
このガイドでは、Zendeskで承認ワークフローを設定する方法について説明します。ネイティブで利用できる機能、下位プランのチーム向けの回避策、およびより高度な機能が必要な場合のオプションについて説明します。
Zendeskの承認ワークフローとは?
Zendeskの承認ワークフローは、本質的に、チケットに対してアクションを実行する前に承認を得るための構造化されたプロセスです。これには、次の2つの種類があります。
チケットレベルの承認を使用すると、エージェントはサポートチケット内で他のエージェントまたはエンドユーザーから直接承認をリクエストできます。払い戻しの承認、例外の承認、またはソフトウェアアクセスリクエストなどを考えてください。
ナレッジベースの記事承認は、ヘルプセンターのコンテンツに編集ワークフローを提供します。ライターが記事を送信し、エディターがレビューし、承認されるまで何も公開されません。
ネイティブの承認機能は、ZendeskのProfessional、Enterprise、およびEnterprise Plusプランで利用できます。TeamまたはGrowthプランをご利用の場合は、手動による回避策(これについては後述します)を構築するか、サードパーティアプリを使用する必要があります。
一般的なユースケースは次のとおりです。
- 特定のしきい値を超える払い戻しの処理
- ソフトウェアまたはシステムアクセスの許可
- 従業員の休暇または経費リクエストの承認
- ヘルプセンターの記事の公開
- 顧客からの機密性の高い問題のエスカレーション
開始するために必要なもの
設定に入る前に、次のものが揃っていることを確認してください。
- ネイティブの承認リクエストには、Zendesk Suite Professionalプラン以上
- ナレッジベースの承認ワークフローには、Zendesk Enterpriseプラン
- 承認設定とチケットフォームを構成するための管理者アクセス
- 明確に定義された承認プロセス(誰が何をいつ承認するか)
TeamまたはGrowthプランをご利用の場合でも、グループ、マクロ、およびビューを使用して承認のようなワークフローを構築できます。このアプローチについても説明します。
ネイティブのZendesk承認リクエストの設定
Zendeskの組み込みの承認機能を有効にして構成する方法について説明します。
ステップ1:Zendeskで承認リクエストを有効にする
まず、管理設定で承認機能をオンにする必要があります。
管理センター > オブジェクトとルール > 承認に移動します。承認リクエスト設定を「オン」に切り替えます。
ここで、デフォルト設定を確認します。
- エージェントが承認リクエストを取り下げることができるかどうかを決定します
- 通知設定を構成します
- デフォルトの承認リクエストテンプレートを設定します
有効にすると、対象プランのすべてのエージェントがエージェントワークスペースで承認リクエスト機能を利用できるようになります。
ステップ2:チケットフォームに承認ステータスフィールドを追加する
承認が正しく機能するためには、「承認ステータス」フィールドをチケットフォームに追加する必要があります。このフィールドは、チケットに保留中、承認済み、または拒否済みの承認リクエストがあるかどうかを自動的に追跡します。
管理センター > オブジェクトとルール > チケットフォームで、承認を利用可能にするフォームを選択します。各フォームに「承認ステータス」フィールドを追加します。

アカウントに複数のチケットフォームがある場合は、承認を利用可能にする各フォームにこのフィールドを追加する必要があります。このフィールドはエージェントに対して読み取り専用です(承認アクティビティに基づいて自動的に更新されます)。
ステップ3:最初の承認リクエストを作成する
エージェントが日々の業務で実際に承認をどのように使用するかを見てみましょう。
エージェントワークスペースで任意のチケットを開きます。右側のコンテキストパネルで承認リクエストアイコンを探します。それをクリックし、承認リクエストを作成を選択します。

承認リクエストに記入します。
- 承認者:個々のエージェント、グループ(30人未満のグループのみ)、またはエンドユーザーを選択します
- 件名:リクエストされている内容の簡単な説明(最大500文字)
- 説明:承認者が決定を下すために必要な詳細(最大2,500文字)
留意すべき重要な制約:
- 承認者はチケットリクエスターであってはなりません
- 30人を超えるエージェントのグループは承認者として選択できません
- チケットごとにアクティブな承認リクエストは一度に1つのみ
- チケットごとに最大50件の非アクティブ(完了済み)の承認
承認リクエストを送信をクリックします。チケットのステータスが保留中の承認を反映するように変更され、承認者はメール通知を受け取ります。
ステップ4:承認に応答して管理する
承認リクエストが送信されたら、応答が必要です。その方法については、誰が承認するかによって異なります。
エージェント承認者は、エージェントワークスペースで直接応答します。承認、拒否、またはコメントの追加(リクエストごとに最大40件のコメント、それぞれ500文字)が可能です。

エンドユーザー承認者は、ヘルプセンターを通じて応答します。リクエストを表示して応答するためのリンクが記載されたメールが届きます。エンドユーザーが承認リクエストを表示するには、ヘルプセンターがコペンハーゲンテーマ(または承認機能が有効になっているカスタムテーマ)である必要があることに注意してください。
リクエストを作成したエージェントは、決定の通知を受け取ります。チケットの承認ステータスフィールドが自動的に更新され、プロセス全体が監査目的でチケットイベントに記録されます。
リクエストをキャンセルする必要がありますか?リクエストエージェントとチケット担当者の両方が、応答される前に承認リクエストを取り下げることができます。
手動による承認ワークフローの作成(すべてのプラン向け)
ProfessionalまたはEnterpriseプランをご利用ではありませんか?Zendeskの標準機能を使用して、承認のようなプロセスを構築できます。ここでは、グループ、マクロ、およびビューを使用して承認をシミュレートするワークフローを示します。
このアプローチは、部門間の承認に適しています。たとえば、サポートチームが500ドルを超える払い戻しについて財務部門の承認を必要とする場合を考えてみましょう。
グループを設定する:「サポート」グループと「財務承認」グループを作成します。
マクロ#1(承認リクエスト)を作成する:次のマクロを作成します。
- 承認が必要な内容を説明する内部メモを追加します
- チケットを財務承認グループに割り当てます
- 「needs_approval」のようなタグを追加します
- オプションでステータスを「保留中」に変更します
承認者のビューを作成する:財務部門はレビューを待っているチケットを確認する必要があります。次のビューを作成します。
- 財務承認グループに割り当てられたチケット
- 「needs_approval」のタグが付いている
- 優先度とリクエスト日でソート
マクロ#2(承認応答)を作成する:財務部門はこれを使用して応答します。
- 承認決定を含む内部メモを追加します
- チケットをサポートグループに再割り当てします
- 「needs_approval」タグを削除します
- レポート用に「approved」または「denied」タグを追加します
この回避策では、ネイティブの承認よりも多くの手動調整が必要ですが、Zendeskのすべてのプランで機能します。主な欠点は、承認決定の組み込み監査証跡がないことです(内部メモに依存しています)。
ナレッジベースの記事承認ワークフロー
Zendeskを技術ドキュメントまたはヘルプセンターコンテンツに使用している場合は、編集ワークフローが必要になる場合があります。利用可能な機能は次のとおりです。
ネイティブKBワークフロー(Enterpriseプランのみ):
- 記事のレビューおよび承認ワークフロー
- 再利用可能な承認済みコンテンツのコンテンツブロック
- バージョン履歴とロールバック機能
- スケジュールされた公開
注意点:レビュープロセスに関与するすべての人がエージェントライセンスを必要とします。主題の専門家がZendeskエージェントでない場合、追加のシートの料金を支払わずにワークフローに含めることはできません。
制限事項:一度に1人しか記事を操作できません。専用のドキュメントツールとは異なり、共同編集はありません。
ドキュメントワークフローを真剣に考えているチームは、Zendeskのナレッジベースが適切なツールであるかどうかを検討してください。Paligoの分析が指摘しているように、Zendeskはカスタマーサポート向けに構築されており、技術ドキュメント向けではありません。コンテンツのニーズが複雑な場合は、専用のCCMS(コンポーネントコンテンツ管理システム)の方が適している場合があります。
サードパーティアプリによる承認の拡張
ネイティブ機能が不十分な場合は、サードパーティアプリでギャップを埋めることができます。SweetHawkのApproveアプリは最も人気のあるオプションであり、Amazon、eBay、MongoDBを含む12,000を超える組織で使用されています。

Approveアプリは、Zendeskがネイティブに提供していない機能を追加します。
| 機能 | ネイティブZendesk | SweetHawk Approve |
|---|---|---|
| 複数ステップの承認 | ❌ | ✅ |
| エージェント以外の承認者 | ❌ | ✅ |
| 自動トリガー | ❌ | ✅ |
| エスカレーションパス | ❌ | ✅ |
| 承認中のフィールドロック | ❌ | ✅ |
| カレンダー連携 | ❌ | ✅ |
価格:Approveアプリの費用はエージェントあたり月額8ドルです。高度なワークフローを必要とするチームにとって、これはZendesk Enterpriseにアップグレードするよりも価値があることがよくあります。
主なユースケース:従業員の休暇リクエスト。リクエストはまず従業員のマネージャーに送信され、承認された場合は人事部に送信されます。マネージャーも人事部も参加するためにZendeskライセンスは必要ありません。承認されると、休暇は会社のカレンダーに自動的に同期されます。
Zendesk承認ワークフローのベストプラクティス
ネイティブ機能を使用しているか、サードパーティアプリを使用しているかに関わらず、これらのプラクティスを使用すると、承認プロセスをスムーズに実行できます。
承認チェーンを短く保つ。追加の承認者はすべて潜在的なボトルネックです。リクエストに3人の承認が必要な場合は、代わりに権限を持つ1人が決定できるかどうかを検討してください。
明確で説明的な件名を使用する。承認者は、リクエスト全体を開かなくても、何が要求されているかを理解する必要があります。「払い戻しの承認が必要です:2,400ドルのエンタープライズ顧客」は、「承認してください」よりも優れています。
応答時間の期待値を設定する。承認者はどのくらいの速さで応答する必要がありますか?これを明確に定義し、チームに伝えます。SweetHawkアプリを使用すると、承認者が定義された時間内に応答しない場合に自動エスカレーションを設定できます。
プロセスを文書化する。承認が必要なもの、誰が承認するか、および使用する基準を書き留めます。これは、新しいチームメンバーを支援し、一貫性を確保するのに役立ちます。
メトリクスを追跡およびレビューする。レポートの承認ステータスフィールドを使用して、ボトルネックを特定します。特定の承認者が一貫して遅いですか?承認リクエストは特定の時間に積み上がっていますか?
ルーチンな決定にAIを検討する。すべての承認に人間が必要なわけではありません。基準が明確で一貫している場合、AIエージェントはルーチンな承認を自動的に処理する可能性があります。
AI搭載ソリューションによる承認の合理化
考慮すべきことがあります。実際には、より複雑な承認ワークフローが必要ですか、それともそもそも承認が必要なものを減らす必要がありますか?
多くの承認リクエストは予測可能なパターンに従います。正当な理由のある100ドル未満の払い戻しは、95%の確率で承認されます。標準のソフトウェアアクセスリクエストは、ほぼ常に許可されます。AIシステムがこれらの決定を一貫して正しく行うことができれば、承認のボトルネックを完全に排除できます。
これは、eesel AIが異なるアプローチを取る場所です。より複雑な承認チェーンを構築する代わりに、チームが決定自体を自動化するのを支援します。

仕組みは次のとおりです。
まず、eeselがエージェントレビュー用の応答を下書きすることから始めます。AIがビジネスを学習するにつれて、エスカレーションが必要なものとそうでないものを理解するのが得意になります。最終的には、eeselにルーチンなリクエストを自律的に処理させ、人間の判断が本当に必要なエッジケースのみをエスカレーションさせることができます。
その結果、キューを詰まらせる承認リクエストが減り、解決時間が短縮され、チームは実際に専門知識を必要とする複雑な問題に集中できます。
AIと従来の承認を検討するタイミング:
- ビジネスに大きな影響を与えるハイステークスの決定には、従来の承認を使用します
- 明確な基準のあるルーチンでリスクの低い決定には、AI自動化を検討します
- 多くのチームは両方を使用します。AIは簡単なケースを処理し、人間は例外を処理します
よくある質問
この記事を共有

Article by
Stevia Putri
Stevia Putri is a marketing generalist at eesel AI, where she helps turn powerful AI tools into stories that resonate. She’s driven by curiosity, clarity, and the human side of technology.



